Hi! I attempted to measure the time required to process large vector point maps (derived from the landcover.30m spearfish map) with v.what.vect/v.distance.
a. v.distance without "dmax=" and afterwards v.what.vect b. v.distance with -pa, grabbing "dmax" and feeding afterwards v.what.vect with "dmax=" Unfortunately, the process crashed because I (wrongly) ran concurrently another heavy process for my work. I have no more time to repeat it. Nevertheless, I have a question: can a good C/C++ programmer, without GRASS- background, make it more efficient within a day let's say? Is the cause of v.distance being slow known? I did not find any specific trac-ticket. (I am asking this because I know somebody which could eventually help-out. In case it takes a _lot_ of time to jump-in the GRASS-C/++ stuff then I won't bother to asking him.) A bit more... "v.distance" is slow (for the impatient user) with very large vectors (from my memory I estimate that it took ~20h for ~600.000 features). Trying to get the "dmax=" first in order to tell "v.distance" to look for features within a certain radius, might _not_ be very efficient as well. It takes time to get results from "v.distance -pa" and, depending on the vector(s), the addition of the _real_ v.distance can be a deal-breaker. However, it might be worthwhile in the end to use "dmax=", as MoritzL mentioned in some post. I think it makes sense when the area of interest (in which v.distance _should_ operate) is much smaller than the queried vector map itself (right?). Unfortunately, the process which was doing exactly this, crashed (using >6000 points and a vector fishnet to count the points that fall inside each box of the fishnet map) In case "dmax=" does a real good job in some cases, maybe v.what.vect can be improved. For example, check the features of the vector maps fed in "vect=" and "qvect=" respectively, compare, and, depending on the occasion, decide automatically if or not to use first a "v.distance -pa" step. Probably you are aware of all this but I post them anyway. Below is the information that I have collected. Thank for your time, Nikos ======================= The stuff I collected so far: --Count points within vectors-- -Posts- "Point count with large vectors" + <http://lists.osgeo.org/pipermail/grass-user/2009-May/050317.html> + <http://lists.osgeo.org/pipermail/grass-dev/2007-May/031533.html> + (this is rather old) <http://lists.osgeo.org/pipermail/grass-user/2003- September/010200.html> -Tools- v.count.points.sh (uses v.what.vect which in turn uses v.distance) + <http://wiki.iosa.it/dokuwiki/spatial_analysis:feature_count> --%<--- + (the following post is is rather old - maybe fixed in latest v.count.points.sh?) <http://lists.osgeo.org/pipermail/grass-user/2007- May/039737.html>: ...this script is very slow, because it uses a nested for loop, so if you have 10000 points and 1000 areas, it calls 10000 * 1000 database queries (in case you provide a class column)... -->%--- --Count points in raster cells (not relevant to v.distance)-- - "r.in.xyz method=n" - + <http://grass.osgeo.org/wiki/Count_points_in_raster_cells> + see also <http://lists.osgeo.org/pipermail/grass-user/2010- April/055678.html> -Information that might be relevant to "count points"- + <http://duncanjg.wordpress.com/2008/04/19/an-example-of-using-postgis-from- r/> + <http://www.mail-archive.com/[email protected]/msg01859.html> + <http://www.mail-archive.com/[email protected]/msg01932.html> [Point in polygon] + <http://grass.osgeo.org/wiki/Point_in_polygon> [r.statistics base=name cover=name method=count ?] <http://lists.osgeo.org/pipermail/grass-user/2009-September/052471.html> [density surface from points in PostGIS] +<http://lists.osgeo.org/pipermail/grass-user/2003-September/010182.html> --Towards a faster "count of points within..." script-- + About SQL statements, related to "v.what.vect": <http://www.mail- archive.com/[email protected]/msg00321.html> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
