New Xarray accessor for rasters and DEMs

[rhugonnet]

Hi all,

We are planning to build on top of rioxarray for end-users focusing on analysis of EO data by building accessor in our packages GeoUtils and xDEM for raster/vector and DEM analysis, respectively, which are currently built on top of rasterio and geopandas.
See: pydata/xarray#8040 and pydata/xarray#8041

I don't see much overlap for xDEM, except that we could use vertical CRS reprojection through rioxarray if one day we implement it in rasterio, for now not possible (see rasterio/rasterio#2433).

For GeoUtils, part of the package's functionalities are closely linked to georeferencing and aim to simplify the interaction raster/raster or raster/vector, like the reproject_match function of rioxarray. Those did not exist in rasterio, but they have been more of a focus in rioxarray and geocube. In the Raster and Vector classes of GeoUtils, we tried to implement these "convenience" ops for all type of operations and the two objects.

And so I am wondering: where do you think those functionalities should live if we build an xarray accessor? Should we keep them in GeoUtils like is done on top of rasterio (e.g., Raster.reproject(ref), Raster.polygonize(ref)) and implement ds.geo.reproject(ref) and ds.geo.polygonize(ref)) by simply wrapping what is done, or should we try to make those available directly in rioxarray and geocube (but then the functioning of rioxarray would stray quite a bit from that of rasterio)?

More details in our doc for match-reference ops: https://geoutils.readthedocs.io/en/stable/core_match_ref.html

Thanks for all the great work! 😄

[snowman2]

Thank you for sharing, that looks useful.

And so I am wondering: where do you think those functionalities should live if we build an xarray accessor?

I think it depends on the scope of what you would like to support. There is likely room to migrate some of the functionality into existing libraries if that is your goal.

For example:

• See if the reproject logic makes sense to merge with rio.reproject.
• See if polygonize logic makes sense to merge with geocube ref.

Then, for the things that don't fit in other libraries, you could make geo-utils an expansion pack on existing libraries.

[snowman2]

Side note: The .geo accessor is being used by geoxarray.