I think we should also delete the transform from the grid_mapping variable like so:

grid_mapping=ds.rio.grid_mappingobj[grid_mapping].attrs.pop("GeoTransform")

followinghttps://github.com/dcherian/rasterix/blob/main/design_notes/raster_index.md#read-time and our discussions. This will trigger some more changes (from a quick search,_cached_transform will need to pull the Affine from RasterIndex)

It'd be nice to have an accessor function to set this index even if I opened a Zarr file for example. Is there something likeds.rio.assign_coords? I didn't see anything similar in the docs. Perhaps we should haveds.rio.assign_indexes(raster:bool=True, crs: bool=True) that does both RasterIndex and CRSIndex

Do you think that would be a good fit to add to a rasterix accessor? If you do that, you just setdecode_coords=False and assign the index/coords post load.

It needs a bunch of extra info : x dim name, y dim name, transform, and so it's pretty convenient to just do all that with the.rio accessor. It seems like a prudent and convenient addition

Inside rasterix, it could look for the.rio ,.odc, or.geo accessors inside the method. It could be done similar toopen_dataset where it automatically figures out how to open files based on what's available. It also allows the user select their preferred engine. If they don't exist, then raise an error.

That is an option but to me it feels a lot cleaner to add a method under therio namespace. (and similarly under the other namespaces if they thought it was a good idea). At least for rioxarray it's just a small wrapper around an existing function, so it doesn't seem like meaningful extra maintenance burden to me.

Inside rasterix, it could look for the .rio , .odc, or .geo accessors inside the method

Hmm this wouldn't be ideal IMHO, assuming that the goal of the rasterix (and xproj) project is to provide reusable utilities to downstream packages like rioxarray, odc-geo, etc. even though technically looking for those accessors is possible without having cyclic dependencies.

Under the same assumption, rasterix and xproj should also be flexible / not strongly opinionated about the names of the spatial coordinates and dimensions, etc.