add WCPS as a processing means

[pebau]

The GDC specification should allow WCPS queries the same way it references CQL.

Background: Currently, GDC offers openEO, OAPI-Processing, and CQL. The latter has in common with WCPS that it is a query language approach, albeit with different mechanisms. So both should be possible.

I will be happy to discuss and co-work on prose.

[jerstlouis]

Thanks @pebau

Currently as far as I know, CQL2 is not actually included in the Draft API output from Testbed 19, but like WCPS, it is mentioned in the Summary Engineering Report (D011).

However, I do think CQL2 can play an important role for both "Coverages - Part 2: filtering, deriving and aggregating fields" and for Processes - Part 3: Workflows "input/output modifiers".

Back to WCPS, it could be an alternative way of describing the workflow generating a virtual GeoDataCube (aka Collection aka Coverage), just like an openEO process graph or an OGC API - Processes execution request (whether or not extended with Part 3: Worfklows capability and optional CQL2).

The idea is that you could submit the workflow specification in any way that a given implementation understands using a POST operation, and get back an OGC API Collection (as defined by Common - Part 2: Geospatial Data) from which you can then make OGC API - Coverages request (which could map to the basic "Core" profile of the GeoDataCube API), including the ability to get a description of the coverage, subset the domain and range and request downsampled data.

You would make these Core GeoDataCube description / data requests the exact same way regardless of how the virtual GeoDataCube was defined (using openEO, Processes execution request with or without Workflows/CQL2, or WCPS).

Is that in line with what you have in mind for WCPS integration?

(see also #8)

[pebau]

@jerstlouis yes indeed, as you describe it: several different ways to express workflows.

I would just see it simplified, unless I am getting this wrong: I read a 2-step process where WCPS delivers all in 1 step already. But then again, different mechanisms may employ different methods...

[jerstlouis]

I read a 2-step process where WCPS delivers all in 1 step already.

The 1 step process you mention is WCPS as it is already standardized.

As such, it does not integrate easily with openEO, OGC API - Processes, OGC API - Coverages, or OGC API - GeoDataCubes.

The 2-step process is necessary to facilitate integration with these (which I understand is what we're trying to achieve here):

1. Define the processing workflow you want to perform (operations on one or more input coverages) using the WCPS language (where we ignore the Service aspect of the WCPS standard). Instead, the WCP(S)(language) workflow would be provided as an alternate workflow definition as defined by OGC API - Processes - Part 3: Workflows and/or OGC API - GeoDataCubes.
2. Now that the processing workflow is defined producing a coverage (possibly "virtual", generated on-demand), this resulting coverage can be accessed as usual just like any Coverage aka Collection aka GeoDataCube using OGC API - Coverages, OGC API - GeoDataCubes, OGC API - Processes - Part 3: Workflows "Collection Input", possibly also openEO with the "LoadCollection" process (or by openEO process graphs together with Processes-3: Workflows "Collection Input").

Note that this second step determines the final encoding format (through HTTP content negotiation with an Accept: header), subsetting (with the subset and/or bbox and/or datetime and/or properties parameters) and downsampling (using width/height and/or scale-factor and/or scale-axes and/or scale-size parameters), and this should ideally trickle down to the downsampling / subsetting used by the workflow defined by the WCPS processing, so that it doesn't perform unnecessary processing on parts of the coverage that will get discarded by the request, so as to satisfy that request efficiently.

Similarly, this could also allow integration between WCPS and WCS, so that once you've instantiated your virtual coverage using WCPS, you can reqest data from it using WCS, and that will trigger the WCPS workflow on demand based on the specifics of the WCS request.