On Tue, Dec 2, 2008 at 8:20 PM, Helena Mitasova <[EMAIL PROTECTED]> wrote: > I very much agree with Hamish: > >>it is really nice to have two independent methods to use & race against >>each other, and compare the results of. ie apply the scientific method. >>Each will have its strength and weaknesses and now we can quantify more >>what those are.
I think so too. The flow accumulation output from flow routing modules is always tough to visualize-- and more options aid in creative display of the data. > > I am a big proponent and user of r.watershed, especially for stream > extraction and watershed delineation at lower resolutions (30-90m), mostly > due to its unique algorithm for overflowing depressions, which is among the > most robust and accurate because it is not doing the standard pit filling. > However, its D8 flow direction algorithm makes it less suitable for modeling > at higher resolutions where it creates artificial pattern of parallel lines > as seen in examples posted by Hamish (btw some of the parallel line features > may also be due to the flats created by use of integers in r.watershed). > r.watershed works well with SRTM data which are rather noisy, helping to > avoid the parallel lines to some extent. > Another example where r.watershed does not produce usable results is here: > http://www.grassbook.org/gallery/chapters/s050404f070_flow.jpg > a) is by r.watershed > > Adding one of the MFD algorithms with an optional switch to SFD for given > accumulation threshold might help to make the results of r.watershed useful > to those applications that require decent representation of flow dispersion > on convex hillslope forms and avoid some of the artifacts. YES!!! Despite the 'better' output from r.watershed, I have avoided it for the last couple of years for 2 reasons: 1. very long run times (now fixed) 2. only support for SFD I haven't really seen any landscapes at the watershed scale in low to moderate relief that can be described with the SFD algorithm. > One of the reason we have included DEMs ranging from 30m resolution to 2m > resolution in the NC data set was to provide examples of how the different > flow routing modules available in GRASS behave and how to select which one > to use based on the data and task at hand. > > Helena > > P.S. and a small addition to the color table discussion - uniform interval > indeed rarely works Indeed. That was motivation for recently suggesting an update to r.quantile for generation of recode rules-- now in 6.4. Cheers, Dylan > unless you want to have all your streams and rivers colored a single color - > the color table from Hamish is quite clever and provides a good way how to > display more info abut the size of streams. > I found that both -e and log color tables worked pretty well for the nc_spm > data, -e was good for applications where distribution on hillslopes was of > interest, log helped to highlight the streams: > see slides 18 and 19 here > http://skagit.meas.ncsu.edu/~helena/lteachtest/GIS_anal_lecture/GIS_Anal_Lvisual.ppt > > On Dec 2, 2008, at 2:23 PM, Isaac Ullah wrote: > >> Markus Metz wrote: >> In my personal opinion, flow accumulation of r.watershed is also more >> realistic than flow accumulation of r.terraflow (SFD), but I have >> admittedly not tested it in detail. >> >> I just wanted to add that I have, in fact, compared the results of the >> r.watershed with r.terraflow, as well as with r.flow. In my opinion, >> r.watershed consistently gives more accurate results than either of the >> other two. r.flow gives the worst results (for the kind of process modeling >> that I am interested in at least), while r.terraflow provides somewhat >> better results. Both modules produce results with "spikes" of high values >> that do not correspond perfectly with real topographic changes (or perhaps >> it is better to say that they overestimate changes in accumulation at >> certain places on the landscape), but r.watershed does not do that. The only >> reason I was not using the old r.watershed in my scripts was the time vs. >> map size issue. It was impossible to build it in as a dependant if it would >> make the modle hang for days if the input map was too big for it. However, I >> am please to say that initial tests running my r.landscape.evol with new >> r.watershed are VERY encouraging! Not only does the whole thing run faster, >> the results are MUCH more realistic! I may even be able to remove a time >> consuming "smoothing" routine from the module since it seems that I no >> longer am creating the anomolous "spikes" in elevation change do to problems >> in the flowacc map. This, I think, is a very good reason for focusing more >> development "sweat" to perfecting r.watershed. For future reference, I am >> more than happy to test out any changes to the module.... >> >> Cheers >> >> -- >> >> Isaac I Ullah, M.A. >> >> Archaeology PhD Student, >> ASU School of Evolution and Social Change >> >> Research Assistant, >> Mediterranean Landscape Dynamics Project >> *************************************************** >> [EMAIL PROTECTED] >> [EMAIL PROTECTED] >> >> http://www.public.asu.edu/~iullah >> *************************************************** >> _______________________________________________ >> grass-dev mailing list >> grass-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-dev > > _______________________________________________ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev > _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev