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:

pygeoapi/pygeoapi/api.py

Line 3558 in f436f05

data_dict = data.get('inputs', {})

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]

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]

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: ogc api processes subscriber #1313 was merged on March 11th
• outputs: Add support for parameter Outputs of OGC API Processes #1602 was merged on May 10th
• response: currently not implemented