Saving a spatial point object into a shapefile
On 11/04/2010 11:34 AM, Barry Rowlingson wrote:
On Thu, Nov 4, 2010 at 10:25 AM, Edzer Pebesma <edzer.pebesma at uni-muenster.de> wrote:
Because the documentation sais so. ?writeOGR tells me:
Usage:
writeOGR(obj, dsn, layer, driver, dataset_options = NULL,
layer_options=NULL, verbose = FALSE)
Arguments:
obj: a SpatialPointsDataFrame, SpatialLinesDataFrame, or a
SpatialPolygonsDataFrame object.
Although that's not what the code says:
if (!"data" %in% names(getSlots(class(obj))))
stop("obj of wrong class")
- it just looks to see if there's a 'data' slot in the argument, and
then carries on, stumbling blindly into all sorts of problems if one
is dumb enough to create a class with a data slot:
> setClass("foo",representation(data="numeric"))
> z=new("foo")
> writeOGR(z,dsn="/tmp",layer="pts",driver="ESRI Shapefile")
Error in writeOGR(z, dsn = "/tmp", layer = "pts", driver = "ESRI Shapefile") : NULL NULL unknown data type Surely there should be _methods_ for writeOGR for classes that it supports, such as SpatialPointsDataFrame. Explicitly testing for the presence of a slot/member is worse than explicitly testing for the name of a class when you should really use 'inherits' which is worse than the correct approach which is writing methods... *end mini-rant* :)
Although you're the first one to bring up this feature (bug?) of writeOGR, I fully agree. Using methods would also allow e.g. package raster to define a writeGDAL method for Raster, stacks, bricks, and the like. In that case we might have to define the method first in sp (rgdal depends on sp), so that other package don't require rgdal - CRAN still does not provide OS-X and solaris ports.
Barry
Edzer Pebesma Institute for Geoinformatics (ifgi), University of M?nster Weseler Stra?e 253, 48151 M?nster, Germany. Phone: +49 251 8333081, Fax: +49 251 8339763 http://ifgi.uni-muenster.de http://www.52north.org/geostatistics e.pebesma at wwu.de