Updates to the OGC API - Maps Support

[doublebyte1]

Overview

• Introduced some guardrails for WebMercator, to prevent issues with out of bounds.
• Since the WMS Facade does not support a bbox-crs different than the crs, there is no need to pass a bbox-crs to the provider; however we must ensure that we always pass the bbox in crs coordinates (transform, if needed).
• Support default values for crs, bbox-crs and bbox (read from extent); make sure that the combination of a missing crs and missing spatial extent defaults to 4326;
• Turn an invalid crs to 4326;

This PR also addresses a current issue with the map preview on the collection page, which affects the demo server.

Additional information

Collection preview of the maps provider:

TODOS:

• update unit tests
• update docs

Dependency policy (RFC2)

• I have ensured that this PR meets RFC2 requirements

Updates to public demo

• I have ensured that breaking changes to the pygeoapi master demo server have been addressed
  • https://github.com/geopython/demo.pygeoapi.io/blob/master/services/pygeoapi_master/local.config.yml

Contributions and licensing

(as per https://github.com/geopython/pygeoapi/blob/master/CONTRIBUTING.md#contributions-and-licensing)

• I'd like to contribute [feature X|bugfix Y|docs|something else] to pygeoapi. I confirm that my contributions to pygeoapi will be compatible with the pygeoapi license guidelines at the time of contribution
• I have already previously agreed to the pygeoapi Contributions and Licensing Guidelines

[webb-ben]

Should the bbox-crs not be used to convert the bbox into the requested crs?

[doublebyte1]

Should the bbox-crs not be used to convert the bbox into the requested crs?

Whenever it exists, yes; but this is an optional parameter, so we should have a fallback if we want to support a minimal map query (e.g.: no crs, no bbox-crs, no bbox).

https://github.com/doublebyte1/pygeoapi/blob/b581b8cd93bf8691a5adee34c7ce8fd425784ae0/pygeoapi/api/maps.py#L120-129

[webb-ben]

Makes some sense to me. Is there a reason to derive the default CRS from bbox or should we align this with crs list and storage_crs as implemented for OAFeat?

[doublebyte1]

Makes some sense to me. Is there a reason to derive the default CRS from bbox or should we align this with crs list and storage_crs as implemented for OAFeat?

If we don' t have bbox-crs and bbox as parameters, we still need some defaults to provide a map to the user. The defaults are taken from what is defined on the spatial extents of the collections (bbox and bbox-crs), but I am open to more ideas (:

Examples:
https://demo.pygeoapi.io/master/collections/mapserver_world_map/map?f=png&crs=4326
https://demo.pygeoapi.io/master/collections/mapserver_world_map/map?f=png

If the spatial extents of the collection are not defined in the config, I also defined some defaults. But I am actually not sure, if that is even possible?

In the case of our WMS providers, the storage_crs make less sense, because they are basically facades.