The chunk sizes are available as part of .zmetadata
The zmetadata also contains potentially other useful information, especially for I/O drivers implementation.
But for now the chunk size of the written file chunks (saved arrays) should be visible at the asset/assets group level this would an "equivalent" of BLOCKXSIZE and BLOCKYSIZE for tiffs for instance [BLOCKXSIZE](https://gdal.org/en/stable/drivers/raster/gtiff.html#creation-options).
Bottom line is that this would expose this information for user to read only the chunks as they are written and multitude if they wish to do so to stick to or enforce default I/O (read) behavior based on the written data.
There might be some other useful xarray.open_dataset kwargs, but this one is important especially to optimize read request for targeted chunks.
Petr
The chunk sizes are available as part of .zmetadata
The
zmetadataalso contains potentially other useful information, especially for I/O drivers implementation.But for now the chunk size of the written file chunks (saved arrays) should be visible at the asset/assets group level this would an "equivalent" of BLOCKXSIZE and BLOCKYSIZE for tiffs for instance [BLOCKXSIZE](https://gdal.org/en/stable/drivers/raster/gtiff.html#creation-options).
Bottom line is that this would expose this information for user to read only the chunks as they are written and multitude if they wish to do so to stick to or enforce default I/O (read) behavior based on the written data.
There might be some other useful
xarray.open_datasetkwargs, but this one is important especially to optimize read request for targeted chunks.Petr