OGC API - Processes does not guarantee support for a set of basic math operators
The guaranteed availability of a well defined set of basic operators is much appreciated
As @pvretano mentioned at the Delft GeoDataCube SWG, it is by design that OGC API - Processes "Core" is agnostic to the process definitions.
However, there were lots of discussions going back several years about the concept of a "Well Known Process".
Two examples of these are a process that performs the same routing calculation (and takes the same execution requests and inputs) as OGC API - Routes (currently not part of OGC API - Routes, but potentially a separate part: https://github.com/opengeospatial/ogcapi-routes/blob/master/proposals/clause_8_ogcapi_processes.adoc ).
Another example is a process rendering a map that takes in as input a list of collections to and styles to render them with as layers, as discussed in https://github.com/opengeospatial/ogcapi-maps/issues/42 .
We proposed previously that there could be an OGC registry of "Well-Known Processes" where you can identify a process with a URI, and it corresponds to a particular description (inputs, outputs, and what it does).
The key thing with this URI is that an implementation of OGC API - Processes may decide to implement a particular WellKnownProcess at an arbitrary processId, so only the URI would be normative.
If an implementation is expected to have implemented specific processes at a particular /processes/{processId}, then this would need to be defined in a particular profile of OGC API - Processes.
Because processes in OGC API - Processes are essentially functions, there is also a significant overlap with the concept of CQL2 functions (all of the spatial, temporal relation functions of CQL2 are well-known functions).
Any process that returns a single output is also a candidate for a Well-Known Function (techically, with an array or object return types a function can also effectively return multiple outputs).
I proposed there before a similar concept of a "Well-Known Functions" registry, which would work with CQL2 if the list of function names can declare the URI of the well known-function it implements.
A perfect example is a buffer() geometry manipulation function takes takes a geometry and a distance in meters by which to expand it, and returns the resulting geometry as an output.
All of the Pre-defined processes of openEO are good candidates for Well-Known Processes, and several of them probably as Well-Known Functions as well.
All of the arithmetic operations are already handled by CQL2 Arithmetic Operations.
So there are two possible ways how a set of basic math operators and functions can be guaranteed:
With a particular profile of OGC API - Processes (e.g., "openEO profile"), specifying a list of WellKnown Processes URIs and at which ID they should be deployed
With CQL2, including support for Arithmetic Operations, as well as the necessary basic math functions (which could be defined in a CQL2 extension or profile, and/or in requirement classes of Coverages - Part 2)
Beyond these math operations, all this also applies to aggregation and convolution, such as the Aggregate() and Convolve() functions that I propose in the ER in section 5.1.2.6. Future work: geometry intersections, spatial joins, aggregation and convolution (which could also be both Well-Known functions and Well-known processes), and to some extent to subsetting functions and resampling, though these are handled by data access mechanisms such as coverages.
From Testbed 19 GDC ER Critical Feedback:
As @pvretano mentioned at the Delft GeoDataCube SWG, it is by design that OGC API - Processes "Core" is agnostic to the process definitions. However, there were lots of discussions going back several years about the concept of a "Well Known Process". Two examples of these are a process that performs the same routing calculation (and takes the same execution requests and inputs) as OGC API - Routes (currently not part of OGC API - Routes, but potentially a separate part: https://github.com/opengeospatial/ogcapi-routes/blob/master/proposals/clause_8_ogcapi_processes.adoc ). Another example is a process rendering a map that takes in as input a list of collections to and styles to render them with as layers, as discussed in https://github.com/opengeospatial/ogcapi-maps/issues/42 .
We proposed previously that there could be an OGC registry of "Well-Known Processes" where you can identify a process with a URI, and it corresponds to a particular description (inputs, outputs, and what it does). The key thing with this URI is that an implementation of OGC API - Processes may decide to implement a particular WellKnownProcess at an arbitrary processId, so only the URI would be normative. If an implementation is expected to have implemented specific processes at a particular
/processes/{processId}, then this would need to be defined in a particular profile of OGC API - Processes.Because processes in OGC API - Processes are essentially functions, there is also a significant overlap with the concept of CQL2 functions (all of the spatial, temporal relation functions of CQL2 are well-known functions). Any process that returns a single output is also a candidate for a Well-Known Function (techically, with an array or object return types a function can also effectively return multiple outputs). I proposed there before a similar concept of a "Well-Known Functions" registry, which would work with CQL2 if the list of function names can declare the URI of the well known-function it implements.
A perfect example is a buffer() geometry manipulation function takes takes a geometry and a distance in meters by which to expand it, and returns the resulting geometry as an output.
All of the Pre-defined processes of openEO are good candidates for Well-Known Processes, and several of them probably as Well-Known Functions as well. All of the arithmetic operations are already handled by CQL2 Arithmetic Operations.
So there are two possible ways how a set of basic math operators and functions can be guaranteed:
Beyond these math operations, all this also applies to aggregation and convolution, such as the Aggregate() and Convolve() functions that I propose in the ER in section 5.1.2.6. Future work: geometry intersections, spatial joins, aggregation and convolution (which could also be both Well-Known functions and Well-known processes), and to some extent to subsetting functions and resampling, though these are handled by data access mechanisms such as coverages.