[GRASS-dev] grass wiki main page & colorbrewer tool

Hamish hamish_b at yahoo.com
Sun Feb 3 20:17:58 PST 2013


Hamish wrote:
> > ps- if anyone at the sprint is looking for a nice task, building
> > a wxPy color wizard around the ColorBrewer tables might be fun:
> >  http://colorbrewer2.org/
> > I've got their data reduced to some csv text files from a past
> > attempt, and AFAIR the licensing on those was compatible w/ GPL.

(you can also download the excel spreadsheet from their site directly)

Helena wrote:
> Hamish, if there is no time or interest to do this at the
> sprint (fixing the bugs for GRASS6.4.3 release are probably
> higher priority)

fwiw one of my strong wishes for 6.4.3 is to convert the wxPsMap
eps symbols into proper grass symbols and use the 'symbol' command
with them. I don't really want to release the current way and
have to keep support for the duplicated eps decorations forever.


> maybe you can add it into the cartography enhancements topic
> for GSoC2013
> http://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2013.

that's fine too.

a minor note about one of the suggestions already there: Google
only accepts projects which are primarily coding in nature to
SoC. So graphics design, website overhaul, and documentation
projects while very important and often badly needed for FOSS
projects are actually beyond the scope of the program.
IIUC Google's Code In for high school students allows those
sorts of things as challenges though. (at perhaps the cost
of more mentoring time needed)

> Given the max. number of classes supported - 12 and less for
> some color schemes, supposedly you cannot distinguish more,

I haven't read the academic paper behind the site (I assume
there is one based on how they got their funding), so I'm not
sure if the colors were selected algorithmically, by educated
eye, or a mix of both. If there's a formula we could tap into
(like r.watershed has), then all the better for it.

> it would be nice to add a button for generating discrete
> colors for continuous data, such as elevation,
> for a given number of classes - it can be done now, but as
> far as I know you would have to reclass your raster first.

Even though it is very popular in other widely used software,
I've always tried to steer away from applying discrete classes
to continuous raster data. IMO it deserves it's own chapter
in "How to lie with statistics"*, as it is very easy to fool
both yourself and others about what the data says based on the
ultimately arbitrary choice (as far as nature is concerned)
of intervals. I realize that it is also difficult for the human
eye to follow a constant hue and isolines can be useful, so
typically what I try to do for those as a compromise is have the
continuous gradient colors in the back ground with contour lines
of the same data over the top.

[*] actually I think there's already a book on it called "How to lie with maps"

If you really want to do it though there's no reason to reclass,
see the r.colors.stddev script for an example. Just make two
rules at the same value right next to each other. e.g., from
r.colors.stddev:

r.colors "$GIS_OPT_INPUT" color=rules << EOF
       0% black
       $MEAN_MINUS_3STDEV black
       $MEAN_MINUS_3STDEV red
       $MEAN_MINUS_2STDEV red
       $MEAN_MINUS_2STDEV yellow
       $MEAN_MINUS_1STDEV yellow
       $MEAN_MINUS_1STDEV green
       $MEAN_PLUS_1STDEV green
       $MEAN_PLUS_1STDEV yellow
       $MEAN_PLUS_2STDEV yellow
       $MEAN_PLUS_2STDEV red
       $MEAN_PLUS_3STDEV red
       $MEAN_PLUS_3STDEV black
       100% black
EOF

screenshots here, but google's pages site seems to have gone
a bit haywire:
   https://sites.google.com/site/hamishbowman/grass_color_maps


regards,
Hamish


More information about the grass-dev mailing list