sp

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

sp

R-sig-geo mailing list
Dear all,I'm not very familiar with R.
I'm tying to use this code I've written months ago. At that time it was working but now it is not.
library(sp)library(spdep)example(columbus)
coord <- coordinates(columbus)and get this messageError in (function (classes, fdef, mtable)  :
  unable to find an inherited method for function ‘coordinates’ for signature ‘"sf"’I've tried to also calllibrary(sf)but got the same error.I was wondering why?Thanks a lot.Francesco



        [[alternative HTML version deleted]]

_______________________________________________
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: sp

Roger Bivand
Administrator
Please post in plain text to avoid code mangling. You have not noticed
that a lot has been happening. First, data sets from spdep have mostly
been moved to spData. Next, spData mostly uses sf to read and format data.
Finally you may also see changes as spdep model fitting functions are in
spatialreg and will shortly be dropped from spdep. In your case:

> library(sp)
> library(spdep)
Loading required package: spData
Loading required package: sf
Linking to GEOS 3.7.2, GDAL 3.0.0, PROJ 6.1.0
> example(columbus)

colmbs> columbus <- st_read(system.file("shapes/columbus.shp",
package="spData")[1], quiet=TRUE)

colmbs> col.gal.nb <- read.gal(system.file("weights/columbus.gal",
package="spData")[1])
> coord <- coordinates(columbus)
Error in (function (classes, fdef, mtable)  :
   unable to find an inherited method for function ‘coordinates’ for
signature ‘"sf"’
> columbus <- as(columbus, "Spatial")
> coord <- coordinates(columbus)

Giving the full output, you can see that example(columbus) reads in the
data and neighbours from spData, using sf. Consequently, you'd need to
coerce columbus to an sp class if you do not want to upgrade your
workflow to sf compatability.

Hope this clarifies,

Roger

On Thu, 16 May 2019, Francesco Perugini via R-sig-Geo wrote:

> Dear all,I'm not very familiar with R.
> I'm tying to use this code I've written months ago. At that time it was
> working but now it is not.
>> library(sp)
>> library(spdep)
>> example(columbus)
>> coord <- coordinates(columbus)and get this message
> Error in (function (classes, fdef, mtable)  : unable to find an
> inherited method for function ‘coordinates’ for signature ‘"sf"’
> I've tried to also calllibrary(sf)but got the same error.I was wondering
> why?
> Thanks a lot.Francesco
>
>
>
> [[alternative HTML version deleted]]
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>
--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: [hidden email]
https://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Roger Bivand
Department of Economics
Norwegian School of Economics
Helleveien 30
N-5045 Bergen, Norway
Reply | Threaded
Open this post in threaded view
|

Re: sp

R-sig-geo mailing list
 Thanks a lot for the reply Prof. Bivand. It works fine now.
Yes I did not use R since few months.I was wondering why this piece of coding left is not working:
neighbors.knn1 <- knn2nb(knearneigh(coord, 1, longlat=F), sym=F)## Global G   
dlwknn1.B <- nb2listw(neighbors.knn1, style="B", zero.policy=TRUE)
globalG.test(CRIME, dlwknn1.B, zero.policy=F)

Error: object 'CRIME' not found
Thanks again for your help.Francesco

    Il giovedì 16 maggio 2019, 15:07:37 CEST, Roger Bivand <[hidden email]> ha scritto:  
 
 Please post in plain text to avoid code mangling. You have not noticed
that a lot has been happening. First, data sets from spdep have mostly
been moved to spData. Next, spData mostly uses sf to read and format data.
Finally you may also see changes as spdep model fitting functions are in
spatialreg and will shortly be dropped from spdep. In your case:

> library(sp)
> library(spdep)
Loading required package: spData
Loading required package: sf
Linking to GEOS 3.7.2, GDAL 3.0.0, PROJ 6.1.0
> example(columbus)

colmbs> columbus <- st_read(system.file("shapes/columbus.shp",
package="spData")[1], quiet=TRUE)

colmbs> col.gal.nb <- read.gal(system.file("weights/columbus.gal",
package="spData")[1])
> coord <- coordinates(columbus)
Error in (function (classes, fdef, mtable)  :
  unable to find an inherited method for function ‘coordinates’ for
signature ‘"sf"’
> columbus <- as(columbus, "Spatial")
> coord <- coordinates(columbus)

Giving the full output, you can see that example(columbus) reads in the
data and neighbours from spData, using sf. Consequently, you'd need to
coerce columbus to an sp class if you do not want to upgrade your
workflow to sf compatability.

Hope this clarifies,

Roger

On Thu, 16 May 2019, Francesco Perugini via R-sig-Geo wrote:

> Dear all,I'm not very familiar with R.
> I'm tying to use this code I've written months ago. At that time it was
> working but now it is not.
>> library(sp)
>> library(spdep)
>> example(columbus)
>> coord <- coordinates(columbus)and get this message
> Error in (function (classes, fdef, mtable)  : unable to find an
> inherited method for function ‘coordinates’ for signature ‘"sf"’
> I've tried to also calllibrary(sf)but got the same error.I was wondering
> why?
> Thanks a lot.Francesco
>
>
>
>     [[alternative HTML version deleted]]
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: [hidden email]
https://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en 
        [[alternative HTML version deleted]]

_______________________________________________
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: sp

Roger Bivand
Administrator
On Thu, 16 May 2019, Francesco Perugini wrote:

> Thanks a lot for the reply Prof. Bivand. It works fine now. Yes I did
> not use R since few months.I was wondering why this piece of coding left
> is not working: neighbors.knn1 <- knn2nb(knearneigh(coord, 1,
> longlat=F), sym=F)## Global G dlwknn1.B <- nb2listw(neighbors.knn1,
> style="B", zero.policy=TRUE) globalG.test(CRIME, dlwknn1.B,
> zero.policy=F)

Note that HTML always mangles code. You have not shown any errors apart
from:

>
> Error: object 'CRIME' not found

which is self-evident, as ls() in your workspace will show. You would
always have needed columbus$CRIME to access CRIME.

Roger

> Thanks again for your help.Francesco
>
>    Il giovedì 16 maggio 2019, 15:07:37 CEST, Roger Bivand <[hidden email]> ha scritto:
>
> Please post in plain text to avoid code mangling. You have not noticed
> that a lot has been happening. First, data sets from spdep have mostly
> been moved to spData. Next, spData mostly uses sf to read and format data.
> Finally you may also see changes as spdep model fitting functions are in
> spatialreg and will shortly be dropped from spdep. In your case:
>
>> library(sp)
>> library(spdep)
> Loading required package: spData
> Loading required package: sf
> Linking to GEOS 3.7.2, GDAL 3.0.0, PROJ 6.1.0
>> example(columbus)
>
> colmbs> columbus <- st_read(system.file("shapes/columbus.shp",
> package="spData")[1], quiet=TRUE)
>
> colmbs> col.gal.nb <- read.gal(system.file("weights/columbus.gal",
> package="spData")[1])
>> coord <- coordinates(columbus)
> Error in (function (classes, fdef, mtable)  :
>   unable to find an inherited method for function ‘coordinates’ for
> signature ‘"sf"’
>> columbus <- as(columbus, "Spatial")
>> coord <- coordinates(columbus)
>
> Giving the full output, you can see that example(columbus) reads in the
> data and neighbours from spData, using sf. Consequently, you'd need to
> coerce columbus to an sp class if you do not want to upgrade your
> workflow to sf compatability.
>
> Hope this clarifies,
>
> Roger
>
> On Thu, 16 May 2019, Francesco Perugini via R-sig-Geo wrote:
>
>> Dear all,I'm not very familiar with R.
>> I'm tying to use this code I've written months ago. At that time it was
>> working but now it is not.
>>> library(sp)
>>> library(spdep)
>>> example(columbus)
>>> coord <- coordinates(columbus)and get this message
>> Error in (function (classes, fdef, mtable)  : unable to find an
>> inherited method for function ‘coordinates’ for signature ‘"sf"’
>> I've tried to also calllibrary(sf)but got the same error.I was wondering
>> why?
>> Thanks a lot.Francesco
>>
>>
>>
>>     [[alternative HTML version deleted]]
>>
>> _______________________________________________
>> R-sig-Geo mailing list
>> [hidden email]
>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>
>
>
--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: [hidden email]
https://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Roger Bivand
Department of Economics
Norwegian School of Economics
Helleveien 30
N-5045 Bergen, Norway
Reply | Threaded
Open this post in threaded view
|

Re: sp

R-sig-geo mailing list
 Thnaks a lot Prof. Bivand.
It works.Francesco

    Il giovedì 16 maggio 2019, 15:47:36 CEST, Roger Bivand <[hidden email]> ha scritto:  
 
 On Thu, 16 May 2019, Francesco Perugini wrote:

> Thanks a lot for the reply Prof. Bivand. It works fine now. Yes I did
> not use R since few months.I was wondering why this piece of coding left
> is not working: neighbors.knn1 <- knn2nb(knearneigh(coord, 1,
> longlat=F), sym=F)## Global G dlwknn1.B <- nb2listw(neighbors.knn1,
> style="B", zero.policy=TRUE) globalG.test(CRIME, dlwknn1.B,
> zero.policy=F)

Note that HTML always mangles code. You have not shown any errors apart
from:

>
> Error: object 'CRIME' not found

which is self-evident, as ls() in your workspace will show. You would
always have needed columbus$CRIME to access CRIME.

Roger

> Thanks again for your help.Francesco
>
>    Il giovedì 16 maggio 2019, 15:07:37 CEST, Roger Bivand <[hidden email]> ha scritto:
>
> Please post in plain text to avoid code mangling. You have not noticed
> that a lot has been happening. First, data sets from spdep have mostly
> been moved to spData. Next, spData mostly uses sf to read and format data.
> Finally you may also see changes as spdep model fitting functions are in
> spatialreg and will shortly be dropped from spdep. In your case:
>
>> library(sp)
>> library(spdep)
> Loading required package: spData
> Loading required package: sf
> Linking to GEOS 3.7.2, GDAL 3.0.0, PROJ 6.1.0
>> example(columbus)
>
> colmbs> columbus <- st_read(system.file("shapes/columbus.shp",
> package="spData")[1], quiet=TRUE)
>
> colmbs> col.gal.nb <- read.gal(system.file("weights/columbus.gal",
> package="spData")[1])
>> coord <- coordinates(columbus)
> Error in (function (classes, fdef, mtable)  :
>   unable to find an inherited method for function ‘coordinates’ for
> signature ‘"sf"’
>> columbus <- as(columbus, "Spatial")
>> coord <- coordinates(columbus)
>
> Giving the full output, you can see that example(columbus) reads in the
> data and neighbours from spData, using sf. Consequently, you'd need to
> coerce columbus to an sp class if you do not want to upgrade your
> workflow to sf compatability.
>
> Hope this clarifies,
>
> Roger
>
> On Thu, 16 May 2019, Francesco Perugini via R-sig-Geo wrote:
>
>> Dear all,I'm not very familiar with R.
>> I'm tying to use this code I've written months ago. At that time it was
>> working but now it is not.
>>> library(sp)
>>> library(spdep)
>>> example(columbus)
>>> coord <- coordinates(columbus)and get this message
>> Error in (function (classes, fdef, mtable)  : unable to find an
>> inherited method for function ‘coordinates’ for signature ‘"sf"’
>> I've tried to also calllibrary(sf)but got the same error.I was wondering
>> why?
>> Thanks a lot.Francesco
>>
>>
>>
>>     [[alternative HTML version deleted]]
>>
>> _______________________________________________
>> R-sig-Geo mailing list
>> [hidden email]
>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>
>
>

--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: [hidden email]
https://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en 
        [[alternative HTML version deleted]]

_______________________________________________
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: sp

R-sig-geo mailing list
In reply to this post by Roger Bivand
 Prof. Bivand,sorry again. I'm trying to update the coding I used.I'm now changing, as suggested, a <- readShapePoly("C:/Users/Francesco pc/Prov2011_WGS84", IDvar="COD_PRO")into
a <- readOGR("C:/Users/Francesco pc/Prov2011_WGS84", IDvar="COD_PRO")
I guess IDvar is not correct. Should that be layer="COD_PRO" ?Thanks a lotFrancesco



    Il giovedì 16 maggio 2019, 15:47:36 CEST, Roger Bivand <[hidden email]> ha scritto:  
 
 On Thu, 16 May 2019, Francesco Perugini wrote:

> Thanks a lot for the reply Prof. Bivand. It works fine now. Yes I did
> not use R since few months.I was wondering why this piece of coding left
> is not working: neighbors.knn1 <- knn2nb(knearneigh(coord, 1,
> longlat=F), sym=F)## Global G dlwknn1.B <- nb2listw(neighbors.knn1,
> style="B", zero.policy=TRUE) globalG.test(CRIME, dlwknn1.B,
> zero.policy=F)

Note that HTML always mangles code. You have not shown any errors apart
from:

>
> Error: object 'CRIME' not found

which is self-evident, as ls() in your workspace will show. You would
always have needed columbus$CRIME to access CRIME.

Roger

> Thanks again for your help.Francesco
>
>    Il giovedì 16 maggio 2019, 15:07:37 CEST, Roger Bivand <[hidden email]> ha scritto:
>
> Please post in plain text to avoid code mangling. You have not noticed
> that a lot has been happening. First, data sets from spdep have mostly
> been moved to spData. Next, spData mostly uses sf to read and format data.
> Finally you may also see changes as spdep model fitting functions are in
> spatialreg and will shortly be dropped from spdep. In your case:
>
>> library(sp)
>> library(spdep)
> Loading required package: spData
> Loading required package: sf
> Linking to GEOS 3.7.2, GDAL 3.0.0, PROJ 6.1.0
>> example(columbus)
>
> colmbs> columbus <- st_read(system.file("shapes/columbus.shp",
> package="spData")[1], quiet=TRUE)
>
> colmbs> col.gal.nb <- read.gal(system.file("weights/columbus.gal",
> package="spData")[1])
>> coord <- coordinates(columbus)
> Error in (function (classes, fdef, mtable)  :
>   unable to find an inherited method for function ‘coordinates’ for
> signature ‘"sf"’
>> columbus <- as(columbus, "Spatial")
>> coord <- coordinates(columbus)
>
> Giving the full output, you can see that example(columbus) reads in the
> data and neighbours from spData, using sf. Consequently, you'd need to
> coerce columbus to an sp class if you do not want to upgrade your
> workflow to sf compatability.
>
> Hope this clarifies,
>
> Roger
>
> On Thu, 16 May 2019, Francesco Perugini via R-sig-Geo wrote:
>
>> Dear all,I'm not very familiar with R.
>> I'm tying to use this code I've written months ago. At that time it was
>> working but now it is not.
>>> library(sp)
>>> library(spdep)
>>> example(columbus)
>>> coord <- coordinates(columbus)and get this message
>> Error in (function (classes, fdef, mtable)  : unable to find an
>> inherited method for function ‘coordinates’ for signature ‘"sf"’
>> I've tried to also calllibrary(sf)but got the same error.I was wondering
>> why?
>> Thanks a lot.Francesco
>>
>>
>>
>>     [[alternative HTML version deleted]]
>>
>> _______________________________________________
>> R-sig-Geo mailing list
>> [hidden email]
>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>
>
>

--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: [hidden email]
https://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en 
        [[alternative HTML version deleted]]

_______________________________________________
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: sp

R-sig-geo mailing list
 Hello,thanks for the suggestions. I've tried to switch to the new function readOGR() instead of the readShapePolyas follows
### Readpolygon shape files into SpatialPolygonsDataFrame objects

#a <-readShapePoly("C:/Users/Francesco pc/ Prov2011_WGS84",IDvar="COD_PRO")

a <-readOGR(dsn="C:/Users/Francesco pc/",layer="Prov2011_WGS84")
The readOGR function seems to work. However I've now some difficulties in Matching spatial dataframe and dataframe.
My code is:
quars<-  read.dta("dataset_resilience_perR.dta")         #reading file from STATA

save(quars,file = "quars.rda")

load("quars.rda")

names(quars)

attach(quars)

data.quars  <- quars

dim(data.quars)

MATCH <-match(a$COD_PRO, data.quars$codpro); MATCH

### OBJECTID

data.quars1<- data.quars[MATCH,]; dim(data.quars1)

row.names(data.quars1)<- a$COD_PRO; dim(data.quars1)

aa <-spCbind(a, data.quars1)

sample<- aa[!is.na(aa$stand),]

#

writePolyShape(sample,"sample",factor2char= TRUE)

sample<- readShapePoly("sample",IDvar="COD_PRO")

The last two coding lines must also be changed. But I get an error before that, when using the spCbind
Error in spCbind(a, data.quars1) : row names not identicalwhich I was not having before when using the readShapePoly function.Don't know why. Thanks a lot for the suggestions.Francesco





    Il giovedì 16 maggio 2019, 21:24:22 CEST, Ben Tupper <[hidden email]> ha scritto:  
 
 Hi,
This seems like a different question than your original question.  I have a couple of suggestions...
Check out ogrInfo() from the rgdal package.  It may help you understand the contents of your shape file.
Be sure that you are using the readOGR() function properly - I don't see IDvar in the help page for readOGR. 
Keeping mind that only you have the data, post this new question to the R-sig-geo list in way that helps your readers understand what you have done and what the problem is.
Best wishes,Ben

On May 16, 2019, at 1:13 PM, Francesco Perugini <[hidden email]> wrote:
 Dear Ben Tupper,sorry for the inconvinience cuased.
I've now switched into plain text. Hopefully it reads fine now.
Here again my previuos email to the forum then
___________
Prof. Bivand,sorry again. I'm trying to update the coding I used.I'm now changing, as suggested, a <- readShapePoly("C:/Users/Francesco pc/Prov2011_WGS84", IDvar="COD_PRO")into
a <- readOGR("C:/Users/Francesco pc/Prov2011_WGS84", IDvar="COD_PRO")
I guess IDvar is not correct. Should that be layer="COD_PRO" ?Thanks a lotFrancesco
___________


    Il giovedì 16 maggio 2019, 18:54:55 CEST, Ben Tupper <[hidden email]> ha scritto:  
 
 Hi Francesco,
It really would help the rest of us if you would configure your email client to send plain text, rather than rich-formatted text or HTML formatted text.  The latter two simply mess up what others, like me, see when we read your messages.  Most email clients, including Yahoo, allow you to switch.  Attached is a snapshot of my Yahoo mail - you can access the option through the "..." menu at the bottom.
Best wishes,Ben

<yahoo-plain-text.png>

On May 16, 2019, at 12:07 PM, Francesco Perugini via R-sig-Geo <[hidden email]> wrote:
Prof. Bivand,sorry again. I'm trying to update the coding I used.I'm now changing, as suggested, a <- readShapePoly("C:/Users/Francesco pc/Prov2011_WGS84", IDvar="COD_PRO")into
a <- readOGR("C:/Users/Francesco pc/Prov2011_WGS84", IDvar="COD_PRO")
I guess IDvar is not correct. Should that be layer="COD_PRO" ?Thanks a lotFrancesco



   Il giovedì 16 maggio 2019, 15:47:36 CEST, Roger Bivand <[hidden email]> ha scritto:  

On Thu, 16 May 2019, Francesco Perugini wrote:


Thanks a lot for the reply Prof. Bivand. It works fine now. Yes I did 
not use R since few months.I was wondering why this piece of coding left 
is not working: neighbors.knn1 <- knn2nb(knearneigh(coord, 1, 
longlat=F), sym=F)## Global G dlwknn1.B <- nb2listw(neighbors.knn1, 
style="B", zero.policy=TRUE) globalG.test(CRIME, dlwknn1.B, 
zero.policy=F)


Note that HTML always mangles code. You have not shown any errors apart 
from:



Error: object 'CRIME' not found


which is self-evident, as ls() in your workspace will show. You would 
always have needed columbus$CRIME to access CRIME.

Roger


Thanks again for your help.Francesco

    Il giovedì 16 maggio 2019, 15:07:37 CEST, Roger Bivand <[hidden email]> ha scritto:

Please post in plain text to avoid code mangling. You have not noticed
that a lot has been happening. First, data sets from spdep have mostly
been moved to spData. Next, spData mostly uses sf to read and format data.
Finally you may also see changes as spdep model fitting functions are in
spatialreg and will shortly be dropped from spdep. In your case:


library(sp)
library(spdep)

Loading required package: spData
Loading required package: sf
Linking to GEOS 3.7.2, GDAL 3.0.0, PROJ 6.1.0

example(columbus)


colmbs> columbus <- st_read(system.file("shapes/columbus.shp",
package="spData")[1], quiet=TRUE)

colmbs> col.gal.nb <- read.gal(system.file("weights/columbus.gal",
package="spData")[1])

coord <- coordinates(columbus)

Error in (function (classes, fdef, mtable)  :
  unable to find an inherited method for function ‘coordinates’ for
signature ‘"sf"’

columbus <- as(columbus, "Spatial")
coord <- coordinates(columbus)


Giving the full output, you can see that example(columbus) reads in the
data and neighbours from spData, using sf. Consequently, you'd need to
coerce columbus to an sp class if you do not want to upgrade your
workflow to sf compatability.

Hope this clarifies,

Roger

On Thu, 16 May 2019, Francesco Perugini via R-sig-Geo wrote:


Dear all,I'm not very familiar with R.
I'm tying to use this code I've written months ago. At that time it was
working but now it is not.

library(sp)
library(spdep)
example(columbus)
coord <- coordinates(columbus)and get this message

Error in (function (classes, fdef, mtable)  : unable to find an
inherited method for function ‘coordinates’ for signature ‘"sf"’
I've tried to also calllibrary(sf)but got the same error.I was wondering
why?
Thanks a lot.Francesco



    [[alternative HTML version deleted]]

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






-- 
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: [hidden email]
https://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en  
 [[alternative HTML version deleted]]

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

Ben Tupper
Bigelow Laboratory for Ocean Sciences
60 Bigelow Drive, P.O. Box 380
East Boothbay, Maine 04544
http://www.bigelow.org
Ecological Forecasting: https://eco.bigelow.org/




  <yahoo-plain-text.png>

Ben Tupper
Bigelow Laboratory for Ocean Sciences
60 Bigelow Drive, P.O. Box 380
East Boothbay, Maine 04544
http://www.bigelow.org
Ecological Forecasting: https://eco.bigelow.org/




 
        [[alternative HTML version deleted]]

_______________________________________________
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: sp

Roger Bivand
Administrator
In reply to this post by R-sig-geo mailing list
On Thu, 16 May 2019, Francesco Perugini wrote:

> Prof. Bivand,sorry again. I'm trying to update the coding I used.I'm now
> changing, as suggested, a <- readShapePoly("C:/Users/Francesco
> pc/Prov2011_WGS84", IDvar="COD_PRO")into

maptools::readShapePoly() has been deprecated for many years, I should
make it defunct soon (remove shapefile support completely). The IDvar=
argument was used to set the row.names of the sp object returned.

> a <- readOGR("C:/Users/Francesco pc/Prov2011_WGS84", IDvar="COD_PRO")

rgdal::readOGR cannot itself set the row.names and as you would see from
the help page, there is no such argument. So:

row.names(a) <- as.character(a$COD_PRO)

should work. In any case, all should now be moving to sf::st_read(), so:

a <- sf::st_read("C:/Users/Francesco pc/Prov2011_WGS84.shp")

should work. From there on, merge() is better supported.

Roger

> I guess IDvar is not correct. Should that be layer="COD_PRO" ?Thanks a
> lotFrancesco
>
>
>
>    Il giovedì 16 maggio 2019, 15:47:36 CEST, Roger Bivand <[hidden email]> ha scritto:
>
> On Thu, 16 May 2019, Francesco Perugini wrote:
>
>> Thanks a lot for the reply Prof. Bivand. It works fine now. Yes I did
>> not use R since few months.I was wondering why this piece of coding left
>> is not working: neighbors.knn1 <- knn2nb(knearneigh(coord, 1,
>> longlat=F), sym=F)## Global G dlwknn1.B <- nb2listw(neighbors.knn1,
>> style="B", zero.policy=TRUE) globalG.test(CRIME, dlwknn1.B,
>> zero.policy=F)
>
> Note that HTML always mangles code. You have not shown any errors apart
> from:
>
>>
>> Error: object 'CRIME' not found
>
> which is self-evident, as ls() in your workspace will show. You would
> always have needed columbus$CRIME to access CRIME.
>
> Roger
>
>> Thanks again for your help.Francesco
>>
>>     Il giovedì 16 maggio 2019, 15:07:37 CEST, Roger Bivand <[hidden email]> ha scritto:
>>
>> Please post in plain text to avoid code mangling. You have not noticed
>> that a lot has been happening. First, data sets from spdep have mostly
>> been moved to spData. Next, spData mostly uses sf to read and format data.
>> Finally you may also see changes as spdep model fitting functions are in
>> spatialreg and will shortly be dropped from spdep. In your case:
>>
>>> library(sp)
>>> library(spdep)
>> Loading required package: spData
>> Loading required package: sf
>> Linking to GEOS 3.7.2, GDAL 3.0.0, PROJ 6.1.0
>>> example(columbus)
>>
>> colmbs> columbus <- st_read(system.file("shapes/columbus.shp",
>> package="spData")[1], quiet=TRUE)
>>
>> colmbs> col.gal.nb <- read.gal(system.file("weights/columbus.gal",
>> package="spData")[1])
>>> coord <- coordinates(columbus)
>> Error in (function (classes, fdef, mtable)  :
>>   unable to find an inherited method for function ‘coordinates’ for
>> signature ‘"sf"’
>>> columbus <- as(columbus, "Spatial")
>>> coord <- coordinates(columbus)
>>
>> Giving the full output, you can see that example(columbus) reads in the
>> data and neighbours from spData, using sf. Consequently, you'd need to
>> coerce columbus to an sp class if you do not want to upgrade your
>> workflow to sf compatability.
>>
>> Hope this clarifies,
>>
>> Roger
>>
>> On Thu, 16 May 2019, Francesco Perugini via R-sig-Geo wrote:
>>
>>> Dear all,I'm not very familiar with R.
>>> I'm tying to use this code I've written months ago. At that time it was
>>> working but now it is not.
>>>> library(sp)
>>>> library(spdep)
>>>> example(columbus)
>>>> coord <- coordinates(columbus)and get this message
>>> Error in (function (classes, fdef, mtable)  : unable to find an
>>> inherited method for function ‘coordinates’ for signature ‘"sf"’
>>> I've tried to also calllibrary(sf)but got the same error.I was wondering
>>> why?
>>> Thanks a lot.Francesco
>>>
>>>
>>>
>>>     [[alternative HTML version deleted]]
>>>
>>> _______________________________________________
>>> R-sig-Geo mailing list
>>> [hidden email]
>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>>
>>
>>
>
>
--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: [hidden email]
https://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Roger Bivand
Department of Economics
Norwegian School of Economics
Helleveien 30
N-5045 Bergen, Norway
Reply | Threaded
Open this post in threaded view
|

Re: sp

Roger Bivand
Administrator
In reply to this post by R-sig-geo mailing list
On Fri, 17 May 2019, Francesco Perugini via R-sig-Geo wrote:

> Hello,thanks for the suggestions. I've tried to switch to the new function readOGR() instead of the readShapePolyas follows
> ### Readpolygon shape files into SpatialPolygonsDataFrame objects
>
> #a <-readShapePoly("C:/Users/Francesco pc/ Prov2011_WGS84",IDvar="COD_PRO")
>
> a <-readOGR(dsn="C:/Users/Francesco pc/",layer="Prov2011_WGS84")

> The readOGR function seems to work. However I've now some difficulties
> in Matching spatial dataframe and dataframe.

See my previous reply. The sf package provides better support for merging
sf objects and data.frames than sp. Do remember to eliminate your use of
shapefile functions from maptools, moving to sf instead. You'll find sf
covered well in Lovelace et al. (2019), also at:

https://geocompr.robinlovelace.net/

Also look there for left_join() and othe *_join() methods as well as
merge().

Roger


> My code is:
> quars<-  read.dta("dataset_resilience_perR.dta")         #reading file from STATA
>
> save(quars,file = "quars.rda")
>
> load("quars.rda")
>
> names(quars)
>
> attach(quars)
>
> data.quars  <- quars
>
> dim(data.quars)
>
> MATCH <-match(a$COD_PRO, data.quars$codpro); MATCH
>
> ### OBJECTID
>
> data.quars1<- data.quars[MATCH,]; dim(data.quars1)
>
> row.names(data.quars1)<- a$COD_PRO; dim(data.quars1)
>
> aa <-spCbind(a, data.quars1)
>
> sample<- aa[!is.na(aa$stand),]
>
> #
>
> writePolyShape(sample,"sample",factor2char= TRUE)
>
> sample<- readShapePoly("sample",IDvar="COD_PRO")
>
> The last two coding lines must also be changed. But I get an error
> before that, when using the spCbind Error in spCbind(a, data.quars1) :
> row names not identicalwhich I was not having before when using the
> readShapePoly function.Don't know why. Thanks a lot for the
> suggestions.Francesco
>
>
>
>
>
>    Il giovedì 16 maggio 2019, 21:24:22 CEST, Ben Tupper <[hidden email]> ha scritto:
>
> Hi,
> This seems like a different question than your original question.  I have a couple of suggestions...
> Check out ogrInfo() from the rgdal package.  It may help you understand the contents of your shape file.
> Be sure that you are using the readOGR() function properly - I don't see IDvar in the help page for readOGR. 
> Keeping mind that only you have the data, post this new question to the R-sig-geo list in way that helps your readers understand what you have done and what the problem is.
> Best wishes,Ben
>
> On May 16, 2019, at 1:13 PM, Francesco Perugini <[hidden email]> wrote:
> Dear Ben Tupper,sorry for the inconvinience cuased.
> I've now switched into plain text. Hopefully it reads fine now.
> Here again my previuos email to the forum then
> ___________
> Prof. Bivand,sorry again. I'm trying to update the coding I used.I'm now changing, as suggested, a <- readShapePoly("C:/Users/Francesco pc/Prov2011_WGS84", IDvar="COD_PRO")into
> a <- readOGR("C:/Users/Francesco pc/Prov2011_WGS84", IDvar="COD_PRO")
> I guess IDvar is not correct. Should that be layer="COD_PRO" ?Thanks a lotFrancesco
> ___________
>
>
>    Il giovedì 16 maggio 2019, 18:54:55 CEST, Ben Tupper <[hidden email]> ha scritto:
>
> Hi Francesco,
> It really would help the rest of us if you would configure your email client to send plain text, rather than rich-formatted text or HTML formatted text.  The latter two simply mess up what others, like me, see when we read your messages.  Most email clients, including Yahoo, allow you to switch.  Attached is a snapshot of my Yahoo mail - you can access the option through the "..." menu at the bottom.
> Best wishes,Ben
>
> <yahoo-plain-text.png>
>
> On May 16, 2019, at 12:07 PM, Francesco Perugini via R-sig-Geo <[hidden email]> wrote:
> Prof. Bivand,sorry again. I'm trying to update the coding I used.I'm now changing, as suggested, a <- readShapePoly("C:/Users/Francesco pc/Prov2011_WGS84", IDvar="COD_PRO")into
> a <- readOGR("C:/Users/Francesco pc/Prov2011_WGS84", IDvar="COD_PRO")
> I guess IDvar is not correct. Should that be layer="COD_PRO" ?Thanks a lotFrancesco
>
>
>
>    Il giovedì 16 maggio 2019, 15:47:36 CEST, Roger Bivand <[hidden email]> ha scritto:  
>
> On Thu, 16 May 2019, Francesco Perugini wrote:
>
>
> Thanks a lot for the reply Prof. Bivand. It works fine now. Yes I did 
> not use R since few months.I was wondering why this piece of coding left 
> is not working: neighbors.knn1 <- knn2nb(knearneigh(coord, 1, 
> longlat=F), sym=F)## Global G dlwknn1.B <- nb2listw(neighbors.knn1, 
> style="B", zero.policy=TRUE) globalG.test(CRIME, dlwknn1.B, 
> zero.policy=F)
>
>
> Note that HTML always mangles code. You have not shown any errors apart 
> from:
>
>
>
> Error: object 'CRIME' not found
>
>
> which is self-evident, as ls() in your workspace will show. You would 
> always have needed columbus$CRIME to access CRIME.
>
> Roger
>
>
> Thanks again for your help.Francesco
>
>     Il giovedì 16 maggio 2019, 15:07:37 CEST, Roger Bivand <[hidden email]> ha scritto:
>
> Please post in plain text to avoid code mangling. You have not noticed
> that a lot has been happening. First, data sets from spdep have mostly
> been moved to spData. Next, spData mostly uses sf to read and format data.
> Finally you may also see changes as spdep model fitting functions are in
> spatialreg and will shortly be dropped from spdep. In your case:
>
>
> library(sp)
> library(spdep)
>
> Loading required package: spData
> Loading required package: sf
> Linking to GEOS 3.7.2, GDAL 3.0.0, PROJ 6.1.0
>
> example(columbus)
>
>
> colmbs> columbus <- st_read(system.file("shapes/columbus.shp",
> package="spData")[1], quiet=TRUE)
>
> colmbs> col.gal.nb <- read.gal(system.file("weights/columbus.gal",
> package="spData")[1])
>
> coord <- coordinates(columbus)
>
> Error in (function (classes, fdef, mtable)  :
>   unable to find an inherited method for function ‘coordinates’ for
> signature ‘"sf"’
>
> columbus <- as(columbus, "Spatial")
> coord <- coordinates(columbus)
>
>
> Giving the full output, you can see that example(columbus) reads in the
> data and neighbours from spData, using sf. Consequently, you'd need to
> coerce columbus to an sp class if you do not want to upgrade your
> workflow to sf compatability.
>
> Hope this clarifies,
>
> Roger
>
> On Thu, 16 May 2019, Francesco Perugini via R-sig-Geo wrote:
>
>
> Dear all,I'm not very familiar with R.
> I'm tying to use this code I've written months ago. At that time it was
> working but now it is not.
>
> library(sp)
> library(spdep)
> example(columbus)
> coord <- coordinates(columbus)and get this message
>
> Error in (function (classes, fdef, mtable)  : unable to find an
> inherited method for function ‘coordinates’ for signature ‘"sf"’
> I've tried to also calllibrary(sf)but got the same error.I was wondering
> why?
> Thanks a lot.Francesco
>
>
>
>     [[alternative HTML version deleted]]
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>
>
>
>
>
>
> -- 
> Roger Bivand
> Department of Economics, Norwegian School of Economics,
> Helleveien 30, N-5045 Bergen, Norway.
> voice: +47 55 95 93 55; e-mail: [hidden email]
> https://orcid.org/0000-0003-2392-6140
> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en  
> [[alternative HTML version deleted]]
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>
> Ben Tupper
> Bigelow Laboratory for Ocean Sciences
> 60 Bigelow Drive, P.O. Box 380
> East Boothbay, Maine 04544
> http://www.bigelow.org
> Ecological Forecasting: https://eco.bigelow.org/
>
>
>
>
>  <yahoo-plain-text.png>
>
> Ben Tupper
> Bigelow Laboratory for Ocean Sciences
> 60 Bigelow Drive, P.O. Box 380
> East Boothbay, Maine 04544
> http://www.bigelow.org
> Ecological Forecasting: https://eco.bigelow.org/
>
>
>
>
>
> [[alternative HTML version deleted]]
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>
--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: [hidden email]
https://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Roger Bivand
Department of Economics
Norwegian School of Economics
Helleveien 30
N-5045 Bergen, Norway