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

[Hamish]

Hi,

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
welcome)
  http://grass.gdf-hannover.de/wiki/GRASS_AddOns#Raster_add-ons


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
> EOF
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)
  http://ilab.usc.edu/wiki/index.php/HSV_And_H2SV_Color_Space

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.


enjoy,
Hamish

ps-
GRASS> r.cpt2grass --help

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

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

Flags:
  -s   Stretch color scale to match map data extent

Parameters:
   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