[R-sig-Geo] Spatial data tower of babel

[Robert J. Hijmans]

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.pebesma at 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.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
>>>
>>> _______________________________________________
>>> R-sig-Geo mailing list
>>> R-sig-Geo at stat.math.ethz.ch
>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>>
>>
>> _______________________________________________
>> R-sig-Geo mailing list
>> R-sig-Geo at 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.pebesma at wwu.de
>
> _______________________________________________
> R-sig-Geo mailing list
> R-sig-Geo at stat.math.ethz.ch
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>