[GRASS-user] Question about r.watershed and flow accumulation grid

[Markus Metz]

On Sat, Feb 14, 2015 at 3:45 PM, Thomas Adams <tea3rd at gmail.com> wrote:
>
> The reason I need to use the D8 (SFD) algorithm is that I am generating a
> file that identifies how pixels are connected hydraulically; the distributed
> hydrologic model I am using requires that this connectivity be unique; so a
> pixel must be uniquely connected to a single downstream pixel. Consequently,
> with the GRASS scripting I have done to produce the needed ascii output file
> I need, I think I have to use the D8 SFD algorithm.

The connectivity (drainage output of r.watershed) is always unique, no
matter if you use D8 or MFD. In case of MFD, the predominant direction
is used.

As Micha said, r.watershed does not produce breaks in flow
accumulation, it stops only at the edge of the current region and at
NULL cells.

Modifying a DEM to match a river network can be dangerous, I would
recommend to not burn the whole river network into the DEM but modify
only those parts that really need modification. Usually you will never
get a perfect match between a river network created from different
sources and a stream network derived from a DEM.

Markus M

>
> Cheers!
> Tom
>
>
> On Sat, Feb 14, 2015 at 5:02 AM, Micha Silver <micha at arava.co.il> wrote:
>>
>> Hi Thomas:
>>
>> On 02/13/2015 10:28 PM, Thomas Adams wrote:
>>
>> Micha,
>>
>> No, after looking at what's going-on in more detail, I think the DEM is
>> too coarse (even at 90m), so the flow direction and accumulation is
>> mis-directed in one critical area of the watershed. I tried using r.carve,
>> but it is taking forever — after 15 minutes, no advancement of the progress
>> bar…
>>
>>
>> I don't see why carving into a DEM should cause r.watershed to run more
>> slowly, unless you have carved out only a section of some of the streams. If
>> your carving does not continue right to the outlet of the stream (i.e. to an
>> ocean, or to the edge of the region) then r.watershed would actually have to
>> fill in that carved out stream to find a flow path.  That could cause the
>> performance hit.
>>
>> Additionally, are you using GRASS 7.0? As you probably know some
>> substantial improvements to the algorithms were introduced in 7 for several
>> modules, r.watershed among them.
>>
>> And third, why use the D8 flow direction when MFD is available (again in
>> GRASS 7.0)? That could also be causing what you refer to as breaks in the
>> channels. MFD is especailly good, I believe, in flat areas.
>>
>> In any case, Keep up posted on your progress.
>> Thanks,
>> Micha
>>
>>
>> I did not want to have to do this for my testing, but I'll probably try at
>> 3 or 10 meter — lots of pixels for my basin! The problem, in general, for me
>> is that I want to apply my techniques at international locations where I
>> probably won't have the benefit of higher resolution DEMs, so I need to
>> develop something a bit more robust…
>>
>> Cheers!
>> Tom
>>
>> On Fri, Feb 13, 2015 at 1:15 PM, Micha Silver <micha at arava.co.il> wrote:
>>>
>>>
>>> On 02/13/2015 08:48 PM, Thomas Adams wrote:
>>>
>>> Stefan,
>>>
>>> A fair question; since I know the stream topology from personal
>>> experience it is clear that there should be no break in the stream network
>>> and the flow accumulation grid should reflect that. I am seeing the flow
>>> accumulation values break at a point where they should continue to
>>> accumulate downstream.
>>>
>>>
>>> Are these breaks possibly caused by null pixels in the DEM?
>>>
>>> Tom
>>>
>>> On Fri, Feb 13, 2015 at 11:43 AM, Stefan Lüdtke <sluedtke at gfz-potsdam.de>
>>> wrote:
>>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Hi Tom,
>>>>
>>>> just out of curiosity, what do you mean by "break in the flow
>>>> accumulation"?
>>>>
>>>> Cheers,
>>>>
>>>> Stefan
>>>>
>>>> On 02/13/2015 07:12 PM, Thomas Adams wrote:
>>>> > Hello all!
>>>> >
>>>> > I'm making use of the flow accumulation grid in GRASS 6.4.5
>>>> > generated from r.watershed using the SFD (D8) flow algorithm. The
>>>> > DEM has a 250m spatial resolution. What I'm getting is a break in
>>>> > the flow accumulation in a few locations which is causing me
>>>> > serious problems with subsequent processing (with help from some
>>>> > here, I have put together some scripting to generate a pixel
>>>> > connectivity file for a distributed hydrologic model).
>>>> >
>>>> > Besides going to a higher resolution DEM, are there any thoughts as
>>>> > to how I can eliminate these flow accumulation breaks?
>>>> >
>>>> > Thank you, Tom
>>>> >
>>>> > --
>>>> >
>>>> >
>>>> >
>>>> > _______________________________________________ grass-user mailing
>>>> > list grass-user at lists.osgeo.org
>>>> > http://lists.osgeo.org/mailman/listinfo/grass-user
>>>> >
>>>>
>>>> - --
>>>> Stefan Lüdtke
>>>>
>>>> Section 5.4-  Hydrology
>>>> Tel.: +49 331 288 2821
>>>> Fax: +49 331 288 1570
>>>> Email: sluedtke at gfz-potsdam.de
>>>>
>>>> Helmholtz-Zentrum Potsdam
>>>> Deutsches GeoForschungsZentrum GFZ
>>>> (GFZ German Research Centre for Geoscience)
>>>> Stiftung des öff. Rechts Land Brandenburg
>>>> Telegrafenberg, 14473 Potsdam
>>>> - -------------------
>>>>
>>>> PGP Public Key: http://bit.ly/13d9Sca
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG v1.4.11 (GNU/Linux)
>>>>
>>>> iQEcBAEBAgAGBQJU3kXYAAoJEB5GAbKcg+D8YqMH/jgJZ70cz69IJal6ICi66wqW
>>>> lQYnnko592KAOlFDu1lReZhWWVgeA59rDsYA2Gg/rBzoL9Nst3hzIJDWqnhIWl3W
>>>> YgF/vOJgTRnrNJtOibGpOc8hxrHwElxU7afYlXU8Zk+4tXdZRK4/vrQ4tKEcbY0z
>>>> MrhAYjR66RRpoNf9/3WJ3s14CpPA+KEkOaysOOoTV6Ni7qZTK8rVxt+svQQoPtW+
>>>> 5QwRJLkLeM6bUrqfQifHis91j4k3JSoSp7ZjIInKwi1tvCSfcFQhzvANs4x8e1Lo
>>>> Q5wDbzHshhJieGKyraUZyT8cn9vszv9cm2Sf49O/0FWVz3Eyc9vsKFxVcvfEb1E=
>>>> =Sy/3
>>>> -----END PGP SIGNATURE-----
>>>
>>>
>>>
>>>
>>> --
>>>
>>>
>>>
>>> This mail was received via Mail-SeCure System.
>>>
>>>
>>> _______________________________________________
>>> grass-user mailing list
>>> grass-user at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-user
>>> This mail was received via Mail-SeCure System.
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>> This mail was received via Mail-SeCure System.
>>
>>
>
>
>
>
> _______________________________________________
> grass-user mailing list
> grass-user at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user