[GRASS-dev] trying to amend d.vect.chart - need for advice

[Moritz Lennert]

Hamish wrote:
> Moritz Lennert wrote:
>> With a colleague we are trying to amend d.vect.chart in order to
>>
>> 1) speed it up
>> 2) allow a where clause
>>
>> Currently, d.vect.chart loops through each vector feature and opens a 
>> new db cursor to fetch the column information. On a map with a fair 
>> amount of features (20464 centroids) with the table in Postgresql it 
>> seems that the db connection is what takes the most of the time (even 
>> worse obviously when the map is linked to a view which needs to be 
>> recalculated for every feature).
>>
>> So currently, the program's logic is as follows (in 
>> display/d.vect.chart/plot.c):
>>
>> - get number of features (little aside question: why is this done with
>>
>> Vect_get_num_lines() which should return number of lines, not number
>> of  features - as you can see I'm very new to the vector library)
>> - loop through each feature:
>>     - get cat of feature
>>     - open cursor selecting columns [and sizecol] for this feature 
>> according to cat
>>     - close cursor
>>     - plot with this info
>>
>> We would like to modify this according to the following logic:
>>
>> - add a 'where' option
>> - open a cursor selecting cat, columns [and sizecol] limited by the 
>> where option
>> - loop through the cursor:
>>     - find x,y values according to cat
>>     - plot with this info
>> - close cursor
> 
> plotting to the screen is probably the slowest part; having that inside
> the loop is probably a slow down ..

Yes, but unless you create a temporary map with the charts as objects, I 
don't know how you could not plot every chart separately.

> as a prototype could you write a
> shell script that runs v.extract + d.vect.chart?

This would show an implementation of a where clause, but would not 
change the creation of a new cursor for every chart. But I can do that.


> 
> But it shouldn't be to hard to do as you suggest, and I imagine if you
> leave the actual close driver/stabilize call until after the loop it
> shouldn't be much slower.

Any hints as to a function to get x,y point values according to cat value ?

Moritz