Open geofizzydrink opened 2 years ago
< keep these for the "What is Here?" and "Where is it?" classes >
What is Here? class
Where is it? class
CQL conformance class - filtering
4 DGGS classes
@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:
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)
Since it is an API standard compatible with various DGGSs, should we consider adding functions for interoperability of different types of DGGSs?
@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?
@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.
Working out some more of the details for the derived fields and aggregation support I think:
properties
(to select only some of the existing fields, or compute new fields, possibly using aggregration) is used with the Data Retrieval conformance class (.../dggs/{dggsId}/zones/{zoneId}/data
or .../dggs/{dggsId}/data
) -- it specifies what fields / properties will be included in the response (e.g., the GeoJSON, GeoTIFF, netCDF, Zarr file...). When aggregating over dimensions of the DGGS itself, the data retrieval response would return much smaller responses (e.g., a single record with values per zone).properties
is used with a Zone Query request (.../dggs/{dggsId}/zones
), it could mean to include an aggregation in the response, along with the list of zones (assuming the zone list response format supports this). It could default to a Sum()
over all dimensions, if no specific aggregation function is used in a particular field expression..../dggs/{dggsId}/zones/{zoneId}
) by default, if they are quick to compute.
Initial Topics for Elaboration