opengeospatial / ogcapi-coverages

OGC API - Coverages draft specification
https://ogcapi.ogc.org/coverages
Apache License 2.0
22 stars 13 forks source link

Different per-band spatial resolutions #142

Open jerstlouis opened 3 years ago

jerstlouis commented 3 years ago

In LANDSAT-8 the panchromatic band (8) is 15 meters/pixels, while most other bands are 30 meters/pixels.

It would be nice at the API level for clients to be able to infer this information, allowing to either request a coverage with different bands of different resolutions, if possible in the requested the data format, and/or requesting different bands individually at different resolutions.

This may trickle down as new CIS requirements / permissions / extensions.

chris-little commented 3 years ago

@jerstlouis We encountered a similar (if not the same) issue in the API-EDR. We chose, simple as possible, to return the data as stored, and the metadata of course reveals the correct resolution. If the requester wants control over the resolution of the returned data, we supported that in the Corridor query. We may have chsoen the wrong parameterisation in that case, but time will tell. As the data returned is generally a small subset of a full coverage, it may not suit the Coverage API use cases.

jerstlouis commented 3 years ago

Thank you @chris-little. Some of the main challenges here are:

Those specific issues might not have been relevant to EDR.

chris-little commented 3 years ago

@jerstlouis If those multiband coverages are being used with Index CRS, I would argue that is not a valid use - the CRS should be the same for all bands - otherwise it is a coverage collection. The onus is on the service providers to structure the bands correctly and consistently. A similar problem occurs in meteorology, where many traditional datasets have upper air data plus surface data. To make a valid Collection for OGC APIs, they should be in seperate Collections, if the upper air vertical coordinate is not height above the surface. HTH

jerstlouis commented 3 years ago

So here is an idea which might work:

We have a similar pattern in OGC API - Tiles for multi-layer tilesets, supporting the selection of specific collections with the collections= query parameter, which will modify the layers included in the response. A similar solution could also solve a similar problem for reporting the domainset for alternate output CRS with the CRS extension.

jerstlouis commented 1 year ago

We could easily define an x-ogc- field for this as part of #173 that could allow this flexibility for encodings that support different resolution per band/field, or for when retrieving only fields of a particular resolution.