[pygeoapi] PSC vote: RFC5: Enhanced data limit handling

[Ricardo Filipe Soares Garcia da]

Hi all

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

- 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

- 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

- `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

- `defaultitems` and `maxitems` are to be used for limiting the length of
returned lists of features and records

- `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.

- Tom also agreed to consider renaming some of the parameters in order to
be a bit more consistent.

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.

Best regards, and thanks to Tom for his patience :)


Jorge S. Mendes de Jesus via pygeoapi <pygeoapi at lists.osgeo.org> escreveu
(segunda, 6/01/2025 à(s) 14:10):

> I think for now it is good enough
> +1
>
> But it will more efford than expected to have everything at 100%
>
> On Mon, 6 Jan 2025 at 13:36, Youssef Harby via pygeoapi <
> pygeoapi at lists.osgeo.org> wrote:
>
>> +1
>> 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...
>>
>> From: "Angelos Tzotsos via pygeoapi"<pygeoapi at lists.osgeo.org>
>> Date: Mon, Jan 6, 2025, 2:22 PM
>> Subject: Re: [pygeoapi] PSC vote: RFC5: Enhanced data limit handling
>> To: <pygeoapi at lists.osgeo.org>
>> +1
>> Angelos
>>
>> On 1/6/25 03:44, Tom Kralidis via pygeoapi wrote:
>> > Hi all: FYI per subject, putting RFC5 [1] to PSC vote.
>> >
>> > I will start with my +1.
>> >
>> > Thanks
>> >
>> > ..Tom
>> >
>> > [1] https://pygeoapi.io/development/rfc/5
>> >
>> >
>> > _______________________________________________
>> > pygeoapi mailing list
>> > pygeoapi at lists.osgeo.org
>> > https://lists.osgeo.org/mailman/listinfo/pygeoapi
>>
>>
>> --
>> Angelos Tzotsos, PhD
>> President, Board of Directors
>> Open Source Geospatial Foundation
>> https://www.osgeo.org/member/angelos-tzotsos/
>>
>> _______________________________________________
>> pygeoapi mailing list
>> pygeoapi at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/pygeoapi
>> _______________________________________________
>> pygeoapi mailing list
>> pygeoapi at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/pygeoapi
>>
>
>
> --
> OpenPGP Key: 0x7212572C
> _______________________________________________
> pygeoapi mailing list
> pygeoapi at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/pygeoapi
>


-- 
___________________________ ___ __
Ricardo Garcia Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pygeoapi/attachments/20250107/5166cd91/attachment.htm>