[GRASS-dev] color tables

[Hamish]

Helena wrote:
> I am just going through some old emails and I am wondering whether there 
> was a reason why the images illustrating the pre-defined color tables 
> generated by Hamish and available on wiki 
> 
> http://grass.osgeo.org/wiki/Raster_color_tables
> 
> could not be included directly into the man page
> http://skagit.meas.ncsu.edu/~helena/grasswork/grasscontrib/r.colors.html
> or is this just an unfinished thread.

done by Glynn for GRASS 7:
  http://grass.osgeo.org/grass70/manuals/html70_user/r.colors.html

(I notice dynamic ones are broken [random, grey.log, grey.eq])


> Also, when using histogram equalized color table the legend is 
> generated with equal intervals which often ends up being just
> one color  for most of the legend - would it be difficult to generate
> the legend with histogram equalized values? 

Yes and no. Suggested method using current tools is to figure
out the breaks with r.quantile/r.univar and then run d.legend
with the use= option. e.g.:


g.region rast=slope
r.colors -e slope col=bcyr

TICKS=`r.quantile slope perc=$(seq -s, 0 10 100) --quiet | \
   cut -f3 -d: | tr '\n' ',' | sed -e 's/,$//'`

d.legend slope -f use=$TICKS


which works quite nicely.
(beware if working with 0.0<1.0 values that use= might cast to int(??))


Probably we could add that to d.rast.leg as a new -e flag without much
trouble; a new flag to G_spawn(r.quantile) from within d.legend is
possible, but more work. (I've been putting off un-monolithing d.legend
as it is working well, but I'll have to sit down and do that at some
point as I've been meaning to for years)


for ps.map output use the colortable's "discrete Yes" option
to force a categorical legend, after using r.category to assign
labels to FP tick values you want displayed. (just guessing; untested)


> Maybe a task to add to GSoC GRASS cartographic output project?

My plan for a possible SoC GRASS cartographic output project is simply
a wxGUI frontend for ps.map which creates ps.map instruction files and
runs ps.map at ~10 dpi for previews. IMO ps.map and d.legend are near-
feature complete mature code and I don't really want to throw students
into them. I do plan however to work with Jorge to merge some of the
nice stuff from ps.output back into ps.map. (starting with fancy borders)

I'm not sure what future work needs to be done for the PS display driver
beyond lots of testing, otherwise it is mostly general improvements to
the main wxGUI display window (which also benefits the day-to-day GUI).


The OSGeo cartographic library is something else entirely, from my POV
probably svg + gdal/ogr centered & I'd lobby strongly to try and get
the GMT people involved as early as possible. (our [ie grass] code bases
are already quite compatible already actually, some long ago common
history I guess.)


finally, I'll mention that in the last 6 months I've been using GMT a bit
more and now that I am more familiar with it the gulf between it and
ps.map seems a lot smaller than I once thought it was.
(depends on your usage of course- GMT can do a lot of things!)


Hamish