Geocoding Support in GeoSPARQL

[situx]

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:

• GeoHash
• MapCode
• Natural Area Code
• Open Location Code

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]

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]

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

[VladimirAlexiev]

There is also Quadtree

[jabhay]

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.

[VladimirAlexiev]

@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]

@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

[VladimirAlexiev]

@situx I'm very glad that https://github.com/opengeospatial/ogc-geosparql/pull/537 defines so many geocoding resources! But here are some comments:

• Don't use "slash and hash" in the URL. Use only slash (better than hash because this is a big collection of resources)
• You define them as Individual, but according to the above they should be Datatype?
• Some changes are needed in the spec: fix the example, suggest to use the same URL inside and outside the literal, and point to Geocoding Vocabulary

[situx]

Hi @VladimirAlexiev thanks for the hints.

• I corrected the URIs. We will have to see whether these will be the final URIs accepted by the OGC Naming Authority or if they have other plans. So the URIs are still subject to change anyway
• Geocoding URLs are to be used in the GeoCode Literal that was merged previously. In the definition of the GeoCode Literal there is no mention of the URIs identifying the Geocode System to be a datatype. In my opinion, defining them as Individuals is better. Then they are resolvable in RDF for better accessibility. We currently have some issues building the development version of GeoSPARQL, but you can find the GeoCode Literal definition here (https://github.com/opengeospatial/ogc-geosparql/blob/geosparql-1.3/spec/sections/11-geometry_extension.adoc)
• I am not sure what you mean by example... if you are referring to the DGGS example, this is a different literal type unrelated to the GeoCode Literal

Apart from that @VladimirAlexiev feel free to add suggestions of missing GeoCode Systems you would need to PR #537

[VladimirAlexiev]

@situx Maybe I'm confused here: I assumed that DGGS is a subset of Geocoding (some geocoding systems like What3Words are DGGS but others like postal codes are not).

(DGGS) is a different literal type unrelated to the GeoCode Literal

So your Geocoding contribution is not meant to expand on DGGS as defined in GeoSPARQL? But surely What3Words (for example) is a DGGS?!

In the definition of the GeoCode Literal there is no mention of the URIs identifying the Geocode System to be a datatype.

This quotation from https://docs.ogc.org/is/22-047r1/22-047r1.html#10-8-5-1-%C2%A0-rdfs-datatype-geo-dggsliteral:

The specific implementation should be indicated by use of a subclass of the geo:dggsLiteral datatype.

Sounded to me that each DGGS must define its own datatype, being a subclass of geo:dggsLiteral.

what you mean by example

I meant this example:

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

In my opinion, defining them as Individuals is better.

Ok, so it would look like this:

# your definitions
<http://opengis.net/ont/geocode/AusPIX> a <http://opengis.net/ont/geocode/GeoCode>;
  rdfs:isDefinedBy "..."; 
  rdfs:comment "Cells are defined as... Eg R3234 is decoded by...".

# Instance data
<myGeometry> geo:asDGGS "<http://opengis.net/ont/geocode/AusPIX> CELL (R3234)"^^geo:dggsLiteral

So to understand AusPIX (to get to your RDF definition), one would need a query like:

where {
  ?geo geo:asDGGS ?literal.
  bind(iri(replace(?literal,"^ *<(.*?*)>.*","$1")) as ?dggs)
  ?dggs rdfs:isDefinedBy ?definedBy; rdfs:comment ?definition

If the geocode URL was used as datatype, then we wouldn't need to manipulate strings:

where {
  ?geo geo:asDGGS ?literal.
  bind(datatype(?literal) as ?dggs)
  ?dggs rdfs:isDefinedBy ?definedBy; rdfs:comment ?definition

[nicholascar]

I think @VladimirAlexiev may be right here. We have a legacy of pairs of matching predicates and datatypes:

Predicate	Datatype
asWKT	wktLiteral
asGeoJSON	geoJSONLiteral
asKML	kmlLiteral
asGML	gmlLiteral

which was followed for

Predicate	Datatype
asWKT	wktLiteral

but then we have the CRS/SRS indicator within some of those literals like WKT.

The DGGS type was thought of as being equivalent to an SRS and, I suppose, a GeoCode type is also equivalent because you have to know the SRS/DGGS type/GeoCode type to be able to interpret the literal.

I guess the problem is that there are just multiple dimensions needed to understand the literal:

• type - WKT, GeoJSON, GeoCode etc.
• SRS - present in WKT, could soon be in GeoJSON etc.

The OGC will soon have a much better capability to deliver dynamic registers for anything because of a tooling upgrade within the Rainbow, so they could deliver a sophisticated register of GeoSPARQL geometry serialization types which could include:

• all known GeoCodes
  • mode can be registered
• all known DGGSes
  • more can be registered
  • they may, or may not, be a subset of GeoCodes - GeoSPARQL need not know

We could make a new GeometrySerialization class which could be a specialized datatype that, via a mandated axiom/shape defines all the elements we need to efficiently process geometry literals.

@situx @VladimirAlexiev and others:

• what do you think about a new class of GeometrySerialization and then a super-register of them at OGC Rainbow?
  • collections for each group of types, or subsidary registers can be made

We can then reduce GeoSPARQL's special properties down with a pattern like this:

ex:feature-x
    a geo:Feature ;
    geo:hasGeometry [
        a geo:Geometry ;
        geo:hasSerialization "lots of stuff"^^geo:GeometrySerialization ;  # <-- but really a subclass of GeometrySerialization
    ] ;
.

We can then move to a new phase of validating GeoSPARQL data v. a dynamic register (in OGC Rainbow) which data stored would need to catch in order to ensure that data they are validating is using GeometrySerialization subclasses that they can handle.

[VladimirAlexiev]

Hi @nicholascar ! I think we need to be backward compatible to 1.0 and 1.1. From that point of view, we should keep using Datatypes. These can be organized in a hierarchy if needed.

For DGGS, having the URL both inside the string and outside as datatype is redundant. I vote to have it only outside as that is more explicit.

(For eg WKT, the datatype specifies the overall structure, whereas the CRS specifies how to interpret the numbers. No such need has perspired for DGGS.)

[VladimirAlexiev]

@situx thanks for the explanations in the telco today!

But please take a look at my second comment:

The specific implementation should be indicated by use of a subclass of the geo:dggsLiteral datatype.

This sentence is from the current standard and IMHO is not satisfied by the example (because that uses a specific URL inside the string, but the general geo:dggsLiteral outside.