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

Hamish hamish_b at yahoo.com
Tue Dec 2 21:40:34 EST 2008


Markus Metz wrote:
> >> Why not setting colors for accum in the module?

Hamish:
> > If you like, but a simple linear color model will not work well:

MMz:
> Since the bulk of the flow accumulation output has little flow, a simple
> fixed linear model would work in most cases as it does for the visual
> output 

focuses on the wrong thing? The interesting part of the map to me is the
high accumulation cells, not the many low acc cells. The suggested
rules show information about the flatland noise and relegate the entire
stream network to black. (which means you can see it reasonably well)
it's a matter of what you want to spend your effort looking at I guess.

from 'r.univar -e' output given here:
  http://article.gmane.org/gmane.comp.gis.grass.devel/30432/

the 90th percentile has only 32 cells flowing into it. (to me*) all the
interesting stuff is happening at >200 inflow cells.

[*] this isn't my field of study, so humble opinion from a layman's
perspective


this is what the example stddev rules in the map page creates:
  http://bambi.otago.ac.nz/hamish/grass/rwat_acc_colr.png
(and new r.colors -a)


> Suggested color rules for flow accumulation including negative values
> (offmap inflow), inspired from the color model of the visual output
> covering the full range of flow accumulation values:
> 0% black
> -200 black
> -150 blue
> -40 cyan
> -20 green
> 0 yellow
> 20 green
> 40 cyan
> 150 blue
> 200 black
> 100% black
> 
> first making sure that 0% is smaller than -200 and 100% is
> larger than 200

screenshot:
  http://bambi.otago.ac.nz/hamish/grass/rwat_acc_colr_mm.png


> >> The speed increase is not static, the new version will be
> >> faster the larger the region (more cells). For somewhat
> >> larger regions, the new module is >1000 times faster.
> >
> > ok, can you suggest better wording for the release announcement?
> >   
> Something like:
> The new version of r.watershed produces results identical to the
> original version at a substantial speed increase by optimizing the A *
> search method. The speed increase with the new version is relative to
> the size of the region, i.e. the more cells have to be processed the
> higher is the speed gain. E.g a region with 2,000,000 cells is processed
> about 100 times faster and a region with 20,000,000 cells is processed
> about 5000 times faster (exact differences are system-dependent). More
> technically, the time needed with the new version for a given region is
> (in theory) proportional to the logarithm of the time needed with the
> original version. [Now that is terrible wording...]

I was hoping for 5 words or less "orders of magnitude faster" or so,
for  http://trac.osgeo.org/grass/wiki/Release/6.4.0RC1-News
.... was O(2^N) now O(N) ?


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

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.


Hamish

ps- step 4 in seg/sg_factor.c isn't working as it tries to do G_percent()
backwards.



      



More information about the grass-dev mailing list