changes to `nb` objects and use of `spdep::n.comp.nb`

[Roger Bivand]

In r-spatial/spdep#160 and r-spatial/spdep#161, changes are made to the use of n.comp.nb. It seems now more important to move checks of the possible existence of disjoint subgraphs to the creation and modification of nb neighbour objects, adding these to the nb object at creation or modification in spdep. This means that separate checking may be carried out on the "ncomp" attribute of an nb object from spdep version >= 1.3-6 (branch n_comp until r-spatial/spdep#161 is merged).

geostan uses n.comp.nb in: R/convenience-functions.R, so for larger and/or denser neighbour objects will benefit from the upcoming changes.

[Connor Donegan]

Thanks for the notification Roger.

I've read through the discussion on the spdep github page. From what I gather, the following will still be okay:

 class(G) <- "Graph"
 nb2 <- spdep::n.comp.nb(spdep::graph2nb(G))

I'm using the comp.id values returned by n.comp.nb, so I (currently) plan to keep this as is unless I'm missing something.

Thanks again

[Roger Bivand]

At
https://github.com/r-spatial/spdep/blob/a0a7d030ff836c396e80d61a30a26ae477d62433/R/graph2nb.R#L35-L39
spdep::graph2nb already creates the object returned by spdep::n.comp.nb if the default is followed and if the sum of the number of nodes and the number of edges is less than 100000, in the development version of spdep, so:

class(G) <- "Graph"
G1 <- spdep::graph2nb(G)
nb2 <- attr(G1, "ncomp")
if (is.null(nb2)) {
  nb2 <- spdep::n.comp.nb(G1)
}

The underlying problem was that for largish node counts and very dense neighbour sets, spdep::n.comp.nb could run for an unexpectedly long time, and that the subgraph count was recently added to the print.nb method.

[Connor Donegan]

I see, great! Thanks, I'll use that