Converting Spatial Polygons to data frame for krige.conv

	Subject: 	Re: [R-sig-Geo] Spatial data tower of babel
	Date: 	25 August 2010 8:53:33 PM AWST

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