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

[Roger Bivand]

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

-- 
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand at nhh.no