[GRASS-dev] C replacement for d.vect.thematic

Hamish hamish_b at yahoo.com
Sat Dec 29 20:32:10 EST 2007

> I have finally started living up to my many promises over the last
> year about trying to write a C replacement for the d.vect.thematic
> script.

This is good. thanks!

> - d.symbol.thematic: a module for line and point symbol thematic 
> mapping, including symbol size variation

It would be easy to make up a prototype script using d.graph, also very
easy to use the d.graph C source to quickly make something like this.

It will be nice to be able to make things like bubble graphs in one
place. Right now you can use d.vect.chart (pie, 1 column), v.buffer
(sizecol=), d.vect (in a loop with SQL), d.graph, ps.map, ... to do
that, but it is not very clean/clear.

Variables to consider are size, color(s), rotation. Colors can be
specified as primary/secondary which is more flexible than line/fill.
See d.graph, d.vect source. ps.map even allows symbol by cat number
(via dynamic .eps filename).

> I'd rename the thematic modules to d.thematic.area, d.thematic.point,
> d.thematic.legend. This lets them easily group in any alphabetical
> listing and clearly associates them. It also uses consistent GIS
> objects for the subname of each (i.e., point instead of symbol,
> because points and areas are the objects being displayed). 

I agree. Consistency and intuitiveness are so very important. They
short circuit the nasty learning curve.

> Can we make use of the kind of color tables used by r.colors to get
> color ramps in d.area.thematic?
> that would be cool, see
> "v.colors -> add raw colr rules file parsing to r.what.color"
> for related ideas.

Support for parsing the r.color table format would be great. I think it
is very resource wasteful to store a full GRASSRGB varchar(11) column
for every category if you don't need to. e.g. displaying vector LIDAR
data which has no DB table where you want the size=0 "x" symbol's color
to change with elevation. Please reuse the same colr/ table format!

Personally I prefer a constant color gradient, not stepped/binned
legend like Arc produces. I consider that to be a relic from the days
of 16 or 256 max color pallets. Of course I work with mostly FP data
and not categorical, so I'm biased. I guess the legend should follow
the nature of the data, be it categorical, a continuous linear range, a
continuous logarithmic range, a +/- differences map centered on 0, etc.
Anytime you introduce an unneeded histogramming step you are getting
dangerously near to writing a new chapter for "How to lie with
statistics" (great book).


Never miss a thing.  Make Yahoo your home page. 

More information about the grass-dev mailing list