Coordinating efforts on potential new geospatial Xarray accessor

[rhugonnet]

Hi all,

First of all, thanks for the great work on GeoWombat!

We are thinking of building Xarray accessors for end-users focusing on analysis of EO data in our packages GeoUtils and xDEM for raster/vector and DEM analysis (https://geoutils.readthedocs.io/en/stable/, https://xdem.readthedocs.io/en/stable/), and thought it would be great to reach out and hear what you think, what makes sense and how we could coordinate, given the bit of overlap and everything you've already implemented in GeoWombat 🙂 !
Related Xarray/Rioxarray issues here: corteva/rioxarray#687.

More context:
As in GeoWombat, in GeoUtils (that is only based on rasterio and geopandas), one of our primary purpose has been to facilitate raster/vector interfacing and geo-referencing operations. As you know well, rasterio (or rioxarray) are fairly "low-level" to allow flexibility for any type of GIS user, and this makes higher-level end-user operations (e.g., match-reference for cropping, reprojection, rasterization or vectorization) inconsistent and sometimes hard to perform. To remedy this, we defined Raster and Vector classes that interface easily and implicitly allow for those higher-level ops, and were thinking of making their methods API also available as an Xarray accessor to allow more scalability and being part of the Xarray ecosystem.

For xDEM, I see little overlap.
However, for GeoUtils, if we build an accessor, I see some potential overlap between our efforts:

• The facilitated geo-manipulation (although the logic is different): here we were thinking of wrapping rioxarray the same way we wrapped rasterio, to mirror our current API (https://geoutils.readthedocs.io/en/stable/api.html#geospatial-handling-methods). It wouldn't be exactly the same "functioning" as GeoWombat (our logic here: https://geoutils.readthedocs.io/en/latest/core_match_ref.html), but still goes in the same direction. GeoWombat relies more on its config manager and default args for this... Do you think it make sense to have those two implementations, or should we merge efforts somehow? As it is a minimal development effort with rioxarray and geocube, I think it'd be fine to have the two implementations (wouldn't be a loss of time, even if it ends up not being used).
• The side focus on satellite imagery (still a lot of stuff in side projects, currently we only parse metadata from filename on opening through the SatelliteImage subclass: https://geoutils.readthedocs.io/en/stable/satimg_class.html): here I'm thinking that a Xarray metadata reader for satellite imagery could be its own package/accessor sat, living independently of all the rest (GeoUtils, GeoWombat)? Could be a great way to merge efforts!
• Wrappers for other image processing methods (e.g., coregistration): on our side we have mostly focused on 3D coregistration for DEMs (https://xdem.readthedocs.io/en/stable/coregistration.html) but also intended to add 2D coregistration and others. You've done so much work on these aspects, it doesn't make sense to duplicate it... But if we wanted to use GeoWombat's functionalities on this, a dependency would be needed to access it. Maybe eventually moving these as "add-ons" independent of the core geo-manipulation, somewhere in another package, would make sense? The Xarray geo landscape has been evolving a lot in the past years, but now it seems easier to have this type of functionality living separately (with advances in the core of GeoWombat, or also rioxarray, geocube, etc).

That's it, otherwise I see minimal overlap on the rest of our functionalities! Those include notably:

• Spatial operations (buffering, proximity, etc... here there's a tiny bit of overlap with Xarray-Spatial),
• Terrain attributes (also a tiny bit of overlap with Xarray-Spatial),
• Wrappers for geostatistics and uncertainty analysis methods.

Tell me what you think!

[jgrss]

Hi @rhugonnet thanks for the note with background and references. I need to look over your package in more detail, but my quick reaction.

The facilitated geo-manipulation

Merging efforts could make sense. Within our config manager, we basically just have rasterio/WarpedVRT and dask.delayed methods. I could see having many of the Xarray/Dask warping methods elsewhere while maintaining the same geowombat API.

The side focus on satellite imagery

This is intriguing. We could do better in terms of supporting more sensors. But we could also benefit from a centralized location as you suggest.

[rhugonnet]

Thanks for the feedback @jgrss!

I could see having many of the Xarray/Dask warping methods elsewhere while maintaining the same geowombat API.

Yes, that makes sense. Technically, how would you see this? A repo built on the same rasterio/dask logic, or probably using directly rioxarray? It might also make sense to contribute there directly for some aspects, but probably not all. If we write our own accessor in GeoUtils, it would essentially wrap rioxarray with facilitated logic for passing metadata between vectors/rasters in any CRS (match-reference, point interpretation, etc, but I'm not sure just adding this feature justifies a whole new repo; having WarpedVRT support would already justify it much more).

We could do better in terms of supporting more sensors. But we could also benefit from a centralized location as you suggest.

Yes, it'd be great but probably the most work! I feel there are a lot of efforts distributed all throughout the Python landscape for satellite imagery... (to the point that I probably don't even know half of them). The Xarray ecosystem needs it. Would need someone very motivated to start this up!