<div dir="ltr"><div>Hi all</div><div><br></div><div>I'm not on the PSC, so not voting really, just wanted to share some additional clarifications I was able to get from Tom after nagging him all afternoon yesterday :P</div><div><br></div><div>- Overall I was a bit confused, as I thought the RFC was too terse - which led me to misunderstand most of it, as I was deducting things which were not in scope. Tom agreed to add a bit more context in order to provide a short description of what these new parameters mean. Once I could understand the context, the document became a lot clearer to me</div><div><br></div><div>- The `units` parameter serves to denote the units of the `maxdistance` parameter. I guess I would just rename `maxdistance` to `max_distance_meters` and mandate that unit would always be meters - but I understand that may be a bit too imposing on users</div><div><br></div><div>- `maxdistance` is to be used for processing requests that want coverage data. I found it strange that its type would be a two-element iterable (as in my mind a distance would be a single number). The intention is to have this represent a maximum width and maximum length that can be requested</div><div><br></div><div>- `defaultitems` and `maxitems` are to be used for limiting the length of returned lists of features and records</div><div><br></div><div>- `on_exceed` also relates to how many items are returned on listings. In this context, if the server is not willing to return as many items as were requested (by means of having limited the number of items via `maxitems`), then it can either choose to `throttle` (i.e. just return the max number it is able to process) or `error`, in which case it will error out and let the user know it will not satisfy requests for so much data at a time. Personally I think I would just implement the `throttle` behavior and never error out if the client requests more items - they would just get less data.<br></div><div><br></div><div>- Tom also agreed to consider renaming some of the parameters in order to be a bit more consistent.<br></div><div><br></div><div>As is maybe evident by the text above, I complained a bit about some of these things. So if anyone were to ask my opinion, I'd say I'm +0 on the RFC. However, at the end of the day, it seems there is a consensus that this proposal is going forward, which is fine by me.</div><div><br></div><div>Best regards, and thanks to Tom for his patience :)<br></div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Jorge S. Mendes de Jesus via pygeoapi <<a href="mailto:pygeoapi@lists.osgeo.org">pygeoapi@lists.osgeo.org</a>> escreveu (segunda, 6/01/2025 à(s) 14:10):<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 dir="ltr"><div>I think for now it is good enough <br>+1<br><br></div>But it will more efford than expected to have everything at 100%<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 6 Jan 2025 at 13:36, Youssef Harby via pygeoapi <<a href="mailto:pygeoapi@lists.osgeo.org" target="_blank">pygeoapi@lists.osgeo.org</a>> wrote:<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 id="m_4867322480610092937m_4184801814453253092editor_version_7.29.0_7sMnISV6" style="word-break:break-word"><div style="margin-top:4px;margin-bottom:4px;line-height:1.6"><div dir="auto" style="font-size:14px">+1</div></div><div style="margin-top:4px;margin-bottom:4px;line-height:1.6"><div dir="auto" style="font-size:14px">Could we also consider allowing maxitems, defaultitems, maxdistance, etc., to support an indicator (like unlimited or -1) for cases where users need the full resource or no limits/pagination applied? This would provide more flexibility without being tied to a fixed number, especially for servers with small layers/resources servers...</div></div><div style="margin-top:4px;margin-bottom:4px;line-height:1.6"><div dir="auto" style="font-size:14px"><br></div></div></div><div id="m_4867322480610092937m_4184801814453253092lark-mail-quote-173616697"><div><div style="border-left:medium;padding-left:0px"><div><div id="m_4867322480610092937m_4184801814453253092lark-mail-meta-5ULpkI8i4" style="padding:12px;background:rgb(245,246,247);color:rgb(31,35,41);border-radius:4px;margin-top:24px;margin-bottom:12px"><div id="m_4867322480610092937m_4184801814453253092lark-mail-quote-366fd6afccda0fb44bd5678093efe945"><div style="word-break:break-word"><div><span style="white-space:nowrap">From: </span> <span style="white-space:nowrap">"Angelos Tzotsos via pygeoapi"<<a style="white-space:pre-wrap;word-break:break-word;text-decoration:none;color:inherit" href="mailto:pygeoapi@lists.osgeo.org" target="_blank">pygeoapi@lists.osgeo.org</a>></span></div><div><span style="white-space:nowrap">Date: </span> Mon, Jan 6, 2025, 2:22 PM</div><div><span style="white-space:nowrap">Subject: </span> Re: [pygeoapi] PSC vote: RFC5: Enhanced data limit handling</div><div><span style="white-space:nowrap">To: </span> <span style="white-space:nowrap"><<a style="white-space:pre-wrap;word-break:break-word;text-decoration:none;color:inherit" href="mailto:pygeoapi@lists.osgeo.org" target="_blank">pygeoapi@lists.osgeo.org</a>></span></div></div></div></div><div><div>+1
<br>Angelos
<br>
<br>On 1/6/25 03:44, Tom Kralidis via pygeoapi wrote:
<br>> Hi all: FYI per subject, putting RFC5 [1] to PSC vote.
<br>>
<br>> I will start with my +1.
<br>>
<br>> Thanks
<br>>
<br>> ..Tom
<br>>
<br><span>> [1] <a href="https://pygeoapi.io/development/rfc/5" target="_blank">https://pygeoapi.io/development/rfc/5</a>
</span><br>>
<br>>
<br>> _______________________________________________
<br>> pygeoapi mailing list
<br><span>> <a href="mailto:pygeoapi@lists.osgeo.org" target="_blank">pygeoapi@lists.osgeo.org</a>
</span><br><span>> <a href="https://lists.osgeo.org/mailman/listinfo/pygeoapi" target="_blank">https://lists.osgeo.org/mailman/listinfo/pygeoapi</a>
</span><br>
<br>
<br>--
<br>Angelos Tzotsos, PhD
<br>President, Board of Directors
<br>Open Source Geospatial Foundation
<br><span><a href="https://www.osgeo.org/member/angelos-tzotsos/" target="_blank">https://www.osgeo.org/member/angelos-tzotsos/</a>
</span><br>
<br>_______________________________________________
<br>pygeoapi mailing list
<br><span><a href="mailto:pygeoapi@lists.osgeo.org" target="_blank">pygeoapi@lists.osgeo.org</a>
</span><br><span><a href="https://lists.osgeo.org/mailman/listinfo/pygeoapi" target="_blank">https://lists.osgeo.org/mailman/listinfo/pygeoapi</a></span><br></div></div></div></div></div></div></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" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/pygeoapi</a><br>
</blockquote></div><div><br clear="all"></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">OpenPGP Key: 0x7212572C</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" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/pygeoapi</a><br>
</blockquote></div><div><br clear="all"></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">___________________________ ___ __<br>Ricardo Garcia Silva</div>