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

[Tim Keitt]

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