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

[Nikos Alexandris]

Moritz L:
 
> As a follow-up:

> The counting points in polygons algorithm I prefer at this stage is
> (using municipal boundaries and hospitals in the NC data set with an
> SQLite backend - DBF won't work):

> g.copy hospitals,myhospitals
> v.db.addcol myhospitals col="cat_municip int"
> v.distance from=myhospitals at sqlite to=boundary_municp at PERMANENT
> upload=cat column=cat_municip dmax=0.0
> db.select sql="select cat_municip, count(*) from myhospitals group by
> cat_municip"

> If your hospital attribute table contains number of beds (nbeds), the
> you could sum the number of beds as such:
> 
> db.select sql="select cat_municip, sum(nbeds) from myhospitals group by
> cat_municip"
> 
> etc...
> 
> Using 6.5 to test a similar case to yours (I assume):
> 
> 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...)

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?

Nikos

> 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
> 
> 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...