Skip to content

How to improve calculation time of spatial weight matrices on spdep

3 messages · Hisaji ONO, Roger Bivand

#
Hello.

 Currently, among GeoComputaion community in Japan,
GeoDa's calculation speed of  spatial weight matrices of
polygons are highly evaluated.

 Any idea to improve this of spdep?



 Regards.
#
Hisaji:
On Tue, 9 May 2006, Hisaji ONO wrote:

            
At present poly2nb() uses two steps, first to try to find candidate 
neighbours using bounding boxes, then to check candidates for  
boundary points within a snap distance. Both steps are in C, but the main 
loop is in R. To go faster, it would mean moving everything to C, avoiding 
the (n*(n-1))/2 loop in R. Profiling the function would show where time is 
being used - I can try to do that. 

On a map of all the US counties, Rprof() shows that there may be a way to 
reduce time by simplifying as.double() calls - because numeric data in R 
can be at least integer or double, it needs coercing before being passed 
to C. I'll try to do something with this, but it may be that there are 
other ways (passing a whole SpatialPolygons object to C, because the 
coordinates there are known to be of storage mode "double").

Speed is - I think - not so important, because the neighbour lists only
need to be made once for each set of polygons, and the function does work
even with very large numbers of polygons. Then the output list can be
stored as an R object, or written out as a GAL file. Do you have examples 
where speed matters more, or are there particular kinds of configurations 
of sets of polygons that are a problem?

Best wishes,

Roger

  
    
#
On Tue, 9 May 2006, Hisaji ONO wrote:

            
Further to my previous message, the next release of spdep will have time 
savings like from 1000 seconds reduced to 300 seconds on a 3500 polygon 
data set. Thanks for pointing this out, with Rprof(), it wasn't difficult 
to find a cheap way to economise (only check storage mode once per 
polygon).

Roger