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.