Weaver: Workflow Execution Management Service (EMS); Application, Deployment and Execution Service (ADES); OGC API - Processes; WPS; CWL Application Package
Given a process execution, normally (Core specification), the resulting outputs are literal data directly provided, or a URI to a file where it can be retrieved.
This feature adds the response query parameter provided in the execution request to obtain the result through a OGC API /collections/... capable endpoint.
The resulting collection must support (at least) one of OGC API data access mechanisms (e.g., OGC API - Tiles, Coverages, DGGS, Features, EDR, Maps) as defined by OGC API - Common - Part 2: Geospatial data.
⚠️ Pre-requirements:
The process must have only 1 output (from its outputs definition), or a single output must be explicitly selected when multiple are available, using the outputs field in the execution request.
Selection of the outputs depends on #380 to be implemented.
The process should ideally verify if a Collection Output is a valid type of representation for the unique/selected output.
This is maybe not so trivial depending on cases. For example, if the output is:
Feature Collection (GeoJSON): this makes sense
literal data: this probably doesn't make sense
Bounding Box: could be a single item GeoJSON Collection (requires conversion with shapely)
GeoTiff: could make sense, but must it be represented as STAC Single-Item Collection? Should certain STAC extension be inferred... (relates to #103)
Other complex data? Depends on what it is...
The produced output must be POST'd to a (remote) catalog to fulfil the requirement that the linked collection data must be accessible/filterable. It cannot be a simple static document. Therefore, this output catalog must be configurable (similar to how S3 output bucket can be configured).
fmigneault
commented
4 months ago
Description
Given a process execution, normally (Core specification), the resulting outputs are literal data directly provided, or a URI to a file where it can be retrieved.
This feature adds the
responsequery parameter provided in the execution request to obtain the result through a OGC API/collections/...capable endpoint.The resulting collection must support (at least) one of OGC API data access mechanisms (e.g., OGC API - Tiles, Coverages, DGGS, Features, EDR, Maps) as defined by OGC API - Common - Part 2: Geospatial data.
⚠️ Pre-requirements:
outputsdefinition), or a single output must be explicitly selected when multiple are available, using theoutputsfield in the execution request. Selection of the outputs depends on #380 to be implemented.shapely)The produced output must be POST'd to a (remote) catalog to fulfil the requirement that the linked collection data must be accessible/filterable. It cannot be a simple static document. Therefore, this output catalog must be configurable (similar to how S3 output bucket can be configured).
Adds support of:
http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/collection-outputresponse=collection, return HTTP 303 See Other,Location: <collection-uri>response=landingPage, idem ascollection, but the link is the root of the server with/collectionslisted within itslinkshttp://www.opengis.net/spec/ogcapi-processes-3/0.0/req/output-fields-modifiersReferences