search

opengeospatial / ogcapi-coverages

OGC API - Coverages draft specification
https://ogcapi.ogc.org/coverages
Apache License 2.0
22 stars 13 forks source link

Processing end-point and integration with OGC API - Processes, and support for modular workflows #79

Open jerstlouis opened 4 years ago

jerstlouis commented 4 years ago

Currently, the draft processing spec suggests /collections with a q query parameter for passing e.g. a WCPS requests.

However, /collections is defined in Common - Part 2, and a q parameter is too generic for an extension at this end-point in this manner. A q parameter changing completely the nature of the response to a GET request at this end-point, which normally returns a list of collections, does not seem appropriate either. Moreover, processing may act on coverages spread out across different datasets (or even different services), and may be part of a workflow chain, where /collections would not be an appropriate end-point for this.

I suggest instead a dedicated processing resource at /processes/wcps to receive WCPS processing requests. This could live at multiple end-points within an OGC API tree, for example for a single collection, for a dataset, and for a multi-dataset API (as detailed at https://eratosthenes.pvretano.com/Projects/tb16/ogcapi/datastores.html, with these 3 separate processing end-points). Such an extension would also not specifically require WCPS, and algorithms could be submitted in other languages (e.g. openEO). This is also consistent with a similar approach suggested for OGC API - Maps (https://github.com/opengeospatial/OGC-API-Maps/issues/42).

A request would be posted to this end-point following a process execution schema defined by OGC API - Processes and being refined in Modular OGC API Workflow projects ( as detailed in https://github.com/opengeospatial/wps-rest-binding/issues/47#issuecomment-664508833 ). If Processes is fully supported, this would also be a self-describable end-point which explains that this receives WCPS code.

Potentially this end-point may also supporting WCPS directly with a WCPS-specific media type, as opposed to a process execution document in the POST payload. If support for a GET request together with a q parameter is desired to facilitate access, perhaps this could live at a sub-resource e.g. GET /processes/wcps/queryResult?q=....

pebau commented 4 years ago

@jerstlouis but again, this is violating REST as much as it can. A WCPS request operates on a collection, and returns a collection. This is perfectly resource-oriented.

jerstlouis commented 4 years ago

@pebau Please clarify which part of this you think is violating REST as much as it can.

I understand that some concerns have been raised specifically with the deferred mode, where POSTing to a resource gives the client links back for its own use (which may expire). But I believe that is a very useful alternative to forcing creation of resources which may be very ephemeral in nature, and as an alternative solution preventing to pollute the server with public resources not meant to be shared when no identity management is available. However conceptually even in deferred mode, the original resource is still stateless.

But deferred mode aside (all this can also work with sync and async mode), the main point of this suggestion here is to integrate OGC API - Coverages Processing with OGC API - Processes, where the processes themselves have their own resources organized under a /processes end-point.

A WCPS request operates on a collection, and returns a collection.

I agree with that fully, except that as you pointed out yourself, it may operate on more than one collection, which may be spread out between multiple datasets and/or services.

The enhancement we are suggesting to OGC API - Processes based on the Modular OGC API Workflows process execution schema design discussions is precisely to treat inputs and outputs of a processes as first class resource objects (in addition to the processing resources themselves).

ghobona commented 4 years ago

@jerstlouis I understand your concerns on this.

@bpross-52n @Schpidi I would suggest that this issue be discussed with the feedback from the Public Review.

pebau commented 4 years ago

@jerstlouis

I agree with that fully, except that as you pointed out yourself, it may operate on more than one collection, which may be spread out between multiple datasets and/or services.

exactly, therefore just collection/ is used, without a name qualifier, effectively working like a wildcard. The concept is just following the RESTful approach that a request addresses a resource (the collection, ie: server offering) to get a representation (ie: the somehow processed result).

jerstlouis commented 4 years ago

@pebau /collections is still limited to a single dataset, and single service, and we are trying to support beyond that. (in addition to the fact that a GET on that resource should always mean the same basic thing, i.e. "give me back the list of collections for this dataset", not actual data or process execution).