inconsistent as.data.frame(SpatialPointsDF)

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

inconsistent as.data.frame(SpatialPointsDF)

dschneiderch
I have a spatial points dF that is causing me trouble. I've figured out what is happening but without a clue why.

at the prompt, I do
> locs
class       : SpatialPointsDataFrame
features    : 10
extent      : -112.0623, -109.0571, 33.65387, 36.32678  (xmin, xmax, ymin, ymax)
coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
variables   : 7
names       : network, State, Station_ID, Site_ID,        Site_Name, Elevation_ft, Elevation_m
min values  :    SNTL,    AZ,     09N05S,     308,      BAKER BUTTE,         7100,        2164
max values  :    SNTL,    AZ,     12P01S,    1143, HANNAGAN MEADOWS,         9200,        2804

> head(as.data.frame(locs))
          x        y network State Station_ID Site_ID       Site_Name
1 -111.4064 34.45660    SNTL    AZ     11R06S     308     BAKER BUTTE
2 -111.3827 34.45547    SNTL    AZ     11R07S    1140 BAKER BUTTE SMT
3 -109.5034 33.97883    SNTL    AZ     09S01S     310           BALDY
4 -109.2166 33.69144    SNTL    AZ     09S06S     902     BEAVER HEAD
5 -109.0571 36.32678    SNTL    AZ     09N05S    1143   BEAVER SPRING
6 -112.0623 35.26247    SNTL    AZ     12P01S    1139       CHALENDER
  Elevation_ft Elevation_m
1         7300        2225
2         7700        2347
3         9125        2781
4         7990        2435
5         9200        2804
6         7100        2164

so as expected(?) my coordinate names get converted from Longitude, Latitude to x, y.

However, when I run my script, the output of head(as.data.frame(locs)) is:
    Longitude   Latitude network State Station_ID Site_ID       Site_Name
1 -111.4064 34.45660    SNTL    AZ     11R06S     308     BAKER BUTTE
2 -111.3827 34.45547    SNTL    AZ     11R07S    1140 BAKER BUTTE SMT
3 -109.5034 33.97883    SNTL    AZ     09S01S     310           BALDY
4 -109.2166 33.69144    SNTL    AZ     09S06S     902     BEAVER HEAD
5 -109.0571 36.32678    SNTL    AZ     09N05S    1143   BEAVER SPRING
6 -112.0623 35.26247    SNTL    AZ     12P01S    1139       CHALENDER
  Elevation_ft Elevation_m
1         7300        2225
2         7700        2347
3         9125        2781
4         7990        2435
5         9200        2804
6         7100        2164


I found out the hard way because i was doing as.data.frame(locs)[,c('x','y')] to get the coordinates.... I switched this line to coordinates(locs) but I have other lines in the same code that use as.data.frame() so I'm wondering if there are designed circumstance for one behavior compared to the other.  I did notice that data.frame(locs)[,c('x','y')] seems to always maintain the original coordinate names but I confirmed that the script uses as.data.frame()

Below is dput of a sample of my data. does anyone else get this behavior?

> dput(locs)
new("SpatialPointsDataFrame"
    , data = structure(list(network = c("SNTL", "SNTL", "SNTL", "SNTL", "SNTL",
"SNTL", "SNTL", "SNTL", "SNTL", "SNTL"), State = c("AZ", "AZ",
"AZ", "AZ", "AZ", "AZ", "AZ", "AZ", "AZ", "AZ"), Station_ID = c("11R06S",
"11R07S", "09S01S", "09S06S", "09N05S", "12P01S", "09S07S", "11P02S",
"11P13S", "09S11S"), Site_ID = c(308L, 1140L, 310L, 902L, 1143L,
1139L, 416L, 1121L, 488L, 511L), Site_Name = c("BAKER BUTTE",
"BAKER BUTTE SMT", "BALDY", "BEAVER HEAD", "BEAVER SPRING", "CHALENDER",
"CORONADO TRAIL", "FORT VALLEY", "FRY", "HANNAGAN MEADOWS"),
    Elevation_ft = c(7300L, 7700L, 9125L, 7990L, 9200L, 7100L,
    8400L, 7350L, 7200L, 9020L), Elevation_m = c(2225L, 2347L,
    2781L, 2435L, 2804L, 2164L, 2560L, 2240L, 2195L, 2749L)), .Names = c("network",
"State", "Station_ID", "Site_ID", "Site_Name", "Elevation_ft",
"Elevation_m"), row.names = 63:72, class = "data.frame")
    , coords.nrs = c(7L, 6L)
    , coords = structure(c(-111.40643, -111.38272, -109.50344, -109.21657, -109.05711,
-112.06231, -109.15282, -111.74486, -111.84374, -109.30952, 34.4566,
34.45547, 33.97883, 33.69144, 36.32678, 35.26247, 33.80392, 35.26806,
35.07297, 33.65387), .Dim = c(10L, 2L), .Dimnames = list(NULL,
    c("Longitude", "Latitude")))
    , bbox = structure(c(-112.06231, 33.65387, -109.05711, 36.32678), .Dim = c(2L,
2L), .Dimnames = list(c("Longitude", "Latitude"), c("min", "max"
)))
    , proj4string = new("CRS"
    , projargs = "+proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0"
)
)


This is running on a cluster at my university, using a SOCK cluster to parallelize dlply and then an MC backend for a ddply inside the dlply, if that's important. It seems to produce the expected behavior of my desktop.
> sessionInfo()
R version 3.1.2 (2014-10-31)
Platform: x86_64-unknown-linux-gnu (64-bit)

locale:
[1] C

attached base packages:
[1] grid      parallel  stats     graphics  grDevices utils     datasets
[8] methods   base

other attached packages:
 [1] ncdf4_1.13          smwrBase_1.0.1      lubridate_1.3.3
 [4] digest_0.6.8        memoise_0.2.1       gridExtra_0.9.1
 [7] spdep_0.5-82        Matrix_1.1-4        fields_7.1
[10] maps_2.3-9          spam_1.0-1          doSNOW_1.0.12
[13] snow_0.3-13         doMC_1.3.3          iterators_1.0.7
[16] foreach_1.4.2       ipred_0.9-3         MASS_7.3-37
[19] RColorBrewer_1.1-2  rgdal_0.9-1         stringr_0.6.2
[22] ggplot2_1.0.0       plyr_1.8.1          reshape2_1.4.1
[25] raster_2.3-12       sp_1.0-17           ProjectTemplate_0.6

loaded via a namespace (and not attached):
 [1] LearnBayes_2.15  Rcpp_0.11.3      boot_1.3-13      class_7.3-11
 [5] coda_0.16-1      codetools_0.2-9  colorspace_1.2-4 deldir_0.1-7
 [9] gtable_0.1.2     lattice_0.20-29  lava_1.3         munsell_0.4.2
[13] nlme_3.1-118     nnet_7.3-8       prodlim_1.5.1    proto_0.3-10
[17] rpart_4.1-8      scales_0.2.4     splines_3.1.2    survival_2.37-7
Reply | Threaded
Open this post in threaded view
|

Re: inconsistent as.data.frame(SpatialPointsDF)

Frede Aakmann Tøgersen-2
Hi Dominik

The as.data.frame() function called on an object of class SpatialPointsDataFrame will subsequently call the as.data.frame.SpatialPointsDataFrame() function. That function do not alter any columns names in any circumstances.

What you have seen (I'm of course guessing here) will probably be because of some previously made objects with columns names x and y for coordinates masking objects that you believe have columns x and y but now in fact have column names Longitude and Latitude instead because you made some changes to your script file. This is what usually can happen when interactively developing a script in an R session where several objects have been created under the way to the final script. When launching the final script within a clean R session (no objects created yet) then it fails because some of parts of your code do not fits other parts of the script.

So if it is possible for your (meaning all needed R objects are created during execution of the script so you can safely remove all objects) then do a rm(list = ls()), which deletes all objects in current R session and then step interactively through your script file. Whenever meeting an error edit the script accordingly to change the offending part of your script.

Yours sincerely / Med venlig hilsen


Frede Aakmann Tøgersen
Specialist, M.Sc., Ph.D.
Plant Performance & Modeling

Technology & Service Solutions
T +45 9730 5135
M +45 2547 6050
[hidden email]
http://www.vestas.com

Company reg. name: Vestas Wind Systems A/S
This e-mail is subject to our e-mail disclaimer statement.
Please refer to www.vestas.com/legal/notice
If you have received this e-mail in error please contact the sender.


> -----Original Message-----
> From: R-sig-Geo [mailto:[hidden email]] On Behalf Of
> dschneiderch
> Sent: 20. marts 2015 00:03
> To: [hidden email]
> Subject: [R-sig-Geo] inconsistent as.data.frame(SpatialPointsDF)
>
> I have a spatial points dF that is causing me trouble. I've figured out what
> is happening but without a clue why.
>
> at the prompt, I do
> > locs
> class       : SpatialPointsDataFrame
> features    : 10
> extent      : -112.0623, -109.0571, 33.65387, 36.32678  (xmin, xmax, ymin,
> ymax)
> coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
> variables   : 7
> names       : network, State, Station_ID, Site_ID,        Site_Name,
> Elevation_ft, Elevation_m
> min values  :    SNTL,    AZ,     09N05S,     308,      BAKER BUTTE,
> 7100,        2164
> max values  :    SNTL,    AZ,     12P01S,    1143, HANNAGAN MEADOWS,
> 9200,        2804
>
> > head(as.data.frame(locs))
>           x        y network State Station_ID Site_ID       Site_Name
> 1 -111.4064 34.45660    SNTL    AZ     11R06S     308     BAKER BUTTE
> 2 -111.3827 34.45547    SNTL    AZ     11R07S    1140 BAKER BUTTE SMT
> 3 -109.5034 33.97883    SNTL    AZ     09S01S     310           BALDY
> 4 -109.2166 33.69144    SNTL    AZ     09S06S     902     BEAVER HEAD
> 5 -109.0571 36.32678    SNTL    AZ     09N05S    1143   BEAVER SPRING
> 6 -112.0623 35.26247    SNTL    AZ     12P01S    1139       CHALENDER
>   Elevation_ft Elevation_m
> 1         7300        2225
> 2         7700        2347
> 3         9125        2781
> 4         7990        2435
> 5         9200        2804
> 6         7100        2164
>
> so as expected(?) my coordinate names get converted from Longitude,
> Latitude
> to x, y.
>
> However, when I run my script, the output of head(as.data.frame(locs)) is:
>     Longitude   Latitude network State Station_ID Site_ID       Site_Name
> 1 -111.4064 34.45660    SNTL    AZ     11R06S     308     BAKER BUTTE
> 2 -111.3827 34.45547    SNTL    AZ     11R07S    1140 BAKER BUTTE SMT
> 3 -109.5034 33.97883    SNTL    AZ     09S01S     310           BALDY
> 4 -109.2166 33.69144    SNTL    AZ     09S06S     902     BEAVER HEAD
> 5 -109.0571 36.32678    SNTL    AZ     09N05S    1143   BEAVER SPRING
> 6 -112.0623 35.26247    SNTL    AZ     12P01S    1139       CHALENDER
>   Elevation_ft Elevation_m
> 1         7300        2225
> 2         7700        2347
> 3         9125        2781
> 4         7990        2435
> 5         9200        2804
> 6         7100        2164
>
>
> I found out the hard way because i was doing
> as.data.frame(locs)[,c('x','y')] to get the coordinates.... I switched this
> line to coordinates(locs) but I have other lines in the same code that use
> as.data.frame() so I'm wondering if there are designed circumstance for one
> behavior compared to the other.  I did notice that
> data.frame(locs)[,c('x','y')] seems to always maintain the original
> coordinate names but I confirmed that the script uses as.data.frame()
>
> Below is dput of a sample of my data. does anyone else get this behavior?
>
> > dput(locs)
> new("SpatialPointsDataFrame"
>     , data = structure(list(network = c("SNTL", "SNTL", "SNTL", "SNTL",
> "SNTL",
> "SNTL", "SNTL", "SNTL", "SNTL", "SNTL"), State = c("AZ", "AZ",
> "AZ", "AZ", "AZ", "AZ", "AZ", "AZ", "AZ", "AZ"), Station_ID = c("11R06S",
> "11R07S", "09S01S", "09S06S", "09N05S", "12P01S", "09S07S", "11P02S",
> "11P13S", "09S11S"), Site_ID = c(308L, 1140L, 310L, 902L, 1143L,
> 1139L, 416L, 1121L, 488L, 511L), Site_Name = c("BAKER BUTTE",
> "BAKER BUTTE SMT", "BALDY", "BEAVER HEAD", "BEAVER SPRING",
> "CHALENDER",
> "CORONADO TRAIL", "FORT VALLEY", "FRY", "HANNAGAN MEADOWS"),
>     Elevation_ft = c(7300L, 7700L, 9125L, 7990L, 9200L, 7100L,
>     8400L, 7350L, 7200L, 9020L), Elevation_m = c(2225L, 2347L,
>     2781L, 2435L, 2804L, 2164L, 2560L, 2240L, 2195L, 2749L)), .Names =
> c("network",
> "State", "Station_ID", "Site_ID", "Site_Name", "Elevation_ft",
> "Elevation_m"), row.names = 63:72, class = "data.frame")
>     , coords.nrs = c(7L, 6L)
>     , coords = structure(c(-111.40643, -111.38272, -109.50344, -109.21657,
> -109.05711,
> -112.06231, -109.15282, -111.74486, -111.84374, -109.30952, 34.4566,
> 34.45547, 33.97883, 33.69144, 36.32678, 35.26247, 33.80392, 35.26806,
> 35.07297, 33.65387), .Dim = c(10L, 2L), .Dimnames = list(NULL,
>     c("Longitude", "Latitude")))
>     , bbox = structure(c(-112.06231, 33.65387, -109.05711, 36.32678), .Dim =
> c(2L,
> 2L), .Dimnames = list(c("Longitude", "Latitude"), c("min", "max"
> )))
>     , proj4string = new("CRS"
>     , projargs = "+proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0"
> )
> )
>
>
> This is running on a cluster at my university, using a SOCK cluster to
> parallelize dlply and then an MC backend for a ddply inside the dlply, if
> that's important. It seems to produce the expected behavior of my desktop.
> > sessionInfo()
> R version 3.1.2 (2014-10-31)
> Platform: x86_64-unknown-linux-gnu (64-bit)
>
> locale:
> [1] C
>
> attached base packages:
> [1] grid      parallel  stats     graphics  grDevices utils     datasets
> [8] methods   base
>
> other attached packages:
>  [1] ncdf4_1.13          smwrBase_1.0.1      lubridate_1.3.3
>  [4] digest_0.6.8        memoise_0.2.1       gridExtra_0.9.1
>  [7] spdep_0.5-82        Matrix_1.1-4        fields_7.1
> [10] maps_2.3-9          spam_1.0-1          doSNOW_1.0.12
> [13] snow_0.3-13         doMC_1.3.3          iterators_1.0.7
> [16] foreach_1.4.2       ipred_0.9-3         MASS_7.3-37
> [19] RColorBrewer_1.1-2  rgdal_0.9-1         stringr_0.6.2
> [22] ggplot2_1.0.0       plyr_1.8.1          reshape2_1.4.1
> [25] raster_2.3-12       sp_1.0-17           ProjectTemplate_0.6
>
> loaded via a namespace (and not attached):
>  [1] LearnBayes_2.15  Rcpp_0.11.3      boot_1.3-13      class_7.3-11
>  [5] coda_0.16-1      codetools_0.2-9  colorspace_1.2-4 deldir_0.1-7
>  [9] gtable_0.1.2     lattice_0.20-29  lava_1.3         munsell_0.4.2
> [13] nlme_3.1-118     nnet_7.3-8       prodlim_1.5.1    proto_0.3-10
> [17] rpart_4.1-8      scales_0.2.4     splines_3.1.2    survival_2.37-7
>
>
>
> --
> View this message in context: http://r-sig-
> geo.2731867.n2.nabble.com/inconsistent-as-data-frame-SpatialPointsDF-
> tp7587920.html
> Sent from the R-sig-geo mailing list archive at Nabble.com.
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Reply | Threaded
Open this post in threaded view
|

Re: inconsistent as.data.frame(SpatialPointsDF)

MacQueen, Don
In reply to this post by dschneiderch
In my experience, relying on column names to extract the coordinates is
not at all a good idea. I would strongly recommend that you take the time
to update all of your scripts to use the coordinates() function. I think
it will be worth it in the long run.

It's not a good idea because the column names of the coordinates depend on
how the SpatialPointsDataFrame was originally created, and in my own
applications that is highly variable.  Sometimes ('x','y'), sometimes
('lon','lat'), or any of several other variations of how to spell or
abbreviate latitude and longitude (with or without capitalization). Or
('easting','northing'). Or, or, or... Trying to carefully control all that
is more trouble than it's worth; I just use, for example,
coordinates(obj)[,1] and coordinates(obj)[,2] if I want to pull them out
as vectors. Ugly, but I can count on it.

That said, if
  as.data.frame(locs)
produces different names for the coordinates when used in different
contexts, then you've got something else going on that should not be going
on. This is where Frede's suggestions might help. You will need to
carefully track the construction of your locs object and see if it is
somehow different in the two situations. I don't know of any "designed
circumstance" that would explain this.

-Don

--
Don MacQueen

Lawrence Livermore National Laboratory
7000 East Ave., L-627
Livermore, CA 94550
925-423-1062





On 3/19/15, 4:02 PM, "dschneiderch" <[hidden email]> wrote:

>I have a spatial points dF that is causing me trouble. I've figured out
>what
>is happening but without a clue why.
>
>at the prompt, I do
>> locs
>class       : SpatialPointsDataFrame
>features    : 10
>extent      : -112.0623, -109.0571, 33.65387, 36.32678  (xmin, xmax, ymin,
>ymax)
>coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
>variables   : 7
>names       : network, State, Station_ID, Site_ID,        Site_Name,
>Elevation_ft, Elevation_m
>min values  :    SNTL,    AZ,     09N05S,     308,      BAKER BUTTE,
>  
>7100,        2164
>max values  :    SNTL,    AZ,     12P01S,    1143, HANNAGAN MEADOWS,
>  
>9200,        2804
>
>> head(as.data.frame(locs))
>          x        y network State Station_ID Site_ID       Site_Name
>1 -111.4064 34.45660    SNTL    AZ     11R06S     308     BAKER BUTTE
>2 -111.3827 34.45547    SNTL    AZ     11R07S    1140 BAKER BUTTE SMT
>3 -109.5034 33.97883    SNTL    AZ     09S01S     310           BALDY
>4 -109.2166 33.69144    SNTL    AZ     09S06S     902     BEAVER HEAD
>5 -109.0571 36.32678    SNTL    AZ     09N05S    1143   BEAVER SPRING
>6 -112.0623 35.26247    SNTL    AZ     12P01S    1139       CHALENDER
>  Elevation_ft Elevation_m
>1         7300        2225
>2         7700        2347
>3         9125        2781
>4         7990        2435
>5         9200        2804
>6         7100        2164
>
>so as expected(?) my coordinate names get converted from Longitude,
>Latitude
>to x, y.
>
>However, when I run my script, the output of head(as.data.frame(locs)) is:
>    Longitude   Latitude network State Station_ID Site_ID       Site_Name
>1 -111.4064 34.45660    SNTL    AZ     11R06S     308     BAKER BUTTE
>2 -111.3827 34.45547    SNTL    AZ     11R07S    1140 BAKER BUTTE SMT
>3 -109.5034 33.97883    SNTL    AZ     09S01S     310           BALDY
>4 -109.2166 33.69144    SNTL    AZ     09S06S     902     BEAVER HEAD
>5 -109.0571 36.32678    SNTL    AZ     09N05S    1143   BEAVER SPRING
>6 -112.0623 35.26247    SNTL    AZ     12P01S    1139       CHALENDER
>  Elevation_ft Elevation_m
>1         7300        2225
>2         7700        2347
>3         9125        2781
>4         7990        2435
>5         9200        2804
>6         7100        2164
>
>
>I found out the hard way because i was doing
>as.data.frame(locs)[,c('x','y')] to get the coordinates.... I switched
>this
>line to coordinates(locs) but I have other lines in the same code that use
>as.data.frame() so I'm wondering if there are designed circumstance for
>one
>behavior compared to the other.  I did notice that
>data.frame(locs)[,c('x','y')] seems to always maintain the original
>coordinate names but I confirmed that the script uses as.data.frame()
>
>Below is dput of a sample of my data. does anyone else get this behavior?
>
>> dput(locs)
>new("SpatialPointsDataFrame"
>    , data = structure(list(network = c("SNTL", "SNTL", "SNTL", "SNTL",
>"SNTL",
>"SNTL", "SNTL", "SNTL", "SNTL", "SNTL"), State = c("AZ", "AZ",
>"AZ", "AZ", "AZ", "AZ", "AZ", "AZ", "AZ", "AZ"), Station_ID = c("11R06S",
>"11R07S", "09S01S", "09S06S", "09N05S", "12P01S", "09S07S", "11P02S",
>"11P13S", "09S11S"), Site_ID = c(308L, 1140L, 310L, 902L, 1143L,
>1139L, 416L, 1121L, 488L, 511L), Site_Name = c("BAKER BUTTE",
>"BAKER BUTTE SMT", "BALDY", "BEAVER HEAD", "BEAVER SPRING", "CHALENDER",
>"CORONADO TRAIL", "FORT VALLEY", "FRY", "HANNAGAN MEADOWS"),
>    Elevation_ft = c(7300L, 7700L, 9125L, 7990L, 9200L, 7100L,
>    8400L, 7350L, 7200L, 9020L), Elevation_m = c(2225L, 2347L,
>    2781L, 2435L, 2804L, 2164L, 2560L, 2240L, 2195L, 2749L)), .Names =
>c("network",
>"State", "Station_ID", "Site_ID", "Site_Name", "Elevation_ft",
>"Elevation_m"), row.names = 63:72, class = "data.frame")
>    , coords.nrs = c(7L, 6L)
>    , coords = structure(c(-111.40643, -111.38272, -109.50344, -109.21657,
>-109.05711,
>-112.06231, -109.15282, -111.74486, -111.84374, -109.30952, 34.4566,
>34.45547, 33.97883, 33.69144, 36.32678, 35.26247, 33.80392, 35.26806,
>35.07297, 33.65387), .Dim = c(10L, 2L), .Dimnames = list(NULL,
>    c("Longitude", "Latitude")))
>    , bbox = structure(c(-112.06231, 33.65387, -109.05711, 36.32678),
>.Dim =
>c(2L,
>2L), .Dimnames = list(c("Longitude", "Latitude"), c("min", "max"
>)))
>    , proj4string = new("CRS"
>    , projargs = "+proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0"
>)
>)
>
>
>This is running on a cluster at my university, using a SOCK cluster to
>parallelize dlply and then an MC backend for a ddply inside the dlply, if
>that's important. It seems to produce the expected behavior of my desktop.
>> sessionInfo()
>R version 3.1.2 (2014-10-31)
>Platform: x86_64-unknown-linux-gnu (64-bit)
>
>locale:
>[1] C
>
>attached base packages:
>[1] grid      parallel  stats     graphics  grDevices utils     datasets
>[8] methods   base
>
>other attached packages:
> [1] ncdf4_1.13          smwrBase_1.0.1      lubridate_1.3.3
> [4] digest_0.6.8        memoise_0.2.1       gridExtra_0.9.1
> [7] spdep_0.5-82        Matrix_1.1-4        fields_7.1
>[10] maps_2.3-9          spam_1.0-1          doSNOW_1.0.12
>[13] snow_0.3-13         doMC_1.3.3          iterators_1.0.7
>[16] foreach_1.4.2       ipred_0.9-3         MASS_7.3-37
>[19] RColorBrewer_1.1-2  rgdal_0.9-1         stringr_0.6.2
>[22] ggplot2_1.0.0       plyr_1.8.1          reshape2_1.4.1
>[25] raster_2.3-12       sp_1.0-17           ProjectTemplate_0.6
>
>loaded via a namespace (and not attached):
> [1] LearnBayes_2.15  Rcpp_0.11.3      boot_1.3-13      class_7.3-11
> [5] coda_0.16-1      codetools_0.2-9  colorspace_1.2-4 deldir_0.1-7
> [9] gtable_0.1.2     lattice_0.20-29  lava_1.3         munsell_0.4.2
>[13] nlme_3.1-118     nnet_7.3-8       prodlim_1.5.1    proto_0.3-10
>[17] rpart_4.1-8      scales_0.2.4     splines_3.1.2    survival_2.37-7
>
>
>
>--
>View this message in context:
>http://r-sig-geo.2731867.n2.nabble.com/inconsistent-as-data-frame-SpatialP
>ointsDF-tp7587920.html
>Sent from the R-sig-geo mailing list archive at Nabble.com.
>
>_______________________________________________
>R-sig-Geo mailing list
>[hidden email]
>https://stat.ethz.ch/mailman/listinfo/r-sig-geo

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Reply | Threaded
Open this post in threaded view
|

Re: inconsistent as.data.frame(SpatialPointsDF)

edzer
There is some logic: sp tries to track coordinate names when it can, but
if coordinates are set as a nameless matrix, as in the last example
below, it will choose names itself. coordnames() helps you discover how
the coordinates of a SpatialPointsDataFrame are called:

> df = data.frame(x=1:2, y=2:1, z = 3:4)
> df1 = df
> library(sp)
> coordinates(df1) = ~x+y
> as.data.frame(df1)
  x y z
1 1 2 3
2 2 1 4
> coordnames(df1)
[1] "x" "y"
> df1=df
> coordinates(df1) = df[1:2]
> coordnames(df1)
[1] "x" "y"
> df1=df
> coordinates(df1) = cbind(df$x,df$y) # nameless
> df1
  coordinates x y z
1      (1, 2) 1 2 3
2      (2, 1) 2 1 4
> coordnames(df1)
[1] "coords.x1" "coords.x2"


a bit of a semantic trap is this: if your coordinates are longitude and
latitude and carry these names, after you project the object with
rgdal::spTransform they're still called longitude and latitude, although
they are no longer understood as such. You can then solve this yourself by

> coordnames(df1) = c("x", "y")

after which

> coordnames(df1)
[1] "x" "y"


On 03/20/2015 05:01 PM, MacQueen, Don wrote:

> In my experience, relying on column names to extract the coordinates is
> not at all a good idea. I would strongly recommend that you take the time
> to update all of your scripts to use the coordinates() function. I think
> it will be worth it in the long run.
>
> It's not a good idea because the column names of the coordinates depend on
> how the SpatialPointsDataFrame was originally created, and in my own
> applications that is highly variable.  Sometimes ('x','y'), sometimes
> ('lon','lat'), or any of several other variations of how to spell or
> abbreviate latitude and longitude (with or without capitalization). Or
> ('easting','northing'). Or, or, or... Trying to carefully control all that
> is more trouble than it's worth; I just use, for example,
> coordinates(obj)[,1] and coordinates(obj)[,2] if I want to pull them out
> as vectors. Ugly, but I can count on it.
>
> That said, if
>   as.data.frame(locs)
> produces different names for the coordinates when used in different
> contexts, then you've got something else going on that should not be going
> on. This is where Frede's suggestions might help. You will need to
> carefully track the construction of your locs object and see if it is
> somehow different in the two situations. I don't know of any "designed
> circumstance" that would explain this.
>
> -Don
>
--
Edzer Pebesma
Institute for Geoinformatics (ifgi),  University of Münster,
Heisenbergstraße 2, 48149 Münster, Germany; +49 251 83 33081
Journal of Statistical Software:   http://www.jstatsoft.org/
Computers & Geosciences:   http://elsevier.com/locate/cageo/
Spatial Statistics Society http://www.spatialstatistics.info


_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

signature.asc (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: inconsistent as.data.frame(SpatialPointsDF)

dschneiderch
In reply to this post by MacQueen, Don
Hi -
Thanks for your replies.
I should have mentioned, I made sure to test this with a clean workspace before posting and confirmed the behavior this morning. it sounds like the names of the coordinates should never change?
another example of the names being converted at the prompt from Longitude, Latitude to x,y.
> library('ProjectTemplate')
> load.project() #since i'm loading the data from a cached .rdata file, it is always the same to begin. please excuse the slightly different variable names. locs = snotellocs[1:10,]
... bunch of packages loading ... and cached data loading ...
> head(str(snotellocs))
Formal class 'SpatialPointsDataFrame' [package "sp"] with 5 slots
  ..@ data       :'data.frame': 315 obs. of  7 variables:
  .. ..$ network     : chr [1:315] "SNTL" "SNTL" "SNTL" "SNTL" ...
  .. ..$ State       : chr [1:315] "AZ" "AZ" "AZ" "AZ" ...
  .. ..$ Station_ID  : chr [1:315] "11R06S" "11R07S" "09S01S" "09S06S" ...
  .. ..$ Site_ID     : int [1:315] 308 1140 310 902 1143 1139 416 1121 488 511 ...
  .. ..$ Site_Name   : chr [1:315] "BAKER BUTTE" "BAKER BUTTE SMT" "BALDY" "BEAVER HEAD" ...
  .. ..$ Elevation_ft: int [1:315] 7300 7700 9125 7990 9200 7100 8400 7350 7200 9020 ...
  .. ..$ Elevation_m : int [1:315] 2225 2347 2781 2435 2804 2164 2560 2240 2195 2749 ...
  ..@ coords.nrs : int [1:2] 7 6
  ..@ coords     : num [1:315, 1:2] -111 -111 -110 -109 -109 ...
  .. ..- attr(*, "dimnames")=List of 2
  .. .. ..$ : NULL
  .. .. ..$ : chr [1:2] "Longitude" "Latitude"
  ..@ bbox       : num [1:2, 1:2] -112.2 33 -105.1 43.7
  .. ..- attr(*, "dimnames")=List of 2
  .. .. ..$ : chr [1:2] "Longitude" "Latitude"
  .. .. ..$ : chr [1:2] "min" "max"
  ..@ proj4string:Formal class 'CRS' [package "sp"] with 1 slot
  .. .. ..@ projargs: chr "+proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0"
NULL
> head(as.data.frame(snotellocs))
          x        y network State Station_ID Site_ID       Site_Name
1 -111.4064 34.45660    SNTL    AZ     11R06S     308     BAKER BUTTE
2 -111.3827 34.45547    SNTL    AZ     11R07S    1140 BAKER BUTTE SMT
3 -109.5034 33.97883    SNTL    AZ     09S01S     310           BALDY
4 -109.2166 33.69144    SNTL    AZ     09S06S     902     BEAVER HEAD
5 -109.0571 36.32678    SNTL    AZ     09N05S    1143   BEAVER SPRING
6 -112.0623 35.26247    SNTL    AZ     12P01S    1139       CHALENDER
  Elevation_ft Elevation_m
1         7300        2225
2         7700        2347
3         9125        2781
4         7990        2435
5         9200        2804
6         7100        2164


> sessionInfo()
R version 3.1.2 (2014-10-31)
Platform: x86_64-unknown-linux-gnu (64-bit)

locale:
[1] C

attached base packages:
[1] grid      parallel  stats     graphics  grDevices utils     datasets
[8] methods   base

other attached packages:
 [1] ncdf4_1.13          smwrBase_1.0.1      lubridate_1.3.3
 [4] digest_0.6.8        memoise_0.2.1       gridExtra_0.9.1
 [7] spdep_0.5-82        Matrix_1.1-4        fields_7.1
[10] maps_2.3-9          spam_1.0-1          doSNOW_1.0.12
[13] snow_0.3-13         doMC_1.3.3          iterators_1.0.7
[16] foreach_1.4.2       ipred_0.9-3         MASS_7.3-37
[19] RColorBrewer_1.1-2  rgdal_0.9-1         stringr_0.6.2
[22] ggplot2_1.0.0       plyr_1.8.1          reshape2_1.4.1
[25] raster_2.3-12       sp_1.0-17           ProjectTemplate_0.6

loaded via a namespace (and not attached):
 [1] LearnBayes_2.15  Rcpp_0.11.3      boot_1.3-13      class_7.3-11
 [5] coda_0.16-1      codetools_0.2-9  colorspace_1.2-4 deldir_0.1-7
 [9] gtable_0.1.2     lattice_0.20-29  lava_1.3         munsell_0.4.2
[13] nlme_3.1-118     nnet_7.3-8       prodlim_1.5.1    proto_0.3-10
[17] rpart_4.1-8      scales_0.2.4     splines_3.1.2    survival_2.37-7
Reply | Threaded
Open this post in threaded view
|

Re: inconsistent as.data.frame(SpatialPointsDF)

dschneiderch
In reply to this post by edzer
Edzer - Look like we posted at the same time.
In my example my coordinates are named, no?

I tried your example in my R environment and can replicate the behavior I mentioned.

> df = data.frame(x=1:2, y=2:1, z = 3:4)
> df1 = df
> library(sp)
> coordinates(df1) = ~x+y
> as.data.frame(df1)
  x y z
1 1 2 3
2 2 1 4
> coordnames(df1)
[1] "x" "y"
> coordnames(df1)=c('long','lat')
> str(df1)
Formal class 'SpatialPointsDataFrame' [package "sp"] with 5 slots
  ..@ data       :'data.frame': 2 obs. of  1 variable:
  .. ..$ z: int [1:2] 3 4
  ..@ coords.nrs : int [1:2] 1 2
  ..@ coords     : num [1:2, 1:2] 1 2 2 1
  .. ..- attr(*, "dimnames")=List of 2
  .. .. ..$ : NULL
  .. .. ..$ : chr [1:2] "long" "lat"
  ..@ bbox       : num [1:2, 1:2] 1 1 2 2
  .. ..- attr(*, "dimnames")=List of 2
  .. .. ..$ : chr [1:2] "long" "lat"
  .. .. ..$ : chr [1:2] "min" "max"
  ..@ proj4string:Formal class 'CRS' [package "sp"] with 1 slot
  .. .. ..@ projargs: chr NA
> as.data.frame(df1)
  x y z
1 1 2 3
2 2 1 4


Interestingly, when I open a new R instance and without loading all the packages associated with my project, the names are *not* converted.  So it seems that one of the packages I have loaded is conflicting with sp and causing the names to change...  my sessionInfo() was attached in the other post.
Reply | Threaded
Open this post in threaded view
|

Re: inconsistent as.data.frame(SpatialPointsDF)

MacQueen, Don
In reply to this post by edzer
Thanks, Edzer, this is helpful.

-Don


--
Don MacQueen

Lawrence Livermore National Laboratory
7000 East Ave., L-627
Livermore, CA 94550
925-423-1062





On 3/20/15, 9:28 AM, "Edzer Pebesma" <[hidden email]> wrote:

>There is some logic: sp tries to track coordinate names when it can, but
>if coordinates are set as a nameless matrix, as in the last example
>below, it will choose names itself. coordnames() helps you discover how
>the coordinates of a SpatialPointsDataFrame are called:
>
>> df = data.frame(x=1:2, y=2:1, z = 3:4)
>> df1 = df
>> library(sp)
>> coordinates(df1) = ~x+y
>> as.data.frame(df1)
>  x y z
>1 1 2 3
>2 2 1 4
>> coordnames(df1)
>[1] "x" "y"
>> df1=df
>> coordinates(df1) = df[1:2]
>> coordnames(df1)
>[1] "x" "y"
>> df1=df
>> coordinates(df1) = cbind(df$x,df$y) # nameless
>> df1
>  coordinates x y z
>1      (1, 2) 1 2 3
>2      (2, 1) 2 1 4
>> coordnames(df1)
>[1] "coords.x1" "coords.x2"
>
>
>a bit of a semantic trap is this: if your coordinates are longitude and
>latitude and carry these names, after you project the object with
>rgdal::spTransform they're still called longitude and latitude, although
>they are no longer understood as such. You can then solve this yourself by
>
>> coordnames(df1) = c("x", "y")
>
>after which
>
>> coordnames(df1)
>[1] "x" "y"
>
>
>On 03/20/2015 05:01 PM, MacQueen, Don wrote:
>> In my experience, relying on column names to extract the coordinates is
>> not at all a good idea. I would strongly recommend that you take the
>>time
>> to update all of your scripts to use the coordinates() function. I think
>> it will be worth it in the long run.
>>
>> It's not a good idea because the column names of the coordinates depend
>>on
>> how the SpatialPointsDataFrame was originally created, and in my own
>> applications that is highly variable.  Sometimes ('x','y'), sometimes
>> ('lon','lat'), or any of several other variations of how to spell or
>> abbreviate latitude and longitude (with or without capitalization). Or
>> ('easting','northing'). Or, or, or... Trying to carefully control all
>>that
>> is more trouble than it's worth; I just use, for example,
>> coordinates(obj)[,1] and coordinates(obj)[,2] if I want to pull them out
>> as vectors. Ugly, but I can count on it.
>>
>> That said, if
>>   as.data.frame(locs)
>> produces different names for the coordinates when used in different
>> contexts, then you've got something else going on that should not be
>>going
>> on. This is where Frede's suggestions might help. You will need to
>> carefully track the construction of your locs object and see if it is
>> somehow different in the two situations. I don't know of any "designed
>> circumstance" that would explain this.
>>
>> -Don
>>
>
>--
>Edzer Pebesma
>Institute for Geoinformatics (ifgi),  University of Münster,
>Heisenbergstraße 2, 48149 Münster, Germany; +49 251 83 33081
>Journal of Statistical Software:   http://www.jstatsoft.org/
>Computers & Geosciences:   http://elsevier.com/locate/cageo/
>Spatial Statistics Society http://www.spatialstatistics.info
>

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Reply | Threaded
Open this post in threaded view
|

Re: inconsistent as.data.frame(SpatialPointsDF)

dschneiderch
In reply to this post by dschneiderch
I just went through my packages, iteratively unloading each one with:
detach('package:raster')
and found that if I unload the raster package then the expected behavior of keeping the existing coordnames is achieved.

now why that differs in my script I have no idea.

> coordnames(snotellocs)
[1] "Longitude" "Latitude"
> detach('package:raster')
> head(as.data.frame(snotellocs))
  network State Station_ID Site_ID       Site_Name Latitude Longitude
1    SNTL    AZ     11R06S     308     BAKER BUTTE 34.45660 -111.4064
2    SNTL    AZ     11R07S    1140 BAKER BUTTE SMT 34.45547 -111.3827
3    SNTL    AZ     09S01S     310           BALDY 33.97883 -109.5034
4    SNTL    AZ     09S06S     902     BEAVER HEAD 33.69144 -109.2166
5    SNTL    AZ     09N05S    1143   BEAVER SPRING 36.32678 -109.0571
6    SNTL    AZ     12P01S    1139       CHALENDER 35.26247 -112.0623
  Elevation_ft Elevation_m
1         7300        2225
2         7700        2347
3         9125        2781
4         7990        2435
5         9200        2804
6         7100        2164
>

Dominik Schneider
o 303.735.6296 | c 518.956.3978 


On Fri, Mar 20, 2015 at 11:02 AM, dschneiderch [via R-sig-geo] <[hidden email]> wrote:
Edzer - Look like we posted at the same time.
In my example my coordinates are named, no?

I tried your example in my R environment and can replicate the behavior I mentioned.

> df = data.frame(x=1:2, y=2:1, z = 3:4)
> df1 = df
> library(sp)
> coordinates(df1) = ~x+y
> as.data.frame(df1)
  x y z
1 1 2 3
2 2 1 4
> coordnames(df1)
[1] "x" "y"
> coordnames(df1)=c('long','lat')
> str(df1)
Formal class 'SpatialPointsDataFrame' [package "sp"] with 5 slots
  ..@ data       :'data.frame': 2 obs. of  1 variable:
  .. ..$ z: int [1:2] 3 4
  ..@ coords.nrs : int [1:2] 1 2
  ..@ coords     : num [1:2, 1:2] 1 2 2 1
  .. ..- attr(*, "dimnames")=List of 2
  .. .. ..$ : NULL
  .. .. ..$ : chr [1:2] "long" "lat"
  ..@ bbox       : num [1:2, 1:2] 1 1 2 2
  .. ..- attr(*, "dimnames")=List of 2
  .. .. ..$ : chr [1:2] "long" "lat"
  .. .. ..$ : chr [1:2] "min" "max"
  ..@ proj4string:Formal class 'CRS' [package "sp"] with 1 slot
  .. .. ..@ projargs: chr NA
> as.data.frame(df1)
  x y z
1 1 2 3
2 2 1 4


Interestingly, when I open a new R instance and without loading all the packages associated with my project, the names are *not* converted.  So it seems that one of the packages I have loaded is conflicting with sp and causing the names to change...  my sessionInfo() was attached in the other post.



If you reply to this email, your message will be added to the discussion below:
http://r-sig-geo.2731867.n2.nabble.com/inconsistent-as-data-frame-SpatialPointsDF-tp7587920p7587929.html
To unsubscribe from inconsistent as.data.frame(SpatialPointsDF), click here.
NAML

Reply | Threaded
Open this post in threaded view
|

Re: inconsistent as.data.frame(SpatialPointsDF)

Frede Aakmann Tøgersen-2
Hi

I can reproduce this using Edzer's example. See below for output from R. Also notice the naming of the coordinate columns to "x" and "y" in the S4 method of the raster package's function as.data.frame! Isn't that quite unusual? I have maintainer on CC.

> library(sp)
> df = data.frame(Longitude=1:2, Latitude=2:1, z = 3:4)
> df1 = df
> coordinates(df1) = ~Longitude + Latitude
> as.data.frame(df1)
  Longitude Latitude z
1         1        2 3
2         2        1 4
> library(raster)
> search()
 [1] ".GlobalEnv"        "package:raster"    "package:sp"      
 [4] "ESSR"              "package:stats"     "package:graphics"
 [7] "package:grDevices" "package:utils"     "package:datasets"
[10] "package:methods"   "Autoloads"         "package:base"    
> as.data.frame(df1)
  x y z
1 1 2 3
2 2 1 4
> showMethods("as.data.frame")
Function: as.data.frame (package base)
x="ANY"
x="data.frame"
    (inherited from: x="ANY")
x="Raster"
x="SpatialLines"
x="SpatialPoints"
x="SpatialPointsDataFrame"
    (inherited from: x="SpatialPoints")
x="SpatialPolygons"

> selectMethod("as.data.frame", "SpatialPointsDataFrame")
Method Definition:

function (x, row.names = NULL, optional = FALSE, ...)
{
    .local <- function (x, row.names = NULL, optional = FALSE,
        xy = TRUE, ...)
    {
        if (!xy) {
            if (.hasSlot(x, "data")) {
                return(x@data)
            }
            else {
                return(NULL)
            }
        }
        nobj <- length(x)
        d <- coordinates(x)
        if (.hasSlot(x, "data")) {
            d <- cbind(d, x@data)
        }
        colnames(d)[1:2] <- c("x", "y")
        rownames(d) <- NULL
        as.data.frame(d, row.names = row.names, optional = optional,
            ...)
    }
    .local(x, row.names, optional, ...)
}
<bytecode: 0x000000000d037260>
<environment: namespace:raster>

Signatures:
        x                      
target  "SpatialPointsDataFrame"
defined "SpatialPoints"        
>



Yours sincerely / Med venlig hilsen


Frede Aakmann Tøgersen
Specialist, M.Sc., Ph.D.
Plant Performance & Modeling

Technology & Service Solutions
T +45 9730 5135
M +45 2547 6050
[hidden email]
http://www.vestas.com

Company reg. name: Vestas Wind Systems A/S
This e-mail is subject to our e-mail disclaimer statement.
Please refer to www.vestas.com/legal/notice
If you have received this e-mail in error please contact the sender.

> -----Original Message-----
> From: R-sig-Geo [mailto:[hidden email]] On Behalf Of
> dschneiderch
> Sent: 20. marts 2015 18:19
> To: [hidden email]
> Subject: Re: [R-sig-Geo] inconsistent as.data.frame(SpatialPointsDF)
>
> I just went through my packages, iteratively unloading each one with:
> detach('package:raster')
> and found that if I unload the raster package then the expected behavior of
> keeping the existing coordnames is achieved.
>
> now why that differs in my script I have no idea.
>
> > coordnames(snotellocs)
> [1] "Longitude" "Latitude"
> > detach('package:raster')
> > head(as.data.frame(snotellocs))
>   network State Station_ID Site_ID       Site_Name Latitude Longitude
> 1    SNTL    AZ     11R06S     308     BAKER BUTTE 34.45660 -111.4064
> 2    SNTL    AZ     11R07S    1140 BAKER BUTTE SMT 34.45547 -111.3827
> 3    SNTL    AZ     09S01S     310           BALDY 33.97883 -109.5034
> 4    SNTL    AZ     09S06S     902     BEAVER HEAD 33.69144 -109.2166
> 5    SNTL    AZ     09N05S    1143   BEAVER SPRING 36.32678 -109.0571
> 6    SNTL    AZ     12P01S    1139       CHALENDER 35.26247 -112.0623
>   Elevation_ft Elevation_m
> 1         7300        2225
> 2         7700        2347
> 3         9125        2781
> 4         7990        2435
> 5         9200        2804
> 6         7100        2164
> >
>
> Dominik Schneider
> o 303.735.6296 | c 518.956.3978
>
>
> On Fri, Mar 20, 2015 at 11:02 AM, dschneiderch [via R-sig-geo] <
> [hidden email]> wrote:
>
> > Edzer - Look like we posted at the same time.
> > In my example my coordinates are named, no?
> >
> > I tried your example in my R environment and can replicate the behavior I
> > mentioned.
> >
> > > df = data.frame(x=1:2, y=2:1, z = 3:4)
> > > df1 = df
> > > library(sp)
> > > coordinates(df1) = ~x+y
> > > as.data.frame(df1)
> >   x y z
> > 1 1 2 3
> > 2 2 1 4
> > > coordnames(df1)
> > [1] "x" "y"
> > > coordnames(df1)=c('long','lat')
> > > str(df1)
> > Formal class 'SpatialPointsDataFrame' [package "sp"] with 5 slots
> >   ..@ data       :'data.frame': 2 obs. of  1 variable:
> >   .. ..$ z: int [1:2] 3 4
> >   ..@ coords.nrs : int [1:2] 1 2
> >   ..@ coords     : num [1:2, 1:2] 1 2 2 1
> >   .. ..- attr(*, "dimnames")=List of 2
> >   .. .. ..$ : NULL
> >   .. .. ..$ : chr [1:2] "long" "lat"
> >   ..@ bbox       : num [1:2, 1:2] 1 1 2 2
> >   .. ..- attr(*, "dimnames")=List of 2
> >   .. .. ..$ : chr [1:2] "long" "lat"
> >   .. .. ..$ : chr [1:2] "min" "max"
> >   ..@ proj4string:Formal class 'CRS' [package "sp"] with 1 slot
> >   .. .. ..@ projargs: chr NA
> > > as.data.frame(df1)
> >   x y z
> > 1 1 2 3
> > 2 2 1 4
> >
> >
> > Interestingly, when I open a new R instance and without loading all the
> > packages associated with my project, the names are *not* converted.  So it
> > seems that one of the packages I have loaded is conflicting with sp and
> > causing the names to change...  my sessionInfo() was attached in the other
> > post.
> >
> >
> > ------------------------------
> >  If you reply to this email, your message will be added to the discussion
> > below:
> >
> > http://r-sig-geo.2731867.n2.nabble.com/inconsistent-as-data-frame-
> SpatialPointsDF-tp7587920p7587929.html
> >  To unsubscribe from inconsistent as.data.frame(SpatialPointsDF), click
> > here
> > <http://r-sig-
> geo.2731867.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_
> by_code&node=7587920&code=RG9taW5pay5TY2huZWlkZXJAY29sb3JhZG8u
> ZWR1fDc1ODc5MjB8LTEwMzMyMTA1OQ==>
> > .
> > NAML
> > <http://r-sig-
> geo.2731867.n2.nabble.com/template/NamlServlet.jtp?macro=macro_view
> er&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespac
> es.BasicNamespace-nabble.view.web.template.NabbleNamespace-
> nabble.naml.namespaces.BasicNamespace-
> nabble.view.web.template.NabbleNamespace-
> nabble.naml.namespaces.BasicNamespace-
> nabble.view.web.template.NabbleNamespace-
> nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscrib
> ers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-
> send_instant_email%21nabble%3Aemail.naml>
> >
>
>
>
>
> --
> View this message in context: http://r-sig-
> geo.2731867.n2.nabble.com/inconsistent-as-data-frame-SpatialPointsDF-
> tp7587920p7587931.html
> Sent from the R-sig-geo mailing list archive at Nabble.com.
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Reply | Threaded
Open this post in threaded view
|

Re: inconsistent as.data.frame(SpatialPointsDF)

Robert Hijmans
The raster package 'enhances' as.data.frame for SpatialLines* and
SpatialPolygons*. I am not sure why there is also a function for
SpatialPoints* as it does not add anything, except for setting the
names to 'x' and 'y'. Perhaps that is what I did it for, I cannot
remember. But clearly it is not desirable to get different results
depending on when raster is loaded or not, so I have removed it. Sorry
for causing trouble.
Robert

On Fri, Mar 20, 2015 at 11:39 AM, Frede Aakmann Tøgersen
<[hidden email]> wrote:

> Hi
>
> I can reproduce this using Edzer's example. See below for output from R. Also notice the naming of the coordinate columns to "x" and "y" in the S4 method of the raster package's function as.data.frame! Isn't that quite unusual? I have maintainer on CC.
>
>> library(sp)
>> df = data.frame(Longitude=1:2, Latitude=2:1, z = 3:4)
>> df1 = df
>> coordinates(df1) = ~Longitude + Latitude
>> as.data.frame(df1)
>   Longitude Latitude z
> 1         1        2 3
> 2         2        1 4
>> library(raster)
>> search()
>  [1] ".GlobalEnv"        "package:raster"    "package:sp"
>  [4] "ESSR"              "package:stats"     "package:graphics"
>  [7] "package:grDevices" "package:utils"     "package:datasets"
> [10] "package:methods"   "Autoloads"         "package:base"
>> as.data.frame(df1)
>   x y z
> 1 1 2 3
> 2 2 1 4
>> showMethods("as.data.frame")
> Function: as.data.frame (package base)
> x="ANY"
> x="data.frame"
>     (inherited from: x="ANY")
> x="Raster"
> x="SpatialLines"
> x="SpatialPoints"
> x="SpatialPointsDataFrame"
>     (inherited from: x="SpatialPoints")
> x="SpatialPolygons"
>
>> selectMethod("as.data.frame", "SpatialPointsDataFrame")
> Method Definition:
>
> function (x, row.names = NULL, optional = FALSE, ...)
> {
>     .local <- function (x, row.names = NULL, optional = FALSE,
>         xy = TRUE, ...)
>     {
>         if (!xy) {
>             if (.hasSlot(x, "data")) {
>                 return(x@data)
>             }
>             else {
>                 return(NULL)
>             }
>         }
>         nobj <- length(x)
>         d <- coordinates(x)
>         if (.hasSlot(x, "data")) {
>             d <- cbind(d, x@data)
>         }
>         colnames(d)[1:2] <- c("x", "y")
>         rownames(d) <- NULL
>         as.data.frame(d, row.names = row.names, optional = optional,
>             ...)
>     }
>     .local(x, row.names, optional, ...)
> }
> <bytecode: 0x000000000d037260>
> <environment: namespace:raster>
>
> Signatures:
>         x
> target  "SpatialPointsDataFrame"
> defined "SpatialPoints"
>>
>
>
>
> Yours sincerely / Med venlig hilsen
>
>
> Frede Aakmann Tøgersen
> Specialist, M.Sc., Ph.D.
> Plant Performance & Modeling
>
> Technology & Service Solutions
> T +45 9730 5135
> M +45 2547 6050
> [hidden email]
> http://www.vestas.com
>
> Company reg. name: Vestas Wind Systems A/S
> This e-mail is subject to our e-mail disclaimer statement.
> Please refer to www.vestas.com/legal/notice
> If you have received this e-mail in error please contact the sender.
>
>> -----Original Message-----
>> From: R-sig-Geo [mailto:[hidden email]] On Behalf Of
>> dschneiderch
>> Sent: 20. marts 2015 18:19
>> To: [hidden email]
>> Subject: Re: [R-sig-Geo] inconsistent as.data.frame(SpatialPointsDF)
>>
>> I just went through my packages, iteratively unloading each one with:
>> detach('package:raster')
>> and found that if I unload the raster package then the expected behavior of
>> keeping the existing coordnames is achieved.
>>
>> now why that differs in my script I have no idea.
>>
>> > coordnames(snotellocs)
>> [1] "Longitude" "Latitude"
>> > detach('package:raster')
>> > head(as.data.frame(snotellocs))
>>   network State Station_ID Site_ID       Site_Name Latitude Longitude
>> 1    SNTL    AZ     11R06S     308     BAKER BUTTE 34.45660 -111.4064
>> 2    SNTL    AZ     11R07S    1140 BAKER BUTTE SMT 34.45547 -111.3827
>> 3    SNTL    AZ     09S01S     310           BALDY 33.97883 -109.5034
>> 4    SNTL    AZ     09S06S     902     BEAVER HEAD 33.69144 -109.2166
>> 5    SNTL    AZ     09N05S    1143   BEAVER SPRING 36.32678 -109.0571
>> 6    SNTL    AZ     12P01S    1139       CHALENDER 35.26247 -112.0623
>>   Elevation_ft Elevation_m
>> 1         7300        2225
>> 2         7700        2347
>> 3         9125        2781
>> 4         7990        2435
>> 5         9200        2804
>> 6         7100        2164
>> >
>>
>> Dominik Schneider
>> o 303.735.6296 | c 518.956.3978
>>
>>
>> On Fri, Mar 20, 2015 at 11:02 AM, dschneiderch [via R-sig-geo] <
>> [hidden email]> wrote:
>>
>> > Edzer - Look like we posted at the same time.
>> > In my example my coordinates are named, no?
>> >
>> > I tried your example in my R environment and can replicate the behavior I
>> > mentioned.
>> >
>> > > df = data.frame(x=1:2, y=2:1, z = 3:4)
>> > > df1 = df
>> > > library(sp)
>> > > coordinates(df1) = ~x+y
>> > > as.data.frame(df1)
>> >   x y z
>> > 1 1 2 3
>> > 2 2 1 4
>> > > coordnames(df1)
>> > [1] "x" "y"
>> > > coordnames(df1)=c('long','lat')
>> > > str(df1)
>> > Formal class 'SpatialPointsDataFrame' [package "sp"] with 5 slots
>> >   ..@ data       :'data.frame': 2 obs. of  1 variable:
>> >   .. ..$ z: int [1:2] 3 4
>> >   ..@ coords.nrs : int [1:2] 1 2
>> >   ..@ coords     : num [1:2, 1:2] 1 2 2 1
>> >   .. ..- attr(*, "dimnames")=List of 2
>> >   .. .. ..$ : NULL
>> >   .. .. ..$ : chr [1:2] "long" "lat"
>> >   ..@ bbox       : num [1:2, 1:2] 1 1 2 2
>> >   .. ..- attr(*, "dimnames")=List of 2
>> >   .. .. ..$ : chr [1:2] "long" "lat"
>> >   .. .. ..$ : chr [1:2] "min" "max"
>> >   ..@ proj4string:Formal class 'CRS' [package "sp"] with 1 slot
>> >   .. .. ..@ projargs: chr NA
>> > > as.data.frame(df1)
>> >   x y z
>> > 1 1 2 3
>> > 2 2 1 4
>> >
>> >
>> > Interestingly, when I open a new R instance and without loading all the
>> > packages associated with my project, the names are *not* converted.  So it
>> > seems that one of the packages I have loaded is conflicting with sp and
>> > causing the names to change...  my sessionInfo() was attached in the other
>> > post.
>> >
>> >
>> > ------------------------------
>> >  If you reply to this email, your message will be added to the discussion
>> > below:
>> >
>> > http://r-sig-geo.2731867.n2.nabble.com/inconsistent-as-data-frame-
>> SpatialPointsDF-tp7587920p7587929.html
>> >  To unsubscribe from inconsistent as.data.frame(SpatialPointsDF), click
>> > here
>> > <http://r-sig-
>> geo.2731867.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_
>> by_code&node=7587920&code=RG9taW5pay5TY2huZWlkZXJAY29sb3JhZG8u
>> ZWR1fDc1ODc5MjB8LTEwMzMyMTA1OQ==>
>> > .
>> > NAML
>> > <http://r-sig-
>> geo.2731867.n2.nabble.com/template/NamlServlet.jtp?macro=macro_view
>> er&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespac
>> es.BasicNamespace-nabble.view.web.template.NabbleNamespace-
>> nabble.naml.namespaces.BasicNamespace-
>> nabble.view.web.template.NabbleNamespace-
>> nabble.naml.namespaces.BasicNamespace-
>> nabble.view.web.template.NabbleNamespace-
>> nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscrib
>> ers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-
>> send_instant_email%21nabble%3Aemail.naml>
>> >
>>
>>
>>
>>
>> --
>> View this message in context: http://r-sig-
>> geo.2731867.n2.nabble.com/inconsistent-as-data-frame-SpatialPointsDF-
>> tp7587920p7587931.html
>> Sent from the R-sig-geo mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> R-sig-Geo mailing list
>> [hidden email]
>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Reply | Threaded
Open this post in threaded view
|

Re: inconsistent as.data.frame(SpatialPointsDF)

dschneiderch
Thanks for the update.
FWIW, I actually liked the behavior of changing coordinate names to x and y
when converting out of geographic coordinates to projected coordinates. and
vice versa would be convenient but I will make a habit of using
coordinates() and coordnames() instead.
ds


Dominik Schneider
o 303.735.6296 | c 518.956.3978


On Fri, Mar 20, 2015 at 1:39 PM, Robert J. Hijmans <[hidden email]>
wrote:

> The raster package 'enhances' as.data.frame for SpatialLines* and
> SpatialPolygons*. I am not sure why there is also a function for
> SpatialPoints* as it does not add anything, except for setting the
> names to 'x' and 'y'. Perhaps that is what I did it for, I cannot
> remember. But clearly it is not desirable to get different results
> depending on when raster is loaded or not, so I have removed it. Sorry
> for causing trouble.
> Robert
>
> On Fri, Mar 20, 2015 at 11:39 AM, Frede Aakmann Tøgersen
> <[hidden email]> wrote:
> > Hi
> >
> > I can reproduce this using Edzer's example. See below for output from R.
> Also notice the naming of the coordinate columns to "x" and "y" in the S4
> method of the raster package's function as.data.frame! Isn't that quite
> unusual? I have maintainer on CC.
> >
> >> library(sp)
> >> df = data.frame(Longitude=1:2, Latitude=2:1, z = 3:4)
> >> df1 = df
> >> coordinates(df1) = ~Longitude + Latitude
> >> as.data.frame(df1)
> >   Longitude Latitude z
> > 1         1        2 3
> > 2         2        1 4
> >> library(raster)
> >> search()
> >  [1] ".GlobalEnv"        "package:raster"    "package:sp"
> >  [4] "ESSR"              "package:stats"     "package:graphics"
> >  [7] "package:grDevices" "package:utils"     "package:datasets"
> > [10] "package:methods"   "Autoloads"         "package:base"
> >> as.data.frame(df1)
> >   x y z
> > 1 1 2 3
> > 2 2 1 4
> >> showMethods("as.data.frame")
> > Function: as.data.frame (package base)
> > x="ANY"
> > x="data.frame"
> >     (inherited from: x="ANY")
> > x="Raster"
> > x="SpatialLines"
> > x="SpatialPoints"
> > x="SpatialPointsDataFrame"
> >     (inherited from: x="SpatialPoints")
> > x="SpatialPolygons"
> >
> >> selectMethod("as.data.frame", "SpatialPointsDataFrame")
> > Method Definition:
> >
> > function (x, row.names = NULL, optional = FALSE, ...)
> > {
> >     .local <- function (x, row.names = NULL, optional = FALSE,
> >         xy = TRUE, ...)
> >     {
> >         if (!xy) {
> >             if (.hasSlot(x, "data")) {
> >                 return(x@data)
> >             }
> >             else {
> >                 return(NULL)
> >             }
> >         }
> >         nobj <- length(x)
> >         d <- coordinates(x)
> >         if (.hasSlot(x, "data")) {
> >             d <- cbind(d, x@data)
> >         }
> >         colnames(d)[1:2] <- c("x", "y")
> >         rownames(d) <- NULL
> >         as.data.frame(d, row.names = row.names, optional = optional,
> >             ...)
> >     }
> >     .local(x, row.names, optional, ...)
> > }
> > <bytecode: 0x000000000d037260>
> > <environment: namespace:raster>
> >
> > Signatures:
> >         x
> > target  "SpatialPointsDataFrame"
> > defined "SpatialPoints"
> >>
> >
> >
> >
> > Yours sincerely / Med venlig hilsen
> >
> >
> > Frede Aakmann Tøgersen
> > Specialist, M.Sc., Ph.D.
> > Plant Performance & Modeling
> >
> > Technology & Service Solutions
> > T +45 9730 5135
> > M +45 2547 6050
> > [hidden email]
> > http://www.vestas.com
> >
> > Company reg. name: Vestas Wind Systems A/S
> > This e-mail is subject to our e-mail disclaimer statement.
> > Please refer to www.vestas.com/legal/notice
> > If you have received this e-mail in error please contact the sender.
> >
> >> -----Original Message-----
> >> From: R-sig-Geo [mailto:[hidden email]] On Behalf Of
> >> dschneiderch
> >> Sent: 20. marts 2015 18:19
> >> To: [hidden email]
> >> Subject: Re: [R-sig-Geo] inconsistent as.data.frame(SpatialPointsDF)
> >>
> >> I just went through my packages, iteratively unloading each one with:
> >> detach('package:raster')
> >> and found that if I unload the raster package then the expected
> behavior of
> >> keeping the existing coordnames is achieved.
> >>
> >> now why that differs in my script I have no idea.
> >>
> >> > coordnames(snotellocs)
> >> [1] "Longitude" "Latitude"
> >> > detach('package:raster')
> >> > head(as.data.frame(snotellocs))
> >>   network State Station_ID Site_ID       Site_Name Latitude Longitude
> >> 1    SNTL    AZ     11R06S     308     BAKER BUTTE 34.45660 -111.4064
> >> 2    SNTL    AZ     11R07S    1140 BAKER BUTTE SMT 34.45547 -111.3827
> >> 3    SNTL    AZ     09S01S     310           BALDY 33.97883 -109.5034
> >> 4    SNTL    AZ     09S06S     902     BEAVER HEAD 33.69144 -109.2166
> >> 5    SNTL    AZ     09N05S    1143   BEAVER SPRING 36.32678 -109.0571
> >> 6    SNTL    AZ     12P01S    1139       CHALENDER 35.26247 -112.0623
> >>   Elevation_ft Elevation_m
> >> 1         7300        2225
> >> 2         7700        2347
> >> 3         9125        2781
> >> 4         7990        2435
> >> 5         9200        2804
> >> 6         7100        2164
> >> >
> >>
> >> Dominik Schneider
> >> o 303.735.6296 | c 518.956.3978
> >>
> >>
> >> On Fri, Mar 20, 2015 at 11:02 AM, dschneiderch [via R-sig-geo] <
> >> [hidden email]> wrote:
> >>
> >> > Edzer - Look like we posted at the same time.
> >> > In my example my coordinates are named, no?
> >> >
> >> > I tried your example in my R environment and can replicate the
> behavior I
> >> > mentioned.
> >> >
> >> > > df = data.frame(x=1:2, y=2:1, z = 3:4)
> >> > > df1 = df
> >> > > library(sp)
> >> > > coordinates(df1) = ~x+y
> >> > > as.data.frame(df1)
> >> >   x y z
> >> > 1 1 2 3
> >> > 2 2 1 4
> >> > > coordnames(df1)
> >> > [1] "x" "y"
> >> > > coordnames(df1)=c('long','lat')
> >> > > str(df1)
> >> > Formal class 'SpatialPointsDataFrame' [package "sp"] with 5 slots
> >> >   ..@ data       :'data.frame': 2 obs. of  1 variable:
> >> >   .. ..$ z: int [1:2] 3 4
> >> >   ..@ coords.nrs : int [1:2] 1 2
> >> >   ..@ coords     : num [1:2, 1:2] 1 2 2 1
> >> >   .. ..- attr(*, "dimnames")=List of 2
> >> >   .. .. ..$ : NULL
> >> >   .. .. ..$ : chr [1:2] "long" "lat"
> >> >   ..@ bbox       : num [1:2, 1:2] 1 1 2 2
> >> >   .. ..- attr(*, "dimnames")=List of 2
> >> >   .. .. ..$ : chr [1:2] "long" "lat"
> >> >   .. .. ..$ : chr [1:2] "min" "max"
> >> >   ..@ proj4string:Formal class 'CRS' [package "sp"] with 1 slot
> >> >   .. .. ..@ projargs: chr NA
> >> > > as.data.frame(df1)
> >> >   x y z
> >> > 1 1 2 3
> >> > 2 2 1 4
> >> >
> >> >
> >> > Interestingly, when I open a new R instance and without loading all
> the
> >> > packages associated with my project, the names are *not* converted.
> So it
> >> > seems that one of the packages I have loaded is conflicting with sp
> and
> >> > causing the names to change...  my sessionInfo() was attached in the
> other
> >> > post.
> >> >
> >> >
> >> > ------------------------------
> >> >  If you reply to this email, your message will be added to the
> discussion
> >> > below:
> >> >
> >> > http://r-sig-geo.2731867.n2.nabble.com/inconsistent-as-data-frame-
> >> SpatialPointsDF-tp7587920p7587929.html
> >> >  To unsubscribe from inconsistent as.data.frame(SpatialPointsDF),
> click
> >> > here
> >> > <http://r-sig-
> >> geo.2731867.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_
> >> by_code&node=7587920&code=RG9taW5pay5TY2huZWlkZXJAY29sb3JhZG8u
> >> ZWR1fDc1ODc5MjB8LTEwMzMyMTA1OQ==>
> >> > .
> >> > NAML
> >> > <http://r-sig-
> >> geo.2731867.n2.nabble.com/template/NamlServlet.jtp?macro=macro_view
> >> er&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespac
> >> es.BasicNamespace-nabble.view.web.template.NabbleNamespace-
> >> nabble.naml.namespaces.BasicNamespace-
> >> nabble.view.web.template.NabbleNamespace-
> >> nabble.naml.namespaces.BasicNamespace-
> >> nabble.view.web.template.NabbleNamespace-
> >> nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscrib
> >> ers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-
> >> send_instant_email%21nabble%3Aemail.naml>
> >> >
> >>
> >>
> >>
> >>
> >> --
> >> View this message in context: http://r-sig-
> >> geo.2731867.n2.nabble.com/inconsistent-as-data-frame-SpatialPointsDF-
> >> tp7587920p7587931.html
> >> Sent from the R-sig-geo mailing list archive at Nabble.com.
> >>
> >> _______________________________________________
> >> R-sig-Geo mailing list
> >> [hidden email]
> >> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo