[R-sig-Geo] sp

Francesco Perugini |r@nce@co@perug|n| @end|ng |rom y@hoo@|t
Thu May 16 18:07:11 CEST 2019


 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 <Roger.Bivand using nhh.no> 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 <Roger.Bivand using nhh.no> 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
>> R-sig-Geo using r-project.org
>> 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: Roger.Bivand using nhh.no
https://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en  
	[[alternative HTML version deleted]]



More information about the R-sig-Geo mailing list