A package for spatial data classes: request for comments
There is better documentation, I'll look for a digital form or maybe somebody else has found it already. The construction of topology is a tradeoff. It is (can be) fast, so it can be done on the fly. This is actually what ArcGIS 8.2 and later does, topology is no longer "stored". I have found that in spatial regression when the same weights object is used over and over (e.g., 3000+ US counties, or multiples of 100 000 in real estate transactions), it makes sense to store it and to somehow relate it back to the original coverage. This doesn't necessarily mean it has to be part of the class design for that object, but the connection should be there. Also, this is a one to many relationship, in that multiple weights can be constructed for the same coverage. L.
On Thursday, November 6, 2003, at 02:59 AM, Edzer J. Pebesma wrote:
Luc Anselin wrote:
As I mentioned to Roger Bivand a few days ago, it might be a good idea to take a look at the spatial classes in ESRI's ArcGIS. In my view they are not 100% ready for statistical analysis, but the vector classes are very well structured.
Luc, are you referring to the "Geometry" section in the second paper (arcob81post.pdf) of the incredibly hart to read poster at http://www.esri.com/library/whitepapers/ao_lit.html or is there some more accessible information to these classes?
What is missing is an efficient way to incorporate "topology" (contiguity structure) to provide an easy way to construct spatial weights. In GeoDa, we build this from scratch, using the shape files, but that's not the way it should be (although very fast).
If constructing it is very fast, why should we incorporate it in the class definition, instead of creating it on the fly? Package gstat builds PR bucket quadtrees for fast neighbourhood selections, which makes the program scalable to large interpolation or simulation jobs, but it never stores them. We recently found out that if you want to apply gstat to say 1e9 points (so many that you will never be able to hold them in RAM), even then quadtree _building_ does take so little time (minutes, maybe) that it does not reward storing it. When constructing topology from prohibitively large spatial data bases in R, another route to investigate would be Postgress/PostGIS; It can deal with tree search indexes, and I think it uses the GEOS geometry toolkit. -- Edzer