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

[Edzer Pebesma]

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.

Best regards,

On 08/18/2010 09:05 PM, Roger Bivand wrote:
> On Wed, 18 Aug 2010, Barry Rowlingson wrote:
> 
>> Hi,
>>
>> Recently while teaching at SFU I hit the problem that infects R when
>> many people work on similar projects - the multitude of data formats
>> for similar data. The sp project was partly an attempt to give a
>> standard format for spatial data but its widespread non-use in older
>> packages causes trouble.
>>
>> So for example I taught the students all about 'sp' objects, and then
>> they had to use spatstat and splancs for some point-process stuff,
>> then geoR for some kriging, none of which use sp objects.
>>
>> So I figured maybe we need a whole load of 'as' functions that can
>> convert between the various spatial data formats (there are more in
>> CRAN, I am sure) to help us all out on this. Some of these functions
>> may already exist, indeed I just found something about converting
>> fairly raw x-y coordinate objects to SpatialPolygons hidden away in
>> the SpatialEpi package (polygons2spatial.polygons).
> 
> Barry,
> 
> I think that spatstat is well provided for, mostly in maptools, but also
> in the spatstat vignette on using shapefiles. Of course, the available
> functionalities sp <-> spatstat classes could probably be documented
> more fully, and the coercion functions updated, but I think that they do
> most of what is needed.
> 
> I agree that there may be others out there, and like you come across
> them from time to time. Sometimes the CRAN reverse dependencies show who
> they might be. Since splancs is largely pre-S3 (right?) and doesn't use
> classes, coercion isn't an option, so documentation and a wrapper
> function or two might be sensible. I started on this, but only got as
> far as the spkernel2d() that uses a call to GridTopology() to set up the
> output grid.
> 
> geoR does use S3 classes, so might be closer, and does depend on sp.
> There is a method for coercing a SpatialPointsDataFrame to "geodata".
> The borders component of a "geodata" object is harder to introduce.
> Taking the coordinates() of a SpatialPixels object to pass to locations=
> is OK, as are the subsetting of data frame columns for the trend.d= and
> trend.l= arguments. I guess Paulo would need to move to a formula= data=
> interface to likfit(), krige.bayes() and krige.conv(), at least, to
> permit sp objects to be used "closer" to the actual core.
> 
> Probably a good deal could be done by documentation, and by
> communicating better about what already is there.
> 
> Useful topic!
> 
> Best wishes,
> 
> Roger
> 
>>
>> Would it be a good idea to stick all the conversions we can think of
>> into a single package, "spBabel" say (or spConversion to avoid any
>> cultural reference), so people have a one-stop shop? And if we find
>> routines stuck in other packages (such as polygons2spatial.polygons)
>> we rip them out and bundle them?
>>
>> Yes, its a matter of time and effort and we're all busy, but I'd like
>> to put it out as a proposal. It might make a nice intern or GSOC
>> project, but we're a bit late for that, so maybe if anyone has a PhD
>> student starting who needs to get up to speed with R packages and
>> spatial data it would be a good introduction for them. Once its all
>> set up (on R-forge or similar) contributing shouldn't be a problem.
>>
>> Okay, that's my one crazy idea for the day done.
>>
>> 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