Clarification needed for DGGS literal

[FransKnibbe]

The GeoSPARQL ontology has been extended with a datatype and property for Discrete Global Grid Systems (DGGS):

:asDggsWkt
    a owl:DatatypeProperty ;
    rdfs:subPropertyOf :hasSerialization;
    rdfs:domain :Geometry ;
    rdfs:range :dggsWktLiteral ;
    rdfs:isDefinedBy geosparql: , geosparql-spec: ;
    skos:definition """The Discrete Global Grid System (DGGS) serialization of a geometry"""@en ;   
    skos:prefLabel "as DGGS"@en ;
.
:dggsWktLiteral
    a rdfs:Datatype ;
    rdfs:isDefinedBy geosparql: , geosparql-spec: ;
    skos:definition """A textual serialization of a Discrete Global Grid (DGGS) geometry object."""@en ;
    skos:example """ "<https://w3id.org/dggs/auspix> OrdinateList (R3234)"^^<http://www.opengis.net/ont/geosparql#dggsWktLiteral>""" ;
    skos:prefLabel "DGGS Well-Known Text Literal"@en ;
.

As it stands, I think clarification is needed:

1. The OGC defines a DGGS as a spatial reference system, but GeoSPARQL seems to assume it is a way to describe a geometry. There appears to be a contradiction.
2. There is no (reference to a) definition of a DGGS.
3. There is no reference to a specification of DGGS WKT.

[nicholascar]

@FransKnibbe, I'll try to answer as best I can here:

1. The OGC defines a DGGS as a spatial reference system, but GeoSPARQL seems to assume it is a way to describe a geometry. There appears to be a contradiction.

I don't think there's a contradiction because each DGGS - which is, indeed, a spatial reference system - also includes within its SRS definition how to represent geometries according to it. So each DGGS will have completely different and incomparable ways of presenting geometries, not like the majority of CRSes which have some form of x/y, long/lat coordinate pairs.

So a geometry for DGGS X will require the use of a literal format defined for that DGGS only.

2. There is no (reference to a) definition of a DGGS.

You are right. I refer to the DGGS AS "The form of representation is known as a DGGS Well-Known Text geometry representation and is based on elements of the second version of the DGGS Abstract Specification [DGGSAS]" but forget to define DGGS itself, so I will add that. The Bibliograph) already contains the right reference for this.

3. There is no reference to a specification of DGGS WKT.

You're looking at it, as in it's this spec! That's because it's this spec that is driving the format. The DGGS AS doesn't go there. Since, as per point 1 each DGGS is different, there's not much more that can be said about a DGGS WKT-like literal other than you need the DGGS identified and then the literal values in that DGGS' form, so the format "<" + DGG-IRI + ">" + SPACE + THE-GEOMETRY- LITERAL.

I'll add in a NOTE or similar that explicitly states why no DGGS Wkt spec is referenced.

[FransKnibbe]

@nicholascar: Thank you for explaining. Much is clearer now, but some questions remain...

1. The OGC defines a DGGS as a spatial reference system, but GeoSPARQL seems to assume it is a way to describe a geometry. There appears to be a contradiction.

I don't think there's a contradiction because each DGGS - which is, indeed, a spatial reference system - also includes within its SRS definition how to represent geometries according to it. So each DGGS will have completely different and incomparable ways of presenting geometries, not like the majority of CRSes which have some form of x/y, long/lat coordinate pairs.

Isn't there a difference between a DGGS cell and a Geometry? Please correct me if I am wrong, but the way I imagine DGGSs to be mostly used is to identify a single cell as the location of a spatial thing. For example: My house is in cell such and such. That could be encoded similar to this:

ex:myHouseGeom geo:sfWithin ex:DggsCell_1234.

Is this the same as saying

ex:myHouseGeom geo:asDggsWKT "DGGS_X(1234)"^^geo:dggsWktLiteral?

Can the DGGS serialisation of a geometry be expected to be a truthful depiction of a geometry?

And do we silently expect a DGGS serialisation to always be a single cell, even when it would be more sensible to use a cluster of cells (e.g. as a geometric representation of an elongated feature like the river Nile)?

And what do we expect the SRS of a DGGS geometry (e.g. as identified by the proposed inSRS) to identify? Is it the DGGS itself, or the SRS the DGGS is based on? I would expect it to be the former, with the DGGS specification containing a reference to the 'traditional' SRS it is based on.

Is there some sort of official repository of SRS definitions that people can used as a preferred target for inSRS at this moment?

You are right. I refer to the DGGS AS "The form of representation is known as a DGGS Well-Known Text geometry representation and is based on elements of the second version of the DGGS Abstract Specification [DGGSAS]" but forget to define DGGS itself, so I will add that. The Bibliograph) already contains the right reference for this.

At the moment, http://www.opengis.net/doc/AS/dggs/2.0 does not resolve, but http://www.opengis.net/doc/AS/dggs/1.0 does.

1. There is no reference to a specification of DGGS WKT.

You're looking at it, as in it's this spec! That's because it's this spec that is driving the format. The DGGS AS doesn't go there. Since, as per point 1 each DGGS is different, there's not much more that can be said about a DGGS WKT-like literal other than you need the DGGS identified and then the literal values in that DGGS' form, so the format "<" + DGG-IRI + ">" + SPACE + THE-GEOMETRY- LITERAL.

I'll add in a NOTE or similar that explicitly states why no DGGS Wkt spec is referenced.

So... at the moment it is not so well known, but we expect it to become well known :-)?

I now see that in the example an IRI identifying the SRS (DGGS) is used. That would be similar to putting an SRS IRI in geo:WktLiteral, which I think was a mistake (see issue 31). Don't you think that now a inSRS property is in the pipeline there is even less reason for concatenating two geometry properties that should be kept separate?

Also, the difference between DGGS literals and the other literals we have seems to be important for implementers: For WKT, GML and GeoJSON the specifications are known beforehand, so software can be tailored to handle those formats. In the case of DGGS literals, the specification of how to interpret the literal comes with the literal itself. How can an implementer tell users whether it supports DGGS literals?

All in all, at least for me it is easy to be confused by the new DGGS additions. As often in such a case, some examples in the documentation could be enlightening. I'd be happy to help there (as an expert on not understanding at first).

[dr-shorthair]

Please correct me if I am wrong, but the way I imagine DGGSs to be mostly used is to identify a single cell as the location of a spatial thing.

That is one potential use case.

But more interesting, and ultimately more useful, is to use a higher-level DGGS to describe the actual shape of the house.

The ability to use the hierarchically-nested grid to get to an arbitrary resolution makes it possible to describe an actual geometry, at a chosen level of precision. A complete geometry is a list of DGGS cells. They might be all the same level (resolution) in which case it may be a long list. Else you can mix cells of different levels to reduce the length of the list of cells. And this can apply to boundaries or interiors (curves or surfaces).

[nicholascar]

Can the DGGS serialisation of a geometry be expected to be a truthful depiction of a geometry?

Yes, at whatever resolution you are prepared to record the geometry at, exactly the same as for traditional geometries.

DGGS levels have cells of certain sizes often, but not always, tessellating with the coarser level and there's no theoretical maximum level (smallest size cells) so you can go down to manometer precision, just as you can with a Cartesian coordinate with lots of decimal places.

And do we silently expect a DGGS serialisation to always be a single cell,

No, as Simon says: interesting geometries will be lists of cell IDs for cells at different levels of resolution.

Here is a Feature from a test API that has a DGGS polygon geometry:

http://asgs.surroundaustralia.com/collections/SA1s/items/80101100105

It's a Statistical Area, Level 1, that is an Australian census counting block. Level 1, with ID 80101100105. You can see its geometry on that page given in WGS84 and TB16PIX DGGS. The TB16PIX DGGS geometry is a list of level 11 Cell IDs, e.g. P67303515827 and this is is uncompressed - all the Cells are at the same level. A compressed geometry would aggregate Call IDs up to the next level if all Cell IDs for the parent lie within the geometry.

...even when it would be more sensible to use a cluster of cells (e.g. as a geometric representation of an elongated feature like the river Nile)?

Yes, the above is a cluster for a polygon but you can have linestring clusters too.

And what do we expect the SRS of a DGGS geometry (e.g. as identified by the proposed inSRS) to identify? Is it the DGGS itself, or the SRS the DGGS is based on?

The DGGS ID, which is an IRI, so for the example above, it would be <https://w3id.org/dggs/tb16pix>, as given in the geometry encoding.

I would expect it to be the former, with the DGGS specification containing a reference to the 'traditional' SRS it is based on.

Well, it's true that the DGGS use a traditional spheroid or ellipsoidal representation of the earth, but there's really no need to ever relate things that use the DGGS back to that information other than for the purposes of DGGS to non-DGGS or vice versa geometry conversion. So, when using TB16PIX day-to-day, we don't care what 'traditional' SRS it is based on and GeoSPARQL DGGS literals need contain no information about it.

Is there some sort of official repository of SRS definitions that people can used as a preferred target for inSRS at this moment?

I presume you mean only for DGGSes? Well, there are OGC plans to create a DGGS register of them, so I presume they will have IRIs minted for them like the CRSes at http://www.opengis.net/def/crs/, but I don't know where those plans are up to - ask the DGGS DWG!

All in all, at least for me it is easy to be confused by the new DGGS additions. As often in such a case, some examples in the documentation could be enlightening. I'd be happy to help there (as an expert on not understanding at first).

At the moment, http://www.opengis.net/doc/AS/dggs/2.0 does not resolve, but http://www.opengis.net/doc/AS/dggs/1.0 does.

True, but I expect the 2.0 one to resolve before we release the final version of GeoSPARQL 1.1 as I think it's now in review. i will check with @rggibb (the editor).

So... at the moment it is not so well known, but we expect it to become well known :-)?

Yes, chicken and egg situation here I'm afraid. If we don't show people how to use DGGS geometries in a spec like this, it won't become well known any time soon...

Don't you think that now a inSRS property is in the pipeline there is even less reason for concatenating two geometry properties that should be kept separate?

I'm just trying to follow the precedent of the WKT in GeoSPARQL and since that includes it, so should this DggsWkt.

For WKT, GML and GeoJSON the specifications are known beforehand, so software can be tailored to handle those formats. In the case of DGGS literals, the specification of how to interpret the literal comes with the literal itself. How can an implementer tell users whether it supports DGGS literals?

It's true you can currently look up the GeoJSON spec and then know how to interpret GeoJSON literals but I think practically DGGSes are the same: you can look up how to interpret AusPIX or H3 DGGSes and know how to interpret them. It's just that each DGGS is different. It would be like having a GeoJSON only for WGS84 (as it is now) and a completely different GeoJSAOn spec for GDA2020 (the Australian grid). As long as you can identify the system the literal is relevant for, you can decide, as a software implementer, whether you are going to support it or not.

We just may have to review the conformance classes in order to ensure GeoSPARQL implementers can accurately describe what they do and don't support.

All in all, at least for me it is easy to be confused by the new DGGS additions. As often in such a case, some examples in the documentation could be enlightening. I'd be happy to help there (as an expert on not understanding at first).

I think I can usefully add several to Annex B, so I've created an Issue for this, #121, and to add examples for all other New Features as well.

[FransKnibbe]

@nicholascar: Thanks for the census block example, it helps in understanding.

Don't you think that now a inSRS property is in the pipeline there is even less reason for concatenating two geometry properties that should be kept separate?

I'm just trying to follow the precedent of the WKT in GeoSPARQL and since that includes it, so should this DggsWkt.

Not necessarily, I think. 'WKT' in DGGS WKT has no other meaning than 'plain text', right? I mean, dggsWktLiteral could just as wel be called dggsTextLiteral, because a standard does not exist yet? And if there is a need to copy characteristics of a WKT, why not use the original geometry WKT (which does not include SRS information) as an example? But what is more important, I see a risk of painting oneself into a corner. See issue 82: when the SRS IRI can appear in multiple places, which one is the source of truth? That problem can now easily be prevented by keeping the SRS IRI in a separate property (inSRS). Next to that, lots of data operations will be much easier if the SRS is kept separate. Especially when it is possible to indicate an SRS once in the dataset metadata (see issue 104).

We just may have to review the conformance classes in order to ensure GeoSPARQL implementers can accurately describe what they do and don't support.

Yes, I had made an issue for that: issue 120.

[rggibb]

@nicholascar and @FransKnibbe I've just caught up with this great discussion:

and there's no theoretical maximum level (smallest size cells) so you can go down to manometer precision, just as you can with a Cartesian coordinate with lots of decimal places.

Not quite .. AS 2.0 introduces the idea of an error budget as part of the DGGS specification. The size of a cell cannot be smaller than the specified error budget, so this leads to a specified limit to cell resolution, beyond which the particular specification is invalid.

True, but I expect the 2.0 one to resolve before we release the final version of GeoSPARQL 1.1 as I think it's now in review. i will check with @rggibb (the editor).

Both the OGC and ISO instances of the AS 2.0 / 19170-1 have been through all their review and vote cycles and are in the final publication pipeline. I expect OGC AS 2.0 will emerge first, I'm just waiting for a couple of minor Metanorma bugs/improvements to be resolved.

[rggibb]

1. The OGC defines a DGGS as a spatial reference system, but GeoSPARQL seems to assume it is a way to describe a geometry. There appears to be a contradiction.

AS 2.0 clarifies this aspect of reference system by explicitly refering to the DGGS Ref sys as a 'Spatial referencing using zonal identifiers with structured geometry'. The term zone is instroduced to extend the terminology from purely spatial (eg geographic identifier) to spatio-temporal. So a DGGS RS takes the concepts of 'Referencing using geographic identifiers' (19112) or 'Referencing using temporal identifiers' (19108) and adds explicit robust geometry in the form of the hierarchy of grids. The interesting part is that whereas AS 1.0 sort of focused on the grid, which of course is where the name DGGS comes from AS 2.0 puts the identifier first. What makes the identifier spatial is not so much the grid but the suite of functions (these are in AS 1.0 and are further enganced in AS 2.0) that can be performed on the identifiers and this is why the alignment to geoSPARQL is now seen as so powerful.

[dr-shorthair]

Not necessarily, I think. 'WKT' in DGGS WKT has no other meaning than 'plain text', right? I mean, dggsWktLiteral could just as wel be called dggsTextLiteral

Yes. In fact dggsWktLiteral is misleading. DGGS literals are nothing to do with WKT. dggsLiteral shoudl be enough. I should have spotted this before.

(TextLiteral is almost tautological - literals are always represented as text.)

[nicholascar]

dggsLiteral should be enough

OK, I'll change it. I agree that although it is similar to WKT, it's not, in fact Well Known for DGGS!

[FransKnibbe]

@rggibb: Thank you for the extra clarification. A somewhat different topic: I have just nosed around a draft for DGGS AS 2.0 and I came across remarks saying that the AS is applicable to other celestial bodies, besides Earth. It is nice to know the specification is not restricted to Earth. I think that would be good for GeoSPARQL too (see issue 14). But in the majority of the DGGS specification, in its title, and in the official requirements, the term 'Earth' is prevalent. Now if text and definitions from the AS find their way to the Semantic Web, the term 'Earth' will probably still be used. With such an emphasis on semantics in the Semantic Web, this could be an impediment for using OGC's DGGS specifications for celestial bodies other than Earth. Could there be a way around that?

[rggibb]

@FransKnibbe on the use of 'Earth', There are three seperate packages in AS 2.0: Common Spatio-Temporal Classes; DGGS Core; and Equal Area Earth DGGS. Earth dependance should only be present in the Equal Area Earth DGGS Package. Elsewhere the more generic terms 'globe' or 'global world' should be used and they are defined in the terms and definitions to clarify that they may apply to any world system. I say 'should' because that was my intent and it is possible that I slipped up somewhere, I should check thoroughly to be sure. One thing we didnt do was address equal area dggs on bodies other than the earth, and maybe we should explcitly add that as a conformance class in an addendum. Equal-Area Earth has explicit elements to cover off static vs dynamic datums which are hot topics at present. Just thinking about it, non-Earth Equal-Area DGGS would probably align either the dynamic or static datum variant depending on whether the body is deemed to be rigid or not, in the case of fluid bodies I imagine all the CRS are dynamic anyway. But I dont know enough about the way planetary datums are specified to know how that aspect is handled, so it was safest to leave that until the issue arises.

[FransKnibbe]

I still feel uncomfortable about DGGS semantics. For issue 10 I am trying to update the definitions of GeoSPARQL ontology terms. One fundamental class is Geometry. When trying to interpret OGC documentation I get the impression that the Geometry class is intended strictly for things defined by numeric coordinates. See this bit in the OGC Reference Model for example:

A geometric object is a combination of a coordinate geometry and a coordinate reference system. In general a geometric object is a set of geometric points, represented by direct positions. A direct position holds the coordinates for a position within some coordinate reference system. Typical geometric objects are points, lines, and polygons.

Traditionally, the OGC has distinguished two ways of referencing spatial things:

1. Referencing by coordinates (covered by ISO 19111 and OGC Abstract Specification Topic 2: Referencing by coordinates)
2. Referencing by identifiers (covered by ISO 19112)

In the introduction of DGGS AS 2.0 I read that DGGS introduces a third category: referencing by identifiers with structured geometry.

Now if DGGS is not spatial referencing by coordinates, and Geometry is limited to referencing by coordinates, how does it make sense to define a DGGS string as a Geometry literal?

[rggibb]

Hi @FransKnibbe In the data model for DGGS AS 2.0, the UML model for 'referencing by identifiers with structured geometry' inherits from both the root of CRS and the root of Geometry, and both use a common 'datum' which is identified as the 'global world' of the DGGS. cf fig 1 of DGGS AS 2.0. So at the top level of DGGS referencing system, a single geometry is asigned to the object (aka global world) that the datum of the CRS references. So the geometry and the CRS are now tied together. As an example, if the chosen CRS is WGS84 lat/long, then the single geometry would be the surface of the ellipsoid of revolution coincident with the WGS84 datum. Once that geoemtry is established, it can then be recursively tesselated using a chosen algorithm which generates both pieces of geometry (cell or zone) that are portions of the surface of the ellispoid, and a unique identifier (ZoneId). The trick at this point is that if you have the Identifier, if you need to you can compute the coordinates of the piece of geometry associated with it, but you only actually need to do that if you are talking to a traditional spatial system that doesnt know about DGGS. All the DE9IM relations are available as functions of the Identifier without recall to coordinates.

Does that help? Or have I missed a key nuance of your question?

[FransKnibbe]

Thank you for explaining, @rggibb. But are you saying that you see no problem defining a DGGS literal as a serialisation of a geo:Geometry? I still have the feeling that DGGS objects are fundamentally different things. That is not saying that DGGS does not belong in GeoSPARQL, it is only saying that the way DGGS literals are used in GeoSPARQL could be reconsidered. Because obviously DGGS are a nifty way of dealing with spatial data!

Some of the problems I see when we say that Geometry = DGGS Object:

• A commonly used definition for geometry is "a set of direct positions in a particular coordinate reference system", with "direct positions" being numeric coordinates. Since DGGS Objects can be defined in other ways than using coordinates, doesn't this make the assumption invalid?
• With coordinate based geometries, information can be considered to have a time dimension if a dynamic CRS is used. The temporal constraints are then completely defined in the CRS, there are no temporal coordinates. Do DGGS identifiers always work in the same way?
• Geometries currently can not entirely be defined in GeoSPARQL; a serialisation is needed. Are there no problems (loss of information; implementation difficulties) to be expected when going from one serialisation to another? For example, define a Geometry using a DGGS literal and then requesting it as a GML literal, or define a Geometry in GeoJSON and then request it as a DGGS literal?
• Is the concept of spatial resolution (a possible explicit property of Geometry) entirely compatible between GeoSPARQL geometries and DGGS objects?
• It looks like a DGGS and a CRS are different reference frames for defining spatial things. How then can the CRS property of a Geometry (currently named inCRS) be applicable to DGGS objects?
• If I understand correctly, a nice thing about DGGS objects is that although they can be converted to coordinate based geometries, that usually is not necessary. DGGS objects offer plenty of functionality in their native form. But I think that SPARQL engines implementing operations on geometries always expect working with coordinates.

I can foresee that the more geo:Geometry will be fleshed out in GeoSPARQL, the more friction there will be between the classic concept of Geometry and DGGS objects. To overcome semantic problems, the separation between the three ways of describing spatial objects (by coordinates, by identifier and by identifiers with structured geometry) could be carried over to web ontologies. GeoSPARQL could then define DGGS objects as a different kind of SpatialObject, next to Geometry. It could look like this:

:DggsObject
  a owl:Class ;
  rdfs:subClassOf :SpatialObject ;
  skos:definition """A collection of coherent DGGS zones"""@en ;
  skos:prefLabel "DGGS Object"@en ;
.

:hasDggs
  a owl:ObjectProperty ;
  rdfs:domain :DggsObject ;
  skos:definition """A reference to the specification of a Discrete Global Grid System (DGGS). Preferably an IRI."""@en ;
  skos:prefLabel "has DGGS"@en ;
  skos:example """ "<https://w3id.org/dggs/auspix>" """
.

:hasZones
  a owl:DatatypeProperty ;
  rdfs:subPropertyOf :hasSerialization;
  rdfs:domain :DggsObject ;
  rdfs:range :dggsLiteral ;
  skos:definition """The serialization of the zones of a DGGS Object"""@en ;    
  skos:prefLabel "has Zones"@en ;
.

:dggsLiteral
  a rdfs:Datatype ;
  skos:definition """A textual serialization of a Discrete Global Grid System (DGGS) object."""@en ;
  skos:example """ "OrdinateList (R3234)"^^<http://www.opengis.net/ont/geosparql#dggsLiteral>""" ;
  skos:prefLabel "DGGS Literal"@en ;
.

(note that in the example above a reference to the applicable DGGS and the text string describing the spatial thing are separated)

[rggibb]

Some of the problems I see when we say that Geometry = DGGS Object:

Yes, I think you are probably correct, DGGS AS 2.0 actually says DGGS Object has geometry, rather than = geometry

• A commonly used definition for geometry is "a set of direct positions in a particular coordinate reference system", with "direct positions" being numeric coordinates. Since DGGS Objects can be defined in other ways than using coordinates, doesn't this make the assumption invalid?

So, a DGGS identifier has a direct position AND it has geometry.

• With coordinate based geometries, information can be considered to have a time dimension if a dynamic CRS is used. The temporal constraints are then completely defined in the CRS, there are no temporal coordinates. Do DGGS identifiers always work in the same way?

Yes and No. Earth based DGGS may be defined on either static CRS or dynamic CRS, and, as in 19115, that CRS may have vertical and or temporal axes in addition to their 'horizontal' axes. Both Static and Dynamic CRS have implications for the DGGS's spatio-temporal error budget, which contribute to the finest resolution dewfined for the DGGS. In the case of static DGGS, the error budget varies with location - basically if the location is on the plate that is tied to the Static CRS then there is one value, and if it is off the plate there will be a different error budget.

• Geometries currently can not entirely be defined in GeoSPARQL; a serialisation is needed. Are there no problems (loss of information; implementation difficulties) to be expected when going from one serialisation to another? For example, define a Geometry using a DGGS literal and then requesting it as a GML literal, or define a Geometry in GeoJSON and then request it as a DGGS literal?

Just as the transformation from vector to raster to vector isnt perfectly symetrical, so in general a vector to DGGS to vector transformation won't be perfectly symetrical. However two factors work to mitigate this:

1. all vectors in practice have a level of precison - even if this isnt explicitly recorded, and with DGGS best practice is to use a resolution that is finer than the precision for the conversion. So for practical purposes there will be no actual loss of information, even if a different set of coordinates is returned.
2. the act of quantising data to convert it to DGGS form from it's external form, is modelled in the DGGS AS as an O&M observation, which means best practice is to record the item in the master dataset that was the origin of the data. So the back transformation, could be to retrieve the item from the master dataset, rather than to attempt to recreate it.

• Is the concept of spatial resolution (a possible explicit property of Geometry) entirely compatible between GeoSPARQL geometries and DGGS objects?

I wasn't aware of a formal notation for spatial resolution in traditional coordinate geometry, so I can't comment. But it would be geat if there were a recognised way to express spatial resolution in GeoSPARQL.

• It looks like a DGGS and a CRS are different reference frames for defining spatial things. How then can the CRS property of a Geometry (currently named inCRS) be applicable to DGGS objects?

The parallel is that every DGGS identifier has an associated RSID .. which is the DGGS equivalent of inCRS, as well as having a specified CRS that is used to define the location and orientation of both its root geometry and top level parent identfiers. The default CRS that is used for all direct positions associated with a DGGS is the CRS that is specified in the DGGS's RSID. We are in the process of establishing a DGGS RSID register within OGC using the same infrastructure that is used to manage the CRS IDs.

• If I understand correctly, a nice thing about DGGS objects is that although they can be converted to coordinate based geometries, that usually is not necessary. DGGS objects offer plenty of functionality in their native form. But I think that SPARQL engines implementing operations on geometries always expect working with coordinates.

Yes, what we identified in the DGGS thread of Testbed-16, is that what makes an object spatial in traditional systems is the serialisation of the geometry, whereas what makes a DGGS identifier spatial, is that it has an associated library of DGGS spatial functions. We referred to this as the DGGS RS Navigator library, as distinct from the DGGS RS Provider library that generates geometries and coordinates associated with Identifiers. We then demonstrated (in GeoServer) that a generic DGGS wrapper could call both the Uber H3 library and the rHEALPix library to generate coordinates on the fly as required by the spatial functions within geoserver. So I would imagine that SPARQL and GeoSPARQL implementors will need to create such a wrapper. DGGS AS 2.0 defines the functions needed for the wrapper.

The other thing we identified and demonstrated was that at the end of an OGC API <Processes/Features> that contained DGGS identfiers the calling system could specifiy either JSON or GeoJSON .. in the former case they received DGGS Identifers without any geometry or coordinates, whereas in the later case they received the coordinates - as you would expect for GeoJSON. I would therefore imagine that the same or a similar approach could be used with SPARQL vs GeoSPARQL.

I can foresee that the more geo:Geometry will be fleshed out in GeoSPARQL, the more friction there will be between the classic concept of Geometry and DGGS objects. To overcome semantic problems, the separation between the three ways of describing spatial objects (by coordinates, by identifier and by identifiers with structured geometry) could be carried over to web ontologies. GeoSPARQL could then define DGGS objects as a different kind of SpatialObject, next to Geometry. It could look like this:

.. I'm obviously going to have to inform myself more about skos, rdfs etc before I comment, but superficially I think see where you are going and agree with the approach you are taking @nicholascar might want to comment, since he was also involved in TB-16.

[nicholascar]

I think that SPARQL engines implementing operations on geometries always expect working with coordinates.

No, why should they? SPARQL engines only operate on geometries with coordinate functions because, to date, that's how geometries have been presented. But there is no 'SPARQL' reason for this. SPARQL can use any lower-level functions available to it.

We have implemented an SF functions library that performs the functions on DGGS ordinates: https://pypi.org/project/rhealpix-sf/. Our GeoSPARQL DGGS SPARQL functions implementation, https://github.com/RDFLib/geosparql-dggs/, then calls that library.

Since we are able to get correct results - by comparison with with non-DGGS geometries and functions - for all SF functions, we have shown that the expectation you have alluded to is a practical expectation - due to existing data and toosl - not a theoretical one.

GeoSPARQL could then define DGGS objects as a different kind of SpatialObject, next to Geometry. It could look like this:

What would it take to convince you that this is not necessary?

As we flesh out geo:Geometry in GeoSPARQL more we encounter friction for other geometry literals too, and we've removed the property inSRS to reduce some of this, but we still have some regarding conversions, 2D/3D etc.

Just getting some friction can't be a reason for a whole-scale modelling change rather not everything works together perfectly.

But the main things do: we now have convert to/from and SF functions for DGGS and we can see that EH & RCC8 functions as well as min/max and Non-topological Query Functions all work for DGGS literals in the style of existing geometries.

So, at least within GeoSPARQL, DGGS literals look and act just like geometries. They may have a representation that's odd but R323 is no less of a positioned object than 152.345,-35,847 and it can be used in the same way.

[dr-shorthair]

There is no question that DGGS cells could be interpreted as 'features' rather than 'geometries', with a link to a conventional coordinate geometry as the hasGeometry. This would not be inconsistent with the OGC/ISO feature model. However, DGGS cells are features with zero non-spatial properties, so not really very interesting when thought of as 'features'.

On the other hand, the propositions by @nicholascar

• that DGGS cells behave like geometries, so can be considered to be geometries
• the encoding - while novel compared with traditional coordinates - is not intrinsically different than coordinates.

Expanding on the second point: operating on either DGGS objects or traditional coordinates requires knowledge of underlying reference systems and access to certain logical or mathematical operations, particularly topology, for the particular representation.

So while either viewpoint could be used, in the context of GeoSPARQL I agree with @nicholascar that we may treat DGGS purely as geometry.

[rggibb]

This is music to my ears, and seems even more reasonable than my reaction to the alternative proposed by @FransKnibbe https://github.com/opengeospatial/ogc-geosparql/issues/112#issuecomment-818400275. @nicholascar's reasoning follows from the AS 2.0 definition of DGGS RS as a "reference system using identifiers with structured geometry". ie that geometry is a fundamental construct in DGGS.

[FransKnibbe]

I think that SPARQL engines implementing operations on geometries always expect working with coordinates.

No, why should they?

Because, by definition, Geometry consists of a set of direct positions and a CRS. And a direct position consists of coordinates. A direct position is what we colloquially could call a point (in 1,2 or 3-dimensional space). A point and a cell in a tessellation are fundamentally different things.

We have implemented an SF functions library that performs the functions on DGGS ordinates: https://pypi.org/project/rhealpix-sf/. Our GeoSPARQL DGGS SPARQL functions implementation, https://github.com/RDFLib/geosparql-dggs/, then calls that library.

Since we are able to get correct results - by comparison with with non-DGGS geometries and functions - for all SF functions, we have shown that the expectation you have alluded to is a practical expectation - due to existing data and toosl - not a theoretical one.

The fact that Geometries and DGGS objects can be made to behave similarly when subjected to a limited set of tests does not prove that they are the same. It does prove that they are similar, so similar modelling in a knowledge representation is warranted.

GeoSPARQL could then define DGGS objects as a different kind of SpatialObject, next to Geometry. It could look like this:

What would it take to convince you that this is not necessary?

I think that would be a solid proof of how DGGS objects fit the definition of Geometry. All Geometry properties, subclasses, functions, etc. are based on that single idea of what a Geometry is. We really can't be casual about adhering to basic definitions. A counter question: What would be against making semantic provisions for DGSS objects being similar to Geometries, but not the same? We can do this with looking ahead to inclusion of coverages too.

As we flesh out geo:Geometry in GeoSPARQL more we encounter friction for other geometry literals too, and we've removed the property inSRS to reduce some of this, but we still have some regarding conversions, 2D/3D etc. DGGS objects are not a type of Geometry literal, are they? As the DGGS specification explains, DGGS are a new way of modelling spatial data, next to coordinate-based geometry.

Nothing should stand in the way of having a function that returns the CRS of a Geometry in GeoSPARQL, and it is reasonable to expect such a function included in a next version. Similarly, it is reasonable/useful to have a function that returns the Nth X, Y, or Z coordinate of a Geometry. How would such geometry functions behave in case of DGGS objects?

[situx]

I think that SPARQL engines implementing operations on geometries always expect working with coordinates.

No, why should they?

Because, by definition, Geometry consists of a set of direct positions and a CRS. And a direct position consists of coordinates. A direct position is what we colloquially could call a point (in 1,2 or 3-dimensional space). A point and a cell in a tessellation are fundamentally different things.

I think we need to consider two things here:

1. The Semantic Definition
2. The practicalities of treating DGGS Literals as Geometries in SPARQL engines

Concerning the latter: I think implementations of SPARQL engines in fact will not check whether something is a subclass of Geometry before processing. Feel free to prove me wrong here, but I know of not a single SPARQL engine that would check this. Rather, SPARQL engines in my experience will act based on the literal types they process. For example, they will process a literal and have an implementation that will convert this literal to an internal representation that could act like a Geometry (if it is a ogc:geomLiteral). In Java implementations, this is often achieved by the JTS library. So if we have a DGGS literal, as long as we have an implementation that can process a DGGS literal and convert it to some representation that makes it comparable to something that is also parsed as a Geometry (e.g. parse a DGGS literal, convert it to a JTS Geometry and compare it to another JTS Geometry parsed from WKT) I believe we are fine. I would also not see an issue if functions we define in GeoSPARQL would only apply to certain literal types.

With that out of the way, I am at a point where only the question of the Semantic definition is left. If we think that a DGGS is a "grid datatype" of some sort that may be comparable or in some relation to a coverage, then it would make sense to me to think about how we proceed with those data types and whether that entails the definition of classes besides geometry.

We have implemented an SF functions library that performs the functions on DGGS ordinates: https://pypi.org/project/rhealpix-sf/. Our GeoSPARQL DGGS SPARQL functions implementation, https://github.com/RDFLib/geosparql-dggs/, then calls that library. Since we are able to get correct results - by comparison with with non-DGGS geometries and functions - for all SF functions, we have shown that the expectation you have alluded to is a practical expectation - due to existing data and toosl - not a theoretical one.

The fact that Geometries and DGGS objects can be made to behave similarly when subjected to a limited set of tests does not prove that they are the same. It does prove that they are similar, so similar modelling in a knowledge representation is warranted.

GeoSPARQL could then define DGGS objects as a different kind of SpatialObject, next to Geometry. It could look like this:

What would it take to convince you that this is not necessary?

I think that would be a solid proof of how DGGS objects fit the definition of Geometry. All Geometry properties, subclasses, functions, etc. are based on that single idea of what a Geometry is. We really can't be casual about adhering to basic definitions. A counter question: What would be against making semantic provisions for DGSS objects being similar to Geometries, but not the same? We can do this with looking ahead to inclusion of coverages too.

As we flesh out geo:Geometry in GeoSPARQL more we encounter friction for other geometry literals too, and we've removed the property inSRS to reduce some of this, but we still have some regarding conversions, 2D/3D etc. DGGS objects are not a type of Geometry literal, are they? As the DGGS specification explains, DGGS are a new way of modelling spatial data, next to coordinate-based geometry.

Nothing should stand in the way of having a function that returns the CRS of a Geometry in GeoSPARQL, and it is reasonable to expect such a function included in a next version. Similarly, it is reasonable/useful to have a function that returns the Nth X, Y, or Z coordinate of a Geometry. How would such geometry functions behave in case of DGGS objects?

[FransKnibbe]

There is no question that DGGS cells could be interpreted as 'features' rather than 'geometries', with a link to a conventional coordinate geometry as the hasGeometry. This would not be inconsistent with the OGC/ISO feature model. However, DGGS cells are features with zero non-spatial properties, so not really very interesting when thought of as 'features'.

We do not have to choose between Feature and Geometry to model DGGS. Why can't we introduce a new class of Spatial Object with a definition that really fits? Probably the same has to happen when/if coverages can be handled by GeoSPARQL.

On the other hand, the propositions by @nicholascar

• that DGGS cells behave like geometries, so can be considered to be geometries

I do not agree with that. As I wrote in an earlier comment: The fact that Geometries and DGGS object can be made to behave similarly when subjected to a limited set of tests does not prove that they are the same.

• the encoding - while novel compared with traditional coordinates - is not intrinsically different than coordinates.

Which encoding is that? Do you mean text serialisations? My understanding is that both Geometries and DGGS object can have lots of different text encodings.

Expanding on the second point: operating on either DGGS objects or traditional coordinates requires knowledge of underlying reference systems and access to certain logical or mathematical operations, particularly topology, for the particular representation.

So while either viewpoint could be used, in the context of GeoSPARQL I agree with @nicholascar that we may treat DGGS purely as geometry.

That would be based on an assumption that we have to choose between either Feature or Geometry to model DGGS, right?

[FransKnibbe]

This is music to my ears, and seems even more reasonable than my reaction to the alternative proposed by @FransKnibbe #112 (comment). @nicholascar's reasoning follows from the AS 2.0 definition of DGGS RS as a "reference system using identifiers with structured geometry". ie that geometry is a fundamental construct in DGGS.

If geometry is a fundamental construct in DGGS, doesn't it mean that a DGGS object can not be exactly the same as a Geometry?

By the way, a newer alternative to the earlier modelling proposal could be to introduce a new class having SpatialObject as superclass and both Geometry and DggsObject as subclasses. Existing properties and functions working on Geometry could instead use that new class, where appropriate. The class could be named DiscreteSpatialObject for example, and possibly be used for coverages as well.

[FransKnibbe]

As a challenge to the hypothesis that DGSS Objects behave in the same way as Geometries: What would a procedure look like that determines equality of a point Geometry and a DGSS Object? Such a thing would be required by the sfEquals function.

[FransKnibbe]

I think implementations of SPARQL engines in fact will not check whether something is a subclass of Geometry before processing. Feel free to prove me wrong here, but I know of not a single SPARQL engine that would check this.

I don't think so either. Likely triple stores assume that Geometry literals represent Geometries.

Rather, SPARQL engines in my experience will act based on the literal types they process. For example, they will process a literal and have an implementation that will convert this literal to an internal representation that could act like a Geometry (if it is a ogc:geomLiteral). In Java implementations, this is often achieved by the JTS library. So if we have a DGGS literal, as long as we have an implementation that can process a DGGS literal and convert it to some representation that makes it comparable to something that is also parsed as a Geometry (e.g. parse a DGGS literal, convert it to a JTS Geometry and compare it to another JTS Geometry parsed from WKT) I believe we are fine. I would also not see an issue if functions we define in GeoSPARQL would only apply to certain literal types.

One could hold the position that if there is a need to convert A to B, then A is not the same as B.

Still, I wonder if there are working procedures to convert a Geometry to a DGGS Object and vice versa. When combined, such procedures should be able to convert a Geometry to a DGGS Object and back again to a Geometry, or a DGGS Object to a Geometry and back again to a DGGS Object. In both cases the output should be exactly the same as the input. Could such a thing be demonstrated, then it could be a good ground for declaring the two effectively equal.

[situx]

I think implementations of SPARQL engines in fact will not check whether something is a subclass of Geometry before processing. Feel free to prove me wrong here, but I know of not a single SPARQL engine that would check this.

I don't think so either. Likely triple stores assume that Geometry literals represent Geometries.

Rather, SPARQL engines in my experience will act based on the literal types they process. For example, they will process a literal and have an implementation that will convert this literal to an internal representation that could act like a Geometry (if it is a ogc:geomLiteral). In Java implementations, this is often achieved by the JTS library. So if we have a DGGS literal, as long as we have an implementation that can process a DGGS literal and convert it to some representation that makes it comparable to something that is also parsed as a Geometry (e.g. parse a DGGS literal, convert it to a JTS Geometry and compare it to another JTS Geometry parsed from WKT) I believe we are fine. I would also not see an issue if functions we define in GeoSPARQL would only apply to certain literal types.

One could hold the position that if there is a need to convert A to B, then A is not the same as B.

I think the issue here is whether it is a lossless conversion. The WKT literal would be converted to a JTS geometry and the DGGS literal would be converted to a JTS geometry. So both are converted to Java objects internally e.g. for matters of comparison. One cannot compare two geometry literal strings directly without some form of processing I suppose.

Still, I wonder if there are working procedures to convert a Geometry to a DGGS Object and vice versa. When combined, such procedures should be able to convert a Geometry to a DGGS Object and back again to a Geometry, or a DGGS Object to a Geometry and back again to a DGGS Object. In both cases the output should be exactly the same as the input. Could such a thing be demonstrated, then it could be a good ground for declaring the two effectively equal.

I agree and the message would be "effectively equal" and not semantically equal. I think this is what @nicholascar tries to achieve with his implementations on rdflib. In any case, even if we think about integrating coverages and rasters for that matter we need to ensure that all sf functions like sfEquals and touches a.s.o. work on both coverage and vector geometry literals. What usually happens in implementations such as POSTGIS is that the raster geometry (bbox of the raster) is taken for comparison and raster cells are related to subareas of the raster geometry. The granularity of these comparisons depends on the granularity of the raster cells. I would make the case that a DGGS exhibits similar behavior. So I could agree that the type of a DGGS may not necessarily be a geometry, but we could define sth. like a DGGS geometry in a similar fashion as we define a raster geometry to represent the bounding box of a raster. The only difference is that a DGGS envelops the whole globe and not a specified area.

[FransKnibbe]

I agree and the message would be "effectively equal" and not semantically equal. I think this is what @nicholascar tries to achieve with his implementations on rdflib.

I have the distinct feeling that the semantic inequality (DGGS zones vs. coordinates) results in practical problems. Some of the issues I can think of (of which some were mentioned before) are:

1. Is it possible to convert Geometry to DGGS object and back again, or DGGS object to Geometry and back again, without loss of data?
2. How do Geometry properties like geo:coordinateDimension, geo:isEmpty, geo:hasMetricSpatialResolution and geo:hasMetricSpatialAccuracy make sense for DGGS objects? They are all about coordinates.
3. Can we be certain that the supposed equality of DGGS objects and Geometry holds up in all future versions of GeoSPARQL?
4. Just as it makes sense to be able to group/filter Geometry instances by CRS, it will be useful to group/filter DGGS objects by DGGS. Hence the need for something like a hasDGGS property, akin to a hasCRS property. But a hasDGGS property makes no sense for a Geometry. By the way, a hasCRS property would make sense as a property for a hypothetical DggsObject class.
5. When DGGS objects are viewed as Geometry and are imported in a data store, all data on the DGGS (i.e the grid) is lost, because the concept of a DGGS is unknown to the Geometry class. Is this a desirable effect? In other words: using DGGS as a means of encoding spatial data has clear advantages. Wouldn't it be a pity to lose those advantages once DGGS objects are imported into an RDF data store?

In any case, even if we think about integrating coverages and rasters for that matter we need to ensure that all sf functions like sfEquals and touches a.s.o. work on both coverage and vector geometry literals.

Currently the SPARQL functions work on Geometry only. Perhaps at least some of them could be changed to handle a more general input class, like DiscreteSpatialObject, which could cover Geometry, Coverage and DggsObject data. Probably we will want to be able to choose between types of function output too.

I don't know if it is possible to overload SPARQL functions. If it is not feasible/recommendable to have a SPARQL function with different signatures, then at least we have a slight naming challenge.

[situx]

I agree and the message would be "effectively equal" and not semantically equal. I think this is what @nicholascar tries to achieve with his implementations on rdflib.

I have the distinct feeling that the semantic inequality (DGGS zones vs. coordinates) results in practical problems. Some of the issues I can think of (of which some were mentioned before) are:

1. Is it possible to convert Geometry to DGGS object and back again, or DGGS object to Geometry and back again, without loss of data?

@nicholascar for now has the most experience here. All I can say is that would also not be the case if you convert vector geometries to raster and back.

2. How do Geometry properties like geo:coordinateDimension, geo:isEmpty, geo:hasMetricSpatialResolution and geo:hasMetricSpatialAccuracy make sense for DGGS objects? They are all about coordinates.

Possibly not applicable.

3. Can we be certain that the supposed equality of DGGS objects and Geometry holds up in all future versions of GeoSPARQL?

I currently would not see why not, but I would also not see a problem with some functions we define only being applicable for certain tasks.

4. Just as it makes sense to be able to group/filter Geometry instances by CRS, it will be useful to group/filter DGGS objects by DGGS. Hence the need for something like a hasDGGS property, akin to a hasCRS property. But a hasDGGS property makes no sense for a Geometry. By the way, a hasCRS property would make sense as a property for a hypothetical DggsObject class.

I would say that the class of DGGS could be used in a inSRS property. After all it describes a spatial reference.

5. When DGGS objects are viewed as Geometry and are imported in a data store, all data on the DGGS (i.e the grid) is lost, because the concept of a DGGS is unknown to the Geometry class. Is this a desirable effect? In other words: using DGGS as a means of encoding spatial data has clear advantages. Wouldn't it be a pity to lose those advantages once DGGS objects are imported into an RDF data store?

Are they lost? I think they could be added, we just do not have a specific vocabulary for that defined in the GeoSPARQL standard.

In any case, even if we think about integrating coverages and rasters for that matter we need to ensure that all sf functions like sfEquals and touches a.s.o. work on both coverage and vector geometry literals.

Currently the SPARQL functions work on Geometry only. Perhaps at least some of them could be changed to handle a more general input class, like DiscreteSpatialObject, which could cover Geometry, Coverage and DggsObject data. Probably we will want to be able to choose between types of function output too.

Correct, this is an open ticket for GeoSPARQL 2.0. My proposal would be to define more general literal types that we put as arguments in the SPARQL function definitions.

I don't know if it is possible to overload SPARQL functions. If it is not feasible/recommendable to have a SPARQL function with different signatures, then at least we have a slight naming challenge.

I do not think we need to do that. We just define a more general literal type as an argument or extend the meaning of ogc:geomLiteral to also include whatever raster literal types we want

[FransKnibbe]

Response to comments made by @nicholascar in issue 256:

For GeoSPARQL we've shown that they can operate as geometries regarding the GeoSPARQL functions, that they can represent the spatial footprints of Features and that we can convert from other geometry representations to and from DGGS 'geometries'.

It was shown that DGGS objects and Geometries are similar in some ways. But there are differences too. Two things sharing traits does not make them equal.

We've also made the case that the DGGS Cells unambiguous represent parts of a spatial surface, such as the Earth's, using a reference system - an ordinate one, not a coordinate one - but that all the aspects of a coordinate reference systems needed for spatial calculations and data representation are preserved.

The same can be said about coverages. They too have traits in common with Geometry, but there are fundamental differences which merit separate modeling.

By the way, what is your definition of ordinate?

I think you keep going back to the fact that, because DGGS Cells represent an area, not a point

The main point is that DGGS Objects and Geometries are fundamentally different things. Geometries are coordinates + CRS. DGGS objects make use of particular geometries or time periods. Those basics give rise to both shared and different traits.

this doesn't take away from Cells making a perfectly fine geometries: they simple have more possibilities.

OK, if they have more possibilities, wouldn't it make sense to allow GeoSPARQL to make use of those extra possibilities at some point? That would mean that a part of the specification would be about DGGS objects only. Which is yet another indication that they are not the same as Geometries.

[nicholascar]

It was shown that DGGS objects and Geometries are similar in some ways. But there are differences too. Two things sharing traits does not make them equal.

I suggest that they - DGGS Cells and Geometries - are similar enough within the context of GeoSPARQL ontology modelling and functions to be considered the same here.

I am not saying that there is no sensible modelling that differentiates DGGS Cells and tranditional Geometries but I am saying that within what we can do here, GeoSPARQL 1.1, this is allowable. Just as any modelling is a simplification of real-world concepts for some purpose.

My evidence for this is that:

1. DGGS Cell collection serializations can be represented as traditional geometry serializations can be, in RDF literals
2. DGGS Cell collection serializations can be used in SPARQL function extensions to perform Simple Features calculations just as traditional geometry serializations can be (see https://github.com/RDFLib/geosparql-dggs)

So, from GeoSPARQL's point of view, DGGS Cell serializations perform just as traditional geometry serializations. This means they are equivalent in this context. It does not mean they are equivalent in other contexts.

The same can be said about coverages. They too have traits in common with Geometry, but there are fundamental differences which merit separate modeling.

If it was shown that coverages could be represented in literals in GeoSAPRQL and that GeoSPARQL functions could be performed using them, then they too would be equivalent to traditional geometry serializations in this context. I don't believe this is the case, so I don't think they are equivalent in this context.

By the way, what is your definition of ordinate?

Where a coordinate is a pair of values on a Cartesian plane, an ordinate is a single value. DGGSes arrange all their identified Zones on globes and the Zones have a single identifier, so a single value, not a pair, is needed to characterize them.

The main point is that DGGS Objects and Geometries are fundamentally different things. Geometries are coordinates + CRS. DGGS objects make use of particular geometries or time periods. Those basics give rise to both shared and different traits.

DGGS Cells are ordinates and the DGGS provides an SRS (and perhaps also a TRS). The ordinal DGGS IDs (see "ordinate" above) are positioned using the DGGS logic on a globe - the SRS.

DGGS Cells can be used to compute the Simple Features topological relationship between Features that they describe the geometry of: Features with Cells R0012 & R0015 can be calculated to have the relation sfTouches. Features with the Cells R0012 & R00128 can be calculated to have the relation sfContains. so these Cells, or collections of them, act as GeoSPARQL Geometry literals can act.

this doesn't take away from Cells making a perfectly fine geometries: they simple have more possibilities.

OK, if they have more possibilities, wouldn't it make sense to allow GeoSPARQL to make use of those extra possibilities at some point?

Perhaps, in some work outside GeoSPARQL 1.1. There is OGC work on a standard DGGS API and I could imagine that a DGGS ontology and spatial functions set would be interesting work. That does not mean it's not useful to have some simple DGGS handling here, just as GeoSAPRQL uses only some of GML, not all of it. Still useful to use some GML even though it is larger than GeoSPARQL's use of it and has many other purposes.

That would mean that a part of the specification would be about DGGS objects only. Which is yet another indication that they are not the same as Geometries.

No, this specification need not know anything about DGGS that is beyond its scope, just as it knows nothing about, say, KML's ability to style object. Out of scope for GeoSPARQL!

[FransKnibbe]

It was shown that DGGS objects and Geometries are similar in some ways. But there are differences too. Two things sharing traits does not make them equal.

I suggest that they - DGGS Cells and Geometries - are similar enough within the context of GeoSPARQL ontology modelling and functions to be considered the same here.

I am not saying that there is no sensible modelling that differentiates DGGS Cells and tranditional Geometries but I am saying that within what we can do here, GeoSPARQL 1.1, this is allowable. Just as any modelling is a simplification of real-world concepts for some purpose.

My evidence for this is that:

1. DGGS Cell collection serializations can be represented as traditional geometry serializations can be, in RDF literals

Well, that can be said about a lot of things; all kinds of data can be encoded as text.

2. DGGS Cell collection serializations can be used in SPARQL function extensions to perform Simple Features calculations just as traditional geometry serializations can be (see https://github.com/RDFLib/geosparql-dggs)

In itself that is no ground for saying that DGGS cells are GeoSPARQL geometries. And there are some current and future GeoSPARQL functions that seem to make no sense for DGGS cells:

• get the CRS
• geo:coordinateDimension
• get the Nth x,y or z coordinate
• geo:isEmpty
• geo:hasMetricSpatialResolution
• geo:hasMetricSpatialAccuracy

Also, I have not seen proof of lossless or errorless bidirectional conversions.

For the sake of clarity: Does the proposed way of handling DGGS in GeoSPARQL pertain to DGGS cells? Meaning that it wouldn't be possible to encode DGGS zones?

The same can be said about coverages. They too have traits in common with Geometry, but there are fundamental differences which merit separate modeling.

If it was shown that coverages could be represented in literals in GeoSAPRQL and that GeoSPARQL functions could be performed using them, then they too would be equivalent to traditional geometry serializations in this context. I don't believe this is the case, so I don't think they are equivalent in this context.

It is possible to encode raster data as text, and it is possible to convert raster data to vector data and vice versa. It is not that different from DGGS.

By the way, what is your definition of ordinate?

Where a coordinate is a pair of values on a Cartesian plane, an ordinate is a single value. DGGSes arrange all their identified Zones on globes and the Zones have a single identifier, so a single value, not a pair, is needed to characterize them.

If we look at this wikipedia page we see that an ordinate is the y value of a x,y coordinate pair. It has a specific meaning. At least it is certain that an ordinate is a numeric value. I don't think the ordinate label can be used to stretch the meaning of 'coordinate' to 'any kind of identifier'.

The main point is that DGGS Objects and Geometries are fundamentally different things. Geometries are coordinates + CRS. DGGS objects make use of particular geometries or time periods. Those basics give rise to both shared and different traits.

DGGS Cells are ordinates and the DGGS provides an SRS (and perhaps also a TRS). The ordinal DGGS IDs (see "ordinate" above) are positioned using the DGGS logic on a globe - the SRS.

DGGS Cells can be used to compute the Simple Features topological relationship between Features that they describe the geometry of: Features with Cells R0012 & R0015 can be calculated to have the relation sfTouches. Features with the Cells R0012 & R00128 can be calculated to have the relation sfContains. so these Cells, or collections of them, act as GeoSPARQL Geometry literals can act.

Coordinates ≠ any identifier, CRS ≠ SRS, and two things sharing traits does not make them equal.

this doesn't take away from Cells making a perfectly fine geometries: they simple have more possibilities.

OK, if they have more possibilities, wouldn't it make sense to allow GeoSPARQL to make use of those extra possibilities at some point?

Perhaps, in some work outside GeoSPARQL 1.1. There is OGC work on a standard DGGS API and I could imagine that a DGGS ontology and spatial functions set would be interesting work. That does not mean it's not useful to have some simple DGGS handling here, just as GeoSAPRQL uses only some of GML, not all of it. Still useful to use some GML even though it is larger than GeoSPARQL's use of it and has many other purposes.

My point was that by trying to model DGGS cells as Geometries, even simple functionality is blocked. For example, it would make sense to have a function that returns the DGGS used for a cell or cell collection. Such a thing would not require a separate DGGS ontology.

In summary: I think it is clear that DGGS cells can not be viewed as GeoSPARQL geometry. That does not mean that DGGS has no place in GeoSPARQL, but remodelling is in order (and is likely beneficial to DGGS users).

[jabhay]

Vote required: Is DGGSLiteral a legitimate way to represent GeoSPARQL Geometries?

For: The DGGS experts have commented in this ticket and believe that they can be on the basis of functionality and representation... their feedback is above. You can't perform every function on DGGS objects, but there's precedence for this given not all functions can be performed on all traditional Geometries. However the core functionality of Geometry can be modelled for DGGS. We are saying, "If you want to represent Geometry as DGGS, DGGSLiteral is a way to do it". We are not saying they are the same. We have a function, getSRID which returns a URL, and this can be implemented by both.

Against: Support for DGGS is good for GeoSPARQL, but it doesn't have coordinates nor a coordinate reference system. Some of the things in GeoSPARQL don't make sense with DGGS as a Geometry. They are listed above. It will also potentially limit GeoSPARQL functions that could be specific to DGGS, e.g., getDGGS (or something similar). DGGS is not well represented by Geometry because it is a grid like type.

An email vote will be conducted and finalised by next meeting.

[jabhay]

Recording status of votes (Quorum achieved):

1. NC (Surround Australia): Yes
2. LVDB (Geonovum): Yes
3. FK (Using Geoscape Australia's Proxy): No
4. RG (Manaaki Whenua): Yes
5. MP (Oracle): Yes
6. TH (Mainz University Of Applied Sciences): Yes

Interim Totals: Yes (5), No (1)