problems with Geospatial props

VladimirAlexiev commented 1 month ago

[ ] 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.

onthebreeze commented 1 month ago

ok, fair point about ordering of coordinates in a boundary. will have a look at this with the next PR

But google API seems to get away fine with an implied ordering. https://developers.google.com/maps/documentation/javascript/shapes#polylines. If it's good enough for google isnt it good enough for us?

Fak3 commented 1 month ago

That google API uses plain json array which preserves order. In json-ld we have to tell the underlying rdf model that it should honor the order of Json array, by adding to the context:

boundary: {
   @id: untp-core:boundary
   @container: @list
}

VladimirAlexiev commented 1 month ago

@onthebreeze it is not UNTP's business to devise geospatial representations. This is a complex area that is worked out comprehensively by OGC. So please use GeoSPARQL.

onthebreeze commented 1 month ago

it's also UNTPs goal to keep things strictly as simple as possible. I don't think we should do anything that requires any implementer to use semantic repositories etc. If the world's most ubiquitous mapping tools get away with a simple coordinate array then it's hard to understand why we must impose extra complexity. What's wrong with @Fak3 suggestion above https://github.com/uncefact/spec-untp/issues/124#issuecomment-2233837859 ?

VladimirAlexiev commented 1 month ago

If the world's most ubiquitous mapping tools get away with a simple coordinate array

These tools use WKT, GML, KML, GeoJSON... They don't know your untp-core:boundary definition.

Also, you don't specify any CRS.

The default is WGS84, but it's not suitable for regions closer to the poles
and not suitable for engineering survey (eg to check that a plant really falls within a prescribed land plot). For that, people use easting/northing systems. Eg check out https://epsg.io/25833

GeoSPARQL 1.0 supports WKT and GML (prop geo:asWKT and datatype geo:WKTLiteral etc). GeoSPARQL 1.1 supports KML, GeoJSON, and DGGS.

What's wrong with @container: @list

rdf:List is a pretty bad data structure. Eg do you know how to extract all list members in order with SPARQL?

onthebreeze commented 3 weeks ago

I'm not sure how to proceed with this one. I understand that formal geospatial engineering systems need a lot of rich formality such as provided by OGA standards.

But schema.org says https://schema.org/GeoShape where a polygon is a text field described as a list of coordinate pairs where first and last are the same - doesnt even specify coordinate syntax or reference system.

GeoJSON references IETF - which defines a polygon as https://datatracker.ietf.org/doc/html/rfc7946#page-23. It also defines WGS84 as the coordinate system so no need to repeat that is using GeoJSON. Example

{
         "type": "Polygon",
         "coordinates": [
             [
                 [100.0, 0.0],
                 [101.0, 0.0],
                 [101.0, 1.0],
                 [100.0, 1.0],
                 [100.0, 0.0]
             ]
         ]
     }

Here we are back to an ordered list with same beginning and end. I know that JSON-LD does not support ordered arrays but the reality here is that 99% of implementers wont even look at JSON-LD, they'll follow the schema.

One problem is that I dont see a namespace in the GeoJSON specification. Only an IANA type https://datatracker.ietf.org/doc/html/rfc7946#section-12 - which sort of implies that the entire http payload is GeoJSON rather than just a little part of a Facility location description.

Maybe for now we use the GeoJSON structural model and figure out separately how to define the JSON-LD context that says "this is GeoJSON"

VladimirAlexiev commented 3 weeks ago

But schema.org says ... doesnt even specify coordinate syntax or reference system.

Don't repeat Schema's follies! It's not made by gods, and humans are fallible.

it's also UNTPs goal to keep things strictly as simple as possible

That's a legit goal. So:

First define your geospatial requirements as I outlined above
Then use subsets of existing standards (an "application profile")

GeoJSON ... defines WGS84 as the coordinate system so no need to repeat that is using GeoJSON. Example

GeoJSON doesn't allow any other SRS. Yes, that's the default SRS in GeoSPARQL as well, but see https://github.com/opengeospatial/ogc-geosparql/issues/545 on cases where it's a bad choice.

Do you have any proof that GeoJSON is the "most popular" geometry format?

I don't think we should do anything that requires any implementer to use semantic repositories

Ok! GeoSPARQL literals are simple strings that support these representations: WKT, GML, KML, GeoJSON, DGGS. You don't need a semantic repository to process them: just get them from the JSON and process them any way you like. It is even possible to have a GeoJSON literal string be expanded as JSON and embedded in the total JSON, see https://github.com/w3c/json-ld-syntax/issues/425: this uses @json.

uncefact / spec-untp

problems with Geospatial props #124