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

[Nikos Alexandris]

Moritz L:

[...]

> > Using 6.5 to test a similar case to yours (I assume):

The test below in grass64 gives...

> > g.region vect=boundary_municp
> > v.random out=mypoints n=600000
> > v.db.addtable mypoints col="cat int, cat_municip int" (that's veeeeery
> > slow, probably because of 600000 update statements to the database in
> > the v.to.db call...)

Nikos A:

> It runs here... and takes for-ever (like my problem). Silly question but I
> wonder if this has anything to do with my process/data?

> > time v.distance from=mypoints at sqlite to=boundary_municp at PERMANENT
> > upload=cat column=cat_municip dmax=0.0

> > real	2m2.119s <= not so bad

time v.distance from=mypoints at user1 to=boundary_municp at PERMANENT upload=cat 
column=cat_municip dmax=0.0

575595 categories - no nearest feature found
600000 categories read from the map
600000 categories exist in the table
600000 categories read from the map exist in the table
600000 records updated
v.distance complete.

real    1m30.315s <= even faster with grass64 in my machine! :-)

Hmmm???

Maybe v.db.addtable is the crux? I have to check if and when v.db.addtable is 
executed in my pareto scripts. Or is it irrelevant?

> > db.select sql="select cat_municip, count(*) from mypoints group by
> > cat_municip"
> > 
> > So, using the combination of v.distance and db.select I cannot reproduce
> > your problem with 600,000 points, but maybe the number and nature of
> > polygons can also play a role...

...or v.db.addtable?

Nikos