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/