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

[Hamish]

Moritz:
> >> - d.symbol.thematic: a module for line and point symbol thematic 
> >> mapping, including symbol size variation
Hamish:
> > 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.
Moritz:
> 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 ?

Only that d.graph is a simpler and cleaner example.
I am not familiar with d.vect.chart2 yet.


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

?
D_symbol() and D_symbol2() should be very easy to use. Examples are
given in the functions source code comments (lib/display/symbol.c) and
implemented in d.graph, d.vect, ...
see wiki add-ons page for tips on authoring new symbols (svg->grass
symbol format would be a nice add-on tool)
?


> > Variables to consider are size, color(s), rotation.
> 
> Hadn't thought about rotation, but that would definitely be good...

I don't know when you would want to use it, but line width is another
controllable variable.


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

see D_symbol2(). Basically for the "x" symbol you want the lines drawn
in the primary color, but for the "o" symbol you want it filled in the
primary color with the border line being in the secondary color.


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

It is a wish for many years to get a simple eps -> d.graph translating
script.


Hamish: 
> > 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).
Moritz: 
> 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.

The critical thing is who chooses where the bounds of those discrete
classes lie, & why. Based on a power or multiple of 10? Then based on
the genetic accident that we have 10 fingers, and thus usually count in
base 10 and bias towards that. And nature generally works in spectrums
not hard dichotomies, which are often false simplifications by us. This
is of course a much wider question than just GRASS, but ....

Michael mentioned rasters and r.stats, before writing any code note
GRASS automatically calculates some histogram data for rasters and / or
r.univar percentile= in a loop can get you that data.
(??) This also affects the GUI rewrite of d.histogram.

> In any case, I think that discrete ranges should still remain a
> possibility.

Sure, if people want that, go for it. I just don't like making the new
+ default behaviour a known (self-)deceptive solution, without at least
offering the better alternative.


Hamish



      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping