[GRASS-dev] d.vect changes

Hamish hamish_nospam at yahoo.com
Wed May 2 07:20:08 EDT 2007


I've just committed some changes to d.vect in CVS. of note:

bugfix: it wasn't calculating new x,y for symbols if colors were all
none. (potentially nasty, probably invisible so was benign?)

simplification: use D_symbol() to plot symbols. This changes how -c
random and rgb_column work on symbols. Now fill color is constant (ie
whatever fcolor= was set to) and line color changes; previously -c or -a
changed either the line color or fillcolor depending on if the symbol
primitive drawing STRINGs or POLYGONs (that does odd things to symbols
that use both, like pushpin). I don't really see a way around this
without a new flag to specify if the custom color is meant to be the
line color or fill color. Deciding what to do on a per-symbol or per-
primitive basis sucks IMO. I'm open to suggestions (other than putting
the low level symbol rendering code back into d.vect).
I can solve the pushpin problem by forcing its line color to always be
black. But that doesn't solve the "x" vs "o", stroke vs fill, problem.
Lines, areas, and centroids are unaffected.

clone of D_symbol() using primary_color and secondary_color instead of
line_color and fill_color??

speed: It now only plots symbols which are in the graphics frame.
For my tests with the NC sample LIDAR dataset (1.15M points), this,
together with the switch to D_symbol(), sped up zoomed rendering by 54%
(zoomed display region covered 12% of original region area)
The overlapping edges of large offscreen symbols will no longer be drawn
at the edges of the display monitor; the point has to be in the frame.


More information about the grass-dev mailing list