Skip to content

Simpler or more predictable dimension detection with load_stac? #743

Open
@soxofaan

Description

@soxofaan

We recently had various discussion that working with load_stac based cubes can hard because it is not always clear if certain dimensions are present. Which causes confusion down the line, e.g. "can I drop the time dimension?" or "should I re-add this dimension before merge_cubes"?

STAC is pretty flexible, and it is not always very clear if a load_stac'ed datacube is expected to have a temporal dimension for example. Moreover in openEO, it's also important to know the dimension names to properly handle openEO processes like reduce_dimension/apply_dimension/..., and this has to be consistent both at client and backend side.

With the STAC datacube extension it is possible to explicitly list and name dimensions, which seems to be the source of truth for this problem. Note that this extension allows to explicitly omit a dimension, and as such should not be assumed to be present in the data cube.

However, when this datacube extension is not available in the STAC metadata, it seems best, based on discussion with users, to just naively assume a typical 4D EO datacube:

  • spatial dimensions "x" and "y"
  • temporal dimension "t"
  • band dimension "bands"

(based on the openEO recommendation on openEO collection dimension names)

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions