search

opengeospatial / ogc-geosparql

Public Repository for the OGC GeoSPARQL Standards Working Group
77 stars 20 forks source link

Define precedence order of inCRS v. Literal CRS #82

Open nicholascar opened 3 years ago

nicholascar commented 3 years ago

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 commented 3 years ago

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.

situx commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

FransKnibbe commented 3 years ago

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

Ideally people would be making use of an ontology for spatial reference systems. Something like http://data.ign.fr/def/ignf/20190213.htm (English documentation here). That would make all reference systems comparable (have a common way of getting the unit or the axis orientation for example). So then we could have a Geometry property hasSRS with a range like srs:Srs or geo:Srs (i.e. an SRS description in a separate ontology or in GeoSPARQL itself).

FransKnibbe commented 3 years ago

@mathib, thank you the comments.

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).

I agree, and such a class is not necessary if hasCRS/inCRS/hasSRS is strictly a property of Geometry.

Is it also not the case that GeoSPARQL v1.0, dictates/assumes to only have one geometry literal per geo:Geometry instance?

At the moment I am not aware of such a dictate or assumption. Indeed, I can easily imagine a data publisher offering multiple data formats for the users' convenience (some users prefer WKT, others prefer GML).

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 .

The funny thing about this pattern is that it implies that there are two fundamentally different geometries. While in fact only their serialisation, which is supposed to be a recoded description of the object, differs.

In the matter of geometry literals (serialisations), I think it is best to have as little influence as possible of serialisation's peculiarities on the ontology. Anyway, if more guidance is needed in this area, perhaps another change request is needed.

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.

So that means we are in agreement that the subject of this issue (precedence order of CRS specifications) is a non-issue (if inCRS is redefined to apply to Geometry)?

mathib commented 3 years ago

The funny thing about this pattern is that it implies that there are two fundamentally different geometries. While in fact only their serialisation, which is supposed to be a recoded description of the object, differs.

But when you're creating another serialisation of a geometry, more than often this introduces (small but sometimes also larger) changes such as rounding errors, simplifications or not converted/serialised aspects of the original geometry. Consequently, some metadata aspects might change (resolution for example, or even CRS if the geometry serialisation format is limited to a specific CRS). Therefore, I would argue that each geo:Geometry instance can only have one geometry serialisation.

So that means we are in agreement that the subject of this issue (precedence order of CRS specifications) is a non-issue (if inCRS is redefined to apply to Geometry)?

Hmm, I think that issue still stands independently from this discussion (at least for GeoSPARQL v2.0, as in v1.1 it will only be used as optional annotation to assure backwards compatibility). Each geometry format/serialisation has some pecularities regarding CRS (fixed, user configurable, default or not, no CRS at all...) and the way these geometries are created is often separated from the inclusion of such geometry data in a Linked Data environment. Agreements on precendence order will be necessary for a smooth spatial querying of geometries in different CRS and geometry formats.

situx commented 3 years ago

Referring to Frans comment: The issue is not resolved in my opinion:

  1. GeoSPARQL allows to assign multiple literals to a Geometry either of different literal serializations or of the same type (why not have several WKT literals assigned to one geometry?). At least I currently do not know that this would be restricted in the standard.
  2. The literals do not have to be in the same CRS, at least I would not know of such a restriction

So the issue of precedence is still relevant even if we restrict inCRS to a domain of Geometry

FransKnibbe commented 3 years ago

Hi @situx,

My idea is that the situation could be resolved if inCRS is defined as a property of Geometry instead of a serialisation of a Geometry.

(why not have several WKT literals assigned to one geometry?).

That would be strange. And what could be the reason for doing that? Which parts of those WKT literals could be different, when they both are recoding the same geometry?

  1. The literals do not have to be in the same CRS, at least I would not know of such a restriction They would have to be if inCRS (or another name like hasSRS) indicates the SRS of the geometry. The spatial reference system is a fundamental , defining characteristic of a geometry, Transformation to a different SRS leads to a new geometry.

Of course serialisations of a geometry with a different CRS could still be published, That would constitute a data error. But other than providing clear and thorough documentation the ontology does not need safeguards against such mistakes, I think.

situx commented 3 years ago

A reason for two WKT literals could be that the same geometry is captured in a less precise version and a more precise version or with different CRS systems (one in WGS84, one in EPSG:25833).

We had usecases like this before because GeoSPARQL does not provide a function to convert between different CRS systems. We used a WGS84 WKT literal to serve a web frontend and a EPSG:25833 WKT Literal to serve a WFS service. My point is that the standard does not exclude it for now.

Referring to your last point, yes if we:

  1. Define that a geo:Geometry and all its serializations have to be represented in the same CRS - the one determined by geo:inCRS, then you are right.
  2. What you refer to as a data error, I think we have referred to as precedence. So what you suggest I believe is to give the geo:inCRS property precedence So for example: If geo:inCRS is defined as WGS84, but the CRS defined in the literal says it is EPSG:25833, then you would like a system to either assume that the Geometry is encoded in WGS84 or to check the literal for a CRS and raise an error, correct?

For me this is important to be clarified because we should clearly define what happens in these cases to be able to properly test implementations of GeoSPARQL 1.x or 2.x versions which ultimately will have to deal with these issues.

FransKnibbe commented 3 years ago

A reason for two WKT literals could be that the same geometry is captured in a less precise version and a more precise version or with different CRS systems (one in WGS84, one in EPSG:25833).

We had usecases like this before because GeoSPARQL does not provide a function to convert between different CRS systems. We used a WGS84 WKT literal to serve a web frontend and a EPSG:25833 WKT Literal to serve a WFS service. My point is that the standard does not exclude it for now.

I think the standard at this moment does exclude having multiple reference systems for one geometry. The definition of the Geometry class is " ... This class is equivalent to the UML class GM_Object defined in ISO 19107. ..." And if we go to the definition of GM_Object, we see " ... GM_Object instances are sets of direct positions in a particular coordinate reference system ...". So one Geometry instance uses one CRS.

Misunderstandings can occur easily because at the moment the core classes of GeoSPARQL (Geometry, Feature and SpatialObject) are not clearly defined. That is the reason I raised issue 10.

Referring to your last point, yes if we:

  1. Define that a geo:Geometry and all its serializations have to be represented in the same CRS - the one determined by geo:inCRS, then you are right.
  2. What you refer to as a data error, I think we have referred to as precedence. So what you suggest I believe is to give the geo:inCRS property precedence So for example: If geo:inCRS is defined as WGS84, but the CRS defined in the literal says it is EPSG:25833, then you would like a system to either assume that the Geometry is encoded in WGS84 or to check the literal for a CRS and raise an error, correct?

For me this is important to be clarified because we should clearly define what happens in these cases to be able to properly test implementations of GeoSPARQL 1.x or 2.x versions which ultimately will have to deal with these issues.

I think we do not need to bother with literals representing Geometry serialisations in compliance tests, In any test, they can be regarded as opaque strings. We can indicate which specification applies to which serialisation, but I think it should end there. I think it stands to reason to expect that any serialisation is a faithful representation of the data object it encodes. In practice, I don't think a CRS mismatch will easily occur, at least not when there is a CRS property available that any procedure to encode serialisations can use as input.

FransKnibbe commented 3 years ago

But when you're creating another serialisation of a geometry, more than often this introduces (small but sometimes also larger) changes such as rounding errors, simplifications or not converted/serialised aspects of the original geometry. Consequently, some metadata aspects might change (resolution for example, or even CRS if the geometry serialisation format is limited to a specific CRS). Therefore, I would argue that each geo:Geometry instance can only have one geometry serialisation.

@mathib: Good to have these talks! It seems it is easy to have slightly different ideas about fundamentals, so it is good for those differences to surface. My idea of geometry is that it has at least the following (non-mandatory) properties (also see issue 42):

  1. Spatial Reference System (SRS) used
  2. Geometry type (line, polygon, multipolygon, ...)
  3. An array of (co)ordinates
  4. Dimension (0, 1, 2 or 3)
  5. Spatial resolution (level of detail)

If any of these uniquely defining characteristics is different, geometry instances can not be equal. Of course not all of the properties are part of GeoSPARQL at the moment, but that does not change the approach.

So in my line of thinking, it is possible to have multiple serialisations of a single geometry, as long as they do not change any fundamental geometry property value. Even if at the moment we do not have a property for a set of coordinates (direct positions in the GM_Object definition), the coordinates still are a defining attribute of a geometry. So serialisations with slightly different coordinate values should not be possible.

situx commented 3 years ago

A reason for two WKT literals could be that the same geometry is captured in a less precise version and a more precise version or with different CRS systems (one in WGS84, one in EPSG:25833). We had usecases like this before because GeoSPARQL does not provide a function to convert between different CRS systems. We used a WGS84 WKT literal to serve a web frontend and a EPSG:25833 WKT Literal to serve a WFS service. My point is that the standard does not exclude it for now.

I think the standard at this moment does exclude having multiple reference systems for one geometry. The definition of the Geometry class is " ... This class is equivalent to the UML class GM_Object defined in ISO 19107. ..." And if we go to the definition of GM_Object, we see " ... GM_Object instances are sets of direct positions in a particular coordinate reference system ...". So one Geometry instance uses one CRS.

Misunderstandings can occur easily because at the moment the core classes of GeoSPARQL (Geometry, Feature and SpatialObject) are not clearly defined. That is the reason I raised issue 10.

Referring to your last point, yes if we:

  1. Define that a geo:Geometry and all its serializations have to be represented in the same CRS - the one determined by geo:inCRS, then you are right.
  2. What you refer to as a data error, I think we have referred to as precedence. So what you suggest I believe is to give the geo:inCRS property precedence So for example: If geo:inCRS is defined as WGS84, but the CRS defined in the literal says it is EPSG:25833, then you would like a system to either assume that the Geometry is encoded in WGS84 or to check the literal for a CRS and raise an error, correct?

For me this is important to be clarified because we should clearly define what happens in these cases to be able to properly test implementations of GeoSPARQL 1.x or 2.x versions which ultimately will have to deal with these issues.

I think we do not need to bother with literals representing Geometry serialisations in compliance tests, In any test, they can be regarded as opaque strings. We can indicate which specification applies to which serialisation, but I think it should end there. I think it stands to reason to expect that any serialisation is a faithful representation of the data object it encodes. In practice, I don't think a CRS mismatch will easily occur, at least not when there is a CRS property available that any procedure to encode serialisations can use as input.

Okay, I see, thanks for clearing this up! And I agree we should make those things more explicit in the standard. Not everyone will bother reading the ISO19107 definitions or may even be able to access them because they are often behind a paywall. We should define essential information like this inside the ontology.

mperry455 commented 3 years ago

Nice discussion. I definitely see the benefits of specifying CRS information as a separate property of the geometry resource vs. embedding CRS info in the geometry literal itself. Among other things, this is helpful for modeling and retrieving geometries based on CRS information.

However, as an implementer, I have some reservations about this. I am mainly thinking of problems around maintaining a spatial index in an OLTP scenario where new triples are being incrementally added or updated.

When a geometry literal is inserted into my triplestore in GeoSPARQL 1.0, I have all the information I need to update a spatial index. I know the type of geometry, the coordinates, and the CRS. I get all of this information in one triple.

If we decouple the CRS from the geometry literal, I don't know the CRS when a geometry literal is inserted. I need to look for some other triples to find this information, which may be missing or not inserted yet. I could even find multiple CRS specifications. Also consider the case where a user updates the :hasCRS property of a set of geometries. Now I have to go back and find all those associated geometries in my spatial index, do a coordinate transformation, and re-index them.

There are workarounds such as ensuring that geometry and CRS information is always modified in a single transaction, etc., but this is really increasing the complexity that implementers need to handle compared to GeoSPARQL 1.0.

FransKnibbe commented 3 years ago

@mperry455: Good to have an implementer's perspective. Some questions, for an even better understanding:

  1. Isn't it common practice for RDBMS-based data stores to allow only one SRS per column? If so, doesn't such a restriction apply to updates in an OLTP scenario?
  2. Or is it possible to define OLTP data receptables in such a way to limit the number of SRS to one? That would not be so unreasonable, since OLTP data input usually has a single source system.
  3. Would it help if the option to declare the SRS at the dataset level (instead of the instance level) is be supported by GeoSPARQL (see issue 104)?
  4. Couldn't an authoritative source of SRS data be pre-loaded into the datastore, just like a SPATIAL_REF_SYS table? When there's an official SRS ontology, it will a small step towards an official SRS dataset based on that ontology. Would that be helpful?
  5. How about the thought that having an SRS property is a step underway to full geometry descriptions being available in RDF? That way there could be OLTP transactions without any other formats that need processing too (WKT, JSON, XML, ...).
  6. Aren't subgraphs like a geometry instance with all of its properties processed as a whole, in one transaction?
  7. Would it be helpful or useful if the data store fills the hasSRS properties if they aren't defined yet, based on the geometry literal?
  8. In GeoSPARQL 1.0 Geometry instances can have properties geo:dimension, geo:spatialDimension and geo:coordinateDimension. Don't those properties pose similar problems to the spatial index?
mperry455 commented 3 years ago

@FransKnibbe Sorry for the delay in responding. Things have been a bit busy.

My main point is that by decoupling the SRS information from the geometry literal, we are making things harder on implementers. There may be some ways to handle it, but the bottom line is that we are taking something that was easy and making it hard.

Isn't it common practice for RDBMS-based data stores to allow only one SRS per column? If so, doesn't such a restriction apply to updates in an OLTP scenario?

In Oracle's implementation, you create a spatial index for an RDF dataset. At index creation time, you specify the target SRS for the index. As you can imagine, a relational table with an SDO_GEOMETRY column (using the specified SRS) gets created somewhere, and all geometry literals (with encoded SRS info) are transformed to the target SRS and stored in that table. When new geometry literals are inserted, they are also transformed to the target SRS and stored in that table. So basically you can have an RDF dataset with geometry literals in several different serializations and also using different spatial reference systems that are normalized to a common SRS and representation (SDO_GEOMETRY) for processing.

Or is it possible to define OLTP data receptables in such a way to limit the number of SRS to one? That would not be so unreasonable, since OLTP data input usually has a single source system. Would it help if the option to declare the SRS at the dataset level (instead of the instance level) is be supported by GeoSPARQL (see issue 104)?

Wouldn't this be more restrictive than what we already have with the GeoSPARQL 1.0 implementation described above? Now the burden would be on the user instead of the system to ensure that all his or her geometry literals are pre-transformed to a common SRS.

Couldn't an authoritative source of SRS data be pre-loaded into the datastore, just like a SPATIAL_REF_SYS table? When there's an official SRS ontology, it will a small step towards an official SRS dataset based on that ontology. Would that be helpful? How about the thought that having an SRS property is a step underway to full geometry descriptions being available in RDF? That way there could be OLTP transactions without any other formats that need processing too (WKT, JSON, XML, ...).

This would be nice in a pure RDF world, but playing a bit of devil's advocate here, most (if not all) GeoSPARQL implementations will be built on existing GIS libraries or spatial database software, and these systems already have pre-loaded definitions of common SRSs and there are already standard ways to encode the definitions for exchange (e.g. WKT). How useful will it be to have another SRS specification that will simply be mapped to some SRID number or WKT encoding that the system already understands.

Aren't subgraphs like a geometry instance with all of its properties processed as a whole, in one transaction?

I don't think this is a safe assumption to make as an implementer.

Would it be helpful or useful if the data store fills the hasSRS properties if they aren't defined yet, based on the geometry literal?

We have a getSRID() function already defined in GeoSPARQL 1.0 that could be used in a query or as part of a SPARQL Update statement to add these properties if desired.

In GeoSPARQL 1.0 Geometry instances can have properties geo:dimension, geo:spatialDimension and geo:coordinateDimension. Don't those properties pose similar problems to the spatial index?

These properties could lead to some inconsistencies, but, at least in Oracle's implementation, the WKT or GML literal is treated as the source of truth.

situx commented 3 years ago

I think we need a solution to define coordinate reference systems which are currently not included in any of the databases such as EPSG and the likes. I would also expect future triple store implementations to support those and I would expect them to pick them up from an RDF graph if necessary. Currently, this is not possible unless you run your own registry and the definition is given in the implementation of your choice. By defining it in RDF we can provide such options, be it via WKT Literal, Proj4 literal, or purely in RDF. The advantage from my point of view to define it purely in RDF could be that a user may want to choose a CRS for their data with specific properties which could be asked for in a SPARQL query. For example: "I want a CRS that is projected and uses meters as a unit which area of validity intersects with my area of interest as defined by BOUNDINGBOX"

mperry455 commented 3 years ago

@situx This is a good use case for a queryable CRS repository. It can be done today in vendor-specific ways, for example with the SDO_COORD_REF_SYS table in Oracle Spatial, but this is not open and interoperable like a standard RDF solution would be.

FransKnibbe commented 3 years ago

In GeoSPARQL 1.0 Geometry instances can have properties geo:dimension, geo:spatialDimension and geo:coordinateDimension. Don't those properties pose similar problems to the spatial index?

These properties could lead to some inconsistencies, but, at least in Oracle's implementation, the WKT or GML literal is treated as the source of truth.

This brings us back to the original question: Which is the source of truth, the geometry literal or its other properties? It is an issue more general than only SRS. And more properties for Geometry can be expected (spatial resolution for example).

situx commented 3 years ago

As we have decided to not include inSRS in GeoSPARQL 1.1, I set the target release of this issue to GeoSPARQL 1.2