[R-sig-Geo] Spatial data tower of babel
Roger Bivand
Roger.Bivand at nhh.no
Wed Aug 18 21:05:19 CEST 2010
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
More information about the R-sig-Geo
mailing list