[gdal-dev] Multidimensional raster support in GDAL

[Edzer Pebesma]

On 10/26/2017 08:05 AM, Ari Jolma wrote:
> Even Rouault kirjoitti 25.10.2017 klo 22:22:
> 
>> 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
>>
> 
> I was aiming at the 'multidimensional raster' to a case where the
> location (raster cell) data is multidimensional. You get
> multidimensional data whenever you have an axis along which you can do
> measurements (time, depth, electromagnetic spectrum, simulation number,
> etc). I'd take the location as the basis that probably shouldn't need
> extending for GDAL. Or do we want to support taking X,Y,T data from a
> format that supports it and slice it to X,T for another format? Maybe
> that makes sense for some visualization and analysis purposes, but is
> that what GDAL should support at some point? Are there compelling use cases?

I'm thinking of handling and analysing multi-dimensional spatio-temporal
imagery-like array data in general, of which there are many examples.

Two big use case groups: detecting change from remote sensing image time
series, and analysing climate model predictions.

> 
> Would it be possible to keep X,Y as it is and add support for
> multidimensional data as an extension?

I think yes, and Even's proposal of yesterday sketches the path for this
(I still need more time to understand it).

More in general, we have multidimensional arrays where horizontal space
is not an x y image (GDAL raster band) but for instance a sequence of
feature geometries (e.g., in situ sensor data, or demographic data by
administrative region, time, and age class). We may want to keep those
use cases in mind when working on this from the GDAL perspective, since
pretty soon you will want to cut out a point or region, or aggregate
grid values over a polygon area while keeping all other dimensions.

> 
> Ari
> 
> 
>> , 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.
>>
>>  
>>
>> > 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