Closed mpadge closed 3 years ago
Nope, that's actually intentional. oneway-ness is converted to a structural part of the network through only duplicated those edges which are not oneway, and otherwise only keeping the oneway edges intact as single (not duplicated) edges.
Hi! First of all, thanks for this great package. Just wanted to note that I couldn't find info on how one-ways were handled in the documentation (for e.g. weight_streetnet) so I wasn't sure if I need to duplicate/reverse streets myself, or if that's included in the function. Having found this issue I'm now reasonably certain that I don't need to do something like this as pre-processing like I might with a package like sfnetworks:
duplicates <- roads %>% filter(oneway != 'yes' | is.na(oneway)) # to deal with one-ways correctly, I need to duplicate all the two-ways to allow directed graphs to still travel down them
reversed_duplicates <- st_reverse(duplicates)
roads_with_dup <- rbind(roads, reversed_duplicates)
but it would be really helpful to have the handling of oneways somewhere in the docs! Thanks!
Thanks for asking @nataliamush. It's an interesting question, and one that, from a technical perspective, shouldn't be necessary at all. The package is called "Distances on Directed Graphs" = DoDgr, which means that one-way links are always handled appropriately as such. But in the meantime so many equivalent options, including everything in python via osmnx and networkx, as well as any sf-based stuff in python, R, whatever, can not appropriately handle one-way links. So, from a graph-theoretic perspective, it's so implicit it doesn't need stating, but from the perspective of the current software ecosystem(s) of this kind of stuff ... I get your point.
If you can think of a good place to mention that, feel free to submit a pull request to improve the docs. Thanks!
Haha, fair! I'll look and submit a PR. Thanks again!
:bug: uncovered via #152