Clarify how OGC API-Processes receives coverage data from implementations of OGC API - Coverages

[ghobona]

Section 7.9.2 and 7.11.2 present examples that show "inlineValue": "". It is unclear, from the example, how coverage data retrieved from an implementation OGC API - Coverage would be passed to an implementation of OGC API - Processes.

Does mean that one would perhaps reference a coverage via URL?

Please coordinate with the Coverages SWG to identify a suitable example.

[jerstlouis]

@ghobona @Schpidi @pebau

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:

{
   "id" : "EVI",
   "process" : "http://server.com/ogcapi/processes/CoverageProcessor",
   "inputs" : [
      {
         "id" : "data",
         "collection" : "http://somewhereelse.com/ogcapi/datasets/somedataset/collections/someCoverage"
      },
      { "id" : "code", "value" : 
            "double BLUE = data[bands:'B02'], RED = data[bands:'B04'], NIR = data[bands:'B08'];"
            "return min[time](2.5 * (NIR - RED) / (1 + NIR + 6*RED + -7.5*BLUE));"
      }
   ]
}

The result of which, if set up as a virtual collection or using deferred processing, may also be accessed using a Coverages 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).

[pebau]

@jerstlouis

Coverages API which is clueless about the fact that this is the result of a process being executed

cool, so on this URL I can append a /rangetype etc? Such as: http://server.com/ogcapi/processes/CoverageProcessor/rangetype

[jerstlouis]

@pebau Yes, that is the general idea, although rangetype not being a fixed path you should first follow the link relation from the (resulting output) collection description document.

You would normally first POST to {serviceAPI}/processes/{processID}, and receive a collection description document (just as you would with a GET on {datasetAPI}/collections/{collectionId}), as well as an alternate URL where the same document is available via GET (which a non-POST/non-processing enabled Coverages client would presumably be able to consume), and you would follow the link with "rel" : "http://www.opengis.net/def/rel/ogc/1.0/coverage-rangetype" in there to the range type of the resulting coverage.

[ghobona]

All, thanks for the clarification.

I can now close this Issue.