DGGS implications for GeoParquet - what does this mean for OGC API DGGS

[geofizzydrink]

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.

• 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.

1. 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.
2. 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.

[jerstlouis]

@geofizzydrink

I think we've properly addressed points 1 and 2 regarding the link to and the availability of a DGGRS, as well as the need for a URI if the DGGRS definition is published in an authoritative registry. We're also planning to set up an OGC DGGRS registry (#36).

Regarding the more GeoParquet-specific questions, is this in the context of GeoParquet as an encoding for the OGC API - DGGS Zone Data Retrieval requirements class i.e., data from a particular DGGRS zone ID?

In this case, in terms of metadata, just like DGGS-FG-JSON, the DGGRS (as a URI and/or a link to the DGGRS definition), the Zone ID would be useful. The relative zone depth of sub-zones to which the data is quantized or to which the resolution corresponds would also be useful, and essential if geometry coordinates is to be expressed as sub-zone indices (if this is possible as a GeoParquet extension).

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?

The Features API can be used (/items), or the Zone Data resource (.../dggs/{dggrsId}/zones/{zoneId}/data) negotiating a non-DGGS-optimized format (e.g. regular GeoJSON or FG-JSON or GeoParquet) for data living on the server. Anything else I would say is outside the scope of the API, and should rather be handled by a local DGGS software library.

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?

This is an implementation issue and out of scope of the API I would say, though I hope to provide an open-source library facilitating this.

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)

Not sure what a "WKT expression of that DGGS" means -- perhaps you meant a DGGRS here? The URI of a DGGRS in a registry would be the most reliable way to identify a particular DGGRS.

Is there any action to be taken still on this issue, or can we close it?

[geofizzydrink]

I think this requires further discussion as a general DGGS SWG issue - I'll reach out to Robert to see if things have progressed since the original email conversation.

The issue is still open in the main DGGS SWG github repo - https://github.com/opengeospatial/DGGS-swg/issues/2