search

geopython / pygeoapi

pygeoapi is a Python server implementation of the OGC API suite of standards. The project emerged as part of the next generation OGC API efforts in 2018 and provides the capability for organizations to deploy a RESTful OGC API endpoint using OpenAPI, GeoJSON, and HTML. pygeoapi is open source and released under an MIT license.
https://pygeoapi.io
MIT License
499 stars 261 forks source link

Default format for coverage data is invalid #1825

Open barbuz opened 1 month ago

barbuz commented 1 month ago

Description When requesting coverage data without specifying an output format we get an exception "Invalid format requested".

Steps to Reproduce I have reproduced it locally, but this can be easily seen from the demo server: stable: https://demo.pygeoapi.io/stable/collections/gdps-temperature/coverage latest: https://demo.pygeoapi.io/master/collections/gdps-temperature/coverage

Expected behavior We should get the data as json, the same result we get when appending ?f=json to the url e.g. https://demo.pygeoapi.io/master/collections/gdps-temperature/coverage?f=json (can take up to a minute, add some filters to speed it up)

Screenshots/Tracebacks image

Environment Specs for my local deployment (I am not sure about the ones of the demo server)

Additional context This was working fine before version 0.16. I am not sure what introduced this bug.

From my initial investigation it appears that the format being passed is html, which is not a valid format for coverage.

barbuz commented 4 weeks ago

Turns out that the OGC specs specify using HTTP content negotiation to choose the output encoding for resources. This means that a bare request from a browser is going to receive an HTML answer since that is the format that is going to be requested in the headers by the browser.

However, neither of our coverage providers support HTML output, and it is not clear what kind of structure this output would have anyway, so they end up throwing an error instead of giving the user something useful. The OGC specs don't require HTML to be supported, so everything is adhering to them, but the result is less usable than it could be.

The solution to this could be to either add HTML support to the coverage providers (but we would need a good idea to define what this even means) or to revert back to the previous behaviour where a request that does not specify a format results in a coverageJSON output (less strictly following the specs but more useful to the users than the current situation).

I would be happy to provide a PR to implement the second option, but I would like to hear some opinion about this.