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 <[email protected]> wrote: > On Sat, Feb 14, 2015 at 3:45 PM, Thomas Adams <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 < > [email protected]> > >>> 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 [email protected] > >>>> > 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: [email protected] > >>>> > >>>> 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 > >>> [email protected] > >>> 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 > > [email protected] > > http://lists.osgeo.org/mailman/listinfo/grass-user >
_______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
