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=mypoi...@sqlite to=boundary_mun...@permanent > > upload=cat column=cat_municip dmax=0.0 > > real 2m2.119s <= not so bad time v.distance from=mypoi...@user1 to=boundary_mun...@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 _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
