As raised by @tomkralidis at the code sprint in Evora (in the context of OGC API - Coverages), there was confusion about whether the spatial extent grid members in the collection description are in the native (storage) CRS or in CRS84 like the bbox inside the spatial property.
The solution is to replace the storageCrsExtent property outside of the extent by a storageCrsBbox inside the spatial dimension of extent, which makes it clearer that the grid resolution is with respect to this storageCrsBbox (not the bbox always in CRS84 for Earth), or the optional crs which allows specifying an other CRS for the bbox (only allowed for non-Earth data).
Although the grid is not as essential to OGC API - Maps, the storageCrsBbox is, so alignment there is important.
As raised by @tomkralidis at the code sprint in Evora (in the context of OGC API - Coverages), there was confusion about whether the spatial extent grid members in the collection description are in the native (storage) CRS or in CRS84 like the
bbox
inside thespatial
property.The solution is to replace the
storageCrsExtent
property outside of theextent
by astorageCrsBbox
inside thespatial
dimension ofextent
, which makes it clearer that the gridresolution
is with respect to thisstorageCrsBbox
(not thebbox
always in CRS84 for Earth), or the optionalcrs
which allows specifying an other CRS for the bbox (only allowed for non-Earth data).Although the
grid
is not as essential to OGC API - Maps, thestorageCrsBbox
is, so alignment there is important.This is corrected in https://github.com/opengeospatial/ogcapi-maps/pull/131 and should be sync'ed with Common - Part 2 and Coverages.