Rather something like this in the simplest form; i.e. using an S4 method for inheritance, and passing it on to other packages as much as possible.
setMethod('convert', signature(x='ANY', class='character'), function(x, class, ...) { y <- try( as(x, class), silent=TRUE ) if (class(y) == 'try-error') { stop('sorry') } else { return(y) } } ) And adding more methods for classes that do not have as methods. Most objects could be coerced into an sp object, and then into whatever is requested. Perhaps there is a lot of ugly nitty-gritty there. Perhaps you are right about dependencies and S4. Still, I think this could be a step forward from the current situation where many no standard coercion functions exist that might be hard to find or remember. Robert On Wed, Aug 25, 2010 at 1:03 PM, Edzer Pebesma <edzer.pebe...@uni-muenster.de> wrote: > ... and this convert function would then loop over all possible classes > of x, and for each possibility over all values for "AnotherClass"? > Sounds like the n-to-n solution we tried to avoid when we started sp. > > Coercion is formally done in S4 by using as(), as in > > as(x, "AnotherClass") > > and this coercion is automatic when AnotherClass is a superclass for x, > and can otherwise be specified by setAs. Informally in S3, it's > typically done by functions like as.AnotherClass.ThisClass, which is > called when, in > > as.AnotherClass(x) > > x is of class "ThisClass". > > Problems I see with having a package that provides all these functions > is authorship: will each class author of package X update this package > each time she/he changes a class definition (S4) or the assumptions > implicitly made about it (S3)? Also, for S4 classes I believe "suggest:" > only will not do. > > I would rather ask package authors to call for explicit coercion, e.g. > the first line in krige.bayes (geoR) should be > > if (class(data) != "geodata") > data = as.geodata(data) > > so that anyone passing it data of a new class will only have to provide > an as.geodata.MyNewClass function to make this work (provided that > package is loaded, which seems reasonable - some function will need to > create the MyNewClass objects). > > Not dissimilar to Barry's 10 years old idea that coordinates(x) should > return the spatial coordinates of object x, whatever x is. > > Why does > > library(sp) > data(meuse) > coordinates(meuse) = ~x+y > plot(log(zinc) ~ sqrt(dist), meuse) > > work? sp doesn't provide the plot method used here, and this method > doesn't know nor imports the Spatial* classes. Somewhere meuse gets > transformed to a data.frame, for which sp indeed provides methods. > > > On 08/25/2010 09:10 PM, Robert J. Hijmans wrote: >> I think that such a package would be very useful. It could have a >> single function like >> >> convert(x, 'AnotherClass') >> >> The package would only need to depend on sp, all the other packages >> would be "suggested" such that you do not need to install the packages >> you do not use. >> >> Robert >> >> >> On Wed, Aug 25, 2010 at 12:00 PM, Barry Rowlingson >> <b.rowling...@lancaster.ac.uk> wrote: >>> On Wed, Aug 25, 2010 at 1:53 PM, Edzer Pebesma >>> <edzer.pebe...@uni-muenster.de> wrote: >>>> Barry, what exactly did you try out before you posted? >>>> >>>> Your claim is not completely true: geoR has a function >>>> as.geodata.SpatialPointsDataFrame, so you can do, for instance: >>>> >>>> library(geoR) >>>> data(meuse) # from sp >>>> coordinates(meuse) = ~x+y >>>> krige.bayes(as.geodata(meuse, "zinc")) >>>> >>>> and its locations argument can be a SpatialPoints object. >>> >>> Well, I didnt claim these functions didnt exist, nor did I point out >>> that some are trivial - ie to get from a SpatialPointsDataFrame to a >>> set of locations for, say, splancs' K-function, you just do >>> coordinates(foo). What I was hoping for was that we could create a >>> single point where these conversions could be collected, which would >>> be an almost authoritative source of conversions. >>> >>> geoR has SpatialPointsDataFrame to geodata - but does it have the >>> other way round too? Or is that in sp? It doesn't matter too much, >>> since students will find them either way, but does >>> as.sp(as.geodata('meuse","zinc")) get you back where you started? >>> That's what students may expect. Conversion is a big headache for new >>> users and anything that makes it easier is a plus. Imagine doing >>> vignette(spBabel) and getting a whole list of what formats can be >>> converted together with caveats and restrictions - sounds good to me. >>> >>> Obviously the problems are in maintainance and keeping conversions up >>> to date with any changes in the format in the main package, as well as >>> that this package would probably depend on all the other packages... >>> >>> Idle coffee-time thoughts... >>> >>> Barry >>> >>> _______________________________________________ >>> R-sig-Geo mailing list >>> R-sig-Geo@stat.math.ethz.ch >>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo >>> >> >> _______________________________________________ >> R-sig-Geo mailing list >> R-sig-Geo@stat.math.ethz.ch >> https://stat.ethz.ch/mailman/listinfo/r-sig-geo > > -- > 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.pebe...@wwu.de > > _______________________________________________ > R-sig-Geo mailing list > R-sig-Geo@stat.math.ethz.ch > https://stat.ethz.ch/mailman/listinfo/r-sig-geo > _______________________________________________ R-sig-Geo mailing list R-sig-Geo@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-geo