[GRASS-dev] new version of d.vect.chart

Moritz Lennert mlennert at club.worldonline.be
Tue Oct 10 08:27:42 EDT 2006


Thanks to the help of Radim, Daniel, Glynn and Hamish I have finally 
finished a revised d.vect.chart which offers the following improvements 
over the original:

- speed: using a map with over 20.000 charts, it takes only half the 
time with attributes in postgresql and only 10-15% of the time with data 
in dbf. With ~600 charts it takes about 60% of the time in both cases.

This might be different if your map is linked to a table containing many 
more lines than there are objects in the map, since this version loops 
through the entries in the table, instead of looping through the vector 
objects. You can however use the where clause to limit the amount of 
lines retrieved.

- ordering of charts: if sizecol is used, charts are now ordered so that 
largest are at the bottom

- choice in proportionality: a new flag allows to make the chart's area 
proportional to sizecol and not the chart's diameter (by using the 
square root of sizecol)

- where clause: you can limit the objects displayed through a where clause

- multiple objects with same cat: the module now prints a warning if it 
finds multiple objects with the same cat. In most usages of charts I can 
think of, you don't want to display the same chart twice, only because 
your area of reference might be divided into several polygons (e.g. 
total population of Canada displayed for every single island of the 

The module uses the new (today) Vect_cidx_find_all() function, so it 
only compiles if you have the latest version of lib/vector/Vlib/cindex.c 
and include/Vect.h. Also, if you use the dbf data backend, you need the 
new support for ASC/DESC in ORDER BY clauses also committed today.

At this stage, the module draws more than one chart at the same location 
if there is more than one line with identical cat, data columns and size 
column. I wanted to use a SELECT DISTINCT clause, but DISTINCT is not 
supported by the dbf backend, yet. It would be possible to solve this 
within the module, but it might be more interesting to implement a 
DISTINCT clause.

My question now is: should this replace d.vect.chart in CVS head ? It is 
completely backwards compatible in terms of parameters, with only the -s 
(use square root) added. Or should this live as d.vect.chart2 for a 
while for testing (the attached directory compiles the modules as 
d.vect.chart2) ? Should I commit it to CVS ?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: d.vect.chart2.tgz
Type: application/x-gtar
Size: 6504 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20061010/f599ab5a/d.vect.chart2.gtar

More information about the grass-dev mailing list