2009/9/5 Roger Bivand <roger.biv...@nhh.no>: > On Thu, 3 Sep 2009, Matthieu Stigler wrote: > >> Hi >> >> I'm puzzled hot to deal with NAs and lakes on SpatialPolygonsDataFrame >> objects... >> >> My problems (maybe should I post in separated files?): >> -spplot does not seem to handle specially NA values... >> -neighbors graph seem to make links even to lakes/holes >> -moran.test seem to work with NA values... but what about the >> neighbors/weights used as input? Are the results biased? >> -localmoran does not seem to work with NA >> >> I illustrate each of them below. >> >> >> Example is based on Syracuse data from ASDAR (data from web-site >> http://www.asdar-book.org/bundles/lat1_bundle.zip): >> #NA PROBLEM >> setwd("H:/Documents/Stats/Book Bivand/Chap 9") >> library(sp) >> library(rgdal) >> NY8 <- readOGR(".", "NY8_utm18") >> library(spdep) >> Syracuse <- NY8[NY8$AREANAME == "Syracuse city",] >> Syracuse2<-Syracuse >> Syracuse2$POP8[43]<-NA >> spplot(Syracuse2, zcol="POP8") >> #it appears as white, similar to other colors which are nevertheless >> true values and not NA! >
Thanks a lot for your help! For plotting NAs... well changing bg is a little bit radical, as everything is then different... the problem came actually because I used heat.col() which looks really pretty but uses white... isn't it a function in treillis to change only NAs and not all the rest with? Thanks! > NAs are coded "transparent", which look the same when the background is > white. In the default divergent palette, white is used. If you do: > > library(lattice) > trellis.device(bg="grey") > spplot(Syracuse2, zcol="POP8") > > (wrong way to change background but OK to show the point) or > > trellis.par.set(sp.theme()) > spplot(Syracuse2, zcol="POP8") > > where white is not in the palette. > >> >> LAKE problem: >> #check if lakes: >> sapply(sapply(slot(Syracuse, "polygons"),function(x) slot(x, >> "Polygons")), function(x) slot(x, "hole")) >> #btw, it is pretty complicated, are there some more user-friendly >> wrapers for that? kind of isHole, getHole? > > Holes are easy to fall into, so no wrappers. > >> slot(slot(slot(Syracuse2, "polygons")[[43]],"Polygons")[[1]], >> "hole")<-TRUE >> plot(poly2nb(Syracuse), coordinates(Syracuse2)) > > poly2nb() uses all the geometries present. The prefered choice is to subset > the geometries to keep only the ones the user requires, so: > > > not_holes <- !sapply(sapply(slot(Syracuse2, "polygons"),function(x) > slot(x, "Polygons")), function(x) slot(x, "hole")) > nb <- poly2nb(Syracuse2[not_holes,]) > plot(nb, coordinates(Syracuse2)[not_holes,]) > > I guess this clarifies things. In principle, a single Polygon object in a > Polygons object will not be a hole anyway (it is an external ring), so your > example is rather artificial. Subsetting the geometries with "[" is to be > prefered. Oh so for the lake, I should rather use ringDir? And when my dataset contains lakes and NAs, should I do the same as above also for Nas and then subset? Will Moran values be affected by that? Thanks a lot! > > Hope this helps, > > Roger > > I guess the same applies to your followup - but spautolm() ought not to > permit computation on missing data - I'll check this. > >> >> Here it seems that it did not take into account the hole and still >> computes neighbors... right? >> >> And if yes... does it affect the results using moran tests? >> >> Thanks a lot! >> Matthieu Stigler >> >> _______________________________________________ >> R-sig-Geo mailing list >> R-sig-Geo@stat.math.ethz.ch >> https://stat.ethz.ch/mailman/listinfo/r-sig-geo >> > > -- > Roger Bivand > Economic Geography Section, Department of Economics, Norwegian School of > Economics and Business Administration, Helleveien 30, N-5045 Bergen, > Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43 > e-mail: roger.biv...@nhh.no > > _______________________________________________ R-sig-Geo mailing list R-sig-Geo@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-geo
