I added as.data.frame methods to extract a data.frame with all coordinates
from SpatialPolygons & Lines (and other methods to create
SpatialLines/Polygons from such a data.frame), but, unless additional
arguments are used these as.data.frame methods do not change the default
behavior of sp.

For some reason I also added, or forgot to remove, a method for
SpatialPoints that does change the behavior (and as SpatialPixels/Grid
inherit from SpatialPoints also affects the method for these classes) -- I
have now removed this method from raster to avoid this problem in the
future.

Thanks for pointing out this problem, and I am sorry for causing it,

Robert

On Wed, Jul 18, 2012 at 6:39 PM, Michael Sumner <mdsumner@gmail.com> wrote:

> The culprit in raster_2.0-08 is in R/as.data.frame.R
>
> setMethod('as.data.frame', signature(x='SpatialPoints'),
>
> and the relevant usage is in (raster's) ?as.data.frame "Get a
> data.frame with raster cell values, or coerce a SpatialPolygons,
> Lines, or Points file to a data.frame"
>
>  ## S4 method for signature 'SpatialPoints'
>      as.data.frame(x, row.names=NULL, optional=FALSE, xy=FALSE, ...)
>
>
> So, you can get similar to the sp behaviour if you use xy = TRUE, but
> note that this is a completely different pathway and logic to the way
> the sp:::as.data.frame.SpatialPixelsDataFrame works (it passes the job
> to sp:::as.data.frame.SpatialPointsDataFrame).
>
> library(sp)
> data(meuse.grid)
> m = SpatialPixelsDataFrame(points = meuse.grid[c("x", "y")], data =
> meuse.grid)
> head(as.data.frame(m))
>
> library(raster)
> as.data.frame(m, xy = TRUE)
>   object      x      y    x.1    y.1 part.a part.b      dist soil ffreq
> 1      1 181180 333740 181180 333740      1      0 0.0000000    1     1
> 2      2 181140 333700 181140 333700      1      0 0.0000000    1     1
> ...
>
> I haven't followed the trail to where the "object" column is removed
> again when using as.data.frame(m) with raster loaded.
>
> raster introduces as.data.frame as a generic, with methods for
> SpatialPoints, SpatialLines and SpatialPolygons, and the
> SpatialPixelsDataFrame must get captured by the "SpatialPoints" one,
> which has checks for the @data slot, which seems like a catch-all that
> breaks the sp model. Summary is, if you use raster you accept a
> completely different paradigm that you might be used to with sp.
>
> Cheers, Mike.
>
> On Thu, Jul 19, 2012 at 12:59 AM, Michael Sumner <mdsumner@gmail.com>
> wrote:
> > Right, sure enough I got the x.1 and y.1 as per my first reply with
> > raster 1.9-92, but after update to 2.0-08 I get your results without
> > them. And, to be sure, see my run in a fresh session.
> >
> > I need to explore more to understand this, but things should work as
> > expected with sp if you don't load raster (for now).
> >
> > Robert? Sorry I'm not familiar enough with raster to hunt this down
> > easily, so I thought I'd raise it.
> >
> > Cheers, Mike.
> >
> > Code to run:
> >
> >
> > library(sp)
> > data(meuse.grid)
> > m = SpatialPixelsDataFrame(points = meuse.grid[c("x", "y")], data =
> meuse.grid)
> > head(as.data.frame(m))
> >
> >
> >
> > library(raster)
> > head(as.data.frame(m))
> >
> >
> >
> > Session:
> >
> >> library(sp)
> >> data(meuse.grid)
> >> m = SpatialPixelsDataFrame(points = meuse.grid[c("x", "y")], data =
> meuse.grid)
> >
> >> head(as.data.frame(m))
> >        x      y part.a part.b      dist soil ffreq    x.1    y.1
> > 1 181180 333740      1      0 0.0000000    1     1 181180 333740
> > 2 181140 333700      1      0 0.0000000    1     1 181140 333700
> > 3 181180 333700      1      0 0.0122243    1     1 181180 333700
> > 4 181220 333700      1      0 0.0434678    1     1 181220 333700
> > 5 181100 333660      1      0 0.0000000    1     1 181100 333660
> > 6 181140 333660      1      0 0.0122243    1     1 181140 333660
> >>
> >>
> >>
> >> library(raster)
> > raster 2.0-08 (27-June-2012)
> >> head(as.data.frame(m))
> >        x      y part.a part.b      dist soil ffreq
> > 1 181180 333740      1      0 0.0000000    1     1
> > 2 181140 333700      1      0 0.0000000    1     1
> > 3 181180 333700      1      0 0.0122243    1     1
> > 4 181220 333700      1      0 0.0434678    1     1
> > 5 181100 333660      1      0 0.0000000    1     1
> > 6 181140 333660      1      0 0.0122243    1     1
> >>
> >> sessionInfo()
> > R version 2.15.1 Patched (2012-06-29 r59683)
> > Platform: x86_64-pc-mingw32/x64 (64-bit)
> >
> > locale:
> > [1] LC_COLLATE=English_Australia.1252  LC_CTYPE=English_Australia.1252
> > [3] LC_MONETARY=English_Australia.1252 LC_NUMERIC=C
> > [5] LC_TIME=English_Australia.1252
> >
> > attached base packages:
> > [1] stats     graphics  grDevices utils     datasets  compiler  methods
> > [8] base
> >
> > other attached packages:
> > [1] raster_2.0-08 sp_0.9-99
> >
> > loaded via a namespace (and not attached):
> > [1] grid_2.15.1    lattice_0.20-6 tools_2.15.1
> >
> >
> >
> >
> >
> > On Wed, Jul 18, 2012 at 11:48 PM, Johannes Radinger <JRadinger@gmx.at>
> wrote:
> >> Hi,
> >>
> >>> > I tried:
> >>> > 1) to transform the SPDF to a normal dataframe with
> as.data.frame(spdf)
> >>> but then I loose my x and y columns. Thus I can't use them in melt. Was
> >>> that behavior changed recently?
> >>>
> >>> No, I really don't think so. Are you sure?  Here x.1 and y.1 are the
> >>> (re-attached) grid point coordinates, which incidentally are copies of
> >>> the original data "x" and "y".
> >>>
> >>> data(meuse.grid)
> >>> m = SpatialPixelsDataFrame(points = meuse.grid[c("x", "y")], data =
> >>> meuse.grid)
> >>> head(as.data.frame(m))
> >>>        x      y part.a part.b      dist soil ffreq    x.1    y.1
> >>> 1 181180 333740      1      0 0.0000000    1     1 181180 333740
> >>> 2 181140 333700      1      0 0.0000000    1     1 181140 333700
> >>> 3 181180 333700      1      0 0.0122243    1     1 181180 333700
> >>
> >> I am not 100% sure but my output looks different from yours (I am
> missing x.1 and y.1, the original coords from the SPDF and not the
> re-attached ones)
> >> Here the output with the same example and sessionInfo():
> >>
> >>> library(raster)
> >> Loading required package: sp
> >> raster 2.0-08 (27-June-2012)
> >>> data(meuse.grid)
> >>> m = SpatialPixelsDataFrame(points = meuse.grid[c("x", "y")], data =
> meuse.grid)
> >>> head(as.data.frame(m))
> >>        x      y part.a part.b      dist soil ffreq
> >> 1 181180 333740      1      0 0.0000000    1     1
> >> 2 181140 333700      1      0 0.0000000    1     1
> >> 3 181180 333700      1      0 0.0122243    1     1
> >> 4 181220 333700      1      0 0.0434678    1     1
> >> 5 181100 333660      1      0 0.0000000    1     1
> >> 6 181140 333660      1      0 0.0122243    1     1
> >>> sessionInfo()
> >> R version 2.14.1 (2011-12-22)
> >> Platform: i686-pc-linux-gnu (32-bit)
> >>
> >> locale:
> >>  [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C
> >>  [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
> >>  [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
> >>  [7] LC_PAPER=C                 LC_NAME=C
> >>  [9] LC_ADDRESS=C               LC_TELEPHONE=C
> >> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
> >>
> >> attached base packages:
> >> [1] stats     graphics  grDevices utils     datasets  methods
> >> [7] base
> >>
> >> other attached packages:
> >> [1] raster_2.0-08 sp_0.9-99
> >>
> >> loaded via a namespace (and not attached):
> >> [1] grid_2.14.1    lattice_0.20-0 tools_2.14.1
> >>
> >>
> >>
> >>
> >> Any idea?
> >>
> >> /johannes
> >
> >
> >
> > --
> > Michael Sumner
> > Hobart, Australia
> > e-mail: mdsumner@gmail.com
>
>
>
> --
> Michael Sumner
> Hobart, Australia
> e-mail: mdsumner@gmail.com
>

	[[alternative HTML version deleted]]

