Define precedence order of inCRS v. Literal CRS

[nicholascar]

Some geometry literal formats contain CRS indicators but now we also have an inCRS property. We need to indicate precendence order in the following places:

1. in the spec
2. in the ontology
   • perhaps with 2 examples for inCRS for literals with, and without CRS indicated

[mathib]

We might need to split the discussion here for each case (geometry format). The spatial data on the web best practices contain a useful appendix regarding the use of CRS in existing geoformats: https://www.w3.org/TR/sdw-bp/#applicability-formatVbp. If OK, I'll try to assemble and maintain the findings of the supported geometry formats and their CRS particularities here. Decisions taken by the group will be added, in other words the summary below might change over time.

• WKT

  • WKT spec: no default CRS; not possible to include CRS in geometry format; 2D and 3D geometry
  • GeoSPARQL 1.0 (and PostGIS): allow the definition of a CRS inside the literal. Default is WGS84 (2D)
  • GeoSPARQL 1.1: backwards compatibility with GeoSPARQL 1.0 required
    • case 1: CRS both inside literal and with inCRS => CRS from literal (backwards compatible) OR CRS from inCRS
    • case 2: CRS only in literal => CRS from literal
    • case 3: CRS only with inCRS => default to WGS84 (backwards compatible) OR CRS from inCRS
    • case 4: no CRS => default to WGS84
  • conclusion: if we want to maintain backwards compatibility with GeoSPARQL 1.0 (target of 1.1 version), the inCRS pattern is of little use for WKT unless for creating a queryable annotation (value of inCRS should be equal to CRS of literal or default CRS). We can't even indicate to favor the inCRS pattern because of the default to WGS84 in GeoSPARQL 1.0.
  • note: For GeoSPARQL 2.0, where backwards compatibility is less of an issue, the pattern with inCRS could entirely replace the current way of modeling (i.e. the CRS inside the literal).

• GeoJSON and KML

  • GeoJSON and KML current spec: 'fixed' CRS (WGS84) according to spec but the KML format can in theory be extended for other CRS; 2D (GeoJSON) and 3D (KML)
  • GeoSPARQL 1.0: did not support GeoJSON and KML so no issues with backwards compatibility
  • GeoSPARQL 1.1:
    • case 1: no CRS => default to WGS84
    • case 2: CRS with inCRS => default to WGS84 OR CRS from inCRS
  • conclusion: since no backwards compatibility is needed with GeoSPARQL 1.0, there's more freedom. On the other hand, GeoJSON/KML modeling and viewing tools will most likely (?) only support WGS84 according to the GeoJSON/KML specs. The inCRS pattern can be used to create a queryable annotation (value of inCRS should be equal to WGS84).
  • note: If a new version of GeoJSON and/or KML give up on a fixed CRS in their specs, it will probably be replaced by a default CRS and an optional override inside the geometry format (thus in the literal). It seems in other words that there's little added value for inCRS?

• GML

  • GML spec: any CRS can be mentioned in the geometry format itself _{even multiple different CRS for different parts of a complex GML geometry?} ; _{I don't know if it's possible to have a valid GML without mentioning a CRS in the geometry format, i.e. is there a spec-wide default CRS in GML?} ; 2D and 3D
  • GeoSPARQL 1.0: CRS according to what's used inside the GML literal
  • GeoSPARQL 1.1: backwards compatibility with GeoSPARQL 1.0 required
    • case 1: CRS both inside GML and with inCRS =>CRS from GML literal (backwards compatible) OR CRS from inCRS
    • case 2: CRS only inside GML => CRS from GML literal
    • case 3: CRS only with inCRS => N/A (not possible according to GML spec?)
    • case 4: no CRS => N/A (not possible according to GML spec?)
  • conclusion: backwards compatibility with GeoSPARQL 1.0 does not allow us to ignore the CRS inside the GML literal. The inCRS pattern can be used to create a queryable annotation (value of inCRS should be equal to CRS of GML literal).

[situx]

Thanks @mathib for the comprehensive overview.

I see two issues here:
First issue is that inCRS for GeoSPARQL 1.1 is merely an annotation and the consistency between what is stated in inCRS and in the literal value cannot be guaranteed as of now.

Second issue is that even if we define inCRS as the new standard for GeoSPARQL 2.0 we will still have possible inconsistencies between CRS defined in literal values and the value defined in the inCRS property, e.g. if you cannot define a GML literal without defining a CRS as well.

We could completely ignore the CRS defined in a literal from GeoSPARQL 2.0 onward no matter what CRS is defined in the literal, but would that not make querying a geometry unnecessarily complicated?

Not sure what is the best solution here. To be discussed

[mathib]

indeed, the bottom-line seems to be that inCRS property can best be used as annotation only in GeoSPARQL v1.1. In a GeoSPARQL v2.0, I believe something as inCRS can be very valuable for geometry formats that don't have a CRS defined inside their own format (PLY, OBJ, glTF, etc). In addition, geometry in the construction/AEC domain is often defined in a custom local CRS, that might not be known to a receiving application or service, thus the possibility for users to define a custom CRS with their own URI might be beneficial. With some additional properties, it's even possible to georeference such a custom local CRS to a shared/known CRS by defining the transformation between the two CRS using RDF triples (e.g. between Cartesian systems, an affine transformation can be defined, see this previous implementation). In my opinion, the application of the transformation to a geometry, is something an software implementation should deal with, i.e. you don't deal with the calculation inside/via SPARQL.

True, if you need to query for the CRS, queries will become slightly longer, but not to the range that they become impractical. In my opinion, this is a little bit similar to how units are modelled for quantiative properties with QUDT in the sense that it's not difficult to query a property and its value (geometry) together with the unit (CRS) while the exectution of calculations/arithmetics/... (spatial transformations) in SPARQL can be very challenging.

[situx]

Yes I second the need to be able to represent local CRS. We have discussed that in the last GeoSPARQL meeting as well.
I started some extraction of of CRS here: https://github.com/situx/proj4rdf
The goal was to create an ontology model for CRS. Could we maybe adjust it for local CRS to find a solution for GeoSPARQL 2.0?

For the query: It could probably be shortened again with RIF rules?

[FransKnibbe]

Sorry, I have been absent for a while (CoViD-19 struck). But I have some questions about inCRS in the already accepted PR for Geox 1. A particular concern is that these additions might block future extensions of the Geometry class (see issue 42) or having a full-fledged CRS ontology (see issue 12). Also I think that geometry serialisations should have as little influence on the ontology as possible.

1. Why is the CRS reference inCRS tied to the literal representation of the geometry? I agree it makes sense to have a CRS property for the Geometry class, but I think it should be a property of the geometry itself.
2. Why is the property named inCRS, not something like hasCRS? I think inCRS is more appropriate if the property would be a property of coordinates, not the geometry as a whole.
3. It is necessary to have properties pertaining to a serialisation of a Geometry, why not isolate the idea of a geometry serialisation as an ontology class?
4. Why is the range skos:Concept?

[situx]

Hi Frans and welcome back!

To answer your first point the property inCRS is not tied to a literal per se but we might strive for consistency with regards to GeoSPARQL 1.1 being backwards compatible to GeoSPARQL 1.0.

With regards to the other points you raised: So you would propose to create a Geometry instance connected to different serialization instances each of which exposing their own CRS definition and Geomertry serialization literal?
Maybe we could discuss this for GeoSPARQL 2.0 but would it not be a breaking change if we introduced this in GeoSPARQL 1.1?

[FransKnibbe]

A solution to the problem could be to rename inCRS to hasCRS and change its definition to something like ¨The Coordinate Reference System (CRS) of the geometry¨

The current description of inCRS reads: ¨The coordinate reference system of the coordinates in the litaral (sic) representation of the geometry.¨ This causes a discordance. The description asserts inCRS is a property of any geometry literal. But the ontology itself defines it as a property of a geometry. Those two are semantically different things. At the moment, there is no such thing as the class of geometry literals. To illustrate the problem: if a geometry instance as three different serialisations (e.g. WKT, GML and GeoJSON), to which one does the inCRS property apply?
That is why one solution could be to add a class for all serialisations to the ontology. But with respect to serialisiations I would like to advocate a cordon sanitaire doctrine: not let peculiarities of serialisations creep in to the main ontology. Serialisations are fleeting constructs in comparison to the long lasting way we view the fundamentals of spatial data.
So I would like to ask if there really is a problem to the suggested change above. A geometry could have serialisations that either (explicitly or implicitly) have a CRS, or have not. If a serialisation specifies a CRS, it is still helpful to have a hasCRS property to identify the CRS, because it helps filtering geometries without having to decode the serialisation. If a serialisation does not specify a CRS, the hasCRS property helps in interpreting the serialisation. In both cases: helpful & no harm done. I suppose it won't break current implementations.

[mathib]

Hi Frans!

Some comments on the discussion

A solution to the problem could be to rename inCRS to hasCRS and change its definition to something like ¨The Coordinate Reference System (CRS) of the geometry¨

I would be OK with such a change in the definition (in line with the current rdfs:domain of geo:inCRS), as it already opens the door to alternative ways for describing geometry in RDF without using literals with embedded geometry (currently saved for GeoSPARQL v2.0). This includes links to external geometry files and RDF-based geometry (GEOM, OntoBREP, geometry part of ifcOWL, etc).

At the moment, there is no such thing as the class of geometry literals. To illustrate the problem: if a geometry instance as three different serialisations (e.g. WKT, GML and GeoJSON), to which one does the inCRS property apply?

To be honest, I'm absolutely not a fan of initiating a class of geometry literals as that would add clutter to datasets without much added value (additional node between the FoI and the literal with the actual geometry). Is it also not the case that GeoSPARQL v1.0, dictates/assumes to only have one geometry literal per geo:Geometry instance? In other words, the following is not allowed (or at least not common):

inst:building1 geo:hasGeometry inst:building1-geoA .
inst:building1-geoA geo:asWKT "content..."^^geo:wktLiteral ;
    geo:asGML "content..."^^geo:gmlLiteral .

To continue, most of the times one geometry is derived from another geometry (e.g. the WKT from the GML), potentially introducing rounding errors or even failing to translate some part of the geometry correctly. Therefore, I think the following pattern is much clearer:

inst:building1 geo:hasGeometry inst:building1-geoA , inst:building1-geoB .
inst:building1-geoA geo:asWKT "content..."^^geo:wktLiteral ;
   geo:derivedFromGeometry inst:building1-geoB . # this prop is not yet defined in GeoSPARQL
inst:building1-geoB geo:asGML "content..."^^geo:gmlLiteral .

A geometry could have serialisations that either (explicitly or implicitly) have a CRS, or have not

I believe every geometry description, i.e. an instance of geo:Geometry with a connected geometry literal (or in GeoSPARQL v2.0 also linked geometry files), is defined in one main CRS, meaning that the CRS ref can be asserted with inCRS, be included in the literal (or fixed in the geometry format spec) or just simply be unknown (open world assumption). In the last case, the geometry description loses much of its value (it cannot be viewed and analysed together with other geometry) but it can still be viewed/used as an independent geometry.

Why is the range skos:Concept?

No idea, but I believe they wanted to indicate that the property points to an individual and not a class, but that information is already included since it's modeled as an owl:ObjectProperty. It would probably make more sense to start defining the semantics of CRS (and custom transformations for registering between two CRS) separatly from the core GeoSPARQL ontology, e.g. as done in the draft proposal of Timo mentioned here earlier. The rdfs:range can then become the geo:CoordinateSystem from Timo's proposal (probably with a different prefix and namespace than GeoSPARQL core).

[dr-shorthair]

Why is the range skos:Concept?

No idea, but ...

The intention was to imply a preference for a value from a controlled or governed set, rather than a definition coined as a one-off. Maybe textual documentation should have been used to say that clearly.

[mathib]

The intention was to imply a preference for a value from a controlled or governed set, rather than a definition coined as a one-off.

That would imply that users cannot assign their own custom coordinate system? I believe it would be really useful to be able to do so, as long as it's also possible to register/georeference the custom coordinate system to a publicly known one