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

Sat Feb 14 06:45:22 PST 2015

Micha,

You raise very good questions. I think you may have misunderstood; perhaps
I explained poorly. r.watershed is NOT running slowly; I have had no
problems with r.watershed performance. The performance slowness I have had
is with r.carve -- it is running very slowly.

I am also using GRASS 7.0RC1; but for the final step in one of my analysis
(not what I have described here), I need to use r.arc.out, which is now
handled by r.out.gdal; I have not had the chance to explore this, but the
ascii output files generated by the two are different. I use a subsequent
binary application (written by someone else) that reformats the GRASS
r.out.arc output to a new binary grid file that is only used within the
U.S. National Weather Service. So, wanting a more simplified workflow, I'm
stuck with using GRASS 6.4.5 for some of this.

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.

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 <%2B49%20331%20288%202821>
>>> Fax: +49 331 288 1570 <%2B49%20331%20288%201570>
>>> 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 listgrass-user at lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/grass-user
>> This mail was received via Mail-SeCure System.
>>
>>
>>
>>
>>
>
>
>
>
>
> This mail was received via Mail-SeCure System.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20150214/c06a48da/attachment.html>