[GRASS-dev] r.colors confusion with "color", "rules", and "raster" options

Glynn Clements glynn at gclements.plus.com
Tue Sep 23 15:54:20 EDT 2008


Markus Neteler wrote:

> the manual of 6.4 r.colors says:
> "The rules color table type will cause r.colors to read color table
> specifications from standard
>  input (stdin) and will build the color table accordingly.
> "
> 
> r.colors help | grep rules
> ...
>    color   Type of color table
>            options: aspect,aspectcolr,bcyr,bgyr,byg,byr,curvature,
>                     differences,elevation,etopo2,evi,grey,grey1.0,grey255,
>                     gyr,ndvi,population,rainbow,ramp,ryb,ryg,sepia,slope,
>                     srtm,terrain,wave,random,grey.eq,grey.log,rules
> ...
>             rules: create new color table based on user-specified rules
> ...
>    rules   Path to rules file
> 
> but:
> 
> r.colors map=gpcp_1dd_p1d.2002_sum color=rules rules=color_tab.col
> ERROR: "color", "rules", and "raster" options are mutually exclusive
> 
> I know, I know.. but it is far from intuitive... any ideas to improve this
> behaviour/docs?

-rules: create new color table based on user-specified rules
+rules: create new color table based on user-specified rules read from stdin

> This works of course...:
> r.colors map=gpcp_1dd_p1d.2002_sum rules=color_tab.col
> Color table for <gpcp_1dd_p1d.2001_sum> set to color_tab.col
> 
> The first command version above doesn't look harmful to me, could we
> (re)enable it?

Why? If you don't want to read rules from stdin, don't use
color=rules.

If you don't want error messages, don't provide erroneous input.

What's so special about this particular error that it should be
silently ignored?

-- 
Glynn Clements <glynn at gclements.plus.com>


More information about the grass-dev mailing list