[gdal-dev] Multidimensional raster support in GDAL

[Even Rouault]

> 
> I think band is a dimension in the implementation in GDAL 

I disagree with that. There's clearly a GDALRasterBand object to model that.

> because for
> every (x,y,band) we give access to a pixel; if it were not a dimension
> but an attribute, we would for each pixel (x,y) give access to a record
> with named fields e.g. { red, green, blue }.

This could be done, but wouldn't be really practical given that bands can have different data 
types. But fundamentally band/field/variables is a concept that is different from the 
dimensions that index it. This is really clear in the related standards (WCS, CIS), and in the 
format implementations (netCDF), so I  think we shouldn't "merge" the band concept as an 
extra dimension.

If you have variable[x][y][z][t], then whatever the value of x, y, z, t the units, data type and 
semantics of variable[][][][] is the same

whereas dataset[x][y][band] doesn't have that property when you change band.

> 
> In the case where bands reflect colors (or wavelength) they work well as
> a dimension, since they can be uniquely ordered. Like elevation in
> weather data they may be irregularly spaced; in practice, they refer to
> wavelength intervals rather than point values.
> 
> In the case where there is no such ordering, e.g. where bands reflect
> raster layers with abundance of different plant species, we can still
> use it as a dimension to solve a problem

I see your point, but that's more a particular case, than something on which we can base an 
abstraction on. Note also that in some datasets the bands are not ordered in a logical 
fashion. For example in a GeoTIFF file, it is not uncommon to find R, G, B, Near-Infrared in 
that order.
And if you look at Sentinel-2 dataset, all bands are not sampled at the same resolutions, so 
band couldn't be used as an index through the whole band set.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20171026/be7d06a8/attachment.html>