[R-sig-Geo] Re: [R] A package for spatial data classes: request for comments

[Roger Bivand]

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