Per SWG discussion on May 6, 2024 there was agreement to focus upcoming work on the "Profiles" concept put forward by Ecere during Testbed-19. For the processing element of this, focus will be given to developing an approach that allows the input to and outputs from a process to be accessed in the same way. How the process is actually executed could then be determined by the client (e.g. using OGC API - Processes, openEO, WCPS, etc.).
Ecere's text from Testbed-19 is presented below. Also refer to the Testbed-19 ER
4.1. Profiles proposal by Ecere
Ecere’s vision of an OGC GDC API standard is based on profiling existing capabilities defined by other OGC approved and draft standards, such as OGC API — Processes and OGC API — Coverages. This avoids defining yet another way to retrieve data from data cubes, while ensuring that the GDC API definition remains in sync with the still evolving OGC API capabilities.
Different profiles could be defined, regrouping a set of minimal capabilities that must be implemented to conform to each profile.
A “Core” profile could define the minimal capabilities to conform to the GDC API specification, including the ability to retrieve specific fields from a GeoDataCube for a given area, time and resolution of interest. This corresponds to the OGC API — Coverages — Part 1: Core‘s “Core”, “Subsetting”, “Scaling” and “Field Selection” requirement classes.
A “Processing” profile could define the capability to provide a custom execution request to execute a workflow integrating predefined processes and data available from the API or from any other GDC APIs, while remaining flexible as to the content of that execution request. This would correspond to the “Core” and “OGC Process Description” of OGC API — Processes — Part 1: Core, as well as to the “Collection Input”, “Remote Collection”, and “Collection Output” requirement classes of Processes — Part 3.
Processes — Part 3 “Collection Output” would act as the glue ensuring that any client supporting access to a GeoDataCube using the Core profile, can also access data from a GeoDataCube generated on-the-fly by a processing workflow using that same Core capability, as defined in OGC API — Coverages, with only the additional step of submitting the execution request using an HTTP POST operation, resulting in a virtual GeoDataCube. Accessing such a virtual GeoDataCube from an execution request is already partially supported by the GDAL OGC API driver.
Similarly, the Processes — Part 3 “Collection Input” and “Remote Collections” would be the glue to allow using data from any OGC GDC API conformant server implementing the Core profile, including those implementing Processing profile, as an input to a GDC processing workflow.
The specific content of the submitted ad-hoc execution requests would be defined by additional profiles, using mechanisms also defined in OGC API — Processes — Part 3, including extensions to the Processes — Part 1 execution requests for “Nested Processes”, “field modifiers” using CQL2 expressions, as well as alternate workflow definition languages such as “Common Workflow Language (CWL)” and “OpenEO process graphs”. Only clients crafting the workflow defined within the request would need to care about the content of the execution requests. Clients simply accessing and visualizing the resulting GeoDataCube simply submit the request as it is handed to them.
A “CQL2” Profile could support CQL2 expressions to define filters and derived fields directly as part of data requests, without necessarily implementing the “Processing” profile, but implying support for field modifiers when combined with the “Processing” profile. CQL2 expressions provide a very intuitive and compact way to express simple arithmetic calculations such as vegetation indices, as well as more complex use cases, including several uses cases discussed during the Testbed which were then described using more verbose process graphs.
A separate GDC profile could potentially be defined for the different openEO capabilities based on the proposed openEO OGC Community Standard, which differs in some respects from OGC API — Processes.
Per SWG discussion on May 6, 2024 there was agreement to focus upcoming work on the "Profiles" concept put forward by Ecere during Testbed-19. For the processing element of this, focus will be given to developing an approach that allows the input to and outputs from a process to be accessed in the same way. How the process is actually executed could then be determined by the client (e.g. using OGC API - Processes, openEO, WCPS, etc.).
Ecere's text from Testbed-19 is presented below. Also refer to the Testbed-19 ER