Default behaviour for setting edge weights

[luukvdmeer]

This has been discussed before, but I am reopening it in a dedicated space. For any function that involves route calculations, you can define what to use as edge weights by setting the weights argument. However, what values you may provide to this parameter and how these values are interpreted is different for igraph, sfnetworks and tidygraph... This can be very confusing.

In igraph:

weights: Possibly a numeric vector giving edge weights. If this is NULL and the graph has a weight edge attribute, then the attribute is used. If this is NA then no weights are used (even if the graph has a weight attribute).

The default value in igraph for this parameter is always NULL, meaning that the values of an edge attribute named "weight" will be used if present, and no weights will be used otherwise.

In sfnetworks we extended this behaviour by 1) allowing the name of an edge attribute column as as value given to the weights argument and 2) using the geographic length of the edges as weight if weights = NULL and there is no edge attribute column named "weight". Hence:

weights: The edge weights to be used in the shortest path calculation. Can be a numeric vector giving edge weights, or a column name referring to an attribute column in the edges table containing those weights. If set to NULL, the values of a column named weight in the edges table will be used automatically, as long as this column is present. If not, the geographic edge lengths will be calculated internally and used as weights. If set to NA, no weights are used, even if the edges have a weight column.

The default value in sfnetworks for this parameter is always NULL, meaning that the values of an edge attribute named "weight" will be used if present, and geographic edge lengths will be used otherwise. The only case in which no weights are used at all is when setting weights = NA.

Hence the behaviour of sfnetworks is similar to the behaviour of igraph, with the only difference being the geographic edge lengths as "lowest-level default" instead of using no weights at all. Which I think makes sense for spatial networks. However: tidygraph used to have the same behaviour as igraph (it just forwarded the weights parameter value to the igraph function it is wrapping), but changed this last year (see this commit). Now, it interprets weights = NULL always as "do not use any edge weights", even if there is an edge attribute named "weight". It does this intentionally in every function that has a weights parameter, by changing NULL to NA before forwarding the weights parameter value to the igraph function:

if (is.null(weights)) {
    weights <- NA
  }

I do understand the thought behind this. It is indeed somewhat confusing that weights = NULL does not mean "do not use any edge weights" in igraph. However, now it is super confusing that sfnetworks and tidygraph don't interpret the weights argument in the same way. Since sfnetworks is mainly meant to be used as a spatial network extension of tidygraph (and not in the first place of igraph) I would argue that it is more important for us to follow tidygraphs design choices instead of igraphs design choices in case they differ. For example, in the current situation, the following two lines interpret the weights argument differently:

mutate(net, x = centrality_betweenness())
st_network_paths(net, from = < point >, to = < point >)

In both cases shortest paths are calculated, and in both cases we don't explicitly set the weights argument, i.e. it uses the default value of weights = NULL. However, in the first case that means no edge weights are used, while in the second case this means the values of a weight column in the edges table are used (or geographic edge lengths whenever this column does not exist).

As an sfnetworks user you are now used to not having to explicitly set the weights argument whenever you have an edge attribute named "weight". Every time you use a tidygraph function you have to remember that in that case you do have to explicitly tell the function to use the "weight" attribute. Again, I think this is super confusing and surely will lead to mistakes at some point.

Should we also force users to explicitly tell routing functions which column to use for edge weights? Any thoughts?

[loreabad6]

Good and important point. As a first thought that pops in my head, I would say it is better for me as a user to always explicitely tell my functions what to use, so that I am in full control of what happens and why. If I set a weights= myself then I want the function to use this. If I don't set anything then I want the function to not use anything. This is from a general perspective not particular to spatial networks where some defaults might be expected. But of course, this should be discussed among other people working with spatial networks.

[agila5]

Since sfnetworks is mainly meant to be used as a spatial network extension of tidygraph (and not in the first place of igraph) I would argue that it is more important for us to follow tidygraphs design choices instead of igraphs design choices in case they differ

I love the current behaviour of sfnetworks (i.e. internally adopt geographical lengths as weights when no weight argument is explicitly set), but I agree that it might be confusing for tidygraph users. Moreover, the mutate()/st_network_paths() example that you showed is quite tricky, and I also fell into that trap.

I think we could change the existing code in our package and adopt the same approach as tidygraph. However, in that case, I would highlight this part in the NEWS file and also add a warning message (maybe until v0.7 or v1.0 and perhaps just a once-per-session warning, see rlang::warn()) to st_network_paths() and related functions since :

1. I cannot think of any situation in spatial networks analysis where you want to minimise the number of edges instead of their geographical lengths (or time/costs whatever). See also here and linked discussion.
2. The new approach will break all my existing sfnetworks code (which is not a big deal, of course), but I think new/old users may not read the package's news when updating and be really surprised to get completely different results.

[luukvdmeer]

I think we can consider keeping edge length as a default in sfnetworks shortest paths function, e.g. by

st_network_paths(weights = edge_length())

I think the core issue is not that the defaults of sfnetworks might differ from tidygraph (as long as it is clearly documented) but that the same setting weights = NULL does something different depending on if you use an sfnetworks or tidygraph function.

This does mean that the "weight" column does not get special treatment anymore (and also that the length_as_weight argument in the construction functions becomes somewhat useless and maybe even confusing). I kinda liked how that worked, but since tidygraph overwrites that igraph behaviour it is probably better to also do that. Or I could first try to let Thomas reconsider that choice and stick with the igraph behaviour, but low chances I think ;)