As a SWG we should discuss and come to a resolution of what proposed changes we think would be necessary to enable a GeoParquet data file to know which DGGS it is from via an appropriate set of metadata object(s).
And there is a much deeper discussion that this then leads to regarding what we mean when we say a link to the specific DGGS resource.
do we mean,.. which live DGGS implementation resource can the user leverage to translate data from being in a purely DGGS ZoneID context to being in a coordinate space context?
do we mean,... what is the DGGS library and the specific structural variables that can be used to reliably instantiate an instance of that DGGS library - and then perform a translation between DGGS zoneID context and coordinate space context?
do we mean,... what is the "WKT" expression of that DGGS so I can use a translation library like GDAL/proj to translate between DGGS zoneID context and coordinate space context? (this is the "on-the-fly" concept)
Depending on what data the originating DGGS infrastructure places in the GeoParquet file - is a translation between pure DGGS zoneID context and coordinate space context even necessary? (i.e. coordinate representation of the DGGS Zone in question, and the data it holds/is mapped to, is also included in the data structure)
I'm sure there are other fundamental questions that the above raises...
So... what does this mean from the OGC API DGGS perspective.
Given the challenge in describing the DGGS RS (still very much a draft work in progress) - should provide the space for a DGGS RS definition object/endpoint (as say JSON) if the implementer wishes to do so - but not to make publication of a full structural definition of the DGGS RS mandatory.
in the Core Conformance Class we should require a link to the DGGS RS definition/resource. Where this resource could be:
a) a structural definition of the DGGS RS hosted on the API implementers site;
b) a link to the OGC DGGS Registry for the specified DGGS RS;
c) a link to a live, but external, instance of that DGGS RS.
This discussion is a branch off from the discussion logged in DGGS implications for GeoParquet .
As a SWG we should discuss and come to a resolution of what proposed changes we think would be necessary to enable a GeoParquet data file to know which DGGS it is from via an appropriate set of metadata object(s).
And there is a much deeper discussion that this then leads to regarding what we mean when we say a link to the specific DGGS resource.
Depending on what data the originating DGGS infrastructure places in the GeoParquet file - is a translation between pure DGGS zoneID context and coordinate space context even necessary? (i.e. coordinate representation of the DGGS Zone in question, and the data it holds/is mapped to, is also included in the data structure)
I'm sure there are other fundamental questions that the above raises...
So... what does this mean from the OGC API DGGS perspective.