What is a good method to delineate ridge lines that exist within a DEM? My goal is a contour map with heavier lines to represent ridges. [The inverse of this would be to delineate flow lines.]
I’ve been experimenting with grdgradient, with the -D and -S options (azimuth & magnitudes), even applying grdgradient twice, to get some sense of the locations of ridges.
I haven’t quite stumbled upon the means to derive a good representation of ridges. Is there a better algorithm to numerically determine ridge lines (or flow lines)?
After more trial and error, it seems that grdfilter using a box-car mean and a high-pass filter (-Fb25+h), followed by a grdmath command (to mask-out low values) does a fairly decent job of “finding” ridge lines. I’m tweaking parameters to find the sweet spot for what I need.
This experiment is nowhere near being able to directly create a numerical ridge-line data set on the basis of an input DEM. All that I’ve been able to do is identify localized high spots within a DEM.
This is a map of a small portion of the south polar region of the Moon, near the Amundsen Crater. Here’s a sample of the topography (units are meters above the lunar sphere: 1737.4 m):
I’m not sure if this is a potential solution to getting coordinates of the ridges or not.
grdcontour can dump the coordinates of contours using the -D option. If it is somehow possible to contour your last image so that contour lines fall on the black parts, then you might be able to dump the coordinates this way.
@Tim, yes, I thought about that as well, but the lines in the map are rather “fuzzy” and I wasn’t sure that the contour dump would be very meaningful. And the choice of contour may be subjective. Won’t really know until it’s attempted.
@mkono, I spotted some of that material during an on-line search, as well. It seems there are software packages out there that can perform these kinds of tasks. There is a 2019 paper by Tsai & Lin published in the Civil Engineering Research Journal, that provides some very useful ideas. This paper led me to try using grdfilter in a similar fashion.
River paths are detected with those flow accumulation alghoritms. Probably simpler (and less accurate) is the Ridge Detection that uses image processing techniques. GMT has neither of them.
The lack of a ridge detection scheme within GMT was why the question was posed!
My approach succeeds at providing a map with the basic info needed. The particular features that are needed can be digitized, in order to make the map/graphic required.
I’m realising how long it has been since I studied this stuff at university! The divergence of the gradient is the Laplacian. Here is a simplified version of the above script:
If I may, since you seem to remember the lectures at university (..);
In the grdmath docs docs there is an operator called CURV, which returns the Curvature of A (Laplacian). Do you know why it is called Laplacian? As you write, isn’t the divergence of the gradient the Laplacian?
Oh dear @Andreas … when I say remember my lectures, it’s a bit like remember a movie one saw thirty years ago. Bits and pieces come back, but not the whole works. This was stuff they taught us in second year physics … and I remember the lecturer setting extremely hard assignments which would wipe out whole weekends.
I’m not sure why CURV is labelled curvature instead of LAP or some such thing. I just checked, and it returns exactly the same result as the script using D2DX2 etc. So there goes a further simplification.
How I ended up at the Laplacian was I was thinking about drawing the gradient on a DEM. The gradient is a field of vectors pointing in the upwards direction of the terrain. A feature of ridge lines is that the gradient vectors on both sides of the ridge line will be converging at the ridge. And converging vectors have a negative divergence. Similarly for valleys, one would look for the gradient vectors diverging (positive divergence). It was only later that I realised that I was actually just computing the Laplacian.
