problems with Geospatial props
Created by: VladimirAlexiev
-
untp-core:boundary
is inadequate:
untp-core:boundary rdf:type owl:ObjectProperty , rdf:Property ;
rdfs:comment "The list of coordinates that define a closed area polygon as a location boundary." ;
rdfs:label "boundary" ;
schema:domainIncludes untp-core:Location ;
schema:rangeIncludes untp-core:Coordinate .
We need to know the ORDER of points in a polygon but multiple RDF values don't know their order (don't preserve the order in which they were inserted).
Note: https://schema.org/polygon is also inadequate since it doesn't specify the precise string format and CRS.
We need to first define geospatial REQUIREMENTS, eg:
- What coordinate systems are supported
- What geometry kinds are needed (eg can I use arcs?)
Then my advice would be to reuse OGC's GeoSPARQL who have thought this through, and this standard is supported by semantic repositories. GeoSPARQL defines formats like WKT and GML, and a number of geometry kinds.
Example from https://stackoverflow.com/questions/55060508/geosparql-functions-and-spatial-reference-systems-srs, which shows the use of a non-default coordinate system:
geo:asWKT "<https://opengis.net/def/cs/EPSG/0/4499> Polygon((389.0 1052.0, 563.0 1052.0, 563.0 1280.0, 389.0 1280.0, 389.0 1052.0))"^^geo:wktLiteral
-
untp-core:areaReference
"The area of the facility as a URI - typically a plus code (see https://maps.google.com/pluscodes/) " is also not sufficiently defined because there are numerous Geocode systems (see also Discrete_global_grid#Geocoding_variants): OLC (Google Plus Codes), H3 by Uber, Geohash, What3words, Natural Area Code
GeoSPARQL 1.1 includes datatype dggsLiteral
and datatype prop asDGGS
and indicates the specific DGGS system used as a URL preceding the value. The first example is from https://docs.ogc.org/is/22-047r1/22-047r1.html#10-8-5-1-%C2%A0-rdfs-datatype-geo-dggsliteral , the second I made:
geo:asDGGS "<https://w3id.org/dggs/auspix> CELL (R3234)"^^geo:dggsLiteral.
geo:asDGGS "<https://maps.google.com/pluscodes/> M84X+XQ"^^geo:dggsLiteral.
My advice would be to go with GeoSPARQL.