WPS Output Arrays not supported

[christophenoel]

We reported one well-known issue regarding to the possibility to report list of files as outputs.

List of outputs is indeed disallowed by spec : (http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process/output-value-cardinality Each process output shall have a value cardinality of one)

The following workarounds are generally used:

1. Return a list of outputs (despite is forbidden)
2. Return an archive (zip) which is very resource consuming (for large files)
3. Return a Metalink (allows also multiple formats in response)
4. Return Multipart/mixed (not supported by browsers, difficult implementation).

How can we improve the spec regarding that problem ?

[ghobona]

The object returned could itself be a collection/list. For example, returning a single GML document that is itself a gml:FeatureCollection. This is already supported even with a cardinality of one in the output.
Coverages might be slightly more challenging. CoverageCollection was discussed in 2016 as a proposal for a WCS extension.
https://portal.opengeospatial.org/public_ogc/sched/agenda.php?meeting=1603tc&my_session=44166

[christophenoel]

No, you consider XML/JSON document, but EO processing outputs are often binaries (TIF, HDF5, etc.) so you cannot make collections of files (excepted using an archive).

[ghobona]

@spacebel , you are right. We might need an array or list of outputs to be able to support various types of content.

[gfenoy]

From this UI if you input the following information in the "Execute EndPoint" tag:

• ProcessId: mm.vector-tools.BufferPy
• Request Body:

{
	"inputs": [
	{
		"id": "InputPolygon",
		"input": {
			"format": {
				"mimeType": "application/json"
			},
			"value": {
				"href": "https://demo.pygeoapi.io/master/collections/utah_city_locations/items?f=json"
			}
		}
	}
         ],
	"outputs": [
	{
		"id": "Result",
		"format": {
			"mimeType": "application/json"
		},
		"transmissionMode": "value"
	}]
}

Then if you press the "Execute" button, the process is run and (in case you did not ask to run the service asynchronously) the outpuInfois automatically returned (I know this is only at the discussing state to return something for execute requests - see #30) but just to illustrate (note also that we are relying on pygeoapi.io server to access "OGC API - Features" and use them as input data for processing).

What I have found in this model made me think that in case the result is in "application/json" format and the result should be returned as inlineValue (meaning "transmissionMode": "value") then the result can be inserted as an object.

I think we may try to use the "Any Type" defined in OpenAPI like I tried to do in the messy additionalParameters I have edited trying to integrate the additionalParameters.

In case we move to inlineValue to "Any Type", it means that we will then be able to return an array as the JSON object used in this example.

[christophenoel]

I'm not catching what you mean, but the solution will need to handle all kind of outputs (including outputs by reference). If understood correctly, you mention another example of process that can embed multiple "documents" in a single output, but this is well understood.

A considerable part of processing outputs are binaries.

[bpross-52n]

See also #90

[fmigneault]

I agree with @gfenoy regarding the transmissionMode.
If transmissionMode="value" and the format is application/json, we can return something like follows:

{
  "id": "Result"
  "value": [
    "file1",
    "file2", 
    "..."
  ]
}

But if transmissionMode="reference", only a single file should be returned as it was specifically requested.
Considering this, I believe metalink would be the best approach.

{
  "id": "Result"
  "value": "multi-files.metalink"
}

[christophenoel]

I disagree.
The aim of the format property is to describe the output file(s) format (is the output file a GeoTiff, GeoJson, etc.) not how the WPS shall format the result response.

You can only state JSON format if the output file is actually a JSON file.

[fmigneault]

Maybe it wasn't clear. I was not referring to the format field of the output but the format of the response, as requested with f query or Accept header.

[bpross-52n]

The respective changes should be merged now.