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 <mi...@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 <mi...@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 <slued...@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@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: slued...@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@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. > > >
_______________________________________________ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user