Nuth & Kaab coregistration does not work in EPSG4326

[adehecq]

If DEMs are on a non-projected CRS, the Nuth & Kaab coregistration won't work, because the slope calculation does not make sense.
We can try to find a fix to that, or at least raise an Error when the input DEMs are in non-projected CRS.
I don't have time to write a reproducible example, but probably the Nuth & Kaab example with the DEMs reprojected in EPSG 4326 should reproduce that error.

[rhugonnet]

Generically, we could have a UserWarning like they do in geopandas or rasterio:
Attempting to perform this operation in a geographic projection system, the results might be erroneous

For convenience "head" functions for which it is practical to have everything working in one-line, we could force the reprojection to a metric projection system and also raise a warning that this is done in the background.

[erikmannerfelt]

Generically, we could have a UserWarning like they do in geopandas or rasterio: Attempting to perform this operation in a geographic projection system, the results might be erroneous

For convenience "head" functions for which it is practical to have everything working in one-line, we could force the reprojection to a metric projection system and also raise a warning that this is done in the background.

That's a super good idea. Any raster where xres != yres technically risk being a bit wonky.

I'm pretty sure that's what makes co-registration fail in WGS84 cases, not necessarily the degree coordinates. Sure, the units will be super off, but when xres == yres it should be consistent, no?

[erikmannerfelt]

There's also the pyproj.CRS.is_projected property that might be useful in showing if it's a good or bad idea.

[adehecq]

But... I added a NotImplementedError already some time ago here.
Is this sufficient (and so we close that issue) or do we want to implement that weird case?! I don't know why I didn't reference this issue when I made the change, my bad 🤦‍♂️

[rhugonnet]

Indeed this is already covered by the NotImplementedError. Maybe we could generalize this type of error for other classes as well. But for this specific issue, we can close.