Spatial data tower of babel

... 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.rowlingson at lancaster.ac.uk> wrote:

On Wed, Aug 25, 2010 at 1:53 PM, Edzer Pebesma
<edzer.pebesma at 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

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