Skip to content
Prev 29313 / 29559 Next

spdep: new zero.policy attribute

And a question: in nb2listw() and similar functions creating spatial weights listw objects, would it be sensible to guess that the presence of no-neighbour observations in the input nb neighbour implies the choice of a spatially lagged value of zero (zero.policy=TRUE), lx = Wx, rather than NA (zero.policy=FALSE)?

That is, use by default zero.policy=any(card(nb) == 0L) rather than zero.policy=NULL and look in the spdep option set by default on package load to FALSE but settable by the user?

Would this be taking trying to be helpful too far, given that the analyst is creating the neighbour object and presumably should take responsibility for choices made?

Context: polygons not sharing boundaries with other polygons do exist legitimately in data sources, but setting spatially lagged values to zero for those polygons is quite an invasive imputation. It may be better to oblige the user to make the choice when the spatial weights listw object is created.

Little is known about the problem, for a recent treatment for CAR models see: https://arxiv.org/abs/1705.04854, published as https://doi.org/10.1016/j.sste.2018.04.002, where: "The specification of a CAR model on a disconnected graph is undefined ... [t]here are essentially two types of disconnected graphs: first, a graph containing an island (a singleton node with no neighbours), second, a graph split in different sub-graphs (each of them being a connected graph)".

This question concerns the former, singleton, case, but adding sub-graph counts if greater than unity to summary.nb and print.nb address the second . Very possibly, functions creating nb neighbour objects should themselves report that an output object (graph) is not connected, bigDM CARBayes CARBayesST geostan spatialreg stampr do call spdep::n.comp.nb themselves to check the subgraph count.

Interested in feedback,

Roger

--
Roger Bivand
Emeritus Professor
Norwegian School of Economics
Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway
Roger.Bivand at nhh.no
Message-ID: <SV0P279MB0475841DFE21EE66FBCBD252EEABA@SV0P279MB0475.NORP279.PROD.OUTLOOK.COM>
In-Reply-To: <SV0P279MB0475E88F8A0CB703080AA22EEEA4A@SV0P279MB0475.NORP279.PROD.OUTLOOK.COM>