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

[Barry Rowlingson]

> 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.

  For example, the rasp library uses sp.coords(foo) whenever it needs a 
set of point locations for analysis. It doesn't care what 'foo' is, as 
long as sp.coords(foo) returns a 2-column matrix.

  rasp provides spatial.data.frame as a class for when your data is 
conveniently stored in a data frame, but each row has an associated 
coordinate. Suppose your data is a varying number of measurements of 
soil acidity over time at a number of locations - this would be better 
stored as a list with foo[[i]] being a 2-column matrix (or data frame) 
of time and acidity, and a single associated coordinate. This could then 
be made into a spatial.list class. As long as there's an 
sp.coords.spatial.list then you can use rasp analysis functions using 
this object and it will get the coordinates.

  Typical methods that spatial location data will have would be things 
like sp.coords() to get point locations, bbox() for bounding box, and 
ummm, I cant really think of anything else at that level.

  Lat-long geographic data needs a slightly different set of interface 
methods, to cope with projections, and this might implement a 
'project<-' function, for example:

sp.coords(foo) # returns cbind(Lat, Long)
project(foo) <- '+proj=merc +lat0=35'

now sp.coords(foo) returns the projected coordinates.

  Any objects with lat-long coordinates (points, polygons, lines) need 
to implement the 'project<-' function, and whatever 'foo' is, it gets 
projected properly. The object can decide whether to do the projection 
calculations at 'project(foo)<-' time or save it until 'sp.coords(foo)' 
time.

  So, I'll wrap up this ramble with the thought that we need to consider 
interfaces rather than classes, and I might just have another bash at S4 
classes with this :)

Baz