<!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div style="font-family:Arial;">Hi,<br></div><div style="font-family:Arial;"><br></div><div style="font-family:Arial;">While I agree with the sentiment, I'm not sure I agree about some of the details. It assumes that on ZARR ZIPs, you need to make twice as many reads, for the local file headers and for the data. But the information in the local header is already available in the central directory, so you can seek directly to the data. This assumption is then used throughout the analysis.<br></div><div style="font-family:Arial;"><br></div><div style="font-family:Arial;">But there are things I don't really like about the format, like the very flexible data model and physical organization, the implicit assumption that everything is lat/lon, and the lack of overviews. I'm also a bit skeptical about the Python ecosystem. My impression is that Zarr just tries (and manages) to be a better NetCDF.</div><div style="font-family:Arial;"><br></div><div style="font-family:Arial;">Laurentiu</div><div style="font-family:Arial;"><br></div><div style="font-family:Arial;"><br></div><div>On Thu, Feb 27, 2025, at 06:06, Michael Sumner via gdal-dev wrote:<br></div><blockquote type="cite" id="qt" style=""><div dir="ltr"><div>Just clueing into why you might be working with this, have you seen this critique? (was a bit shocked to see that this is apparently going forward for Sentinel 2, let alone that it was even considered!)<br></div><div><br></div><div><a href="https://github.com/csaybar/ESA-zar-zip-decision">https://github.com/csaybar/ESA-zar-zip-decision</a><br></div><div><br></div><div>Also glad to see a working example outlined that I can follow, Thanks!<br></div><div><br></div><div>Cheers, Mike<br></div></div></blockquote><div style="font-family:Arial;"><br></div></body></html>