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

[Hamish]

Helena wrote:
> this topic should cover the programming part, not the design
> of symbology.

ok,

> We need to have d.rast.leg and d.vect.leg - even if it is
> just single color for a feature like water

So like the ps.map vector legend, but as a d.* module, right?
Glynn already converted d.rast.leg to python, how would you
like to see that be improved? (besides renaming it d.rast.legend)

re. improvements for d.rast.leg, here is a mock up I just made
of some MODIS SST data with some ideas in it:

http://bambi.otago.ac.nz/hamish/grass/screenshots/sst_4uNight_A2012047.png

Only part which isn't real is I squashed the LL Plate Carree's
width by percentage (approx cos(lat) * 100) in GIMP, instead of
doing a real reprojection. The rest is scriptable:

* decorations are on the left (flag to move it to the right)
* uses d.font for a TrueType font^ (I set it to Vera)
* units are taken from 'r.info -u' if they are set
* d.legend's range= is take from r.univar -e perc=2,98
* d.text with the map name is rotated 90 deg to up the map space
* a calculation is made to automatically pick a nice d.grid interval
* I still like the black backgrounds from old versions of GRASS
for satellite imagery :)

^note we can make good use of the GRASS_FONT and GRASS_FONTSIZE
enviro variables for all d.* modules, avoiding extra options
thus simplifying the code. Of course the GUI versions would need
friendly wrappers with buttons and drop down lists, but that's
relatively easy.


> (like we have r.colors and v.colors - I was thrilled to
> discover v.colors, thanks a lot for that,

you are welcome, although as you noticed it's a complete hack
taking advantage of r.colors as it does. Better to would be
to add colr files to the vector/ format for GRASS 7. I think
that using GRASSRGB column should remain as an option, but the
'd.vect zcolor=' style could use an optional colr file, so you
had more options for coloring e.g. LiDAR w/ no DB table than just
the presets. Perhaps similar to the user-file symbol support
in the user's mapset (yes, it's possible) you could have a
mapset or location based directory with personal color maps
it could check to use? (&/or a colors/ dir within the grass
addons dir(s) too?)

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

screenshot? (perhaps for the website; we need more good vector
ones there)

> We need better handling of scale bar and everything needs to
> be more robust.

You mean in the wxGUI map display window, not the d.* C modules,
right? Or that those things should be drawn as vector not with
1 pixel wide lines which do not work well with a large display
size as may be used in a poster?

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

fwiw, knowing ps.map well, I think it is absolutely marvelous.
There is still some work to do merging some nice features from
ps.output, like the better borders.

> That is the part of GRASS I get most complaints about,
> although some students produce beautiful maps with GRASS.

I'd be delighted to see them file wishes in the trac'er.
I hope the composer takes care of a lot of the "eeek it's
controlled by text" issues, and once they have their text
control file they feel comfortable changing e.g. the caption
spelling in it, or map name if they need to produce a series,
in a text editor and see the joy of consistent templates.


Hamish: 
> > 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"*,
...
> I totally agree with you on this but there is some research
> that says otherwise

If it's the journal article I'm thinking of, I know about it,
I've read it, and I don't agree with its conclusions.

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

It could be, but I'd probably need to study up on my ER Tufte
a bit more to be able to do it well. :)

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

(I only had Vol 1, but luckily our library has access to the
eBook :)


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

my heart's really not in pursuing that myself, and I discourage
it, but it would seem like a simple front end to a future
colorbrewer module to make the reclass map for that if someone
wanted to do it.


regards,
Hamish