Zarr format support

[dumvin]

Hello,

I am currently working on a STAC catalog containing Zarr files. I was wondering if there were some implementation for the assets of this kind. I am currently loading them, but if I want to compute them I get a error of the type 'NoneType' object has no attribute 'to_epsg'. It seems that it is trying to look at underlying raster object, but the zarr only contains xarrays.

I can provide more information on the error, but I believe my trouble is more about how zarr are interpreted by stackstac!

Thank you very much

Vincent

[TomAugspurger]

stackstac is focused on building xarray data structures from a list of STAC items referencing Cloud Optimized GeoTIFFs. I don't really think it makes sense for it to also handle Zarr datasets. https://github.com/stac-utils/xpystac might be worth looking at.

…

On Thu, May 23, 2024 at 7:36 AM Vincent Dumoulin ***@***.***> wrote: Hello, I am currently working on a STAC catalog containing Zarr files. I was wondering if there were some implementation for the assets of this kind. I am currently loading them, but if I want to compute them I get a error of the type 'NoneType' object has no attribute 'to_epsg'. It seems that it is trying to look at underlying raster object, but the zarr only contains xarrays. I can provide more information on the error, but I believe my trouble is more about how zarr are interpreted by stackstac! Thank you very much Vincent — Reply to this email directly, view it on GitHub <#247>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKAOIQ6TMUY54HGPARLX5LZDXPEVAVCNFSM6AAAAABIFSA2WOVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZWG4YTONZRGY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[gjoseph92]

@dumvin I'm curious about the catalog you're working with. Is it something you can share publicly?

Also, could you share the traceback for that error?

I probably agree with @TomAugspurger that this doesn't make sense for stackstac to handle. It comes down to the "layout" of dataset, and whether the "time"/"stacked" dimension is represented at the STAC level, or within the asset itself.

What I mean by that is that COGs pretty much always represent a single point in time; they're 2D (ignoring bands for now). When there are multiple COGs that cover an area at different points in time, you have a separate STAC item for each COG. It's the role of a tool like stackstac to take those multiple 2D items and stack them together to create the 3D structure that includes the time component.

Zarr, on the other hand, can be N-D. So instead of lots of STAC items for each time, which need to be stacked, you might have just a single STAC item pointing to a huge 3D Zarr dataset, where the time component is already encoded in the 3rd dimension of the Zarr dataset. In that case, the data is "pre-stacked"—there's not much that stackstac needs to do; you could just open the Zarr dataset yourself and be done with it.

There's another case though, which is where the layout is "COG-style", but the format of each image just happens to be Zarr instead of COG. This doesn't seem super common to me, and I'd be curious why a dataset would be structured this way. But Zarr is, after all, a format GDAL can read, so in principle stackstac could be able to handle this case.

The much more confusing case—and reason I'd be hesitant to go too far into this—is a hybrid between the "COG-style" layout and the "one asset with a big zarr dataset" layout. Stackstac is pretty oriented around the assumption that each STAC Item encodes a single point in time. If, say, your STAC Items were 10 (time) x 2048 (y) x 2048 (x) arrays (so "pre-stacked" Zarr datasets of 10 times each), and then you wanted to stack these stacks, that would require quite a lot of change to the implementation for what seems to me to be a very rare case currently.

It also would be tricky because STAC doesn't necessarily contain the metadata you'd need to even tell if these items had 3 dimensions or 2 (or hey, 5?), let alone how big they are, or what they mean. (The datacube extension might give enough to go off of here?)