[GRASS-dev] GMT color tables & r.colors bug

Hamish hamish_nospam at yahoo.com
Thu Oct 4 05:20:44 EDT 2007


I have now put my GMT color table importing shell script up on the wiki
addons site. I called it r.cpt2grass (suggestions for a better name are

There seems to be a bug in r.colors in 6.2 and 6.3.

e.g. for a CELL map containing values of [0-255], if the rules file looks
like this:

0% 0:0:0  37.5% 255:0:0
37.5% 255:0:0  75% 255:255:0
75% 255:255:0  100% 255:255:255

the colr/ file looks like this:

% 0 191.25
0:0 95.625:255:0:0
95.625:255:0:0 191.25:255:255:0

ie the last 100% rule is forgotten.

Same if I give it real values:
G63> r.colors gebco_bathy col=rules << EOF
> 0 0:0:0 95.625 255:0:0
> 95.625 255:0:0 191.25 255:255:0
> 191.25 255:255:0 255 255:255:255
WARNING: Your color rules do not cover the whole range of data!
         (rules 0.000000 to 191.250000 but data 0.000000 to 255.000000)


the usual way to give percentage is typically 1 rule per line, which
is why we haven't noticed this before:
0% 0:0:0
37.5% 255:0:0
75% 255:255:0
100% 255:255:255

GEBCO data + GMT_haxby.cpt looks pretty cool.

HSV is not supported, for that we'd need some small m.hsv2rgb module or
utility in $GISBASE/etc/.  (with a reverse transform flag)
example C++ code: (unknown license)

There are a couple of nice GMT color tables that use HSV. CMYK is
defined in the spec, but I haven't come across anything that uses it
yet. And I have not seen any that use labels either, so won't worry
about that for now.


GRASS> r.cpt2grass --help

 Convert or apply a GMT color table to a GRASS raster map

 r.cpt2grass [-s] input=string [map=string] [output=string]
   [--verbose] [--quiet]

  -s   Stretch color scale to match map data extent

   input   Name of input GMT color table (.cpt file)
     map   Raster map to apply it to
  output   Name for new rules file, or "-" for stdout

More information about the grass-dev mailing list