[GRASS-dev] Re: grass-dev Digest, Vol 29, Issue 62

GRASS GRASS developer
1

On Sep 23, 2008, at 7:22 AM, <grass-dev-request@lists.osgeo.org> wrote:

Date: Tue, 23 Sep 2008 16:22:24 +0200
From: "Markus Neteler" <neteler@osgeo.org>
Subject: [GRASS-dev] r.colors confusion with "color", "rules", and
  "raster" options
To: "GRASS developers list" <grass-dev@lists.osgeo.org>
Message-ID:
  <86782b610809230722g809c191i525db72172279087@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi,

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

This shouldn't cause this error. It seems to think that the raster option has been used (when it hasn't). A new bug recently introduced?

Michael

I know, I know.. but it is far from intuitive... any ideas to improve this
behaviour/docs?

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?

thanks
Markus

2

Michael Barton 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

This shouldn't cause this error. It seems to think that the raster
option has been used (when it hasn't). A new bug recently introduced?

It certainly should cause this error. color=rules means to read rules
from stdin, while rules=<filename> means to read rules from a named
file. If you specify both, where is it supposed to read the rules
from?

Arguably, the description for color=rules should have "from stdin"
appended to it, as that's how it behaves.

Note that removing the mutual exclusivity check will simply cause the
rules= option to be ignored, as color= is checked first. The rules
option is only used if color= isn't given; specifically, the logic is:

  if <-i> read rules from stdin
  else if <color=...> handle the various color= choices
  else if <rules=...> read rules from the specified file
  else copy colours from another map (raster=)

FWIW, 7.0, doesn't accept color=rules; you need to use rules=- to read
rules from stdin (this makes it easier for the GUI, where reading from
stdin won't work.)

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

3

On Sep 23, 2008, at 12:28 PM, Glynn Clements wrote:

Michael Barton 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

This shouldn't cause this error. It seems to think that the raster
option has been used (when it hasn't). A new bug recently introduced?

It certainly should cause this error. color=rules means to read rules
from stdin, while rules=<filename> means to read rules from a named
file. If you specify both, where is it supposed to read the rules
from?

This makes sense, but is not clear in the documentation

Arguably, the description for color=rules should have "from stdin"
appended to it, as that's how it behaves.

This would clear things up a lot.

Michael

Note that removing the mutual exclusivity check will simply cause the
rules= option to be ignored, as color= is checked first. The rules
option is only used if color= isn't given; specifically, the logic is:

  if <-i> read rules from stdin
  else if <color=...> handle the various color= choices
  else if <rules=...> read rules from the specified file
  else copy colours from another map (raster=)

FWIW, 7.0, doesn't accept color=rules; you need to use rules=- to read
rules from stdin (this makes it easier for the GUI, where reading from
stdin won't work.)

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