Option to derive directedness from a 'oneway' column in the edges table

[luukvdmeer]

Is your feature request related to a problem? Please describe. This is a result from the ongoing discussion on what would be the best default for the directed parameter, see #50 . As proposed by @mpadge, an alternative to setting the directed parameter could be to have a oneway column in the provided edges sf object, that defines for each linestring if it can be traversed in both ways, or only from the start vertex to the end vertex. Then, a directed network can be created by duplicating and reversing those linestrings that can be traversed in both ways.

Describe the solution you'd like I have to think still about the exact implementation. For example, the as_sfnetwork.sf(sf_obj) function could have a oneway argument, which you can provide either a vector of booleans of length nrow(sf_obj), or the name of an existing column in sf_obj. When given, the edge duplication will take place as described above and the resulting network will be directed. If sf_obj object has a column named exactly oneway, this will be set automatically as oneway argument. This is similar to how igraph works in shortest path calculations. When the weights argument is NULL, no weights will be used, unless the edges have an attribute (in our case, a column) named exactly weight.

[mpadge]

Note that there is distinction between directedness and oneway-edness. Any graphs in which oneway-type labels are possible must be considered directed. dodgr can implement this because it presumes all graphs are always directed, so a simple "oneway" flag can be used. sfnetworks allows for both directed and undirected graphs, so will generally need a more sophisticated design to distinguish these two - you need to distinguish the following:

1. directed from undirected graphs
2. For directed graphs, oneway vs twoway edges, where the latter simply repeat each edge in reverse order.

I can't see an immediate way to simplify this. The simplest might be assume all networks are undirected unless they have a oneway column, and that that is always used to determine edge duplication - and i guess that is along the lines of what you're suggesting above. But that is likely not a best or optimal approach, and i suspect it might lead to unforeseen restriction of options?

[luukvdmeer]

The title of the issue is indeed not so clear, I meant to say that providing a oneway column always constructs a directed network, no matter what you have set as directed parameter (setting the oneway parameter automatically results in ignoring the directed parameter). I agree that is also not optimal, but when documented clearly maybe the best way, because I do think that also without a oneway column users should be able to create a directed network based on the from and to columns. But any other suggestions are very welcome!

[luukvdmeer]

This is not implemented (yet?) inside a function, but now clearly explained in a separate section of the network pre-processing and cleaning vignette. Think that is enough for now to close the issue.