[GRASS-dev] About v.distance, v.what.vect (wrt "count points within...").

[Moritz Lennert]

On 12/08/10 12:40, Nikos Alexandris wrote:

>
> time v.what.vect --v vector=pareto_ref_points___pareto_ref_30m
> qvect=pareto_grid___OVER___ref_coi_points___pareto_grid___OVER___ref_30m___ON___classification_V___classification_1_500m
> column=gridcell_1 qcolumn=cat
> -->%---
>
> Now this is crawling and I am waiting [*]. Didn't wanna let you waiting too
> long to know that this keeps me waiting - so I've hit the Send button :-p
>

Found the culprit !

Actually the problem is in v.db.dropcol which for the SQLite driver also 
drops all indices (it creates a new table without the dropped column and 
populates with a select from the old table). This means that there is no 
index on the cat column which makes v.distance really slow.

I'm not sure about indices in the dbf driver, but would think that there 
are none...

So, a quick solution for you would be to recreate the index after the 
v.db.dropcol (all this is happening in your pareto_1 script):

echo "CREATE UNIQUE INDEX any_name_for_index on yourtable ( cat )" | 
db.execute

(don't know how to do this in a python script...)

Another (dirty) solution is to copy your map after the v.db.dropcol:

g.copy vect=pareto_ref_points___pareto_ref_30m,test

This automatically creates the index in test, and so

time v.what.vect --v vector=test
qvect=pareto_grid___OVER___ref_coi_points___pareto_grid___OVER___ref_30m___ON___classification_V___classification_1_500m
column=gridcell_1 qcolumn=cat

should be fast again...

I don't have time right now, but I'll look into adding the index 
creation into v.db.dropcol, if you confirm that this is the problem.

Moritz