A package for spatial data classes: request for comments
On Mon, 3 Nov 2003, 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. 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). L.
Yes, it's the topology/no topology that emerges as a question. It will be worth looking at one or more of the following too: Terralib (www.terralib.org) - work going on in Brazil is really well done and exciting (which is why I've CC'd to Paulo Ribeiro), the GRASS 5.7 experimental vector engine, now approaching a draft alpha release but very promising (grass.itc.it), maybe OpenGIS GML - which doesn't do topology, and finally the newly released map* packages, which do topology using the original Bell Labs Geographical Database model. Terralib and GRASS are open source, the map* packages are mixed (2 OS, 1 non-commercial) and don't include methods for ingesting other data, which needs to go through an external tool topologising train (I think). Other users will be grateful for a route from shapefile through topology to map(). I think Barry has an important point about methods, but which may expand fast - as Edzer wrote - if the number of input object types also grows - so to do methods right, we still need more consistency in the input objects. From there on, methods can rule, perhaps. Roger
On Monday, November 3, 2003, at 09:08 AM, Edzer J. Pebesma wrote:
Barry Rowlingson wrote:
To be really useful, the class should include vector (polygon) data, and probably line elements. For this, I need help. The simples approach would be to extend SpatialDataFrame to SpatialDataFramePolygon, and add for each row add the corresponding polygon.
I think you need to stop thinking about building classes at the moment, and to think about specifying _interfaces_. What methods do we want for spatial data? How will functions get the spatial data out of the objects? Then we can build classes that implement these interfaces.
Baz, I agree that interfaces are important. Still, concentrating on
interfaces _only_
does encourage package writers to come up each with a new set of
spatial classes
-- something I would like to discourage: sharing more code makes the
code more
reliable.
I did build upon your idea of sp.coords, but called it coordinates,
and used reference (column name/numbers) instead of actual values:
coordinates(meuse) = c("x", "y")
I prefer coordinates because at some stage the S3 method mechanism may
interpret sp.coords as an sp method for a coords class.
My question, in your perspective, would be: which methods do we need
for
a generic class containing vector/polygon data?
E.g. how is,
polygons(world) # gets or sets the polygons, as a list of 2 col
matrices
polygonAttributes(world) # gets or sets the polygon attributes, as
data frame
--
Edzer
_______________________________________________ R-sig-Geo mailing list R-sig-Geo at stat.math.ethz.ch https://www.stat.math.ethz.ch/mailman/listinfo/r-sig-geo
---------------------------------------------------------------- Luc Anselin, PhD. Faculty Excellence Professor and Director Spatial Analysis Laboratory Dept. Agricultural and Consumer Economics University of Illinois at Urbana-Champaign http://sal.agecon.uiuc.edu/
_______________________________________________ R-sig-Geo mailing list R-sig-Geo at stat.math.ethz.ch https://www.stat.math.ethz.ch/mailman/listinfo/r-sig-geo
Roger Bivand Economic Geography Section, Department of Economics, Norwegian School of Economics and Business Administration, Breiviksveien 40, N-5045 Bergen, Norway. voice: +47 55 95 93 55; fax +47 55 95 93 93 e-mail: Roger.Bivand at nhh.no