[pygeoapi] Process - is it defined how to retrieve single output of a job result ?
Francesco Martinelli
francesco.martinelli at ingv.it
Thu Dec 7 00:33:36 PST 2023
Thank you Francesco and Ricardo.
My organization is a research institute, and currently I am investigating
on how to use the API, trying to make some proof of concept.
I could (and would like to) try helping, but first of all I need to fully
understand how it works (or should work).
I'll make some more questions hoping they require a short answer to not
waste your time.
At the moment I am interested in response type 'raw' only.
I would like to initially focus on transmission mode 'value', and then
would like to consider the 'reference'.
The outputs of the test process "hello_world" is one 'object', "echo", with
the properties (not defined in the metadata) 'id' and 'value'.
The class API, in method execute_process(), *if mime_type ==
'application/json'* serializes the output.
The mime_type is set by the process "hello_world".
Now, if "hello_world" returned an application/json, I would expect it to be
a string, therefore not to be serialized.
Am I missing something?
In any case, is it correct (in this specific case of a single output value)
the returned 'body' contains the process output ?
If I had the outputs section of the process metadata defined as the
following:
'outputs': {
'output_file': {
'title': 'Some title',
'description': 'A generic file',
'schema': {
'type': 'string',
'contentEncoding': 'binary'
}
}
},
should I expect the returned body to be a binary stream encoded base64?
If the outputs section were:
outputs: {
'test_1': {
type: string
},
'test_2': {
type: string
}
}
and the actual values from the process output were:
test_1 = "abc"
test_2 = "123"
I understand the mime_type should be set to 'multipart/related', but what
about the body?
Please, can you write the text of the body I should get from such an
execute request.
Thank you very much in advance for your time.
Hope to be able to contribute shortly.
Francesco
Il giorno mer 6 dic 2023 alle ore 20:59 Francesco Bartoli <
xbartolone at gmail.com> ha scritto:
> Hi Francesco,
>
> First of all, thanks for reaching the pygeoapi community out and point out
> the lack of compliance for the capabilities of OGC API Processes.
> I would second the comment from Ricardo and I do believe that part would
> definitively need some love.
> The best you can do at the moment is in sparse order:
> - Open an issue (if it doesn’t exist) to report that our implementation is
> behind the specification with the details of what is not aligned;
> - Contribute to the project by forking and sending a pull request to close
> the issue;
> - Fund a service provider to do the work for you if it is crucial for your
> organisation.
>
> Hope this helps.
>
> Kind regards,
> Francesco
> On 6 Dec 2023, 18:32 +0100, Ricardo Filipe Soares Garcia da via pygeoapi <
> pygeoapi at lists.osgeo.org>, wrote:
>
> Hi Francesco
>
> If I understand the question correctly, then I think table 12 of the OGC
> API - Processes standard provides you with the answer. The way that results
> are accessed depends on your original processing request:
>
> 1. if you requested sync execution, results ought to be transmitted in a
> similar way as the one described for async (more on that below)
> 2. if you requested async execution (or let's say you requested sync, but
> want to retrieve the results again), then it depends on a number of factors:
>
> 2.1. If response type is 'raw' and transmission mode is 'value' and there
> is a single output, then the result will be available at the link indicated
> by the 'Location' header in the raw output type (e.g. a geotiff file that
> was generated as the result of the process execution)
>
> 2.2. If response type is 'raw' and transmission mode is 'value' and there
> are a multiple outputs, then the result will be a multipart/related
> response with each result being a 'part', and they will be available at the
> link indicated by the 'Location' header (e.g. multiple geotiffs generated,
> then response will have all of them concatenated, each will be a 'part' of
> the message) - This is the same way as an email client would transmit
> images via email. Browse the Internet for information on the
> 'multipart/related' media type in order to know more about this
>
> 2.3. If response type is 'raw' and transmission mode is 'reference' and
> there are is either a single output or multiple outputs, then when you
> visit the resource that the 'Location' header links to you will get back an
> empty response body, but the response headers shall contain a 'Link' header
> for each output, with the value of the header being a link for each output
> where you should be able to get each result in its raw output type (i.e.
> there will be a 'Link' header with a link for the actual geotiff generated
> as a process result)
>
> 2.4. If response type is 'raw' and transmission mode is mixed (i.e. there
> are multiple outputs and some of them are to be transmitted by 'value'
> while others by 'reference') then the result will again be a
> multipart/related resource and presumably there will be one 'part' for each
> output that is being transmitted by 'value' and one 'Link' header for each
> output being transmitted by 'reference' - I think this is my interpretation
> of the standard, it does not actually say this though
>
> 2.5. If the response type is 'document', the response will always be a
> JSON document that complies with the relevant 'results.yaml' schema (as
> mentioned in the standard).
>
> 2.5.1 For each generated process result that has its transmission mode
> requested as 'value', the actual result is transmitted in the JSON
> document. If the result it is a JSON type (int, str, object, etc) then it
> is shown directly. If the result is some binary data, then it should be
> encoded as a string, maybe using base64, but there is a provision for
> specifying the encoding of the data and also the media-type of
> theunderlying data - you can check the example 2 provided in section 7.13.2
> of the standard for more info on this
>
> 2.5.2. For each generated process result that has its transmission mode
> set to 'reference' then the response JSON document will include a link to
> the resource.
>
>
> I hope this makes it a bit clearer.
>
>
> Please note that, as mentioned in a previous message, pygeoapi does not
> currently support this form of result retrieval, not yet anyway ;) - it
> effectively ignores whatever form of output generation has been (thereby
> always assuming response type 'raw' and transmission mode 'value').
>
> As for where to post these kinds of questions, I'm not sure, but maybe you
> can open an issue at the standard's github repo? Here:
>
> https://github.com/opengeospatial/ogcapi-processes/issues
>
> I guess asking them here might also be appropriate.
>
>
> Best regards
>
>
>
> Francesco Martinelli via pygeoapi <pygeoapi at lists.osgeo.org> escreveu no
> dia quarta, 6/12/2023 à(s) 16:29:
>
>> Hi there,
>> I am not sure this is the appropriate mailing list where to ask:
>> if this is inappropriate I apologize,
>> and if possible I ask to advise where should I post my question.
>>
>> Reading the OGC API - PROCESSES -Part 1: CORE
>> I don't find a way (if possible) to retrieve a single output result from
>> a job.
>> Specifically I am looking to paragraph 7.13
>>
>> If I submit an execute request, and I get back a UUID for the job (i.e.
>> a 'Location' in the header, where the location contains the UUID/jobID),
>> then I can thereafter get the results of the job on the path
>> /jobs/{jobID}/results.
>>
>> However if I had multiple outputs (possibly of sensible size)
>> and I want to get only one,
>> I don't find a way to get only that single output: is it possible?
>> If positive: how to specify this request?
>>
>>
>> Thank you,
>> Francesco
>> _______________________________________________
>> pygeoapi mailing list
>> pygeoapi at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/pygeoapi
>>
>
>
> --
> ___________________________ ___ __
> Ricardo Garcia Silva
> _______________________________________________
> pygeoapi mailing list
> pygeoapi at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/pygeoapi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pygeoapi/attachments/20231207/04c0512e/attachment.htm>
More information about the pygeoapi
mailing list