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