Idea: Xarray interface

I stumbled upon the Open-EO project a few times and find it very interesting. As a Xarray developer I've been wondering whether it would benefit from an Xarray interface.

I see that Xarray is already used here, but as far as I understand it is for defining user defined functions. My suggestion is rather interacting with Open-EO directly via the Xarray API, which may be complementary to using Xarray for UDFs.

New Xarray developments are going towards very flexible containers, with the recent addition of IO backends, alternative array backends (cupy, sparse, pytorch...), alternative parallel execution backends, flexible indexes (https://github.com/pydata/xarray/discussions/7041, https://github.com/pydata/xarray/projects/1), and accessors.

Leveraging Xarray's flexibility, I can imagine something like this:

import openeo
import xarray as xr

connection = openeo.connect("https://earthengine.openeo.org")

ds = xr.open_dataset(
    connection,
    engine="openeo",
    collection="COPERNICUS/S1_GRD",
    spatial_extent={"west": 16.06, "south": 48.06, "east": 16.65, "north": 48.35},
    temporal_extent=["2017-03-01", "2017-06-01"],
    bands=["VV"],
)

# internally calls DataCube.filter_temporal() via a custom Xarray Index
# attached to dataset and returns a new xarray.Dataset
ds_march = ds.sel(time=slice("2017-03-01", "2017-04-01"))

# internally calls DataCube.mean_time()
ds_mean_march = ds_march.mean("time")

# sends the processing job, waits for its execution and downloads
# the result into a new xarray.Dataset
ds_result = ds_mean_march.compute()

# or only sends the job...
ds_mean_march.persist()

# ...and later waits for the job to finish its execution and downloads the result
ds_result = ds_mean_march.load()

I think that such an Xarray interface could be built on top of this client library (perhaps in another repository). To make things easier, ideally openeo.DataCube would need to implement some duck array API.

The main advantage is that users can interact with OpenEO using an API they are already familiar with (assuming they already know about Xarray). They can also further process the data (results) locally using the same interface.

This is a very rough idea that I just wanted to share here, though. I'm pretty sure that providing an Xarray interface would represent quite some work with lots of challenging issues (and likely things to address in Xarray). I'd be happy to read what you think about this idea! (Sorry, I'm not sure if it is the right place here for discussing this)

Start by reviewing the existing openeo.DataCube and its current Xarray use for user-defined functions, then assess whether an Xarray interface belongs in this client or another repository. The issue names no files or tests and does not define a concrete implementation or completion criteria, so the scope and minimum supported API need agreement first.