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
