To local neighborhood

[agila5]

Examples:

# packages
library(tidygraph)
library(sfnetworks)

# data
roxel_sfn <- as_sfnetwork(roxel, directed = FALSE)

# plot with no weights
par(mar = rep(0, 4))
plot(roxel_sfn)
plot(convert(roxel_sfn, to_spatial_local_neighborhood, 1, 1000), col = "orange", add = TRUE)
#> Linking to GEOS 3.8.0, GDAL 3.0.4, PROJ 6.3.1
plot(convert(roxel_sfn, to_spatial_local_neighborhood, 1, 200), col = "red", add = TRUE)
plot(convert(roxel_sfn, to_spatial_local_neighborhood, 1, 1), col = "darkgreen", add = TRUE, cex = 2)

# random weights:
roxel_sfn <- roxel_sfn %>% 
  activate(edges) %>% 
  mutate(weight = rgamma(n(), shape = 3, scale = 40))

plot(roxel_sfn)
plot(convert(roxel_sfn, to_spatial_local_neighborhood, 1, 1000), col = "orange", add = TRUE)
plot(convert(roxel_sfn, to_spatial_local_neighborhood, 1, 200), col = "red", add = TRUE)
plot(convert(roxel_sfn, to_spatial_local_neighborhood, 1, 1), col = "darkgreen", add = TRUE, cex = 2)

^{Created on 2021-01-23 by the reprex package (v0.3.0)}

If you agree with the implementation, I will add tests and update the vignette.

[luukvdmeer]

Thanks a lot @agila5 for moving this forward! I have been working a lot on other morphers locally so will rather include your code in my branch than merging the PR (which will probably have quite some conflicts to solve).

Some modifications I have in mind:

• Allow to provide the node not only as a node index, but also as a sf geometry. Then this point will be snapped to its nearest node before proceeding. This workflow is already implemented in the paths calculation functions so I can simply copy that.
• Allow also to give any column name as weights. Again, this way of handling a weights argument is already implemented in the paths calculation functions and I can simply copy that.
• Allow to not only calculate neighborhoods based on distances from the central node, but also to the central node. In directed networks this may yield different results. I think it is enough to have a boolean argument for that, and depending on that argument either call tidygraph::node_distance_from or tidygraph::node_distance_to.
• As much as possible use low-level igraph functions instead of the tidygraph wrappers around them (e.g. use igraph::induced_subgraph instead of tidygraph::filter).

To stay with the tidygraph morphing design, we should also return the result as a named argument in a list.

What do you think about these modifications. I can include them in my local branch that I merge soon.

Finally, about the name of the function: do you think to_spatial_neighborhood is clear enough to be used? to_spatial_local_neighborhood is quite a long name. But not sure if it is confusing in any way to use the shorter name.

[agila5]

Hi @luukvdmeer, and thanks for your comments.

What do you think about these modifications. I can include them in my local branch that I merge soon.

I agree with all suggestions and, if you want, I can work on the existing PR tomorrow in the afternoon/evening. Feel free to ignore the PR if you plan to merge your local branch sooner.

Finally, about the name of the function: do you think to_spatial_neighborhood is clear enough to be used?

Yes, I would use to_spatial_neighborhood