[GRASS-dev] testing results of r.watershed2 against old r.watershed

[Helena Mitasova]

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 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.

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
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
> ***************************************************
> isaac.ullah at asu.edu
> ullah at archaeologist.com
>
> http://www.public.asu.edu/~iullah
> ***************************************************
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev