[GRASS-user] error message coming with r.colors

[Glynn Clements]

Martin Landa wrote:

> > I try to adapt the color table of a raster file using an ascii file (> rules option) with the following statement:
> >
> > r.colors map=b25_daymax0.l1_neu at PERMANENT color=rules 'rules=/sonne3/.../GIS/colorscript_farben_temp'
> >
> > Hence the following message comes up:
> >
> > "color", "rules", and "raster" options are mutually exclusive
> >
> > Any ideas what this means? Please see also the attached colorscript.
> 
> it seems to be a bug in r.colors, the attached patch quickly fix it.

It isn't a bug. color=rules was left as an "alias" for -i solely for
backwards compatibility.

> Anyway r.colors needs some more cleaning. In GRASS7 I would suggest to
> remove
> 
> -i   Enter rules interactively
> 
> 1) then if rules file is given read from the file
> 2) if not given (and color=rules) switch to the interactive mode
> 3) or completely remove interactive mode, print error about missing
> rules file <- seems to be a better solution, to avoid any interactive
> mode in GRASS7
> 
> ?

If reading from stdin remains, it will be via -i, although I'm
inclined to simply remove the feature altogether (it doesn't work well
the GUI).

> > What it says; you can't use both "color" and "rules". If you use
> > "color=rules", the rules are read from stdin (equivalent to -i). If
> > you use "rules=...", the rules are read from the specified file.
> >
> > So, just omit the color=rules option, i.e.:
> >
> > r.colors map=b25_daymax0.l1_neu at PERMANENT 'rules=/sonne3/.../GIS/colorscript_farben_temp'
> 
> hm, maybe quite confusing (at least for me). Can we change it in GRASS 7
> 
> color=rules
> 
> * rules not given or rules=-, read from stdin
> * otherwise read from the file
> 
> and eliminate interactive mode

The color=rules option will go. Note that the description of -i is
misleading; it reads rules from stdin, which can be redirected from a
file (you only get "interactive" behaviour if stdin is a tty).

Reading rules from stdin is a substantial deviation from normal
behaviour. If this feature remains (and I'm not sure that it should),
it should be a completely separate flag (i.e. -i), not just a
particular choice for the color= option.

Currently, there are four special cases for the color= option: random,
grey.eq, grey.log and rules. All other options just use the
corresponding rules file from $GISBASE/etc/colors.

The -g and -e switches make grey.log and grey.eq redundant, and -i
makes color=rules redundant, which leaves color=random as the only
special case (it cannot be implemented via a rules file, and only
works for integer maps). I'm considering making color=random a
separate flag.

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