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

Dylan Beaudette dylan.beaudette at gmail.com
Wed Dec 3 00:05:25 EST 2008


On Tue, Dec 2, 2008 at 8:20 PM, Helena Mitasova <hmitaso at unity.ncsu.edu> 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
>> ***************************************************
>> 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
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>


More information about the grass-dev mailing list