sp: a package with classes and methods for spatial data in R
Very cool. I'd been thinking of something similar, but not had the time to act on it. Looks like we need to add OGR wrappers to rgdal so that vector data can be read in. A couple of immediate items I noticed: 1) "sp" is rather terse, no? I like more descriptive package names. 2) I think it is always a good idea to let typing describe internal states (ie making objects stateless). It leads to much cleaner interfaces and many fewer coding errors. If there are two different ways to represent a grid, make two classes. If they are perfectly substitutable (functions can take either), join them with a super-class. If one is a perfect subset of the other, then make it the parent class and the extension the child (inherits). See GDALDataset and GDALReadOnlyDataset. GDALDataset is a perfect superset of GDALReadOnlyDataset and so can be passed to any function needing the interface of GDALReadOnlyDataset. This is formalized by having GDALDataset inherit from GDALReadOnlyDataset. If you are writing functions that check or update the internal states of your objects (except ordinary insertion and deletion of contained items), then you should think twice about the object hierarchy. This is why there are no "is.writable" or "make.writable" functions in rgdal. That's all handled by type declarations (meaning you can customize dispatch on types in your methods ;-) 3) As long as we can override methods of the interface, all will be well. We can substitute external data representations when we need to scale to larger datasets. Try allocating a 50Kx50K matrix in R. There will be times when we will want to have data be in a database or on disk and still manipulate it with the "sp" interface. I don't see any barriers to this at the moment. These external wrappers will want to inherit from existing classes, so see point 2 above. Love the image gallery! Nice work! THK
On Thu, 2005-04-14 at 18:43 +0200, Edzer J. Pebesma wrote:
Dear spatial R package maintainer and/or R-sig-geo subscriber,
we are happy to announce the beta (i.e. pre-CRAN) release of "sp",
a new R package which has new-style classes and methods for spatial data.
Spatial data types that sp implements are: points, grids, lines and
polygons (i.e., rings). Methods include
+ the usual print, summary, plot, [, [[, ...
+ coercion between types (e.g. points and grids, matrices, data.frames)
+ coordinates(x), which returns the spatial coordinates of x
+ bbox(x), returns the bounding box of x
+ overlay, to query the value of e.g. points in polygons or grid
(essentially does a point-in-polygon or point-in-raster cell)
+ spsample, for random sampling methods over a spatial domain.
An additional package (spproj) provides coordinate reference system
transformation (projection or re-projection) using the PROJ.4 library
[2]. Others will provide interfaces to GRASS and gdal.
A good deal of work has also gone into providing plotting methods using
base, grid and lattice graphics, through the spplot function, a
front-end to lattice plots for spatial data (see gallery [1]).
The home page of these packages is found at
http://r-spatial.sourceforge.net/
The reason why we wrote this package is that we think R is an excellent
environment to deal with spatial data, but that it lacks a uniform way
to deal with spatial data. Compared to the handling of dates and times,
which can utilize base classes or those provided in the chron package,
spatial data handling is much more fragmented. As a consequence:
- various packages make their own assumptions about how spatial data
are organized
- spatial data organized for a certain package cannot easily be used
for another package
- few (or no) packages address the full range of spatial data types
(points, grids, lines, polygons)
- generic spatial functionality (e.g. I/O to GIS, plotting, projection)
is scattered and limited in functionality.
It also means that many different package authors have to use time writing
similar data handling code, rather than concentrating on analytical
functions. If the sp package achieves its goals, data I/O will become
many-to-one, and data access for analysis one-to-many, providing a shared
data object layer for which shared methods can be written.
Classes and methods for spatial data are only useful when the spatial
packages support them. Our team includes maintainers of a number
of spatial R packages, but we would value your support in making sp
a success.
First, we would like to ask you to review critically what we are proposing
in the package, and to give us the benefit of your experience in spatial
data handling. Are there classes of data that you feel we define wrongly
or inadequately? Are there clearly better ways of designing the classes
and methods we have tried so far? Are any of our classes unnecessary? We
realise that the documentation needs more work, first we would like to
get the code into better shape. So your comments will have most value
now; when on CRAN, users will count on the classes (i.e. the slots)
being fixed; at this stage we can still modify them.
Secondly, we would like to invite you to consider supporting the sp
classes directly in your packages. Two possible ways of supporting sp
classes are:
a. to write conversion routines to and from the classes in sp
b. extend your package with methods for your (main) package functions
that accept and return the classes provided by sp, allowing the user
to directly display the results, or use them in other packages.
If we can help in any way with this process, please let us know.
The development of this package is a joint effort of Virgilio Gomez-Rubio,
Barry Rowlinson, Roger Bivand and Edzer Pebesma, and followed from
discussions held at a pre-DSC2003 workshop [3], announcements on R-sig-geo
[4], and a meeting held last November in Lancaster [5].
With best regards,
--
Roger Bivand and Edzer Pebesma
[1] http://r-spatial.sourceforge.net/
[2] http://www.remotesensing.org/proj/
[3] http://spatial.nhh.no/meetings/vienna/index.html
[4] e.g. https://stat.ethz.ch/pipermail/r-sig-geo/2003-October/000028.html
[5] http://elearning.maths.lancs.ac.uk:8080/RSpatial/
_______________________________________________ R-sig-Geo mailing list R-sig-Geo at stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-geo