[gdal-dev] Multidimensional raster support in GDAL

[Edzer Pebesma]

On 10/25/2017 09:22 PM, Even Rouault wrote:
> On mercredi 25 octobre 2017 14:42:54 CEST Ari Jolma wrote:
> 
>> I'd like to first know / decide what would we mean by a
> 
>> "multidimensional raster"?
> 
>  
> 
> The current rasters handled by GDAL are already multidimensional, with
> the number of dimensions being fixed to 2, and being 2 horizontal
> dimensions (X/Y, lon/lat). The idea here would be to at least address
> the 3D (X,Y,Z / X,Y,T) and 4D case (X,Y,Z,T), and when you need to do
> that, arbitrary number of dimensions is at hand.
> 
>  
> 
> The dimensions/ones here are mostly spatio-temporal ones, along which
> you can measure a physical phenomenon (a temperature field measures at
> different position, elevation, time)
> 
>  
> 
>>
> 
>> What we now have as a raster is a dataset with one or more bands. The
> 
>> bands represent the data dimension and thus there is one of those
> 
>> (2D+1).
> 
>  
> 
> Bands do not represent a dimension. In OGC SIS
> 
> ( http://docs.opengeospatial.org/is/09-146r6/09-146r6.html ) or WCS,
> bands are called fields of a rangeType.
> 
> Bands are different from the above mentionned dimensions in which they
> do not really consider an axis along which you have some consistency.
> Along the X/Y axis, you can mark ticks every n meters. Along the "band
> axis", you will have a temperature field in Kelvin, a wind direction in
> degrees, etc.
> 

I think band is a dimension in the implementation in GDAL 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 }.

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, but we can't do meaningful
operations on it that assume ordering: you can smooth a spectral curve
or depth profile to reduce noise, but doing this over an arbitrarily
ordered set of species doesn't make sense.


>  
> 
>> Would we like to have more data dimensions? What Even sketches
> 
>> below is ND, but would we really want to have 2D + ND?
> 
>  
> 
> My scetch of ND intended to capture the current 2D case, as a particular
> case.
> 
>  
> 
>>
> 
>> Also now there is no unit for the data dimension and the value is
> 
>> strictly increasing positive integer,
> 
>  
> 
>> would we like to have an explicit
> 
>> unit
> 
>  
> 
> Was the GDALDataset::char* apszAxisUnit[nAxisCount] or
> GDALGridAxis::pszUnit in my scetch
> 
>  
> 
>> and arbitrary value (double, date, time, ...)?
> 
>  
> 
> In my scetch, I had indeed some hesitation about the appropriate type
> for adfAxisCoordinates array. I think that for the cases mentionned
> above (4D spatio-temporal) we can always represent the coordinates along
> each axis as a double value. The case where that's the less obvious is
> for date/time, but using some reference like the Unix Epoch.
> 
>  
> 
>  
> 
> Even
> 
>  
> 
> -- 
> 
> Spatialys - Geospatial professional services
> 
> http://www.spatialys.com
> 
> 
> 
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
> 

-- 
Edzer Pebesma
Institute for Geoinformatics
Heisenbergstrasse 2, 48151 Muenster, Germany
Phone: +49 251 8333081