[R-sig-Geo] Re: [R] A package for spatial data classes: request for comments
B.Rowlingson at lancaster.ac.uk
Mon Nov 3 12:23:12 CET 2003
> 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)'
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 :)
More information about the R-sig-Geo