opengeospatial/ogc-geosparql

Geocoding Support in GeoSPARQL

Opened this issue · 6 comments

situx commented

Our group has already received a request from @paulc-dstl to add GeoHash literals to GeoSPARQL.

However, there are more geocoding systems which could be taken into account here.

In fact, a lot of geocoding systems can be resolved to coordinates in either UTM or WGS84-based coordinate reference systems.

My question here:

Would it make sense to maybe define two literal types: "wgs84GeocodingLiteral" and "utmGeoCodingLiteral" and indicate the Geocoding system with a URI definition, similar to how we do it in WKT?

WGS84-based Open Geocoding Systems:

We could curate a list of URIs for well-known geocoding systems which implementers could use.

Or should we proceed with defining GeoHash, and people should create their own literal types outside the standard?

situx commented

As discussed in the last meeting, I will provide possible ways to encode Geocoding types here with the example of a GeoHash.

  1. Using one literal type per geocoding type:
    "u4pruydqqvj"^^geo:geoHashLiteral
  2. Using one literal type per CRS:
    "<http://opengis.net/ont/geosparql/geocoding/geohash> u4pruydqqvj"^^geo:wgs84GeocodingLiteral
  3. Using one literal type per CRS, but encoding it as a separate property
    ex:point rdf:type sf:Point . ex:point geo:in GeoCode <http://opengis.net/ont/geosparql/geocoding/geohash>. ex:point geo:asGeoCode "u4pruydqqvj"^^geo:wgs84GeocodingLiteral
nicholascar commented

I provided an example of catering for just GeoHashes like we do for DGGSes over at Issue #428

VladimirAlexiev commented

There is also Quadtree

jabhay commented

OGC has indicated a willingness to register non-vendor specific or broadly adopted geocode types. I'll track where this conversation leads in this ticket.

  • 👍1
VladimirAlexiev commented

@nicholascar @situx
The current 1.1 spec https://docs.ogc.org/is/22-047r1/22-047r1.html#10-8-5-1-%C2%A0-rdfs-datatype-geo-dggsliteral uses a belt-and-suspenders approach:

  • All RDFS Literals of type geo:dggsLiteral shall consist of an IRI identifying the specific DGGS and a representation of the DGGS geometry data.
  • The specific implementation should be indicated by use of a subclass of the geo:dggsLiteral datatype.

But then the example implements only the first bullet:

geo:asDGGS "<https://w3id.org/dggs/auspix> CELL (R3234)"^^geo:dggsLiteral

Shouldn't this be like:

geo:asDGGS "<https://w3id.org/dggs/auspix> CELL (R3234)"^^<https://w3id.org/dggs/auspix> .
<https://w3id.org/dggs/auspix> a rdfs:Datatype; rdfs:subClassOf geo:dggsLiteral.

I see nothing wrong with using the same URL inside the string, and as a datatype: it's useful if the spec mentions that is legit

situx commented

@nicholascar might correct me on this, but here is my view:

  • Yes, the URI mentioned in the DGGS literal should describe a subclass of the geo:dggsLiteral datatype
  • The description of these types is out of scope of GeoSPARQL and should be stored somewhere else
  • We currently have not defined a place where these definitions live, but they should probably live in the OGC registry
  • For the example, which describes the Literal only it is sufficient to state the contents of the literal and the definition of the datatype is not necessarily required