[gdal-dev] Motion: adopt RFC 75: Multidimensional array

Howard Butler howard at hobu.co
Fri Jul 19 11:40:45 PDT 2019


+1 Howard

> On Jul 18, 2019, at 11:34 AM, Norman Barker <norman.barker at gmail.com> wrote:
> 
> Hi Even,
> 
> thanks for the clarification around indexing and nodata. This works great and when I have availability and your changes last in master I will upgrade the tiledb driver.
> 
> +1 from me.
> 
> Norman
> 
> On Thu, Jul 18, 2019 at 10:48 AM Even Rouault <even.rouault at spatialys.com <mailto:even.rouault at spatialys.com>> wrote:
> Hi,
> 
> > 
> > I am in favour of the work on multi-dimensional arrays. There are two open
> > PRs https://github.com/rouault/gdal/pulls <https://github.com/rouault/gdal/pulls> with changes to the text. 
> 
> Oh I didn't see them before. I've merged the first one from Edzer. Answering 
> yours now:
> 
> > Though
> > I and my employer would like TileDB included in the list of formats (though
> > happy to wait until I have added the code to support this) 
> 
> I'd prefer to limit the scope of the RFC to the drivers I'll take care of. 
> Other contributors are welcome to implement it for their own drivers of 
> interest once this has landed into master.
> 
> > the issues
> > around dimension ordering
> 
> https://github.com/rouault/gdal/blob/rfc75/gdal/doc/source/user/ <https://github.com/rouault/gdal/blob/rfc75/gdal/doc/source/user/>
> multidim_raster_data_model.rst mentions
> 
> """Most drivers use the row-major convention for dimensions: that is, when 
> considering that the array elemnts are stored consecutively in memory, the 
> first dimension is the slowest varying one (in a 2D image, the row), and the 
> last dimension the fastest varying one (in a 2D image, the colum). That 
> convention is the default convention used for NumPy arrays, the MEM driver and 
> the HDF5 and netCDF APIs. The GDAL API is mostly agnostic about that 
> convention, except when passing a NULL array as the stride parameter for the 
> :cpp:func:`GDALAbstractMDArray::Read` and 
> :cpp:func:`GDALAbstractMDArray::Write` methods. You can refer to NumPy 
> documentation about multidimensional array indeing order issues:
> https://docs.scipy.org/doc/numpy/reference/internals.html#multidimensional-array-indexing-order-issues <https://docs.scipy.org/doc/numpy/reference/internals.html#multidimensional-array-indexing-order-issues> """
> 
> Does that answer your concern / question ?
> 
> > and defining NULL are two things I would like to
> > discuss.
> 
> Yes, nodata support is there. Mentionned in
> https://github.com/rouault/gdal/blob/rfc75/gdal/doc/source/user/ <https://github.com/rouault/gdal/blob/rfc75/gdal/doc/source/user/>
> multidim_raster_data_model.rst#multidimensional-array
> 
> and in the C++ API:
> https://github.com/rouault/gdal/blob/rfc75/gdal/gcore/gdal_priv.h#L2257 <https://github.com/rouault/gdal/blob/rfc75/gdal/gcore/gdal_priv.h#L2257>
> 
> so 2 virtual methods that can be implemented by drivers:
> const void* GetRawNoDataValue() const;
> bool SetRawNoDataValue(const void* pRawNoData);
> 
> and 2 helpers that get/set as double for the common cases.
> 
> Even
> 
> -- 
> Spatialys - Geospatial professional services
> http://www.spatialys.com <http://www.spatialys.com/>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20190719/cf38f83f/attachment.html>


More information about the gdal-dev mailing list