[R-sig-Geo] sp: a package with classes and methods for spatial data in R

[Edzer J. Pebesma]

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/