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

[Helena Mitasova]

On Feb 3, 2013, at 11:17 PM, Hamish wrote:

> 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.

this topic should cover the programming part, not the design of symbology. We need to have
d.rast.leg and d.vect.leg - even if it is just single color for a feature like water
(like we have r.colors and v.colors - I was thrilled to discover v.colors, thanks a lot for that,
e.g. the streets map with speed limits in the nc data set looks great and I see the trick with the legend,
but that is not a solution for vector data in general)
We need better handling of scale bar and everything needs to be more robust.
I looked at the cartographic composer and recommended it to students but 
we are still behind other packages in terms of producing nice maps in a convenient way -
everything (or most of it ) is there, it just needs more work. That is the part of GRASS I get
most complaints about, although some students produce beautiful maps with GRASS.

> 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.

I totally agree with you on this but there is some research that says otherwise
and there are some situations when the discrete maps simply work better.
I can see it when we have the GRASS and ArcGIS maps side-by-side,
our continuous color ramps are certainly better than the grey ramp for continuous
data in ArcGIS, but the discrete color ramps produced by some ArcGIS modules
are often more readable although they can hide some detail - I try to deliver that 
message all the time and we use relief shading a lot to avoid hiding features. 
It very much depends on the data - it would be a  long discussion. 
The precipitation example in GRASSbook - Fig.6.17 is a good example where the continuous
color ramp did not work, even when it was in color you could not see the pattern.
> 
> [*] actually I think there's already a book on it called "How to lie with maps"

yes there is famous book about it by Monmonier (#2 on Amazon in Cartography)
> 
> 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

I use this trick too (or sometimes it is enough just create an integer copy of the map), 
but  what I had in mind was something like ryg with 6 classes,
or elevation with 12 classes. So the user selects the color table and number of intervals
and the map is created without specifying the individual colors.
> 
> screenshots here, but google's pages site seems to have gone
> a bit haywire:
>   https://sites.google.com/site/hamishbowman/grass_color_maps

that is a great document - I was just looking at it recently.

Helena
> 
> 
> regards,
> Hamish