titiler `/cog/stac` endpoint: populate `eo:bands commonName` with description (red, green, blue)

[jo-chemla]

Background

Context: I'm trying to load a remote COG on a kepler-gl/demo map app, which requires a STAC item json pointing to the COG in order to load it - for now I'm trying with a standard, 8-bits RGB COG.

The flow to add this COG is, within kepler demo app: Add Data -> Tileset -> Raster Tile, then

• Tileset Metadata URL should point to the STAC item URL
• and Raster-Tile Server should point to a live titiler endpoint, eg https://titiler.xyz

I realized titiler can create such a STAC after PR developmentseed/titiler#1038 from a COG via the endpoint /cog/stac which relies on rio-stac. So I tried to load the STAC generated by titiler given a COG url into kepler map, and unfortunately the user can only select one band preset, with colormap of choice, and not display the trueColor representation of the dataset.

Reason

At the moment, for 3 bands COG, the item eo:bands is generated by rio-stac, with b1, b2, b3 description: red, green, blue.

Unfortunately, for Keplergl to understand the COG is an RGB which can be represented as trueColor, it relies on the bands having the correct commonNames attribute - see kplergl trueColor definition, which expects commonNames: ['red', 'green', 'blue'] to be present in the item bands. Hence why for now the dataset can only be represented as preset: single-band, with either b1..b3 colormapped.

Do you think it could make sense, in addition for rio-stac to populating description with b1: red, b2: green, b3: blue, if the description name is actually a STAC spec common_name, to also populate that field? See the list of accepted common_name's

If so, I can try to do a quick PR to do so.

Example via a test-data COG sample from developmentseed/geotiff-test-data hot-oam: titiler-stac item

Possible similar issue developmentseed/titiler#29

{
  "type": "Feature",
  "stac_version": "1.1.0",
  "stac_extensions": [
    "https://stac-extensions.github.io/projection/v1.1.0/schema.json",
    "https://stac-extensions.github.io/raster/v1.1.0/schema.json",
    "https://stac-extensions.github.io/eo/v1.1.0/schema.json"
  ],
  "id": "cog.tif",
  // geometry, bbox, properties, links": [],
  "assets": {
    "data": {
      "href": "....tif",
      "type": "image/tiff; application=geotiff",
      "raster:bands": [
        {
          "data_type": "uint8",
          "scale": 1,
          "offset": 0,
          "sampling": "area",
          "statistics": { /* ... */ },
          "histogram": { /* ... */  }
        },
        // ...
      ],
      "eo:bands": [
        {
          "name": "b1",
          "description": "red"
        },
        {
          "name": "b2",
          "description": "green"
        },
        {
          "name": "b3",
          "description": "blue"
        }
      ],
    }
  }
}

[jo-chemla]

Finished the OP edits, sorry for sending early!

[vincentsarago]

thanks for the issue @jo-chemla 🙏

there are 2 things:

1. we should switch to stac version 1.1.0 where band is now part of the core spec and not the eo extension
2. we should try to match the description/color interpretation with the common name

note: there was a PR started couple month ago #74 but it was too big to review

[jo-chemla]

Thanks for getting back and dissecting the feature request into 2 blocks. I'm not sure whether keplergl does support STAC >= 1.1.0, just asked their team in the linked thread keplergl/kepler.gl#3361.

Does not look like it yet, but interesting if rio-stac supports it anyway. And indeed matching description color interp with common_name was the visible tip of that feature request. Nice to see this PR, which does look indeed quite of an undertaking atm.

PS: just saw you started tweaking async-titiler, interesting to watch-out!