Process execution request parsing not aligned with OGC API - Processes

[ricardogsilva]

Description When asking for the execution of a process, pygeoapi parses the incoming request and only keeps the inputs property of the request:

https://github.com/geopython/pygeoapi/blob/f436f0553f36213fb7be43f19a37d30c143c1c8a/pygeoapi/api.py#L3558

According to OGC API - Processes, an execution request has other relevant properties, such as:

• outputs - allows the client to request different transmission modes (by value or reference) and also to select between available media-types for each output - as such, only the default transmission mode (by value) and for a single media type per output are supported

• response - allows the client to either ask for a raw response or a document response. As such, only the default value, wich is raw response, is supported

• subscriber - allows the client to ask to be notified when processing is over.

In order to be inline with the spec, pygeoapi ought to pass all properties of the execution request down to the process manager and onto processes, and implement these alternative process execution features

[totycro]

We actually need the subscriber property in our company, so I'm going to look into this.

[totycro]

^ this PR is a straightforward implementation of subscriber, we can discuss if anything more advanced/different is needed

[StefanBrand]

@tomkralidis @ricardogsilva Please, comment on the status of this issue and the related merge request(s). We would like to send Slack messages for finished jobs.

[ricardogsilva]

@StefanBrand

To the best of my knowledge there hasn't been much progress on this.

I've reviewed the proposed PR back in July and I'm +1 for it to be merged (with some smaller tweaks, which have mostly already been addressed).

Personally I'm more interested in having support for outputs, as that would unlock a lot of customization in how processes are run - I'm also waiting on the pending PR to be merged so that I can work on implementation of outputs after it.

There could however be some deeper plan for this, as I am not fully in the loop of all the latest OGC-related developments. So I guess the status of this is that we are waiting on @tomkralidis input.

[github-actions[bot]]

As per RFC4, this Issue has been inactive for 90 days. In order to manage maintenance burden, it will be automatically closed in 7 days.

[StefanBrand]

Related PRs #1313 and #1448 were updated 5 days and 34 days ago, respectively.

[github-actions[bot]]

This Issue has been inactive for 90 days. As per RFC4, in order to manage maintenance burden, it will be automatically closed in 7 days.

[StefanBrand]

Current status if I'm not mistaken:

• subscriber: #1313 was merged on March 11th
• outputs: #1602 was merged on May 10th
• response: currently not implemented

[tomkralidis]

* `response`: currently not implemented

Note that response is implemented. PR #1756 adds updates for supporting binary data when a process execution requests response: document. I've also updated the documentation with pygeoapi's OAProc implementation details/nuances for good measure (thanks to @ricardogsilva for the valuable discussion today to help clarify this).