You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 Filter out non-requested outputs #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 Support for STAC metadata #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).
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
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.
outputs
definition), or a single output must be explicitly selected when multiple are available, using theoutputs
field in the execution request.Selection of the outputs depends on Filter out non-requested outputs #380 to be implemented.
This is maybe not so trivial depending on cases. For example, if the output is:
shapely
)Adds support of:
http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/collection-output
response=collection
, return HTTP 303 See Other,Location: <collection-uri>
response=landingPage
, idem ascollection
, but the link is the root of the server with/collections
listed within itslinks
http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/output-fields-modifiers
References
filter
operations withfilter-lang=cql-text|cql-json
using CQL2 #640The text was updated successfully, but these errors were encountered: