nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Flowdirection and sink

ArminReinartz

Hello,

I´m writing my Master-thesis and have some problems to understand the results of "flowdirection" and "sink".

When a cell is lower than all neighbours it is lifted up (during the flowdirection-process) to the height of the lowest neighbour. Normally the current cell and this neighbour will flow into one another. A result what is expected is e.g.: In the raster ...720 705 711 714... the 705 is lifted up to the next neighbour (711) and gets the flowdirection "1", whereas the 711 flows back and gets the "16". So both cell are marked as "sink".

But in my opinion (and my results of DEM-preprocessing confirm my ideas) "sink" don´t really find cells, which are lower than their neighbours, what I would expect by the name "sink". Rather the output gives cells with an undefined flowdirection, which can appear because of several reasons. E.g. when the lowest cell is lifted up and the neighbour has another decisive flowdirection, the deepest cell won´t be marked as a "sink". ...720 705 711 708 700... (705 is lifted up to 711 and gets flowdir=1, but 711 has flowdirection=1 as well and doesn´t flow back to the lifted 705, because 708 is the decisive flowdirection. Is this right? Why the deepest value 705 is neglected in the "sink"-procedure?

Another astonishing case is when two low cells have another cell between (e.g.: .....720 705 711 705 718...) the both 705-values get 711 in the flowdirection-process and get flowdirections "1" and "16" resp. The 711 gets the flowdirection=17 because of the same vertical height in two directions. The point I don´t understand: Why the two 705-points won´t marked as "sinks"; instead just 711 is a "sink" although it is not the deepest value in th neighbourhood?

With this context the first example gives randomly the expected result (705=sink).

I hope you can help me to better understand the functions "flowdirection" and "sink" or show me my mistake in theory!

Best,
Armin

Find more posts tagged with

Accepted answers

All comments

MarkBoucher

When a cell is lower than all neighbours it is lifted up (during the flowdirection-process) to the height of the lowest neighbour.

This is incorrect. The cell is lifted up during the fill sinks process.

The normal process for DEM Reconditioning is in this order: burn in streams, build walls (if needed), and then fill sinks. This results in a "hydrologically correct" DEM if your streams and walls are all in the right places.

All of these are elevation models. You have to perform these functions because the "raster world" misses details, can't see underground or under bridges, and is too coarse to distinguish subtle ridges and swales. These DEM Reconditioning processes make sure the elevations are such that when you perform the flow direction process on the filled DEM, the flow directions will be correct.

The elevations in the filled DEM may be 1000's of feet off, but that does not matter. When you perform the flow direction function on the filled raster and have a flow direction grid the elevations are not used in the rest of the watershed processing of the process in defining streams, catchments, etc. Of course, when you need a correct elevation, you have to go back to the rawdem.

Doing the flow direction before filling, really does not take into account the filled sinks.

Hope this makes sense.

My posts at http://forums.arcgis.com/threads/48100-ArcHydro-Problem-Solvers explain the process in more detail as I've learned it.

ArminReinartz

Hello,

sorry for my wrong term. What I meant is: during the flowdirection the cell is lifted up just virtually, so that it can get a flowdirection-value to its lowest neighbour. Of course the original elevation is not changed here.

Thank you for the explanation of the rationale of the flowdirection...indeed it´s important to fill the wrong cells before the later analysis.

I think I have to write more clear to say that my problems was to understand the "sink"-process. The only input there is a flowdirection-raster...and no information of the elevation is given to the process. Following the results of "sink", not just
the "deepest cells" but also other cells are marked as "sinks". And even sometimes the deepest cells are neglected bein marked as "sinks", whereas the neighbour with the lowest height is a sink. Reading the helps in ArcGIS, I got the information, that the sink-tool just looks for either 1) undefinded flowdirections or 2) cells which flow into one another. Of course this makes sense. But it doesn´t take care of information of the actual elevation. Because of the name "sink" I would expect that the deepest cells would be marked as "sinks" as well.

Can anyone explain these strange results?

A second aspect is the "fill"-procedure. I know, why it is useful and an essential step in preprocessing to lift up error-cells. But I don´t get some information 1) which cells are lifted up and 2) which cell gives its elevation for the new and lifted value. In the ArcGIS-help relating to "sink" (http://help.arcgis.com/de/arcgisdesktop/10.0/help/index.html#/na/009z00000065000000/), it is described, that you can create a watershed based on "sink"-cells and look for the minimum value and its boundary. Every cell which is lower than this watershed-boundary is lifted up then. That is comprehensible!

But in my DEM-examples I had two problems or disagreements:
- sometimes the new value, to which the low cell are lifted up, lies beside (outside) the watershed? (I searched for the value in the original DEM and found it right beside the watershed based on the sink) So why do the swales get this value, when it is not a part of the watershed? Or in other words: How is the new value of the swales determined? It is definitely not just the next neighbour, what the help in ArcGIS hypothesizes (I tested it).

- in some cases there was no "sink"-cells found, but a "fill"-process lifted up the deepest cells anyway. So is the question: Which point is chosen as the pourpoint for the watershed?

In a short form my questions are:
1) Which cells are getting marked as "sinks" and why do not all deepest cells become a "sink"?
2) Which cells are lifted up in the "fill"-process (deepest cells or sink-marked ones)?
3) Which cell or value is responsible for the uplift-value (minimum in watershed?) and how can I determine it (when there are no sinks)?

I hope on your answers!
Thank you
Armin

MarkBoucher

It seems that maybe you are performing more analysis than needed to simply get to the point where you can delineate watersheds. You may want more details for your work, and if so, that's fine.

When I process the DEM, I don't worry that much about the sinks. I perform the Terrain Processing using only the toolbar menu items highlighted in the image below. I follow arrow 1 and then arrow 2 and only use the highlighted tools. After I'm satisfied with catchment delineation I will perform the items below arrow 2 since other watershed processing steps use the layers that result from them.

[ATTACH=CONFIG]21840[/ATTACH]

If you want to see which cells are lifted up (raised) in the fill sinks process, you can use the raster calculator to subtract the rawdem from the fil dem. The result is the amount each grid cell is filled. I use the symbology options to change the background value of 0 to the color "Null" or no color and I use the white to blue color ramp. This makes it easy to see which grid cells have been changed and the color ramp provides some visual comparison. The identify tools will give you the amount the cells were filled.

Hope this helps.

Terrain Processing Image of Menus.jpg

MarkBoucher

It just dawned on me that you are using the Spatial Analyst tools while I have been referring to Arc Hydro tools. Arc Hydro uses Spatial Analyst, but has more specific function and builds a network of the catchments, drainage lines and drainage points to allow more complex analysis.

dwold_1-1717596700292.png

ArminReinartz

Hello,

oh yes sorry, I didn´t tell that I´m just use the Spatial Analyst tools in ArcGIS. I have not heard about the Arc Hydro tools yet.

In fact the linkage of catchments is one specific fact, that is difficult to build with Spatial Analyst.

Especially for my aim: I want to calculate the risk of erosion by the RUSLE-formula. Two of its factors deal with the flowlength (namely the maximum flowlength of a hillside) and the slope. For single hillsides it is no problem to identify both the flowlength and the slope (e.g. using an average slope). In a discontinuous area (DEM) it is quite more complicated. My idea was:

- identify the flowpath (flowaccumulation) and calculate the flowlength...what is no problem
- build watersheds by setting a threshhold for the flowaccumulation (e.g. 1000) and use the functions of pourpoints and watershed
- the problematic step follows: following the flowpath inside a watershed the slope changes...possibly severely. When I want to calculate the erosion-risk I cannot use one characteristic slope-value of the whole watershed but have to divide it in more smaller parts because the RUSLE-formula enables the calculation of parts by using weighting-factors.
- so my way is to build sub-watersheds relating to the changing in slope (e.g. when the slope of the following cell is more than twice or less than half the actual slope I will set a pourpoint for the sub-watershed)

The point is: Is it possible to describe an inhomogious area by just one slope value? Or which variation requires a sub-division?

Do you know if the ArcHydro tool provides some functions to approach a solution? (sub-dividing a watershed relating to slope?)

Thank you for all your answers...
Best
Armin

MarkBoucher

Do you know if the ArcHydro tool provides some functions to approach a solution? (sub-dividing a watershed relating to slope?)

I do not know if Arc Hydro can do that. It can automate the watershed subdivision based on an area, but I've not heard of it using choosing the watersheds using slope.

ArminReinartz

Ok, no problem! It does not matter. But thank you for the hint about ArcHydro.
I will test it in the next days...

Best
Armin

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.