load_stac eo:bands with int band references (instead of dict)

[soxofaan]

found this in load_stac implementation (about "eo:bands" values):

can also be an index into a list of bands elsewhere

from: https://github.com/Open-EO/openeo-geopyspark-driver/blob/1860326e60f85ce48efa9b7e8b80c5ed542ea9b9/openeogeotrellis/backend.py#L823-L836

Not sure if this is valid STAC, but can but can be found in the wild

e.g. STAC item https://bdc-sentinel-2.s3.us-west-2.amazonaws.com/s2-16d/v2/048/006/2022/09/14/S2-16D_V2_048006_20220914_STAC.json

{
  "type": "Feature",
  "stac_version": "1.0.0",
  ...
  "properties": {
    ...
    "eo:bands": [
      {"name": "B12", ...
      {"name": "SCL", ...
      {"name": "EVI", ...
      {"name": "NDVI", ...
      {"name": "NBR", ...
      ...
    ]
  },
  "assets": {
    "EVI": {
      ...
      "eo:bands": [2]
    },
    "NBR": {
      ...
      "eo:bands": [4]
    }
    ...

asset "EVI" seems to points with "eo:band" 2 to {"name": "SCL", ... from "properties > eo:bands"

[soxofaan]

@m-mohr quick question: as far as I understand STAC and the eo extension this STAC Item example seems invalid schema-wise, right? The items under "eo:bands" must be objects (without any required fields however).

[soxofaan]

another variation of this:

STAC item with integer "eo:bands" values, pointing to "summaries > eo:bands" of parent collection:

STAC Item https://tamn.snapplanet.io/collections/S2/items/12d051c5-8c4d-565c-831c-e9e5bf701e40

{
  "type": "Feature",
  "stac_version": "1.0.0",
  ...
  "assets": {
    "B01": {
      "eo:bands": [0],
      ...
  "links": [
    {"rel": "parent", "href": "https://tamn.snapplanet.io/collections/S2" ...

Parent STAC Collection https://tamn.snapplanet.io/collections/S2

{
  "type": "Collection",
  ...
  "summaries": {
    "eo:bands": [
      {
        "name": "B01",
        "common_name": "coastal",
        "center_wavelength": 4.439,
        "gsd": 60
      },
     ...

[m-mohr]

The eo:bands with integer indices were available in a very old version (STAC < 0.9, I think), I'd ignore them and move the ball back to the data providers to upgrade their catalogs.