How should a render fix the non-spatial dimensions of a datacube asset?

[lhoupert]

For multidimensional assets (e.g. Zarr) this extension is missing something to fix the non spatial dimensions to render 2D slices (which time step, which depth level, etc...). From what I saw, today this is done outside STAC. For example in EOPF Explorer, eodash carries an eodash:rasterform link with ${...} templating, and titiler takes it as sel=time=….

I added here a user case from the EOPF Sentinel Zarr Explorer (EOPF-Explorer/data-pipeline#385, background in EOPF-Explorer/data-pipeline#348): a Sentinel-1 RTC cube Item exposes its ascending and descending groups as two assets, each with its own time axis and vv/vh bands. assets fixes the groups but nothing fixes time, and the two axes differ, so a client that resolves time against the wrong group's axis requests a slice that does not exist.

proposal

We could add an optional selection object to the render object. Each key is a cube:dimensions key, looked up on the assets named in assets first, then on the Item, then on the Collection. A render without selection is unchanged, so 2D use is unaffected.

"assets": {
  "gamma0-rtc-backscatter-asc": {
    "href": "s3://…/T30VWJ.zarr/ascending",
    "roles": ["data"],
    "bands": [{ "name": "vv" }, { "name": "vh" }],
    "cube:dimensions": {
      "time": { "type": "temporal", "extent": ["2026-06-24T17:08:16Z", "2026-07-04T05:33:02Z"], "values": ["2026-06-24T17:08:16Z", "…"] }
    }
  }
},
"renders": {
  "vv-ascending": {
    "assets": ["gamma0-rtc-backscatter-asc"],
    "bidx": [1],
    "rescale": [[0, 0.5]],
    "selection": {
      "time": { "default": "last" }
    }
  }
}

default is a required field (string) and correspond to the value used when the client does not choose one. It could be a literal in the dimension's type (ISO 8601 for temporal), or first / last, resolved against the dimension's values or extent.

What are your thoughts @vincentsarago and @A-Behairi ?

[emmanuelmathot]

Thanks for the detailed write-up and the real-world case, @lhoupert
the ascending/descending example makes the problem concrete. Rendering extension currently has nothing for this, and I don't think the STAC Zarr best-practices doc already cover rendering/slice-selection either.

Before we settle on a dedicated selection object, I want to raise an alternative: could this be expressed through expression instead of a new field? We should have expression/expression_type as a generic, dialect-tagged "how to compute the rendered value(s)" mechanism (band math, style expressions, ...) from #28. Datacube slicing is arguably the same kind of operation: "derive a 2D array from the referenced asset(s)". just with a different dialect (e.g. something xarray-.sel()-shaped). Reusing that surface instead of adding a second special-purpose field would:

• Avoid render growing a new field, with its own lookup order (asset → Item → Collection) and default-resolution rules, every time a new kind of "derive what to render" need shows up.
• Push open questions like how is first/last resolved when a dimension has only extent, not explicit values? into the dialect's own definition.
• Stay consistent with the direction we've already taken expression in.

Keen to hear from @vincentsarago too before we commit to a shape here.