Connection to xarray-assets STAC extension pilot?

[weiji14]

Hi there, I've started using xpystac recently after the v0.0.1 release and really like the simple xr.open_dataset(stac_asset, engine="stac") interface that's just a single entrypoint to any STAC Asset!

Question though on what are the next steps for this? I've been reading the discussion at stac-utils/pystac#846 (comment), and also noticed https://github.com/stac-extensions/xarray-assets (cc @TomAugspurger). At the moment, xpystac=0.0.1 seems to only handle the engine parameter in xr.open_dataset:

https://github.com/jsignell/xpystac/blob/051d0ac15b42a60dfc330b6cacf5e8653d4edbd9/xpystac/core.py#L55-L63

Is the idea that other xr.open_dataset parameters like chunks, decode_cf, backend_kwargs, etc would need to be passed in by the user, or read automatically from the xarray-assets STAC extension (xref stac-extensions/xarray-assets#3) if available? This is starting to sound very similar to https://github.com/intake/intake-xarray in some ways, but I'd like to hear more thoughts on how things should 'ideally' work.

[jsignell]

Wow! You are the first user!

Is the idea that other xr.open_dataset parameters like chunks, decode_cf, backend_kwargs, etc would need to be passed in by the user, or read automatically from the xarray-assets STAC extension (xref stac-extensions/xarray-assets#3) if available?

Yes that is exactly right. There is already a little of this handling for "xarray:open_kwargs" and ""xarray:storage_options" but as xarray-assets expandas I would expect to keep growing the list. If the user provides any kwargs to open_dataset directly then those would win over any that are defined in the STAC entry.

This is starting to sound very similar to https://github.com/intake/intake-xarray in some ways, but I'd like to hear more thoughts on how things should 'ideally' work.

Yes! This is heavily inspired by intake. I was originally going to work on intake-stac, but instead I was directed to the original issue where Tom wrote up this idea. My long-term goal is to have intake-stac depend on this library so that the effort of parsing STAC isn't duplicated. I'm not 100% sure how it relates to intake-xarray but yeah it is a very similar concept just coming at it from a slightly different angle.

[weiji14]

Is the idea that other xr.open_dataset parameters like chunks, decode_cf, backend_kwargs, etc would need to be passed in by the user, or read automatically from the xarray-assets STAC extension (xref stac-extensions/xarray-assets#3) if available?

Yes that is exactly right. There is already a little of this handling for "xarray:open_kwargs" and ""xarray:storage_options" but as xarray-assets expands I would expect to keep growing the list. If the user provides any kwargs to open_dataset directly then those would win over any that are defined in the STAC entry.

Cool, that sounds about right - having user-provided kwargs override what is defined in the xarray-assets STAC extension entry.

This is starting to sound very similar to https://github.com/intake/intake-xarray in some ways, but I'd like to hear more thoughts on how things should 'ideally' work.

Yes! This is heavily inspired by intake. I was originally going to work on intake-stac, but instead I was directed to the original issue where Tom wrote up this idea. My long-term goal is to have intake-stac depend on this library so that the effort of parsing STAC isn't duplicated. I'm not 100% sure how it relates to intake-xarray but yeah it is a very similar concept just coming at it from a slightly different angle.

Nice! My take on it is that xpystac would provide the function-then-data interface xr.open_dataset(stac_asset, ...), whereas intake-stac would provide the data-then-function interface stac_asset.to_xarray_dataset(), xref stac-utils/pystac#846 (comment)?

[jsignell]

My take on it is that xpystac would provide the function-then-data interface xr.open_dataset(stac_asset, ...), whereas intake-stac would provide the data-then-function interface stac_asset.to_xarray_dataset(), xref stac-utils/pystac#846 (comment)?

Yes! And I haven't really documented this, but to_xarray is exposed as part of this library so ideally intake-stac can use that in its implementation.