Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exploration of routing libraries #51

Merged
merged 25 commits into from
Jan 31, 2023
Merged

Conversation

tomalrussell
Copy link
Member

Merging to record this exploration - may remove and leave in history rather than dangling PR.

  • pandana has an interesting algorithm, slightly more involved to use
  • igraph source-to-sink runs well
  • slight discrepancy in the path that's found with this test data

@tomalrussell tomalrussell merged commit bdb491b into master Jan 31, 2023
@tomalrussell tomalrussell deleted the i21_source_sinks_routing branch January 31, 2023 12:54
@szhorvat
Copy link
Contributor

szhorvat commented Jan 31, 2023

igraph developer here. I just noticed this and wanted to encourage you to give feedback regarding igraph's shortest path finding functionality. We try to make the library useful for practical work, so knowing what our users are doing is important.

Note that the igraph C library has some shortest path-related features implemented that are not yet exposed in Python, but could easily be exposed in the next version if requested. Examples include the A* shortest path algorithm, which will perform very well for single source to single target problems in spatial networks; Yen's algorithm for finding the $k$ shortest paths; a special version of the Floyd-Warshall algorithm that is likely to be the fastest solution in very dense graphs; as well as a widest path finder.

  • slight discrepancy in the path that's found with this test data

Between some node pairs, there may be more than one shortest path. Several libraries, including igraph, have functions that can find all shortest paths.

When the graph is weighted, and the weights are high-precision numbers, multiple shortest paths are unlikely to occur. But suppose that weight (length) values are rounded to a few decimals, e.g. given as multiple of 0.1 km. Then a route made of segments of lengths 0.2 and 0.6, and a route with segments of length 0.1 and 0.7 would have the same length, 0.8. However, due to the nature of floating point calculations, you can try in Python that 0.1+0.7 == 0.2+0.6 is false and 0.1+0.7 < 0.2+0.6 is true. igraph uses comparisons with tolerances internally and is able to find both of these shortest paths. As far as I know, igraph is unique in having this capability.

@tomalrussell
Copy link
Member Author

Thanks for the notes, @szhorvat much appreciated ☺️

Points well taken about multiple shortest paths, floating point precision and tolerance.

I'll have a think about the other features you mention.

The main use case we have is to find shortest paths between a subset of nodes in a network for various kinds of transport flow assignment - not quite all-pairs, so a bunch of calls to single-source-shortest-paths with a set of targets seems to be a reasonable solution.

The single a-to-b query is often useful too - yes, I'd expect A* to be pretty good, and bidirectional Dijsktra/A* maybe worth looking into.

Last time I was looking into this I had some notes on other more specialised algorithm/data structure combinations - UDST/pandana#120 (comment) - from a little reading around on transport routing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants