load_stac: avoid dependency on eo:bands

[jdries]

When loading our own netcdf metadata, I get:
No band assets found in items; a band asset requires an "eo:bands" property with a "name".
While the use of the name in eo:bands is relevant, all stac assets also have a default name, because assets in STAC are represented by a dictionary.
Can we fall back to those names, if eo:bands is not present? I think that would make our load_stac less extension dependent.

[bossie]

Yes, I've been considering this as a best-effort approach. The implicit assumption then is that those are single band assets.

[soxofaan]

Maybe worth mentioning that in the python client we're also started to collect functionality to parse band information from stac:

• No metadata for datacube loaded with load_stac openeo-python-client#527
• Issue527 load stac metadata openeo-python-client#548
• load_stac: get asset metadata from "item_assets" in collection instead of from items openeo-python-client#553

We might want to consolidate efforts here

[bossie]

Any STAC collection I can test this with @jdries? Was it Joris C. who needs this feature and should I ask him?

[bossie]

Related: Open-EO/openeo-processes#488

[JorisCod]

@bossie it is about the Sentinel 1 Mosaics collection, example product here: https://radiantearth.github.io/stac-browser/#/external/catalogue.dataspace.copernicus.eu/stac/collections/GLOBAL-MOSAICS/items/Sentinel-1_DH_mosaic_2023_M08_13XDE_0_0?.asset=asset-PRODUCT

But for further details on the STAC collection, please refer to @VictorVerhaert, he initially checked the collection and identified this issue.

Background info: https://dataspace.copernicus.eu/news/2024-8-6-announcing-sentinel-1-monthly-mosaics-copernicus-data-space-ecosystem

[bossie]

Seems to work if asset key matches the band name in the asset, however:

netCDF batch job results:

• seem to carry "eo:bands" in my case so Just Works; 👍
• without "eo:bands", will attempt to load NETCDF:openEO.nc:openEO.nc because the asset ID becomes the band name, instead of e.g. NETCDF:openEO.nc:B04.

test sentinel-2-l2a STAC API:

• some assets have "eo:bands", some don't but the latter will now be included as well so 👍
• will not return valid STAC Items if requesting fields like proj:bbox etc. are requested so needs the typical workaround;
• also needs a workaround to cope with alternate/s3 hrefs like s3://eodata/Sentinel-2/... which GDAL does not like (either treat as a file on disk or replace with /vsis3).

GLOBAL-MOSAICS STAC API:

• assets don't have the "data" role so needs a workaround;
• lone PRODUCT assets have alternate/s3 hrefs that point to the product directory rather than the raster files themselves so need special treatment 👎

[bossie]

As discussed with regards to GLOBAL-MOSAICS:

avoid bad STAC API at https://catalogue.dataspace.copernicus.eu/stac; instead expose this as regular collection backed by https://catalogue.dataspace.copernicus.eu/resto/api/collections/GLOBAL-MOSAICS/search.json?platform=SENTINEL-1

A new, better STAC API is under way.

[bossie]

Exposed experimental collection SENTINEL1_GLOBAL_MOSAICS, needs proper metadata.

[bossie]

This process graph for the whole of 2023* works on dev and returns 12 assets, as expected:

{
  "process_graph": {
    "loadcollection1": {
      "arguments": {
        "bands": [
          "VV",
          "VH"
        ],
        "id": "SENTINEL1_GLOBAL_MOSAICS",
        "spatial_extent": {
          "east": 116.677065365837,
          "north": 33.88922021846574,
          "south": 33.81885394464797,
          "west": 116.56835783699199
        },
        "temporal_extent": [
          "2022-12-31T23:59:59Z",
          "2024-01-01T00:00:00Z"
        ]
      },
      "process_id": "load_collection"
    },
    "saveresult1": {
      "arguments": {
        "data": {
          "from_node": "loadcollection1"
        },
        "format": "GTiff",
        "options": {}
      },
      "process_id": "save_result",
      "result": true
    }
  }
}

*the API seems to have a quirk in that the start date is considered exclusive (hence 2022-12-31T23:59:59Z instead of 2023-01-01T00:00:00Z to include the results for 2023-01.

[bossie]

In addition to the new SENTINEL1_GLOBAL_MOSAICS collection, the original issue has been addressed in that:

• a role of "data" also qualifies an asset as a load_stac'able asset with bands;
• in the absence of "eo:bands" it will assume a single-band asset of which the band name equals the asset key.

[bossie]

load_stac from test sentinel-2-l2a STAC API works on staging (AOT_60m does not have eo:bands):

data_cube = (connection
             .load_stac("https://test-stac-api/collections/sentinel-2-l2a",
                        spatial_extent={"west": 13.59, "south": 49.56, "east": 13.73, "north": 49.80},
                        temporal_extent=["2024-03-28T10:06:30.000Z", "2024-03-28T10:06:32.000Z"],
                        bands=["AOT_60m", "B01_60m", "B01_20m"])
             .save_result("GTiff"))

[VictorVerhaert]

@bossie is that load stac url correct? It doesn't seem like a proper URL, or is that simply one that is mocked in the tests?
If so with what source could we already try out the 60m bands?