<div dir="ltr"><div>Thank you Francesco and Ricardo.<br><br>My organization is a research
institute, and currently I am investigating on how to use the API,
trying to make some proof of concept.<br><div>I could (and would like to) try helping, but first of all I need to fully understand how it works (or should work).</div><div>I'll make some more questions hoping they require a short answer to not waste your time.<br></div><br><div>At the moment I am interested in response type 'raw' only.</div><div>I would like to initially focus on transmission mode 'value', and then would like to consider the 'reference'.</div><div><br></div><div>The outputs of the test process "hello_world" is one 'object', "echo", with the properties (not defined in the metadata) 'id' and 'value'.</div><div>The class API, in method execute_process(), <i>if mime_type == 'application/json'</i> serializes the output.</div><div>The mime_type is set by the process "hello_world".<br></div><div>Now, if "hello_world" returned an application/json, I would expect it to be a string, therefore not to be serialized.</div><div>Am I missing something?<br></div><div><br></div><div>In any case, is it correct (in this specific case of a single output value) the returned 'body' contains the process output ?<br></div><div></div><div><br></div><div>If I had the outputs section of the process metadata defined as the following:<br></div><div> 'outputs': {<br> 'output_file': {<br> 'title': 'Some title',<br> 'description': 'A generic file',<br> 'schema': {<br> 'type': 'string',<br> 'contentEncoding': 'binary'<br> }<br> }<br> },</div><div>should I
expect the returned body to be a binary stream encoded base64?</div><br>If the outputs section were:<br>outputs: {<br> 'test_1': {<br> type: string<br> },<br> 'test_2': {<br> type: string<br> }<br>}<br>and the actual values from the process output were:<br>test_1 = "abc"<br><div>test_2 = "123"</div><div>I understand the mime_type should be set to 'multipart/related', but what about the body?<br></div><div>Please, can you write the text of the body I should get from such an execute request.<br></div><br></div><br><div><div><div>Thank you very much in advance for your time.<br></div><div>Hope to be able to contribute shortly.</div><div><br></div><div>Francesco<br></div><div><br></div><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno mer 6 dic 2023 alle ore 20:59 Francesco Bartoli <<a href="mailto:xbartolone@gmail.com">xbartolone@gmail.com</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div name="messageBodySection">
<div dir="auto">Hi Francesco,<br>
<br>
First of all, thanks for reaching the pygeoapi community out and point out the lack of compliance for the capabilities of OGC API Processes.<br>
I would second the comment from Ricardo and I do believe that part would definitively need some love.<br>
The best you can do at the moment is in sparse order:<br>
- 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;<br>
- Contribute to the project by forking and sending a pull request to close the issue;<br>
- Fund a service provider to do the work for you if it is crucial for your organisation.<br>
<br>
Hope this helps.</div>
</div>
<div name="messageSignatureSection"><br>
Kind regards,
<div dir="auto">Francesco</div>
</div>
<div name="messageReplySection">On 6 Dec 2023, 18:32 +0100, Ricardo Filipe Soares Garcia da via pygeoapi <<a href="mailto:pygeoapi@lists.osgeo.org" target="_blank">pygeoapi@lists.osgeo.org</a>>, wrote:<br>
<blockquote type="cite" style="border-left:thin solid grey;margin:5px;padding-left:10px">
<div dir="ltr">
<div>Hi Francesco</div>
<div><br></div>
<div>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:</div>
<div><br></div>
<div>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)<br></div>
<div>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:<br></div>
<div><br></div>
<div>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)</div>
<div><br></div>
<div>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</div>
<div><br></div>
<div>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)</div>
<div><br></div>
<div>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</div>
<div><br></div>
<div>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). </div>
<div><br></div>
<div>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</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div><br></div>
<div>I hope this makes it a bit clearer.<br></div>
<div><br></div>
<div><br></div>
<div>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').<br></div>
<div><br></div>
<div>
<div>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:</div>
<div><br></div>
<div><a href="https://github.com/opengeospatial/ogcapi-processes/issues" target="_blank">https://github.com/opengeospatial/ogcapi-processes/issues</a></div>
<div><br></div>
<div>I guess asking them here might also be appropriate.<br></div>
<div><br></div>
<div><br></div>
<div>Best regards<br></div>
</div>
<div><br></div>
<div><br></div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Francesco Martinelli via pygeoapi <<a href="mailto:pygeoapi@lists.osgeo.org" target="_blank">pygeoapi@lists.osgeo.org</a>> escreveu no dia quarta, 6/12/2023 à(s) 16:29:<br></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi there,<br>
I am not sure this is the appropriate mailing list where to ask:<br>
if this is inappropriate I apologize,<br>
and if possible I ask to advise where should I post my question.<br>
<br>
Reading the OGC API - PROCESSES -Part 1: CORE<br>
I don't find a way (if possible) to retrieve a single output result from<br>
a job.<br>
Specifically I am looking to paragraph 7.13<br>
<br>
If I submit an execute request, and I get back a UUID for the job (i.e.<br>
a 'Location' in the header, where the location contains the UUID/jobID),<br>
then I can thereafter get the results of the job on the path<br>
/jobs/{jobID}/results.<br>
<br>
However if I had multiple outputs (possibly of sensible size)<br>
and I want to get only one,<br>
I don't find a way to get only that single output: is it possible?<br>
If positive: how to specify this request?<br>
<br>
<br>
Thank you,<br>
Francesco<br>
_______________________________________________<br>
pygeoapi mailing list<br>
<a href="mailto:pygeoapi@lists.osgeo.org" target="_blank">pygeoapi@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/pygeoapi" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/pygeoapi</a><br></blockquote>
</div>
<br clear="all">
<br>
<span class="gmail_signature_prefix">--</span><br>
<div dir="ltr" class="gmail_signature">___________________________ ___ __<br>
Ricardo Garcia Silva</div>
_______________________________________________<br>
pygeoapi mailing list<br>
<a href="mailto:pygeoapi@lists.osgeo.org" target="_blank">pygeoapi@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/pygeoapi" target="_blank">https://lists.osgeo.org/mailman/listinfo/pygeoapi</a><br></blockquote>
</div>
</div>
</blockquote></div>