GeoZarr conventions not recognized by xarray (CRS, bounds, coordinates, ...)

[dieter-anb]

Hi!

I’m currently experimenting with creating a GeoZarr dataset following the official GeoZarr conventions.

As far as I can tell, the dataset is valid:

• The GeoZarr toolkit reports no issues with the structure or metadata
• I’m able to write the data successfully to OneLake (Microsoft Fabric)
• The required metadata (e.g., CRS, affine transform, bounds) is present in the JSON files

However, when I try to open and explore the dataset using xarray (and rioxarray), the geospatial metadata does not seem to be recognized:

• The CRS is not detected
• The spatial bounds are not interpreted
• I’m effectively required to redefine this information manually in Python

This feels counterintuitive, since the GeoZarr conventions are supposed to encode this information in the metadata already.

Additionally, I noticed that workflows often require explicitly storing x and y coordinate arrays. This also seems redundant to me, since:

• The affine transform
• The array shape
• dimension_names

should already be sufficient to derive spatial coordinates.

This leads me to suspect that xarray (and rioxarray) are currently not making use of the GeoZarr conventions.

So my questions are:

1. Does xarray currently support GeoZarr conventions at all?
2. If not, are there plans or ongoing efforts to support them?
3. Is there a recommended way to bridge this gap (e.g., preprocessing, plugins, or conventions I might be missing)?

Thanks in advance for any clarification!

[keewis]

xarray is (almost) completely domain agnostic so it doesn't try to interpret the metadata, and we don't plan on changing that.

However, libraries like rioxarray or rasterix should be able to support the geo-proj and spatial zarr conventions (if these are indeed part of GeoZarr), and I know that at least the most recent version of rasterix does support it.

cc @dcherian, @maxrjones, @benbovy

[benbovy]

rasterix allows creating x and y coordinates that are backed by a RasterIndex, which itself wraps the transform, shape and dimension names, thereby avoiding redundancy.

RasterIndex can wrap CRS information too, which can also be handled by a separate "grid mapping" scalar coordinate backed by an xproj CRSIndex.

Rioxarray does not recognize those indexes yet, this is discussed in corteva/rioxarray#908.

[dcherian]

What do you mean by "bounds" here?

rasterix.assign_index(ds) should interpret GeoZarr metadata and assign a RasterIndex that you can use for some operations.

[benbovy]

To summarize the replies in the other threads, there is already support for GeoZarr conventions and/or transform-backed coordinates in 3rd-party Xarray libraries like Rioxarray and Rasterix.

What we still miss is better interoperability between those libraries as well as better discoverability.

One way to solve the latter may be in Xarray to expose an API that allows plugging in custom "coders" (e.g., variable -> variable, dataset -> dataset) that can be passed via xr.open_dataset() or a new xr.decode() function, as discussed in #8548 and in #4490 (comment) onwards.