opengeospatial / ogcapi-discrete-global-grid-systems

https://ogcapi.ogc.org/dggs
Other
20 stars 8 forks source link

Workshoping the Drafting Process of the OGC API DGGS Spec #47

Open geofizzydrink opened 2 years ago

geofizzydrink commented 2 years ago

Initial Topics for Elaboration

geofizzydrink commented 2 years ago

< keep these for the "What is Here?" and "Where is it?" classes >

geofizzydrink commented 2 years ago

4 DGGS classes

https://docs.opengeospatial.org/DRAFTS/19-079r1.html

jerstlouis commented 2 years ago

@geofizzydrink @allixender @perrypeterson As a follow up to today's meeting, see proposed new API definition and preview in SwaggerUI.

I plan to implement a simple working prototype of it as a next step.

In terms of the later steps, I think they are not necessary to complete Part 1: Core (Core, Data Retrieval: What is here?, Zone Query: Where is it?), but:

chris-little commented 2 years ago

The EDR API SWG memeber have been experimenting successfully with integrating with API-Processes. We are also looking to support categorical dimensions (domain, coordinate) for both retrieving and aggregation. But on the other hand we do not want to re-invent python, R, Jupiter, etc Some aggregation could be straightforward (e.g. time averageing or accumulation, vertical accumulation (e.g. total water column salinity, etc) but others not som clear (e.g. x without y not usually sensible or useful)

BenJin77 commented 2 years ago

Since it is an API standard compatible with various DGGSs, should we consider adding functions for interoperability of different types of DGGSs?

jerstlouis commented 2 years ago

@BenJin77 One API implementation can support multiple DGGS at /dggs/{dggsId}.

However I think that the core of the API should focus on zone queries and data retrieval requests for one specific DGGS.

If the system supports multiple DGGS, it should still be possible to reference collections of data that may internally be stored using different DGGS, returning results according to one specific DGGS. Or to use non-DGGS APIs like Features, Coverages, EDR to return the results in a non-DGGS specific way. And collections= could also potentially support referencing collections available from remote APIs as well (on a different server).

Do you feel this would be missing any other interoperability functionality that you are considering?

rggibb commented 2 years ago

@BenJin77, @jerstlouis I think the issues of having a single query/analysis API that can address different DGGS, or indeed as well as other data types, is a serapate issue from the issue of data type conversion - which includes DGGS data conversion. The important thing as Jerome has stated is that the dggsId is explicit so that the zoneids are well defined and not ambiguous.

We've have talked previously of the need for a DGGS best practice, and I think conversion between different types of DGGS (ie differing dggsId) is a key topic for best practice. There are common statements we can make about data conversion, that cover both conversion between differing DGGS and from DGGS to/from non-DGGS. For instance in discussing conversion from satellite imagery to DGGS, the best practice seems to be to choose a destination resolution that is one step finer than the native non-DGGS resolution, and then potentially agregate the data back to a resolution one coarser in the hierarchy using an agregation statistic appropriate for the source' satellite imagery. This principle can be be applied to any source data type, not just satellite imagery, so the question becomes how much of this conversion do we want to explicitly encapsulate in a standard as distinct from a best practice? The way the standard is progressing towards datatype agnostic analytics, my gut feeling is that all the required filtering and agregation tools will already be present in the API for use in other circumstances eg Derived fields and aggregation support #164.

So with that in mind the only missing bits are the bits about choosing a destination resolution one step finer that the source resolution, the question about whether that resolution is saved for future use, or just temporary, and then the agregation to the next coarser resolution in the DGGS hierarchy. And of couase this is potentlially an instance of a derived field.

jerstlouis commented 2 years ago

Working out some more of the details for the derived fields and aggregation support I think: