danlooo
commented
7 months ago Yes, the id of the DGGS is part of the data-spec for sure. However, there will be probably no tool loading the data from the abstract DGGS specification directly (list of tesseltaion constraints, refinement strategy, rotation of polyhedron, ...). Instead, the corresponding data loading tools will just look for the DGGS ID , e.g. DGGRID will be called if it's ISEAXX. We will use the OGC dggsRSID for that variable similar to EPSG ids for this field when it'll be available. Is there any new discussions at OGC aftwer Oct 2021? See also https://github.com/xarray-contrib/xdggs/issues/5
The OGC is currently discussing ways to describe and identify unique DGGS types. This is slightly different from storing DGGS data. But the important info here is to be able to store the metadata about the specifics of the used DGGS in form e.g. an identifier, label, link to a detailed definition. This would likely need to include the main type e.g. H3, S2, HEALPIX, RHEALPIX, DGGGRID_ISEAxxx, but also required parameters like HEALPIX (indexing: nested or ring), RHEALPIX (ellipsoid, orientation/rotation ..), DGGRID-icosahedron-based DGGS types (orientation, potentially mixed apertures..), GeoSOT. It would be good to have synergies here and not reinvent the wheel.