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

[Nikos Alexandris]

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/grass-user@lists.osgeo.org/msg01859.html>
+ <http://www.mail-archive.com/grass-user@lists.osgeo.org/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/grass-stats at lists.osgeo.org/msg00321.html>