Inputs and Ouputs detailed format

[christophenoel]

We faced in project Testbed 14 the difficuty to express the accurate format requirement in input description. The available mime type attribute is not enough when a process only support Sentinel-2, TerraSAR, Landsat data.

How could we extend the spec to support that ?

[ghost]

I think that those would constitute additional media types. If the data types are so specific that explicit and special handling is needed, they should have equally explicit media types.

http://spec.openapis.org/oas/v3.0.2#media-types

[christophenoel]

Good point. HAve any guidance for constructing a specialized mime type from an existing one.

[christophenoel]

I just remember that we have also hightlighted that inputs may have temporal/spatial constraints. Workflow needs a standard definition for comparing compatible inputs/outputs mapping between processes.

[bpross-52n]

It sounds to me as if this would be something for the Workflows Extension? Otherwise, I would like to invite you to discuss this issue in the next SWG telecon in 2021. Thanks!

[christophenoel]

I have no budget/time to work on this, but from the OGC EO Apps Pilot and OGC Testbed-16, I highlighted the need for an EO extension. (and this has nothing to do with a Workflow extension).

Until now, WPS/Processing API has provided poor facilities for geospatial matters.

Such EO extension would provide:

• means for describing I/O conditions including relationship constraints (e.g. input2 should be on same relative orbit as input1)
• possibility to provide WCS/WFS query parameters instead of a product URL
• etc.

I hope that once I'll have a project to propose such extension ;)

Cheers.

[jerstlouis]

A couple comments going in that direction:

• The proposed Geo Data Class concept (also proposed for associating styles with OGC API collections) could provide additional constraints for inputs, in terms of what kind of vector features (geometry type, schema) or coverages (e.g. bands/range type) are expected
• The Workflow extension allows to reference an OGC API collection instead of an href, for which potentially parameters could be specified as part of a collection input object . Also, bbox / scale / format can be specified separately from the execution request itself.

[fmigneault]

For the sensors, maybe additional MIME-type parameters could maybe be specified like follows? image/geo+tiff; sensor=Sentinel-2 image/geo+tiff; sensor=TerraSAR image/geo+tiff; sensor=Landsat

I don't think there is a limitation to define additional parameters, but it would still need to be standardized for specific sensor names.

[bpross-52n]

SWG meeting from 2024-03-18: Add a Geo Data Class member to the input description. There needs to be an OGC naming authority action with regard to the Geo Data Class. See also https://github.com/opengeospatial/styles-and-symbology/issues/12, #322, #394 and #395