New Xarray accessor for DEMs through xDEM

[rhugonnet]

Hi all,

(Co-opening in rioxarray due to the raster nature of the accessor: corteva/rioxarray#687)

Following what is asked in the doc, I'm letting you know that we intend to write an xarray accessor to enable functions specific to digital elevation models in our package xDEM! 🙂

The accessor would mirror all the functionalities we have (and future ones):

• Vertical CRS transformation (not yet supported by rasterio so built on top of pyproj directly, would build on top of rioxarray in the accessor),
• Terrain attributes (I see a bit of overlap with xarray-spatial in "Surface": https://xarray-spatial.org/user_guide/surface.html for some of these; we have more published versions which can be parametrized, so I guess that's OK? I could start a discussion there to coordinate future development),
• 3D registration,
• Terrain corrections,
• Error estimation and propagation (may be moved to GeoUtils as not specific to DEMs but all rasters, see New Xarray accessor for rasters through GeoUtils #8041; eventually using ObsArray).

I was thinking of using the accessor name dem, e.g.: ds.dem.to_vcrs(), ds.dem.profile_curvature() or ds.dem.coregister(). I didn't catch any overlap with other efforts. Would that work fine?

Thanks! (and for the great work on xarray!)

[welcome]

Thanks for opening your first issue here at xarray! Be sure to follow the issue template!
If you have an idea for a solution, we would really welcome a Pull Request with proposed changes.
See the Contributing Guide for more.
It may take us a while to respond here, but we really value your contribution. Contributors like you help make xarray better.
Thank you!

[headtr1ck]

Feel free to also include this project to https://docs.xarray.dev/en/stable/ecosystem.html#ecosystem via a PR.

Seeing that finding out which accessor namespaces are occupied is not a trivial task, maybe we should add a section about that in the above doc?

[rhugonnet]

Thanks @headtr1ck! Will do this soon.

Agreed, a little table with accessor names would be useful, especially when many Xarray-related projects listed don't actually use any accessor, which is also good info. I think some projects are migrating to the accessor logic, it could be the occasion to tag them in a common PR and ask for an update?