Coordinating efforts on potential new geospatial Xarray accessor about geowombat HOT 2 OPEN

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.

from geowombat.

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!

from geowombat.