You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
For some requests there might be a need custom behaviour. This can be implemented using extra parameters in the request which are evaluated later on in providers or plugins. If they're not passed to the request nothing happens. When for example &foo=bar is added to the request this should be available in a dictionary passed to the providers for additional functionality.
@francescoingv
Do you mean the metadata of the table behind the collection?
A Use-Case:
we have a filter for a maximum area for queries with bbox. This makes sense, since some layers might contain a lot of features and they should not be queried at every zoom level and it should not be allowed to, for example query all land properties for the entire USA. However there are certain cases where we want this to happen. Then there might be a parameter passed to the request that could be called allow_big_bbox. This can not be found in the Database Table but can be attached with functionality in a plugin.
There are certainly more use cases, but this one illustrates the problem.
However I think this would still be useful because it provides flexibility for projects using pygeoapi without having to rely on custom implementation in the core of the request logic. Custom implementation comes into play with installable plugins but not at the pygeoapi-core level and allows for projects to define specific behavior later on. A prerequisit is that arbitrary parameters can be passed to the request.
Is your feature request related to a problem? Please describe.
For some requests there might be a need custom behaviour. This can be implemented using extra parameters in the request which are evaluated later on in providers or plugins. If they're not passed to the request nothing happens. When for example &foo=bar is added to the request this should be available in a dictionary passed to the providers for additional functionality.
Describe the solution you'd like
Request can be in the form http://localhost:8080/collections/lakes/items?&foo=bar
and a dictionary containing 'foo':'bar' is avaialable in the providers.
Describe alternatives you've considered
Additional context
@tomkralidis @totycro we talked about this at the vienna code sprint.
The text was updated successfully, but these errors were encountered: