[GRASS-dev] future thematic cartography in GRASS [was: Re: [GRASS GIS] #974: [Patch] add option to d.vect to make symbol size proportionate to square root of size_column]

[Moritz Lennert]

On 02/03/10 10:21, GRASS GIS wrote:
-------------------------------------------------
> Comment (by hamish):
>   non-specific comments-
>    - I worry that the d.vect interface is becoming like a 747 cockpit for
>   new users. So many controls it becomes overwhelming. the solution I guess
>   is good use of tabs and specific task wrapper scripts (eg addons
>   d.stations and d.varea).

I agree, but see below.

>    - now that d.vect has support for sizecol, rgbcol, widthcol, zcolor, etc,
>   what is left for d.thematic.linepoint to do?
>

I've been thinking about this as well these days. What is still missing 
right now is an easy way to display a combination of color-classified 
and proportionately sized symbols. It is possible to declare an 
arbitrary numeric column as z-height and use that with zcolor, but I 
don't think this is very straightforward and even though ISTR you don't 
see the need for that, cartographic theory (at least for thematic maps) 
still calls for reduced numbers of classes.

However, I think that we now have the tools to actually script this 
combining v.class and d.vect, using the first to define the classes 
which we then use to fill the rgbcol or possibly size_column for those 
who want. Two necessary/useful additions would probably be:

- g.colorclasses providing color schemes (possibly integrating color 
combinations from [1]. I'll have to check licensing issues, but think 
uDig has integrated it already, so it should be possible.)

- d.thematic.legend to display legend info (both color classes and sizes)

However, if we go this way, I would need to add a flag to d.vect which 
allows sorting symbols with the largest in the back. This is absolutely 
necessary for readability. However, this implies a fundamental change in 
the d.vect code, as currently d.vect gets each feature from a map one at 
a time and then paints it. In order to allow sorting the symbols, we 
would have to sort the data first, loop through the cats in the defined 
order, find each feature according to its cat and then paint it. I've 
implemented this a long time ago in an alternative d.vect.chart [2]. An 
added advantage of this approach would be that it would open the door to 
a more database-oriented approach to displaying vectors in that it makes 
it possible to use an arbitrary SQL-query (including combination of 
several tables, etc) in d.vect to select those features you want to 
display. See [3] for an example.

So, either I go for a more complete revision of d.vect, or I use d.vect 
as a basis to create d.thematic.symbol (I like this name more than 
d.thematic.linepoint).

In any case, a gui script to integrate these different elements and 
provide things like a color choser for classes would be nice.

What do y'all think ?

Moritz

[1] http://www.personal.psu.edu/cab38/ColorBrewer/ColorBrewer_intro.html
[2] http://grass.itc.it/pipermail/grass5/2006-October/026503.html
[3] http://grass.itc.it/pipermail/grass5/2006-October/026504.html