[GRASS-user] flow accumulation values

GRASS GRASS user
1

I noticed something today that I don’t understand.
When I run r.watershed and calculate the flow accumulation raster, I expect that along each stream, in the direction of flow, accumulation values will always be higher from one cell to the next. But I see this is not the case. Sometimes, along a stream, the accumulation will drop for one cell, then “jump up” again a few cells downstream.

See the attached image. The green squares are clipped from a flow accum grid. And the numbers are flow accum values. The arrow is general flow direction, and the circles show examples of a sudden drop in flow accum.

I’m aware of the “edge of map” behavior where out of region accum gets a negative value. That’s not the issue here, since the sample in the attached image is from right in the center of the region, no off map flow is involved.

This problem surfaced in a script I’ve prepared to calculate total flow accumulation for each stream reach. After running the addon r.stream.order I add columns to the streams vector map for X-Y of the end points and total flow for each reach, then I use v.what.rast to get the flow accum at each stream reach end-point. But the values I’m getting are strange. Sometimes a downstream reach shows lower total accum than the previous, upstream segment.

Maybe someone can shed some light?

Thanks,
Micha

(attachments)

flow accumulation values.png

2

Is this MFD or SFD? If MFD, flow may split and re-join.

I also noticed that r.stream.extract finds different flow-paths than r.watershed, which complicates comparisons between the two. The work-around for this is to use a mask to force r.stream.extract to find the flow-path you want.

  -k.

On 2016-08-25 at 13:35, Micha Silver <micha@arava.co.il> wrote:

I noticed something today that I don't understand. When I run
r.watershed and calculate the flow accumulation raster, I expect that
along each stream, in the direction of flow, accumulation values will
always be higher from one cell to the next. But I see this is not the
case. Sometimes, along a stream, the accumulation will drop for one
cell, then "jump up" again a few cells downstream.

See the attached image. The green squares are clipped from a flow
accum grid. And the numbers are flow accum values. The arrow is
general flow direction, and the circles show examples of a sudden drop
in flow accum.

I'm aware of the "edge of map" behavior where out of region accum gets
a negative value. That's not the issue here, since the sample in the
attached image is from right in the center of the region, no off map
flow is involved.

This problem surfaced in a script I've prepared to calculate total
flow accumulation for each stream reach. After running the addon
r.stream.order I add columns to the streams vector map for X-Y of the
end points and total flow for each reach, then I use v.what.rast to
get the flow accum at each stream reach end-point. But the values I'm
getting are strange. Sometimes a downstream reach shows lower total
accum than the previous, upstream segment.

Maybe someone can shed some light?

Thanks, Micha

3 
Is this MFD or SFD? If MFD, flow may split and re-join.

The default for r.watershed is MFD. I didn’t change that. I didn’t see any splits in the flow path in the sections that I checked. And I didn’t run r.stream.extract, only r.stream.order

Thanks,
Micha

4

On Thu, Aug 25, 2016 at 4:07 PM, Ken Mankoff <mankoff@gmail.com> wrote:

Is this MFD or SFD? If MFD, flow may split and re-join.

Exactly. With MFD, flow may be distributed to several downstream cells
and the accumulation value can drop when following the extracted path.
This is is most prominent when a river flows into an ocean. Paths,
however, follow Horton's stream network logic and can not split, only
join.

I also noticed that r.stream.extract finds different flow-paths than r.watershed, which complicates comparisons between the two. The work-around for this is to use a mask to force r.stream.extract to find the flow-path you want.

r.stream.extract is the preferred stream extraction tool.

Markus M

  -k.

On 2016-08-25 at 13:35, Micha Silver <micha@arava.co.il> wrote:

I noticed something today that I don't understand. When I run
r.watershed and calculate the flow accumulation raster, I expect that
along each stream, in the direction of flow, accumulation values will
always be higher from one cell to the next. But I see this is not the
case. Sometimes, along a stream, the accumulation will drop for one
cell, then "jump up" again a few cells downstream.

See the attached image. The green squares are clipped from a flow
accum grid. And the numbers are flow accum values. The arrow is
general flow direction, and the circles show examples of a sudden drop
in flow accum.

I'm aware of the "edge of map" behavior where out of region accum gets
a negative value. That's not the issue here, since the sample in the
attached image is from right in the center of the region, no off map
flow is involved.

This problem surfaced in a script I've prepared to calculate total
flow accumulation for each stream reach. After running the addon
r.stream.order I add columns to the streams vector map for X-Y of the
end points and total flow for each reach, then I use v.what.rast to
get the flow accum at each stream reach end-point. But the values I'm
getting are strange. Sometimes a downstream reach shows lower total
accum than the previous, upstream segment.

Maybe someone can shed some light?

Thanks, Micha

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

5

Hi Markus



Is this MFD or SFD? If MFD, flow may split and re-join.


Exactly. With MFD, flow may be distributed to several downstream cells
and the accumulation value can drop when following the extracted path.
This is is most prominent when a river flows into an ocean. Paths,
however, follow Horton's stream network logic and can not split, only
join.

So what would be the correct way to get total flow accumulation for each stream segment?
Do I have to revert to running r.watershed with the SFD flag?



I also noticed that r.stream.extract finds different flow-paths than r.watershed, which complicates comparisons between the two. The work-around for this is to use a mask to force r.stream.extract to find the flow-path you want.


r.stream.extract is the preferred stream extraction tool.

OK, but a flow accum raster is required for running r.stream.order (which outputs flow_accum) and AFAIK, the only way to get a flow_accum raster is with r.watershed.
??

Best,
Micha

6

I also noticed that r.stream.extract finds different flow-paths than r.watershed, which complicates comparisons between the two. The work-around for this is to use a mask to force r.stream.extract to find the flow-path you want.

r.stream.extract is the preferred stream extraction tool.

OK, but a flow accum raster is required for running r.stream.order (which outputs flow_accum) and AFAIK, the only way to get a flow_accum raster is with r.watershed.
??

BTW, I’m not the only one who has encountered this:

http://gis.stackexchange.com/questions/201118/how-to-obtain-accumulation-map-from-r-stream-extract

Thanks,

7

On Fri, Aug 26, 2016 at 9:41 AM, Micha Silver <micha@arava.co.il> wrote:

Hi Markus

------ Original Message ------ Subject: Re: [GRASS-user] flow accumulation
values Date: Thu, 25 Aug 2016 19:54:59 +0200 To: Ken Mankoff, Micha Silver,
Grass-user From: Markus Metz

On Thu, Aug 25, 2016 at 4:07 PM, Ken Mankoff <mankoff@gmail.com> wrote:

Is this MFD or SFD? If MFD, flow may split and re-join.

Exactly. With MFD, flow may be distributed to several downstream cells
and the accumulation value can drop when following the extracted path.
This is is most prominent when a river flows into an ocean. Paths,
however, follow Horton's stream network logic and can not split, only
join.

So what would be the correct way to get total flow accumulation for each
stream segment?
Do I have to revert to running r.watershed with the SFD flag?

Probably yes. For MFD, streams can be more than one cell wide, and you
would need to draw a cross-section at the beginning and end of each
stream segment, then sum up all stream cells for each cross-section.

I also noticed that r.stream.extract finds different flow-paths than
r.watershed, which complicates comparisons between the two. The work-around
for this is to use a mask to force r.stream.extract to find the flow-path
you want.

r.stream.extract is the preferred stream extraction tool.

OK, but a flow accum raster is required for running r.stream.order (which
outputs flow_accum) and AFAIK, the only way to get a flow_accum raster is
with r.watershed.
??

Correct. Extracting a stream network needs flow accumulation and
elevation as input. Thus the workflow would be 1) r.watershed to get
flow accumulation, 2) r.stream.extract to get the stream network, 3)
r.stream.order.

Markus M

Best,
Micha

Markus M

  -k.

On 2016-08-25 at 13:35, Micha Silver <micha@arava.co.il> wrote:

I noticed something today that I don't understand. When I run
r.watershed and calculate the flow accumulation raster, I expect that
along each stream, in the direction of flow, accumulation values will
always be higher from one cell to the next. But I see this is not the
case. Sometimes, along a stream, the accumulation will drop for one
cell, then "jump up" again a few cells downstream.

See the attached image. The green squares are clipped from a flow
accum grid. And the numbers are flow accum values. The arrow is
general flow direction, and the circles show examples of a sudden drop
in flow accum.

I'm aware of the "edge of map" behavior where out of region accum gets
a negative value. That's not the issue here, since the sample in the
attached image is from right in the center of the region, no off map
flow is involved.

This problem surfaced in a script I've prepared to calculate total
flow accumulation for each stream reach. After running the addon
r.stream.order I add columns to the streams vector map for X-Y of the
end points and total flow for each reach, then I use v.what.rast to
get the flow accum at each stream reach end-point. But the values I'm
getting are strange. Sometimes a downstream reach shows lower total
accum than the previous, upstream segment.

Maybe someone can shed some light?

Thanks, Micha

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

8

On Fri, Aug 26, 2016 at 9:56 AM, Micha Silver <micha@arava.co.il> wrote:

I also noticed that r.stream.extract finds different flow-paths than
r.watershed, which complicates comparisons between the two. The work-around
for this is to use a mask to force r.stream.extract to find the flow-path
you want.

r.stream.extract is the preferred stream extraction tool.

OK, but a flow accum raster is required for running r.stream.order (which
outputs flow_accum) and AFAIK, the only way to get a flow_accum raster is
with r.watershed.
??

BTW, I'm not the only one who has encountered this:

http://gis.stackexchange.com/questions/201118/how-to-obtain-accumulation-map-from-r-stream-extract

The main purpose of r.stream.extract is to extract a stream network
from any flow accumulation map and elevation map. The flow
accumulation map can be produced with any other tool that is able to
accumulate flow, and that tool does not need to be a GRASS module,
e.g. TAUDEM output is also fine. Further on, any flow accumulation can
be further processed before being used as input for r.stream.extract.
For example, valleys identified by some curvature analysis could be
enhanced.

r.stream.extract can also work with only elevation as input. In this
case flow accumulation is done internally similar to r.watershed. If
you need flow accumulation, it must be calculated first and then used
as input for r.stream.extract.

Markus M

Thanks,

Best,
Micha

9

I’ve changed my script to use the flags “-a -s” in r.watershed so that Single Flow Direction is used, and flow out of the region is a positive value. Works fine now.

···

On 31/08/2016 23:33, Markus Metz wrote:

On Fri, Aug 26, 2016 at 9:41 AM, Micha Silver [<micha@arava.co.il>](mailto:micha@arava.co.il) wrote:


Hi Markus

------ Original Message ------ Subject: Re: [GRASS-user] flow accumulation
values Date: Thu, 25 Aug 2016 19:54:59 +0200 To: Ken Mankoff, Micha Silver,
Grass-user From: Markus Metz

On Thu, Aug 25, 2016 at 4:07 PM, Ken Mankoff [<mankoff@gmail.com>](mailto:mankoff@gmail.com) wrote:

Is this MFD or SFD? If MFD, flow may split and re-join.

Exactly. With MFD, flow may be distributed to several downstream cells
and the accumulation value can drop when following the extracted path.
This is is most prominent when a river flows into an ocean. Paths,
however, follow Horton's stream network logic and can not split, only
join.

So what would be the correct way to get total flow accumulation for each
stream segment?
Do I have to revert to running r.watershed with the SFD flag?


Probably yes. For MFD, streams can be more than one cell wide, and you
would need to draw a cross-section at the beginning and end of each
stream segment, then sum up all stream cells for each cross-section.


-- 
Micha Silver
Arava Drainage Authority
+972-523-665918
10

On Thu, Sep 1, 2016 at 7:28 AM, Micha Silver <micha@arava.co.il> wrote:

On 31/08/2016 23:33, Markus Metz wrote:

On Fri, Aug 26, 2016 at 9:41 AM, Micha Silver <micha@arava.co.il> wrote:

Hi Markus

------ Original Message ------ Subject: Re: [GRASS-user] flow accumulation
values Date: Thu, 25 Aug 2016 19:54:59 +0200 To: Ken Mankoff, Micha Silver,
Grass-user From: Markus Metz

On Thu, Aug 25, 2016 at 4:07 PM, Ken Mankoff <mankoff@gmail.com> wrote:

Is this MFD or SFD? If MFD, flow may split and re-join.

Exactly. With MFD, flow may be distributed to several downstream cells
and the accumulation value can drop when following the extracted path.
This is is most prominent when a river flows into an ocean. Paths,
however, follow Horton's stream network logic and can not split, only
join.

So what would be the correct way to get total flow accumulation for each
stream segment?
Do I have to revert to running r.watershed with the SFD flag?

Probably yes. For MFD, streams can be more than one cell wide, and you
would need to draw a cross-section at the beginning and end of each
stream segment, then sum up all stream cells for each cross-section.

I've changed my script to use the flags "-a -s" in r.watershed so that
Single Flow Direction is used, and flow out of the region is a positive
value. Works fine now.

Testing SFD and MFD flow accumulation as input for r.stream.extract
and r.stream.order showed that using MFD flow accumulation is fine and
provides reasonable results. For high-resolution DEMs, e.g. 1m LiDAR,
SFD-based results are IMHO unrealistic.

Instead of using flow accumulation at each stream reach end point, you
could also use basin sizes for each stream reach outlet determined
with r.water.outlet or r.stream.basins.

Markus M