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

[Moritz Lennert]

On 30/12/07 02:32, Hamish wrote:
>> - 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.

I was planning on using d.vect and my d.vect.chart2 as basis to create a 
module which uses any of the GRASS symbols. Any reason I should prefer 
d.graph ?


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

That's exactly what d.thematic.point should do: allow the display of 
point data with any arbitrary symbol whose size can vary in proportion 
to one attribute (or expression) and whose color can vary according to 
another attribute (or expression).

We really do need an easy way to create GRASS symbols though...


> 
> Variables to consider are size, color(s), rotation.

Hadn't thought about rotation, but that would definitely be good...

> Colors can be
> specified as primary/secondary which is more flexible than line/fill.
 > See d.graph, d.vect source.

I'm not sure I understand what this means. I'll look into the d.graph 
and d.vect source to see if I see what you're hinting at.

> ps.map even allows symbol by cat number
> (via dynamic .eps filename).

Yes, I love this feature which allows nice combination of R and GRASS 
for symbols. Don't know how feasible this would be for normal display, 
though, unless we allow the display of eps symbols...

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

Would be great, yes.


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

Interesting point. Will have to think about it. In human geography 
categorising data to display in discrete classes is the usual way of 
doing things. But I don't know whether there are any other reasons for 
it than technical relics and a desire for simplification. In any case, I 
think that discrete ranges should still remain a possibility.

Moritz