Decision Needed on DGGS Identifier nomenclature for OGC API DGGS

[geofizzydrink]

Hi All,

I think we need to hold a SWG vote on the nomenclature of the DGGS Identifier for use in describing the OGC API DGGS. We have two different but equally valid naming schemes that we could use for DGGS infrastructure Identifiers:

1. {dggsID}

   • This follows the same basic pattern used throughout the OGC API schemas of <resourceType>+"ID".
   • For example: collectionID, itemID, processID, jobID, etc...
   • If we follow this naming convention we will be 100% in sync with the other OGC API specs since a DGGS can be viewed as a "resourceType".
   • This also allows for an individual DGGS instance to be named anything (from the API perspective) despite what the "dggsRSID" actually is.
     • This could also open up the possibility of different instances of the same DGGS resource being accessed via different OGC API DGGS endpoints. (e.g. one might have an instance of the "H3" DGGS implemented on the API Server but wish to expose it as /dggs/bobsDGGS/... instead of /dggs/h3/...).
     • The upside of this approach is that if the dggsRSID is complicated and/or not "pretty" to the human eye (e.g. _TerraNexus_S_IT9_GRS802d10b58e2088c7e2) this could be replaced by a simpler dggsID (such as, TerraNexus1).
     • The downside of this approach is that it could lead to a dislocation, or confusion, between an arbitrary dggsID and the precise dggsRSID that it is referring to. This could potentially lead to complications in machine driven determination of different instances of the same DGGS.

2. {dggsRSID}

   • This follows the approach defined in OGC Abstract Specification Topic 21 (ISO 19170-1:2021) where a DGGS is actually described as a DGGS Reference System where each DGGS_RS will have a unique identifier - i.e. a dggsRSID.
   • This approach will provide explicit linkage between OGC API DGGS resource endpoints/definitions and the specific DGGS they are relevant to.
   • By forcing this explicit naming via the dggsRSID we also provide a tighter coupling with the (yet to be published) OGC DGGS Registry - which is proposed to serve a similar role to that of the CRS Registry by recording and making accessible the standardised definition of all "registered" DGGS specifications.
     • The counter to this would be that, so long as the OGC API DGGS Core definition elements correctly refer to a valid "registered" dggsRSID the OGC API DGGS should still function correctly.

What do people think?

Should we use dggsID, or, dggsRSID for the OGC API DGGS schema?

If we have quorum during the next DGGS SWG telecon I would like us to vote on this? if not, we can vote on this during the October Members Meeting in Singapore.

[jerstlouis]

As hinted at in #57, my preference lies with the simpler {dggsID}. However, we should make it clear that by {dggsID} we identify both a specific discrete global grid as well as a specific indexing scheme, which corresponds to a DGGS Reference System ID in Topic 21.

[AkexStar]

I prefer to {dggsID}, and agree with @jerstlouis .

[jerstlouis]

Although we are sticking to the .../dggs/ paths, after discussion with the editing group, I have updated the spec in bfb9b2adcee1bded97122c9bfd6a10e49ced0513 to use {dggrsId} to really highlight the fact that that these are DGGRSs implying a particular indexing scheme.