Generate spatial coords with rasterix.RasterIndex #855
Conversation
Create a RasterIndex if option use_raster_index is True.
|
|
Yes I will do all of that before marking this PR as ready.
Likely for the tests yes. Since this is an opt-in feature Rioxarray may (should) still support Xarray versions older than the minimum version required by Rasterix. |
| "the spatial coordinates with a RasterIndex" | ||
| ) from err | ||
|
|
||
| raster_index = RasterIndex.from_transform(affine, width, height) |
There was a problem hiding this comment.
I think we should also delete the transform from the grid_mapping variable like so:
grid_mapping = ds.rio.grid_mapping
obj[grid_mapping].attrs.pop("GeoTransform")following https://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)
|
How should we bring in |
Yes, a separate PR will be easier I think. Interoperability between xproj and rioxarray would likely be handled at the accessor level and might require some more refactoring. |
| @@ -162,7 +178,7 @@ def _get_nonspatial_coords( | |||
| src_data_array[coord].values, | |||
| src_data_array[coord].attrs, | |||
| ) | |||
| return coords | |||
| return xarray.Coordinates(coords) | |||
|
|
|||
|
|
|||
| def _make_coords( | |||
There was a problem hiding this comment.
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 like ds.rio.assign_coords? I didn't see anything similar in the docs. Perhaps we should have ds.rio.assign_indexes(raster:bool=True, crs: bool=True) that does both RasterIndex and CRSIndex
There was a problem hiding this comment.
Do you think that would be a good fit to add to a rasterix accessor? If you do that, you just set decode_coords=False and assign the index/coords post load.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Inside rasterix, it could look for the .rio , .odc, or .geo accessors inside the method. It could be done similar to open_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.
There was a problem hiding this comment.
That is an option but to me it feels a lot cleaner to add a method under the rio 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.
There was a problem hiding this comment.
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.
docs/history.rstfor all changes anddocs/rioxarray.rstfor new APIOptionally generates the spatial x/y coordinates with a rasterix's
RasterIndex(opt-in).The example notebook linked in #846 should work here as well.