You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a few questions regarding the functionality of odc-stac when working with collection-level assets and Zarr files:
Collection-Level Assets:
• Is it possible to load a collection with assets directly, without requiring STAC items? For example, in cases where the collection itself contains assets, such as Zarr files.
• The current odc-stac.load method seems to support only STAC items. As per the best practices mentioned in the documentation, individual bands are treated as assets with additional STAC extensions. Is this still the recommended approach, or is there support for collection-level assets in the latest version?
Loading Zarr Assets:
• I am trying to load a Zarr file into odc-stac, similar to the Daymet collection (Daymet Annual North America Collection). In the odc-stac v0.3.10 release notes, Zarr support was mentioned. Could you confirm if odc-stac supports Zarr assets, and if so, are there any specific configurations or examples for this?
Optimal Approach for Zarr Data:
• Would you recommend using odc-stac for loading Zarr assets, or is it more optimal to load Zarr assets directly using xarray, as shown in this Planetary Computer Quickstart Guide?
I appreciate your clarification on these points. Thank you for your work on odc-stac and for helping the community handle STAC and geospatial data efficiently.
The text was updated successfully, but these errors were encountered:
Regarding Collection level assets: I wasn't even aware that was a thing until today, nor was I aware of standalone collections. How well is this supported in pystac? Can one use say ProjectionExtension.ext on a collection rather an Item or asset? Is there an easy way to convert standalone collection to item in pystac.
odc-stac does not understand cube extension. odc-stac is all about presenting a unified view of the data from multiple standalone files, when you already have one single zarr you can just open it with xarray and be done with it. If you need reduced resolution or projected view of the data you can still used .odc.reproject type functionality assuming source zarr has appropriate geo referencing metadata included.
regarding zarr support @omad or @woodcockr might have more info than me, we have reasonably complete "internal" implementation, but interface and docs are less fleshed out. Right now we only understand completely non-standard way, which is entire consolidated zarr store dictionary in properties["zarr:metadata"]
Hello,
I have a few questions regarding the functionality of odc-stac when working with collection-level assets and Zarr files:
Collection-Level Assets:
• Is it possible to load a collection with assets directly, without requiring STAC items? For example, in cases where the collection itself contains assets, such as Zarr files.
• The current odc-stac.load method seems to support only STAC items. As per the best practices mentioned in the documentation, individual bands are treated as assets with additional STAC extensions. Is this still the recommended approach, or is there support for collection-level assets in the latest version?
Loading Zarr Assets:
• I am trying to load a Zarr file into odc-stac, similar to the Daymet collection (Daymet Annual North America Collection). In the odc-stac v0.3.10 release notes, Zarr support was mentioned. Could you confirm if odc-stac supports Zarr assets, and if so, are there any specific configurations or examples for this?
Optimal Approach for Zarr Data:
• Would you recommend using odc-stac for loading Zarr assets, or is it more optimal to load Zarr assets directly using xarray, as shown in this Planetary Computer Quickstart Guide?
I appreciate your clarification on these points. Thank you for your work on odc-stac and for helping the community handle STAC and geospatial data efficiently.
The text was updated successfully, but these errors were encountered: