search

opengeospatial / ogc-geosparql

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

separate geometry properties for coordinates and type #42

Open FransKnibbe opened 3 years ago

FransKnibbe commented 3 years ago

This issue corresponds with OGC Standards tracker request 659

A geometry can be considered as consisting of different elements (properties), at least the following: 1) Coordinate Reference System (CRS) 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)

None of these properties should be mandatory in a description of a geometry.

Addings some of these properties is already covered by other change requests for GeoSPARQL. That is why this request is for adding extra properties to the geometry class for geometry type and the coordinate array. Having them available as separate properties will allow for publication of data where one of the properties is unknown, and will improve data selection and reasoning capabilities of data stores.

situx commented 3 years ago

I think there could be a dimension value of 4 if we include measurement coordinates which are defined in WKT (https://en.wikipedia.org/wiki/Well-known_text_representation_of_geometry) (and I believe also in WKT literals?)

FransKnibbe commented 3 years ago

@situx: thank you for drawing attention to linear referencing. True, in WKT the measurement value (M) acts as a possible fourth or third coordinate. But in terms of a spatial ontology my feeling is that it seems best to treat measurements on a spatial object as something separate from the spatial shape. I don't think any particular data serialization (such as WKT) should influence the core ontology. It seems issue 21 is a good starting point for discussing how linear referencing should be modelled exactly.

nicholascar commented 3 years ago

..extra properties to the geometry class for geometry type and the coordinate array...

The ontology already defines a property for coordinate array: geo:hasSerialization. This is the super property of the more commonly used geo:asWKT and geo:asGML.

The property definition reads "Connects a geometry object with its text-based serialization." and this is better than saying coordinates as some geometries done use coordinates but ordinates (e.g. DGGS lists of Cell IDs) however all are amenable to "text-based serialization".

I will suggest elsewhere that we re-focus on this property and avoid declaring a property per serialization type like geo:asWKT so that we can instead focus on a vocab of "text-based serializations" data types to be published as another profile artefact by the Naming Authority alongside the ontology, but one that can be grown independently of the ontology revision cycle.

FransKnibbe commented 3 years ago

@nicholascar: good to point out that ordinates could also be used - I have edited the issue to reflect that.

Still I think that the actual array of (co)ordinates is different from its text serialization. At least for some use cases and sufficiently small geometries it is worthwhile to have access to the array as a subgraph / an ordered list.

nicholascar commented 3 years ago

Still I think that the actual array of (co)ordinates is different from its text serialization.

Oh, I see, you're suggesting another property then. So a Geometry would have options for representation: a text representation (GML/WKT/other) as defined by a datatype microformat (datatypes in a vocab) and more consistently presented array (coordinates/ordinates).

Hmmm... I wonder about this... I've seen this geometry-elements-as-rdf-nodes issue raised before (in the Spatial Data on the web WG). Will need serious thought!

FransKnibbe commented 3 years ago

Thinking about RDFS entailment extensions for WKT and GML (see issue 62) made me think that instead of having a type property for geometry, geometry types could be added to the GeoSPARQL ontology as a class hierarchy, similar to the Simple Features model. For instance: GeometryCollection is a subclass of Geomety and Multipoint is a subclass of GeometryCollection. That would allow more versatile SPARQL queries and advanced reasoning.

dr-shorthair commented 3 years ago

the actual array of (co)ordinates is different from its text serialization

In ISO 19107:2003 (an older version which I have access to) there was a class GM_PointArray which is then used in the context of geometries of various types. I'm not sure if it was carried over or replaced with something different in later versions.