* fix Coverage output and format exception MIME type
* Minor tweaks, added test to assert that a text/html header (without 'f' query param) returns JSON for get_collection_coverage()
Co-authored-by: Sander Schaminee <sander.schaminee@geocat.net>
* Created localization (l10n) module + tests. Added l10n support to API and plugins (wip).
* Big refactor:
* All routed API methods are now decorated by @pre_process (consistency) and no longer have a headers+format argument but a request argument (**kwargs also removed)
* The pre_process decorator turns an incoming Flask/Starlette request into a generic APIRequest instance
* The new APIRequest class extracts all relevant info (params, data, locale, etc.) from the request and exposes them as properties
* Removed a lot of boilerplate (i.e. format checking) and wrapped that into methods
* Updated server-specific API calls in each route method (pass entire request object, not headers and query params)
* Several improvements and fixes:
* Updated OpenAPI page with "l" query param
* Added example translations (metadata)
* Changed plugin signature: added explicit locale attribute (instead of **kwargs)
* Moved locale processing to get_plugin_locale() function in l10n module
* API should pass raw requested locale to plugins, locale should always be set
* Fixed API tests and added APIRequest tests
* Prepared utils.py for Jinja2 i18n extension
* Rebased on commit b40297a8 and fixed compatibility with #661 and #662
* Updated documentation for language support
* Rebased and fixed compatibility with PR #658:
* Fixed EDR provider signature (added locale)
* Fixed EDR API routes and query function (and improved parameter-name handling)
* Fixed EDR tests
* Translate entire config in render_j2_template for requested locale:
* Added new translate_dict function to l10n module (+ tests)
* Updated all render_j2_template calls with locale parameter
* Updated pygeoapi-test-config.yml with some language structs
* Minor improvements
* support both 'language' and 'languages' property in server config and provider definitions
* renamed and modified translate_dict() to more generic translate_struct() function (l10n module)
* remove Content-Language header from provider responses if provider has no language support and format is json(ld)
* updated tests
* Leave provider locale handling to API
* Moved code to determine locale from providers to API class (and remove for formatters and processes)
* Removed locale parameter from plugin __init__ signatures
* Removed locale parameter from load_plugin()
* Added **kwargs to provider implementations for get, query, get_metadata, get_coverage_domainset and get_coverage_rangetype method signatures
* Added language=<locale> to all API calls to provider get, query, get_metadata, get_coverage_domainset and get_coverage_rangetype methods
* Use 'lang' instead of 'l' as language query parameter
* Updated Open API
* Updated documentation
* Fixed tests
* Implemented requested PR changes:
* Added usage examples to the APIRequest docstring
* Removed language support from coverage functions
* Updated plugins.rst and language.rst to match new behavior
* Removed language struct from resource links in pygeoapi-config.yml
* Rebased on latest master (fixed test_api.py)
* Rebased and applied fixes:
* Data property in APIRequest now is an awaitable attribute (fixed for Starlette compatibility)
* Named references to 'l' parameter to 'lang'
* Final changes/improvements:
* Make sure that Content-Language is always set;
* Added more tests to ensure that the default language returned is the first configured language (if no language was requested by the user);
* Updated docs;
* Replaced re-occuring strings with constants in api.py;
* Fixed Flake8 checks.
* add missing async to starlette routes (#704)
Co-authored-by: Tom Kralidis <tomkralidis@gmail.com>
* - Added missing parameters on the openapi definition of get an observations tile request
* - changed default background map to osm
Co-authored-by: doublebyte1 <info@doublebyte.net>
This is somewhat unconventional with REST design and leaves it up to the
process implementation to deal with duplicates and invalid IDs, however
it can make sense in certain use cases.
An alternative design would be to encode the desired `job_id` in the url:
`POST /processes/<process_id>/jobs/<job_id>`
This would suggest full control over the `job_id` from the client side,
so I'd prefer to pass the id via POST data. This way we can treat it as
suggestion, or possibly as a template from which the server derives the
actual id.
Tom Kralidis