[GRASS-dev] Re: [GRASS GIS] #172: r.recode truncates last character in rules file.

[GRASS GIS]

#172: r.recode truncates last character in rules file.
--+-
  Reporter:  bgullatt |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  major|   Milestone:  6.4.0
 Component:  default  | Version:  6.3.0
Resolution:   |Keywords:  r.recode rules   
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-
Changes (by neteler):

  * platform:  => Unspecified
  * cpu:  => Unspecified
  * milestone:  6.3.1 => 6.4.0

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Markus Metz]

Hamish wrote:
> Hamish:
>   
>>> see the man page for an example of making a nicely colored accum map
>>> based on standard deviations.
>>>   
> MMetz:
>   
>> Why not setting colors for accum in the module?
>> 
>
> If you like, but a simple linear color model will not work well:
>   
Hmm, it does work with the existing visual output:
1. all negative values are set to 0
2. standard rainbow color rules are applied to the range 1 to 120,
leaving out anything beyond.

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

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

The attached diffs for ram and seg mode apply these color rules.

Both visual output and these color rules may not look nice for DEMs with
very high resolution, e.g. LIDAR (just a guess that there will be more
cells with high accum values), then custom color rules can be set. A
fancier color model could use quartiles or quantiles, e.g. 20% steps.

>> 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...]
> t>1000 may as well be infinite, as before the user hit ^C after 2-3 days
> and so it never finished. So this opens the door to analyzing much bigger
> (ie modern) datasets; r.terraflow is nice for those, but doesn't provide
> the catchment basin output maps.
>   
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.

Regards,
Markus

--- r.watershed2.orig/seg/close_maps.c  2008-11-29 11:45:15.0 +0100
+++ r.watershed2/seg/close_maps.c   2008-12-02 11:11:56.0 +0100
@@ -7,11 +7,51 @@
 int r, c;
 CELL is_swale, value;
 double dvalue;
+struct Range accRange;
+CELL min, max;
 
 dseg_close(&slp);
 cseg_close(&alt);
-if (wat_flag)
+if (wat_flag) {
cseg_write_cellfile(&wat, wat_name);
+
+   /*
+  color rules for flow accumulation
+0% black
+  -200 black
+  -150 blue
+   -40 cyan
+   -20 green
+ 0 yellow
+20 green
+40 cyan
+   150 blue
+   200 black
+  100% black
+   */
+
+   G_read_range(wat_name, this_mapset, &accRange);
+   min = max = 0;
+   G_get_range_min_max(&accRange, &min, &max);
+
+   G_init_colors(&colors);
+   if (min < -200)
+   G_add_color_rule(min, 0, 0, 0, -200, 0, 0, 0, &colors);
+
+   G_add_color_rule(-200, 0, 0, 0, -150, 0, 0, 255, &colors);
+   G_add_color_rule(-150, 0, 0, 255, -40, 0, 255, 255, &colors);
+   G_add_color_rule(-40, 0, 255, 255, -20, 0, 255, 0, &colors);
+   G_add_color_rule(-20, 0, 255, 0, 0, 255, 255, 0, &colors);
+   G_add_color_rule(0, 255, 255, 0, 20, 0, 255, 0, &colors);
+   G_add_color_rule(20, 0, 255, 0, 40, 0, 255, 255, &colors);
+   G_add_color_rule(40, 0, 255, 255, 150, 0, 0, 255, &colors);
+   G_add_color_rule(150, 0, 0, 255, 200, 0, 0, 0, &colors);
+
+   if (max > 200)
+   G_add_color_rule(200, 0, 0, 0, max, 0, 0, 0, &colors);
+
+   G_write_colors(wat_name, this_mapset, &colors);
+}
 if (asp_flag) {
cseg_write_cellfile(&asp, asp_name);
G_init_colors(&colors);
--- r.watershed2.orig/ram/close_maps.c  2008-11-29 11:45:15.0 +0100
+++ r.watershed2/ram/close_maps.c   2008-12-02 11:11:59.0 +0100
@@ -9,6 +9,8 @@
 struct Colors colors;
 int value, r, c, fd;
 CELL *buf = NULL;
+struct Range accRange;
+CELL min, max;
 
 if (wat_flag || asp_flag || dis_flag || ls_flag || sl_flag || sg_flag)
buf = G_allocate_cell_buf();
@@ -30,6 +32,43 

[GRASS-dev] Re: [GRASS GIS] #72: PNG driver: boundary rendering is off by one pixel

[GRASS GIS]

#72: PNG driver: boundary rendering is off by one pixel
--+-
  Reporter:  hamish   |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  blocker  |   Milestone:  6.4.0
 Component:  default  | Version:  svn-develbranch6 
Resolution:   |Keywords:  d.vect, rendering, PNG_DRIVER
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-
Changes (by hamish):

  * platform:  => Unspecified
  * cpu:  => Unspecified

Comment:

 new screenshot added showing 6.4svn PNG driver output (d.out.file) of new
 strike_triangle symbol with bad fill/outline alignment.


 Hamish

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] 6.4rc1

[Glynn Clements]

Glynn Clements wrote:

> > > so what remains todo befor 6.4rc1? IMO lib API and module list should be
> > > frozen at that point, which means creating releasebranch_6_4. No need to
> > > wait on that anymore IMO. bugfixes can continue on until the end.
> > > if 6.4 is the last, that means for all of GRASS 6.x so last chances...
> > 
> > I also vote for creating releasebranch_6_4 within the next days...
> > 
> > what about
> > 
> > http://trac.osgeo.org/grass/ticket/72
> > 
> > and
> > 
> > http://trac.osgeo.org/grass/ticket/58
> > 
> > temporal solution would to include pseudodc.cpp and pseudodc.h to
> > gui/wxpython/vdigit and relay on the given version of wxWidgets.

If you want to use a local copy, you will probably have to rename the
classes to prevent conflicts.

> The ideal solution is to figure out how to call the wxPseudoDC
> method(s) via PyEval_CallObject(). I can't see that it could be so
> complex as to either hold up the release or to require a hackaround.

Scratch that. I had assumed that wxPseudoDC was a subclass of wxDC;
unfortunately it isn't. It's a distinct class which just happens to
provide the same methods as wxDC.

That's good enough for Python, but for C++ you can't just treat it as
a wxDC for most operations and call out to Python for the
wxPseudoDC-specific methods (SetId and SetIdBounds). You would have to
invoke *all* methods via Python to eliminate the direct _gdi_.so
dependency.

This probably explains why it isn't part of wxWidgets proper.

-- 
Glynn Clements <[EMAIL PROTECTED]>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] build without NLS broken

[Glynn Clements]

Markus Neteler wrote:

> >> In r34485 there were a bunch of changes to lib/gis/gisinit.c, one of
> >> which calls G_init_locale(). However, this is not necessarily defined
> >> in locale.c. I'm not really a C guy, but this seemed to fix it for
> >> me. For reference, the build fails on an undefined reference to
> >> G_init_locale. I tried it on an Ubuntu machine and on OS X.
> >
> > Oops.
> >
> > I have changed lib/gis/locale.c (r34662) so that only the code which
> > depends upon libintl.h is conditionalised, but G_init_locale() is
> > defined unconditionally. This ensures that the setlocale() calls still
> > occur, which is necessary to ensure that e.g. printf("%f") isn't
> > localised.
> 
> Does this affect 6?

r34662 fixes a bug in r34485, so r34662 should only be back-ported if
r34485 was back-ported (I presume it wasn't).

-- 
Glynn Clements <[EMAIL PROTECTED]>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.colors -a rule sorting

[Glynn Clements]

Hamish wrote:

> I am just trying out the new 'r.colors -a'. Results look good, visually
> matches 'r.mapcalc abs($MAP)' + 'r.colors -g' exactly.

In general, it won't be an exact match, as -a uses "log(abs(x)+1)" so
that values close to zero don't "hog" the colour table. If your range
is small, you will probably notice the difference (if your range
includes values very close to zero, you would definitely notice).

> One thing I notice in the colr/ file, the positive/negative rules are 
> interleaved: 
> 
> 
> nv:255
> *:255
> 1:0:0:255 1.1457610996:0:7:255
> -1.1457610996:0:7:255 -1:0:0:255
> 1.1457610996:0:7:255 1.3127684973:0:15:255
> -1.3127684973:0:15:255 -1.1457610996:0:7:255
> 1.3127684973:0:15:255 1.5041190769:0:22:255
> ...
> -618328.3661061861:255:16:0 -539666.049353256:255:23:0
> 618328.3661061861:255:16:0 708456.5886435417:255:8:0
> -708456.5886435417:255:8:0 -618328.3661061861:255:16:0
> 708456.5886435417:255:8:0 811721:255:0:0
> -811721:255:0:0 -708456.5886435417:255:8:0
> 
> 
> (this is r.watershed accumulation map for spearfish's elevation.10m)
> 
> 
> is it any problem that they are not sorted min to max, or is it just
> cosmetic?

Just cosmetic.

-- 
Glynn Clements <[EMAIL PROTECTED]>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #72: PNG driver: boundary rendering is off by one pixel

[GRASS GIS]

#72: PNG driver: boundary rendering is off by one pixel
--+-
  Reporter:  hamish   |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  blocker  |   Milestone:  6.4.0
 Component:  default  | Version:  svn-develbranch6 
Resolution:   |Keywords:  d.vect, rendering, PNG_DRIVER
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-
Comment (by glynn):

 Replying to [comment:8 hamish]:
 > new screenshot added showing 6.4svn PNG driver output (d.out.file) of
 new strike_triangle symbol with bad fill/outline alignment.

 Please provide the exact sequence of commands used to create the image.

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Isaac Ullah]

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] Re: [GRASS GIS] #72: PNG driver: boundary rendering is off by one pixel

[GRASS GIS]

#72: PNG driver: boundary rendering is off by one pixel
--+-
  Reporter:  hamish   |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  blocker  |   Milestone:  6.4.0
 Component:  default  | Version:  svn-develbranch6 
Resolution:   |Keywords:  d.vect, rendering, PNG_DRIVER
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-
Comment (by hamish):

 > Replying to [comment:8 hamish]:
 > > new screenshot added showing 6.4svn PNG driver output
 > > (d.out.file) of new strike_triangle symbol with bad fill/outline
 > > alignment.

 Replying to [comment:9 glynn]:
 > Please provide the exact sequence of commands used to create
 > the image.

 {{{
 # grass 6.4svn from yesterday
 echo "symbol geology/strike_triangle 22 50 50 black black" >
 draw_triangle.dgr
 d.graph draw_triangle.dgr
 d.out.file strike_triangle_PNG_driver
 }}}

 seems dependent on the symbol size, I tried 125 but it looked ok, so went
 back to 22 as per the screenshot and it misaligns.


 Hamish

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Hamish]

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
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [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
***
[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

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

[Dylan Beaudette]

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,
>> Medit

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

[Hamish]

Markus Metz:
> > The new version of r.watershed produces results identical to the
> > original version at a substantial speed increase by optimizing the A *
> > search method.

that reminds me, the man page needs updating too,

"Both  versions  use  the AT least-cost search algorithm to determine the flow 
of water over the landscape (see SEE ALSO section).  The algorithm produces 
results similar  to  those obtained when running r.cost and r.drain on every 
cell on the map." [...]


thanks,
Hamish



  

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev