[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