Setting up a DGGRS Registry

[rggibb]

Use Case 1 addresses the question of whether a DGGS specification is formally compliant with the Conformance Classes and Requirements in Topic 21 v1 &/or Topic 21 v2 Part 1, and in the near future Parts 2, 3 & 4. Associated with this are the various formalised SWG duties of managing requests for assessment of a DGGS specification from an author and publishing the results.

[rggibb]

Use Case 2 is around DGGS Reference Systems .. this is the Use Case being exercised by the OGC API DGGS. First recall from Testbed 16, we identified that DGGS libraries might be either DGGS RS providers or DGGS Navigators. DGGS RS providers accept a set of parameters and generate a DGGS RS from those parameters. In this use case the role of the registry is to provide the lookup between a DGGS RS ID and the RS’s parameters. This is entirely analogous to the role of the EPSG repository, and the ability of a projection library to take a projection ID in the form of an EPSG code and return a set of parameters that allows the projection library to reliably recreate the maths for the projection.

Further details and variants for this Use case are elaborated in the the SwaggerHub document at /dggs/{dggsRSID}

[rggibb]

Rob Atkinson has mocked up a draft Use Case for how the OGC Definitions Server might interact with the DGGS Register, API definition and run-time implementations of the API

He says:
I am developing and documenting a set of Use Cases for the Definitions Server as most applications have a similar number of moving parts and people struggle to understand it all, or how a sufficiently flexible infrastructure can be applied... so your feedback on this appreciated - and will collaborate with writing up a document if desired.

mock up

Feel free to drop comments or improve my characterisation of the moving parts of the API.

Note there are a few moving parts, and a few options:

1. CMS or file option for managing DGGS registry content
2. static files, general UI and custom UI viewer for both machine and human readable profiles
3. A limited view (profile) for API use is assumed - its possible this is not needed and the entire registry entry would be exposed to the API
4. JSON schema defines API, JSON-LD context decorates content to link schema elements to definitions
5. codelists are managed separately to DGGS but all are available to end API using same mechanisms

This is a bit scary - but in fact all the implementation architecture for the Definitions Server is in place - implementation means defining the DGGS ontology, profile if needed and custom forms, entailment/processing and viewers. Matt Purss has a DGGS registry django plugin already which may provide much of what we need. (I didnt add that generating the static HTML rendering can be done via the CMS as well as pushing the RDF definitions content - we just need to add some actions to fetch and persist these as static files in the github repo)

[ghobona]

Cc: @rob-metalinkage

[jerstlouis]

Retitling this issue.

The need for a DGGRS registry is definitely there, very similar to the concept of the 2DTMS registry.

We now have an informative schema in Annex B of the candidate OGC API - DGGS (a normative version may be a future part of Topic 21 or in a future revision of OGC API - DGGS), along with example definitions and the deployment of a registry together with the publication of the Standard would be very helpful.

See https://github.com/opengeospatial/ogcapi-discrete-global-grid-systems/tree/master/core/schemas/dggrs-definition .

cc. @rob-metalinkage @avillar

[jerstlouis]

Additional notes:

The primary use case is Use Case 2 for now (the DGGRS registry proposed to be at https://www.opengis.net/def/dggrs/).

It's not clear what "DGGS" referred to in Use Case 1.
Perhaps it referred to the concept of Discrete Global Grid Hierarchy (DGGH) which literature has long called "DGGS".
In this case, the setup of the DGGRS registry could potentially include a separate resource tree at https://www.opengis.net/def/dggh/ cataloging this aspect, which the DGGRS could include using $ref.
Similarly, re-usable zone indexing systems could also potentially exist in https://www.opengis.net/def/zirs. See also #41 (comment) on this topic of re-usable components of DGGRS definitions.

The Topic 21 DGGS definition refers to integrated system including quantization, query and interoperability functionality, such as implementations of OGC API - DGGS. In this sense, a register of such "DGGS" would really be registry of implementations.

For this, we have the Implementations resource in this repository.

There is also the OGC product implementations resource which maintains a list of certified and conforming but uncertified implementations, which would address the case of DGGSs implementing OGC API - DGGS.

Anything else is probably outside the scope of this repository / OGC API - DGGS.