create unique render title

[vincentsarago]

this pr update the renders metadata within the Maxar collections:

• asset_bidx: "visual|1,2,3" to {"visual": [1, 2, 3]}
• title: Visual Image to {collection id} Visual Image

the asset_bidx update makes it a bit more simple to understand and less titiler oriented, it's up to the client to do the transformation to a titiler like format (visual|1,2,3)

For the title update, this is mostly to be able to create a list of ALL the renders from a list of collections.

[oliverroick]

The change seems reasonable. I’ve got two questions below.

Are there cases when the object has more than one entry, ie. we’re using more than one asset. Let’s say the object looks like this:

{
  ...
  "asset_bidx": {
      "visual": [1,2]
      "nir": [1]
  }
}

How does this need to be translated for TiTiler? Do we translate this to `visual|1,2|nir|1 or so? Or is this a case that is not possible?

---

I know that for Titiler, the client needs to provide asset_bidx as visual|1,2,3. Another tiler backend might expect something different. How do I know, as a client developer, how to transform the object? If I want to write a server-agnostic front-end, then there should be some way for the client to know how to make this translation. Or is the assumption that a front-end will always make use of a specific tiler but it will work with any STAC catalog that implements the render extension?

[vincentsarago]

@oliverroick

{
  ...
  "asset_bidx": {
      "visual": [1,2]
      "nir": [1]
  }
}

How does this need to be translated for TiTiler? Do we translate this to `visual|1,2|nir|1 or so? Or is this a case that is not possible?

TiTIler accept a list of string in form of asset_bidx=visual|1,2&asset_bidx=nir|1, I'm also going to add support for encoded dictionary.

Another tiler backend might expect something different. How do I know, as a client developer, how to transform the object?

As far as I know, no other client than TiTiler support this for now (I don't really now other client anyway).

If I want to write a server-agnostic front-end, then there should be some way for the client to know how to make this translation.

This is a bit tricky, but one could think that the front-end could check the OpenAPI of the backend.