<div dir="ltr">Hi Sean,<div><br></div><div>Thanks for starting this discussion. Let me first say that the PR is still in an early stage, and that more work is needed upstream to make it fully usable, so definitely not ready for merging yet.</div><div>Although it is not clearly mentioned, xtensor-zarr supports Zarr v3 as well as a part of Zarr v2, actually the test in the PR is based on version 2. But as you mentioned, supporting all the features that are allowed with zarr-python is not going to be possible in C++. We will most likely limit the range of possibilities, and improve the driver based on interest in some features. For instance, this PR starts very modestly by not supporting any geo-metadata.</div><div>In any case, this PR is nothing more than a work in progress at the moment, without any formal scope. I'm interested in getting feedback from the GDAL community, and if there is interest we can work on formalizing this work through an RFC, as it seems it is going to be required for new drivers.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 1, 2021 at 4:46 PM Sean Gillies <<a href="mailto:sean.gillies@gmail.com" target="_blank">sean.gillies@gmail.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"><div dir="ltr"><div>Hi all,</div><div><br></div><div>Also deep in our recent long thread about removing drivers from GDAL is mention of a new PR for a "zarr" driver.</div><div><br></div><div><a href="https://github.com/OSGeo/gdal/pull/3411" target="_blank">https://github.com/OSGeo/gdal/pull/3411</a></div><div><br></div><div>I'd like to see more discussion of the scope of this work and plans for future development and support before a zarr driver is added to GDAL.</div><div><br></div><div>Is the zarr driver not going to support version 2 of the zarr spec? I that v2 would be difficult to implement as a GDAL driver as it is extremely flexible and extensible. For example, I've written custom compressor and storage for use in a project at work and can't imagine how a driver written in C++ would understand it.</div><div><br></div><div>Is the zarr driver based on <a href="https://zarr-specs.readthedocs.io/en/core-protocol-v3.0-dev/protocol/core/v3.0.html" target="_blank">https://zarr-specs.readthedocs.io/en/core-protocol-v3.0-dev/protocol/core/v3.0.html</a>? That work seems not yet finished. Is it premature to add a driver to GDAL for a format that isn't yet specified and may yet be changed? Or should we expect only minor changes at this point?<br></div><div><br></div><div><div>-- <br><div dir="ltr">Sean Gillies</div></div></div></div>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div>