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

[Nikos Alexandris]

Moritz L:

> >>> Then testing the idea from the link Markus N added to your bug report:

> >>> time v.db.update mygrid col=count value="(SELECT count(*) from mypoints
> >>> WHERE mygrid.cat=mypoints.cat_municip group by cat_municip)"

> >>> real 5m28.312s

> >> And to show the magic of database indices:

> >> time echo "create index mypoints_cat_municip on mypoints (cat_municip)"
> >> | db.execute  && time v.db.update mygrid col=count value="(SELECT
> >> count(*) from mypoints WHERE mygrid.cat=mypoints.cat_municip group by
> >> cat_municip)"
> >> 
> >> real    0m10.113s
> >> user    0m6.320s
> >> sys     0m1.300s
> >> 
> >> real    0m0.668s
> >> user    0m0.544s
> >> sys     0m0.124s

Markus M:

> > Thanks a lot! This index was missing here on my sqlite tables. To
> > throw in another timing with 600 000 random points:
> > 
> > time v.distance from=randpoints_600K from_layer=1 to=boundary_municp
> > to_layer=1 to_type=area upload=cat column=to_cat
> > (no dmax, a nearest area was found for each point)
> > 
> > real    3m26.308s
> > user    1m49.736s
> > sys     1m35.067s

Seeing the various timings I' ve got the impression that I did something 
completely wrong.

> Estimate for grass 6: >6 hours

Reading this means there was a "problem" after all, right? 
 
> > same with dmax=0.0
> > 558294 categories - no nearest feature found <-- expected
> > 
> > real    1m24.819s
> > user    0m42.511s
> > sys     0m41.384s

> > tuned v.distance in trunk r43042

Anyhow, the above timing is perfect! I "couting time right now" in grass64, in 
grass70 (both before and after latest v.distance update). Let's see... :-)

Thank you, Nikos