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
Literals can be provided either directly, or nested under value field during execution.
This nested value allows adding other informational fields next to it.
A common use of extra fields is to provide a unit of measure (uom) defining the "scale" of the specified value, as well as a reference describing the unit itself. This case is sufficiently common to be present in both recent OGC-API examples and PyWPS literals implementations parameters (see references).
ToDo
Detect the uom specified for a literal during execution to include it (ie: add it to the LiteralInput).
Consider parsing of OpenAPI object as literal in this specific case.
With [Feature] Support I/O schema field definition #245, object are either converted to bounding box or complex input/output. This is a new variant that would have to be considered for process description and deployment.
Process "known" uom (see URN shortcuts) when applicable.
Given that uom is the only "known" field, the value itself could be define is many ways (value, measure, measurement, etc.). Since it is required, consider using the required field within the schema to identify where the value is. Otherwise, fallback to those "common" names (?) or raise directly at deployment time that the required field should be specified.
During process deployment
During process execution
Determine given a provided unit of measure during execution, how should this be passed to CWL?
Since CWL is simply a script command, it only passes the value. Converting/scaling the value is not necessarily trivial for more complex or non-metric units.
UoM support blocked by geopython/pywps#685 for non-OGC units.
Also blocked by geopython/pywps#686 to fix reporting of UOMs properly in WPS XML representation.
Description
Literals can be provided either directly, or nested under
value
field during execution.This nested
value
allows adding other informational fields next to it.A common use of extra fields is to provide a unit of measure (
uom
) defining the "scale" of the specified value, as well as areference
describing the unit itself. This case is sufficiently common to be present in both recent OGC-API examples and PyWPS literals implementations parameters (see references).ToDo
uom
specified for a literal during execution to include it (ie: add it to theLiteralInput
).object
as literal in this specific case.With [Feature] Support I/O
schema
field definition #245,object
are either converted to bounding box or complex input/output. This is a new variant that would have to be considered for process description and deployment.uom
(see URN shortcuts) when applicable.uom
is the only "known" field, the value itself could be define is many ways (value
,measure
,measurement
, etc.). Since it is required, consider using therequired
field within theschema
to identify where the value is. Otherwise, fallback to those "common" names (?) or raise directly at deployment time that therequired
field should be specified.Since CWL is simply a script command, it only passes the value. Converting/scaling the value is not necessarily trivial for more complex or non-metric units.
References
schema
example: https://github.com/opengeospatial/ogcapi-processes/blob/d5257909ae9dbb8cf9958ef251e44cb3a903d691/core/examples/json/ProcessDescription.json#L27-L49UOM
class: https://github.com/geopython/pywps/blob/f7f00ecc35fb1750f5fca740bfd9dfe8abdade42/pywps/inout/basic.py#L63-L81The text was updated successfully, but these errors were encountered: