Repository navigation
How should a render fix the non-spatial dimensions of a datacube asset? #19
Description
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 ?
Activity
emmanuelmathot commentedon Sep 22, 2026
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
selectionobject, I want to raise an alternative: could this be expressed throughexpressioninstead of a new field? We should haveexpression/expression_typeas 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:first/lastresolved when a dimension has onlyextent, not explicitvalues? into the dialect's own definition.expressionin.Keen to hear from @vincentsarago too before we commit to a shape here.