Support GeoHash literals in GeoSPARQL

[jabhay]

As per Official change request: OGC CR 585

We'd like to extend the set of standard serializations of geometry data to include GeoHash by popular demand.

[nicholascar]

Given that there are multiple forms of GeoHash, the implementation of this looks to me like it could be similar to what we have implemented for DGGS, namely we would implement a single asGeoHash property to indicate the serialization and a matching DataType of geoHashLiteral. The implementer would then need to use a microformat like DGGS does :

dggsLiteral ::= iri-and-whitespace dggs-geomety-data

iri-and-whitespace = "<" IRI ">" LWSP

So for a Google Maps has, we might have:

:geom-x
    a geo:Geometry ;
    geo:asGeoHash "<https://w3id.org/geohashes/google-maps> nd8vqswyxMdgFxK46"^^geo:geoHasLiteral ;
.

As per DGGS, this requires the implementation of a Register of GeoHash types or, at the very least, well-known IRIs for major GeoHashes.

The GeoHash website seems to only implement its own has and a Google Maps has so, using what it produces we would, for the point 27 19' 32S, 153 4' 59"E, have:

:geom-x
    a geo:Geometry ;
    geo:asWKT "<https://epsg.io/4326> POINT (153.083056 -27.325556)"^^geo:wktLiteral ;
    geo:asGeoHash 
        "<https://w3id.org/geohashes/geohash> r7hue3x9jepv"^^geo:geoHasLiteral ,
        "<https://w3id.org/geohashes/google-maps> nd8vqswyxMdgFxK46"^^geo:geoHasLiteral ;
.

To then get the Google Maps GeoHash, you would need a SPARQL query like this:

SELECT ?hash
WHERE {
    ?geom geo:asGeoHash ?hash .

    FILTER REGEX(?hash, "^\<https:\/\/w3id.org\/geohashes\/google-maps\>")
}

[paulc-dstl]

I think this is sufficient and comparable to other forms of geometry serialization, which is neat and consistent.

The key requirement from the 4D community is that the geohash needs to be of a form suitable to act as an IRI to identify a chunk of space. Given naming of individuals is outside the scope of GeoSPARQL, i don't see any reason why a geohash couldn't be used in both situations, as part of a datatype literal of type geohash (as indicated above) and used in some form appended to the URIs noted above to act as an identifier for an individual.

[situx]

I also think that this is a good solution.
The only thing we probably need to think about is how we want to deal with GeoHash identifiers when there is a inSRS property.
Maybe we need an associated inGeoHash property there? Or are only GeoHashes that share the same coordinate reference system defined in inSRS eligible?
But maybe this is also sth. for a future release.

[situx]

Some more thoughts:

• Is it still a GeoHash literal if we can put an arbitrary amount of different geocoding encodings in this literal? Should we not be renaming it to sth. like "Geocoding literal"?
• Would it not be useful to encode these Geocodings in RDF like we anticipate to do with the CRS or would we rather only curate a list of Geocoding URIs?
• Who would curate this list of Geocoding variants?

[nicholascar]

It seems GeoCode is the generic form and GeoHash is a particular form, so replace asGeoHash with asGeoCode in my proposal above

[situx]

Since the Geocode Literal has been merged into 1.3 I think this issue is solved