DGGS RSID elaboration and implementation issues

[rggibb]

OGC Abstract Specification Topic 21 v2.0 Figure 13 has some elements that need further elaboration and dsiscussion before they can be implemented.

The OGC API DGGS refers to an identifier that resolves to a full specification of a DGGS RS /dggs/{dggsRSID}.
At present the DGGS RS that are in use have been given informal identifers, for example H3, AusPIX and TB16-Pix and each of these are described by association with the library that is currently used to create them - which is sufficient for current purposes but isnt robust enough or transparent enough to cater for the range of possibilities that we expect to arise once people start to use the AS Topc 21 more widely. Figure 13 includes a structure that caters to that future, and the development of OGC API DGGS is an appropriate trigger to start doing things more robustly. Part of that is creation of the DGGS Registry cf Issue 36. This issue is intended to start conversations around other elements that may or may not yet be formally supported by existing infrastructures.

A DGGS RS brings together a number of component parts that could exist on their own and therefore can be described independently. This is analogous to the situation with projections, where the defintion of the ellipsoid used to describe the Earth is defined seperately from the definition of the sets of axes. A particular projection is then the combination of a definition of an ellispoid and a definition - including orgin and orientation of a coordinate set.

For DGGS the component parts are - with reference to the elemnts highlighted in red below, which is Figure 13:

1. (cf DGG_ReferenceSystemType::CRS) The ID of the CRS used to specify the grid geometry
2. (cf DGG_ReferenceSystemType::ZIRS)The ID of the RS using Zonal Identifers - the data type is MD_Identifer from ISO 19115-1, but these IDs are for Spatial RS using Geographic Identifers (19112 Ed 2) and Temporal Reference Systems using Period Identifiers (introduced in Topic 21 v2.0 Pt 1). Here we are potentially in new territory,. We need to discover who currently manages registries of Geographic Identifers, and whether they want to extend their registry to include DGGS Zonal Identifiers, or whther we manage them in the DGGS Registry.
3. (cf DGG_ReferenceSystemType::GLOBE)The ID for the geometry data used to define the Globe - geometryData is defined by 19107 Ed2, and instantiated for the earth by the EPSG codes for Ellipsoids and Spheroids such as GRS80, but note that DGGS Globes can also be any planetary body and can also be 2D, 3D or 4D Globes, with 3D extents for earth potential reaching out beyond the lunar orbit. I believe that Mars's geometry has an EPSG codes, but I dont know whether Reference systems for Martian Time are stored. We dont have to solve all of these variations now, but bear it in mind for future scope.
4. The characteristics of the tesselation used to form the hierarchy of zones:
   4.1. (cf DGG_ReferenceSystem::DGGS_Grids) The list of 1..* DGG_GridContraint(s)
   4.2. (cf DGG_ReferenceSystem::DGGS_Refinement) The list of 1..* DGG_RefinementStrategy(s)
   4.3. (cf DGG_ReferenceSystem::DGGS_RefinementRatio) The sequence of 1..* RefinementRatios
5. (cf DGG_ReferenceSystemType::MDRS) Finally a particular DGGS RS has an dggsRSID that points to a structure that brings together all the above pieces.

[allixender]

My main confusion is currently accessing data vs only zone/dggs definitions:

/collection/(collectionid)/dggs/(dggsrsid)/zones: then you could separate the DGGS index and the data layers?

or you would assume all data indexed under a DGGS on a server needs to be accessible via: /dggs/(dggsrsid)/zones ?

[ghobona]

Some ideas below:

• /collection/(collectionid)/dggs/(dggsrsid) for the DGGS definition
• /collection/(collectionid)/dggs/(dggsrsid)/zones for the zone definition
• /collection/(collectionid)/dggs/(dggsrsid)/zones/items for the data from a zone

@jerstlouis I think you encountered a similar question to #41 (comment) in either OGC API - Tiles or OGC API - Coverages. How did you address it there?

[jerstlouis]

@ghobona @allixender

We cannot have both items and {zoneId} at the same resource path

@rggibb @geofizzydrink @pvretano

For a DGGS: What is here? conformance class, I think we would want to return data (e.g. as GeoJSON or FlatGeoBuf for vector features, and for raster GeoTIFF or a more compact format that encodes the particular shape of the e.g. hexagonal shape of the tile) at:

• /collections/{collectionId}/dggs/{dggsrsid}/zones/{zoneId} (all features in the collection inside a specific zone).
• /collections/{collectionId}/coverage/dggs/{dggsrsid}/zones/{zoneId} (coverage data for the collection inside a specific zoneID, useful if collection is available as both Features and a Coverage using the same media type).
• /collections/{collectionId}/items/{itemId}/dggs/{dggsrsid}/zones/{zoneId} (data from a single feature in the collections clipped to a specific zone -- e.g. for large coastline or ocean/landfill).

and for the DGGS: Where is this? conformance class, I think we want to return a list of zones at:

• /collections/{collectionId}/dggs/{dggsrsid}/zones -- zones inside this collection
• /collections/{collectionId}/items/{itemId}/dggs/{dggsrsid}/zones -- zones inside this specific feature

which can take additional parameters like &dggsLevel= at which the most detailed zones should be listed, and option whether lower-level zones can be included when fully within the collection (e.g. compressedZones=false)

To me these are the basic practical and useful conformance classes for OGC API - DGGS.

Then the next most useful one would be DGGS: CQL2 support (used with e.g. filter=) supporting extensions such as:

• a list of DGGS zones (e.g. to be used with spatial operator), either explicitly, or a URL to a ../zones as described above
• URL to an OGC API collection (.../collections/{collectionId}) or feature (.../collections/{collectionId}/items/{itemId}), which could also be used wherever geometry is allowed.

[jerstlouis]

We now have informative Appendix B in the candidate OGC API - DGGS describing a schema for the definition of a DGGRS, as well as 3 example definitions.

The original description at the top of this issue by @rggibb highlights excellent points, and much in line with the approach that we took, in particular:

A DGGS RS brings together a number of component parts that could exist on their own and therefore can be described independently.

I would comment on the original discussion that something we found missing is the independent concept of a Discrete Global Grid Hierarchy (DGGH), which implies a particular CRS, refinement strategy, refinement ratio and the grids themselves (points 1 and 4). It also imples a specific globe / Earth reference system (ellipsoid) -- point 3, parameters like polyhedron orientation, and therefore fully defines the geometry of all zones for the grid hierarchy, but without yet selecting a particular indexing system. This is a key concept that can be re-used.

Unfortunately, in Topic 21 this DGGH concept is not clearly modeled as an entity on its own, since the DGG_ReferenceSystemType already includes the ZIRS, whereas the grids and refinement strategy/ratio is defined outside in the DGG_ReferenceSystem, with no class corresponding to the DGGH, which would include everything except the ZIRS and MDRS.

For the definition of the DGGRS schema therefore took the liberty to re-organize things a little, consisting of 3 main components:

• DGGH
• ZIRS
• Sub-Zone ordering (new concept for zone-local internal indexing, supporting optimized DGGS-quantized data encodings)

with the DGGH definition further split into parameters and properties, allowing for example to change the polyhedron orientation and ellipsoid by modifying only the parameters.

The DGGRS registry could potentially re-use components, which could even have registry of their own, potentially using $ref JSON pointers for including shared resource definitions. Potentially a future revision to Topic 21 could take this into consideration.

If I understand point 5 of the comment correctly, the MDRS corresponds to an identifier for the DGGRS -- I was always somewhat confused by this MDRS. In OGC API - DGGS, there is a distinction between the implementatin/deployment-local {dggrsId}, which only has meaning on that particular deployment, and the concept of a global URI for a particular DGGRS registered with a particular authority, for example on the proposed OGC DGGRS registry on the OGC definition server.

The further discussion is quite tangential to the original issue.
I think the short answer on how this evolved is that we added /data since @allixender 's comment and now data is available at /dggs/{dggrsId}/zones/{zoneId}/data.

In the candidate API, it is possible to retrieve for example GeoJSON representations of:

• a list of zone (.../dggs/{dggrsId}/zones), or
• of a particular zone (.../dggs/{dggrsId}/zones/{zoneId}), or
• of features within a single zone (.../dggs/{dggrsId}/zones/{zoneId}/data) -- which could either be one feature per sub-zone for a rasterized representation, or features clipped to the zone for a vector representation in the case of vector formats.

The DGGS-FG-JSON requirement class also supports retrieving data where the points of feature geometry are quantized to sub-zones for an efficient vector representation.

Updating the paths I proposed above:

• /collections/{collectionId}/dggs/{dggrsId}/zones/{zoneId}/data (all features in the collection inside a specific zone -- whether Features or Coverage (geometry=zone-centroid, zone-region, vectorized can be used to force rasterized vs. vector)

• /collections/{collectionId}/items/{itemId}/dggs/{dggrsId}/zones/{zoneId} -- this could still be relevant as the ../dggs resources are transportable to any resource so it makes sense to support them on a single feature

• /collections/{collectionId}/dggs/{dggrsId}/zones -- zones where data is available for this collection (still valid)

• /collections/{collectionId}/items/{itemId}/dggs/{dggrsId}/zones -- zones inside this specific feature (could be supported for single feature too)

The final query parameters for Zone Query are zone-level for refinement level, and compact-zones for whether to replace zones by parent

We did not define DGGS-specific extensions to CQL2, but the ability to perform integration with other collections is hinted at by mentioning a potential collections= or joinCollections= query parameter, together with the typical use of queryables in CQL2.

The ability to reference DGGRS zones in CQL2 query is not currently planned -- we will wait to see whether that comes up as future requirement.

Closing this issue as there are no further actions to take on this in the DGGS API for now.