Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: terrain attributes based on 5x5 polynomial fit #661

Open
trchudley opened this issue Nov 22, 2024 · 1 comment
Open

Proposal: terrain attributes based on 5x5 polynomial fit #661

trchudley opened this issue Nov 22, 2024 · 1 comment

Comments

@trchudley
Copy link

Posted here following discussion with @rhugonnet

Currently, xdem calculates terrain coefficients over a 3x3 window following Zevenbergen and Thorne (1987) and Horn (1981). This is suitable approach for the vast majority of scenarios, but there are potential alternatives which have advantages in specific situations.

An alternative approach by Florinsky (2009) calculates derivatives by fitting a third-order partial polynomial to a 5x5 window. This larger window can be better suited to high-resolution photogrammetry data as it leads to a local denoising effect.

I have implemented this method in a numba-friendly way in my own work for ArcticDEM/REMA strips and would be happy to help porting this functionality to xdem if desired - if only because in the medium term I would like to move my coregistration functions to use xdem in the backend!

P.S. Elsewhere in Florinsky's work, there are also a number of further curvature attributes that might be desirable to port into xdem and are easy to implement. This includes horizontal, vertical, and gaussian curvature as well as unsphericity.

@rhugonnet
Copy link
Member

Amazing, your implementations are much shorter, probably also more computationally efficient than ours (I wonder if our "if" loops slow down the process or not at all, I don't have a good enough understanding of numba)! 😅

For this type of kernel/array size relation, I remember reading a blogpost showing that convolution was typically faster than numba, which is why we have this ongoing: #486.
But we need to do some more testing before actually implementing it. It could be the perfect occassion to compare with your numba implementation too, then move forward from here 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants