On Mar 4, 2010, at 10:00 AM, grass-dev-request@lists.osgeo.org wrote:
Date: Thu, 04 Mar 2010 11:26:48 +0100
From: Moritz Lennert <mlennert@club.worldonline.be>
Subject: Re: [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]
To: Hamish <hamish_b@yahoo.com>
Cc: grass-dev@lists.osgeo.org
Message-ID: <4B8F8AE8.3050803@club.worldonline.be>
Content-Type: text/plain; charset=ISO-8859-1; format=flowedOn 03/03/10 11:44, Hamish wrote:
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 this is just the beginning, I would prefer a new module for that
along the lines of d.vect.chart.Ok, I'll go in this direction then.
why not simplify the name to just "d.thematic"?
The idea was to simplify modules and so to separate areas from symbols
(incl. lines), but it is obviously possible to put everything together
into one module.ps- see also v.colors and the new extra/ring symbol
Yeah, we could include discrete color schemes in v.colors by feeding it
class breaks.So in summary this means as tasks at hand:
- write an alternative d.vect with attribute-based selection, allowing
sorting of symbols largest in the back- enhance v.colors to provide discrete color schemes (possibly including
the color brewer schemes which are licensed under the Apache license)- write a script which combines the existing tools (v.class, v.colors,
d.vect / d.vect2) to allow for thematic cartography- write a module/script which displays thematic legends (color classes
and sizes)This would make d.thematic.area obsolete.
As mentioned, my time is limited and I don't know how quickly I could do
all this. If anyone's interested in helping, this would be great.Moritz
This sounds very good. FWIW, my vote is to NOT patch this together with scripts but create a comprehensive d.thematic module with these capabilities--except legend. A single module would work much better across multiple platforms and be a snap to implement in the GUI or on the command line (wximgview). If a d.thematic gets created, we should take out the thematic mapping components of d.vect to simplify this very complex module. Finally, if there is some way to enhance d.legend to work with thematic vector maps as well as raster maps, it would be desirable.
Michael