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.biv...@nhh.no

________________________________________
From: R-sig-Geo <r-sig-geo-boun...@r-project.org> on behalf of Roger Bivand 
<roger.biv...@nhh.no>
Sent: 04 November 2023 18:53
To: r-sig-geo@r-project.org
Subject: [R-sig-Geo] spdep: new zero.policy attribute

In forthcoming spdep 1.3-1, spatial weight listw objects get a new zero.policy 
attribute. The attribute is added as objects are created to record the status 
of the zero.policy argument in the function creating the object, see: 
https://github.com/r-spatial/spdep/commit/e159de922c61713529a4075b0dfc2966eb8f9ad6.

Reverse dependency checks only show problems from over-eager unit testing in 
SpatialFeatureExperiment, a Bioconductor package, but other workflows may be 
impacted. The new attribute is used in tests for spatial autocorrelation to set 
the zero.policy argument in those tests (the arguments were zero.policy=NULL, 
are now zero.policy=attr(listw, "zero.policy") where listw is the spatial 
weights object argument to the test function.

This will be extended to spatialreg and friends if nobody reports negative 
impacts here soon. I'll wait before releasing 1.3-1 for a few days to see if 
any feedback is forthcoming.

Hope this long-overdue change is helpful,

Roger

--
Roger Bivand
Emeritus Professor
Norwegian School of Economics
Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway
roger.biv...@nhh.no
_______________________________________________
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

_______________________________________________
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Reply via email to