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

Mon Feb 16 15:12:44 PST 2015

Markus,

Thank you very much for you insights; Yes, I have seen significant
differences between DEM derived streams and those from other sources. I
have not attempted burning the streams into the DEM as Micha suggested.
FORTUNATELY, I had a 100m DEM from the USGS that was fine for my uses; so,
the problem area that I had was resolved and I did not have to resort to
such drastic measures -- it was disheartening to think I might have to
resort to that.

So, what's really cool is that I have hydrologically modeled a good size
basin (8332 sq km) at a 250 meter grid spacing; all the model parameter
estimation was done using GRASS 70, as is the animation of the simulation.
I'll be posting it to Vimeo later today. It's the same basin area I did
previously that you saw, only the previous one had a much coarser (4km)
spatial resolution.

Thanks all!

Tom

On Mon, Feb 16, 2015 at 2:42 PM, Markus Metz <markus.metz.giswork at gmail.com>
wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20150216/47834982/attachment-0001.html>