[FR]: Consider adding `RasterIndex` & `CRSIndex` by default to returned Xarray objects

[dcherian]

Feature Summary

I think it makes sense for Xee to automatically add a RasterIndex (https://rasterix.readthedocs.io/en/latest/raster_index/creating.html) where it makes sense (nearly always?) to the returned Xarray object.

You could also add a CRSIndex from xproj: https://xproj.readthedocs.io/en/latest/

Use Cases

Easier handling of raster data. By using RasterIndex and CRSIndex, many classes of bugs are avoided by default

[jdbcode]

Thanks for the suggestion — we agree that RasterIndex and CRSIndex are likely beneficial in a lot of workflows, and we’re excited to see the ecosystem you’re building around Rasterix + XProj.

That said, Xee’s core goal is to get pixels out of Earth Engine and into "plain" Xarray objects with as little extra policy as possible. We try not to be overly prescriptive about downstream conventions, and we’re cautious about adding default behaviors that (a) introduce new dependencies and (b) subtly change the semantics/serialization of returned objects — mostly to keep maintenance and support load manageable and keep outputs maximally interoperable with the wider Xarray stack.

A middle ground that seems promising is to make it easier for users (or an external helper package) to attach these indexes themselves by ensuring Xee exposes the needed grid metadata in a clear, consistent way. Concretely, we could add a small set of dataset-level attributes (namespaced to avoid collisions), e.g. xee_crs, xee_crs_transform, and xee_shape_2d (and/or a lightweight CF-style mapping), so attaching RasterIndex / CRSIndex becomes a straightforward, reliable step without having to infer anything from internals.

If that works for you, we’d be inclined to approach this incrementally:

1. improve metadata/interop so attaching indexes is trivial downstream, then
2. potentially add an optional flag (not default) to attach RasterIndex/CRSIndex at open-time for users who want it.

Happy to collaborate on what the minimal "interop contract" should look like so it fits Rasterix/XProj well.