[R-sig-Geo] Converting Spatial Polygons to data frame for krige.conv

[Ben Madin]

G'day,

I'm re-running some old models with new data, but in the same location as previously. In the past I had a text file with the border coordinates, but this is no longer anywhere to be found - thus I'm coming unstuck with krige.conv() and the borders option.

I have otherwise moved very happily into using sp classes for everything, so can load a set of boundaries from PostGIS in using rgdal but although I find discussion about this (see below) for SpatialPoints, I am stumped for a method to convert Spatial Polygons to a list of coordinates - I guess I could manually split the object into it's component polygons and then iterate through the coords ... but I was hoping that there might be a method that I've overlooked.

I confess I have also forgotten how I originally created the text file I had - there must have been a method, but I'm not sure I can remember where it was. (> 5years ago). I thought it was maptools, but all the maptools functions seem to read into sp classes...

cheers

Ben





> 	Subject: 	Re: [R-sig-Geo] Spatial data tower of babel
> 	Date: 	25 August 2010 8:53:33 PM AWST
> 
On 25/08/2010, at 8:53 PM, Edzer Pebesma 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.
> 
> 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
> 
> _______________________________________________
> R-sig-Geo mailing list
> R-sig-Geo at stat.math.ethz.ch
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo