# Flowdirection and sink

Discussion created by arminreiinartz on Feb 14, 2013
Latest reply on Feb 21, 2013 by arminreiinartz
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