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. _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
