[R-sig-Geo] Dealing with lakes and NA in Moran/SpatialPolygonsDataFrame

[Matthieu Stigler]

2009/9/5 Roger Bivand <Roger.Bivand at 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 at 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.Bivand at nhh.no
>
>