STAC source understands "eo" extension

[echeipesh]

STAC specification is fairly un-opinionated about what kind of assets it actually contains. This makes it difficult to "do the right thing" for all catalogs because there is simply not enough information on how to interpret what is contained in the catalog (except that its spatial and temporal, you know).

This is why extensions to the spec exist. A common extension is Earth Observation extension - pictures of earth from the sky. This contains many familiar concepts like bands, band sample range, ground sample distance, cloud_cover, etc. Items that use eo extension may either define the tags in this extension or be part of a collection that defines shared values. Knowing this we can do a better job.

To support eo STAC extension for WCS we need to:

• Parse eo tags from item and collection
• Include eo tags in CoverageSummary as metadata fields.
• Provide Range/Field description for bands
• Use bands information to assemble multi-band imagery.
• Interpret RangeSubset query parameters

Our test case for this should be LC8 STAC catalog created by https://github.com/sat-utils/sat-stac-landsat.

Questions to Verify:

What should be our default behavior when RangeSubset is not specified? Reading the first band may be misleading but reading all bands may require opening multiple files (ex: LC8).

Probably the default choice should be to do whatever can be done cheapest. So if the asset is multi-band file, read it. If bands are spread across asset read and return "band 0".

[echeipesh]

Current implementation of STAC in this project requires the user to do the job of assembling the asset bands and defining a MAML expression to either render or return them as multiband raster. This issue would go a step further and make this process automatic for items that define EO extension.

This is possible future improvement still