"ridge" definition used in DEM-terrain derivatives is problematic

[dschwilk]

The definition of ridge is problematic. Here is the key part of the definition of a "ridge" from the methods file:

In other words, grid cells with zero values have no flow accumulation and are thus ridges.

But this results in the much of the landscape being ridges. Additionally, there are linear artefacts for some reason. Here is a zoomed in image of the GM showing all ridges (eg all points where ldist_ridge==0) as black points (points are not to scale but this helps illustrate the problem):

And here is a slightly large scale view of the same problem for the CM. The artefacts are still visible:

So this method over-identifies ridges. This then effects all of the other derivatives that use the ridge layer.

[dschwilk]

Some of the other affected layers that use the ridges definition show these artefacts if you check closely. Eg relelev_l looks fairly smooth, but that is because the main signal is from ldist_valley. The speckling and artefacts are there.

[dschwilk]

I think the variables affected by this are

z_ridge relelev_l relelev_z zdist_ridge ldist_ridge

---

• corrected

[dschwilk]

Can you invert the DEM and use the valley definition? Because your valley calculations seemed to work.

[hpoulos]

I have narrowed this down to the calculation of the flow direction grid in a projected vs. unprojected datum.

This was a simple operation to generate the flow direction from the dem that was directly downloaded and then had sinks filled (which is standard). This link discusses the issue: http://gis.stackexchange.com/questions/7906/calculating-flow-direction-and-delineating-basins-from-projected-vs-unprojected

The distance measures we are trying to get rely on a dem in a projection that is in meters, which is why I projected out of the native WGS1984 projection and into NAD83, and then back again for all the asciis so they would all have the same projection and extents after all layers were generated.

[dschwilk]

Did you do any smoothing on the DEM input into these calcs? I would think that that could help.

[hpoulos]

I am looking into it. I also did the inversion.

[hpoulos]

The flow direction grid in the native WGS 1984 (an unprojected coordinate system) does not have this, as discussed in the link in my last comment.

This is likely the root of the problem. As I said before, because we were interested in distance measures, I reprojected to a metric projection from the DEM in WGS84 which was in decimal degrees before doing the other operations. As the link in my last comment indicates, there is no indication in ArcGIS of this issue. I will now see what happens when I derive the flow direction and flow accumulation grids in WGS1984, delineate ridges/valleys, and then reproject those to NAD83 (metric) for the distance measures.

[hpoulos]

There is some literature on using neighborhood functions to smooth the filled DEM first before making the flow accumulation grid. Smoothing once does little to change the ridge delineation. However, smoothing twice with a neighborhood cell size of 3 x 3 cells, produces better results. The first image below are ridges from the raw flow accumulation grid from the raw unprojected DEM. The second is the twice smoothed (using neighborhood or focal statistics) dem-derived ridges.

[hpoulos]

This paper suggests that up to 10 smoothing iterations can be done to extract desired features: http://discovery.ucl.ac.uk/2105/1/RANA_Sanjay-SDH_2006_revised.pdf

[dschwilk]

Visually, smoothing seems to work well!

[hpoulos]

Sort of been waiting for a comment on how much smoothing to proceed. The bottom image still looks like too many pixels, but I don't have a real quantitative way to proceed other than the above paper, nor do I want to make the final grids more than one more time.

[dschwilk]

If that is the only literature on the subject, then I suppose follow that and try 10 -- but are smoothing algorithms the same? Can this be scripted, though? Having to click and do this stuff manually seems pretty inefficient.

[hpoulos]

This is all I could find. Every other article I read said to just do exactly what I had done before, which ended up being meaningless. I will smooth 10 times (in model builder so it's not so repetitive) and will show you the final product draped over the hillshade to see if it makes sense. Stay tuned.

[hpoulos]

so this is what smoothing does after smoothing the DEM 10 times with model builder, then making the flow direction and flow accumulation grids, and then reclassifying values with flow accumulation of 0 to identify ridges. How does this look? Note: the striping problem is also gone.

[hpoulos]

Here it is as well draped over hillshade. See if this makes sense and I'll proceed to make the other layers we have discussed in this and the other issues.

[hpoulos]

This is what the euclidean distance to ridges looks like with this smoothed product in meters.

[dschwilk]

It looks much better. Some of the ridges look surprisingly broad, but other than that, it seems to have eliminated artefacts a well as the general over-identification. I would imagine the flow accumulation grid might be useful now combined with elevation in order to capture air drainage. Cool.

[hpoulos]

So here is a picture of ridges (red) and valleys (black) using the smoothed definitions and the flow accumulation thresholds on top of the smoothed DEM. This seems reasonable to me. Thoughts?

[hpoulos]

Here is what the zdist_ridge grid looks like with ridges superimposed on the output grid. Values close to the ridges have numbers that are low (i.e. little elevation difference) and values far from ridges have larger numbers (i.e. big diff between elevations).

[dschwilk]

The valleys in the first of your last two posts seem strangely linear in several cases. Explanation? Other than that that loks good.

I don't understand the second figure. Are the black lines ridges? If so, why are theire high values (reds?) near ridges? That looks like elevation, not zdist_ridge.

[hpoulos]

The valleys look linear because the flow accumulation grid is based on the flow direction grid. I can look for another explanation, but i suspect that's why because flow direction is calculated based on each pixel's 8 surrounding neighbors.

As for the second figure, it is zdist_ridge. Look at the model builder .jpgs when I send them and that should clarify the process some.

[dschwilk]

This appears solved as of June 2, 2016 grid update. I am not closing this yet as I have some questions about variables that no longer exist.

z_ridge: No longer exists? Not needed. relelev_l: renamed to relev_l? But looks good. see 84d519e relelev_z: Now missing. Why? zdist_ridge: Looks good ldist_ridge: looks good.

[hpoulos]

the z_ridge and z_valley layers were intermediary. The Euclidean allocation tool automates this process so those layers are gone. relelev_l is now relev_l; a typo, so either change that grid name to the correct one or just leave it.

As for relelev_z, I left it out because I'm not convinced it means much. I can certainly calculate it as: 13. relel_z: Relative z position channel to divide, based on z_distridge and z_distvalley. Relel_z= z_distridge– z_distvalley. The question is the meaning. If you think it's useful and meaningful, I will generate that layer, toolbox, etc.

[dschwilk]

Ok, will leave everything as is. Closing. Thanks.