... 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
