Clarify how OGC API-Processes receives vector feature data from implementations of OGC API - Features

[ghobona]

Section 7.9.2 and 7.11.2 present examples that show "inlineValue": "<test/>". It is unclear, from the example, how features retrieved from an implementation OGC API - Features would be passed to an implementation of OGC API - Processes.

Does <test/> mean that one would add GML or GeoJSON to the request payload?...or does it mean that one would reference a GML or GeoJSON document via URL?

Please coordinate with the OGC API - Features SWG to identify a suitable example.

[jerstlouis]

@ghobona @cportele @pvretano

In #47 , we propose an approach where Collections are inputs and outputs of processes, and where data can be exchanged using the best suited OGC API (including coverages, features, tiles, dggs...). This is the subject of our Modular OGC API Workflows project, and what may become a Workflows extension for OGC API - Processes.

An example MOAW workflow referring to an arbitrary OGC API - Features implementation would look simply like:

{
   "process" : "http://server.com/ogcapi/processes/BufferFeatures",
   "inputs" : {
      "data" : {
         "collection" : "http://somewhereelse.com/ogcapi/datasets/somedataset/collections/someFeatureCollection"
      },
      "distance" : { "value" : 30 }
   }
}

The result of which, if set up as a virtual collection or using deferred processing, may also be accessed using a Features API which is clueless about the fact that this is the result of a process being executed (or even through a Maps API or Map Tiles API rendering that resulting coverage). All this being client-driven (processing only on an as-needed basis).

[ghobona]

Based on the example is Section 7.9.2. Is this example correct?

{
	"id": "EchoProcess",
	"inputs": {
		"complexInputId": {
			"format": {
				"mediaType": "application/geo+json"
			},
			"href": "https://example.org/ogcapi/collections/DaraaRecreationPnt?f=json"
		}
	},
	"outputs": {
		"complexOutputsId": {
			"format": {
				"mediaType": "text/plain"
			},
			"transmissionMode": "reference"
		}
	},
	"response": "document",
	"mode": "async"
}

[jerstlouis]

@ghobona For the Workflows extension, it should use collection instead of href, and not specify query parameters like e.g. f=json or a bounding box, (and not include e.g. /items -- you didn't in this example, but that was inconsistent with the GeoJSON mediaType) allowing the processing service and the data delivery service to negotiate proper encodings, area of interest, etc. Similarly, format is not provided for the input (the usual OGC API format negotiation applies).

mode is also gone in the latest version of Processes, and response and outputs are now optional.