Feature description
base line support would generate a new dimension and line up the first band from each file in the multidim
next level add support for nominating new dimension name and type of indexing variable, specifying input values for the dimension or or start/step values, a common use-case could provide support for templating date time string from the file/uri name
There are potential complications:
- a huge diversity of creation options and types of dimensions and indexing variables
- meaning of intervals in the new dimension/s
- what to do with multiband?
- maybe this is a new app 'gdal mdim stack ...'
but, this is a very common scenario that implemented by band-proxy in many downstream packages. I'd argue it represents a key missing link from other array schemes in this space, fwiw I'm actively exploring it with workarounds in R and python and what impact a simple or more complex implementation would have on the current GDAL soucrce.
Additional context
GDAL mdim VRT supports input from GeoTIFF, but only (afaics) by manual construction on the VRT XML.
Feature description
base line support would generate a new dimension and line up the first band from each file in the multidim
next level add support for nominating new dimension name and type of indexing variable, specifying input values for the dimension or or start/step values, a common use-case could provide support for templating date time string from the file/uri name
There are potential complications:
but, this is a very common scenario that implemented by band-proxy in many downstream packages. I'd argue it represents a key missing link from other array schemes in this space, fwiw I'm actively exploring it with workarounds in R and python and what impact a simple or more complex implementation would have on the current GDAL soucrce.
Additional context
GDAL mdim VRT supports input from GeoTIFF, but only (afaics) by manual construction on the VRT XML.