Different per-band spatial resolutions

[jerstlouis]

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]

@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 chosen 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]

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

• in the CIS DomainSet description, I don't believe it is currently possible to specify a different spatial resolution for different bands
• in returning coverage data, for some formats (e.g. CIS and GeoTIFF) all bands are normally expected to be of the same resolution when returning more than a single band

Those specific issues might not have been relevant to EDR.

[chris-little]

@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]

So here is an idea which might work:

• the domainset could be based on the most detailed resolution. e.g. for LANDSAT-8, the panchromatic band
• the domainset resource (e.g. /coverage/domainset) could support the rangeSubset= query parameter to select specific bands. So the request is for /coverage/domainset?rangeSubset=B1,B2,B3 would then report the maximum resolution of bands B1, B2 and B3 (which is half of the resolution if no rangeSubset is provided, since the higher resolution panchromatic band is omitted).

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]

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.

[jratike80]

What if user requests rangeSubset=(B1,B2,B3) as GeoTIFF, and then again rangeSubset=(B1,B2,B8) where B8 has better resolution?
Will the latter give and exception "format does not support different resolutions", or will the server upsample bands B1 and B2?

[jerstlouis]

@jratike80 If the format does not support returning bands at different resolutions, then yes the server should upsample bands B1 and B2 (we already do that in our implementation).

I think it's actually less obvious what happens if the format does support multiple resolutions, and the client requests a particular resolution using scale-factor= vs. scale-size=.
Would the scale-factor be relative to each band, or to the most detailed band requested? (I would suggest the latter).

[jerstlouis]

SWG 2024-12-04:

• We agree to add an x-ogc-spatialResolution to specify a different resolution per field / band
• We need to update the requirements regarding scale-factor to clarify what a 1.0 factor.
• If the representation being returned supports different resolution per band and scale-factor is used, the resolution of each band will computed separately based on its native resolution.
• If the representation being returned does not support different resolution per band and scale-factor is used, the resolution of the most detailed band being returned will be computed, and other bands will be upsampled to that same resolution.
• If other scaling parameters such as scale-size or resolution are used, then all bands will always be returned at the same resolution.