You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am encountering incorrect shortest path solutions when using the Network.shortest_path (and Network.shortest_paths) method on a network with impedance values of small or large (though still reasonable) orders of magnitude. I have included a very simple toy example below that captures the problem. Essentially, when the impedance values are scaled to a sufficiently small order of magnitude (by experiment seems to be ~1e-4) or large order of magnitude (by experiment seems to be ~1e7), the shortest path solution is no longer correct (and, incidentally, appears to revert to a solution that traverses the least number of nodes, rather than minimizing total impedance, though my example doesn't explore this aspect of the problem).
In the second example, clearly the more expensive and incorrect route has been chosen. The same behavior is observed at the larger end of impedance values also: for example, using the above example, when the impedance values are 1e7 instead .0001, and 2e7 instead of .0002, the same behavior occurs. I'm at a loss as to why this is happening?
Thank you for your help!
The text was updated successfully, but these errors were encountered:
bonza2
changed the title
incorrect shortest paths solutions when impendance values are small
incorrect shortest paths solutions when impendance values are particularly small or large
Jul 8, 2022
I am experiencing the same issue. The returned distance between two nodes of interest is about a mile shorter than the Euclidian distance. NetworkX is able to return a distance greater than the Euclidean distance using the same network. Happy to post code and data if that helps.
Has there been any headway on this, or do we know why the calculations are coming out this way? I think I am having a similar issue, where the shortest_path_length returned is less than the sum of impedances on the sequence of edges returned by shortest_path.
I just tested the outputs by changing the unit of my impedance from minutes to seconds (there were some impedances going down to about 0.002 minutes) and it looks to be more accurate / aligned with the sum of impedances from the shortest_path output. So I guess that's an ad-hoc solution.
Description of the bug
I am encountering incorrect shortest path solutions when using the
Network.shortest_path
(andNetwork.shortest_paths
) method on a network with impedance values of small or large (though still reasonable) orders of magnitude. I have included a very simple toy example below that captures the problem. Essentially, when the impedance values are scaled to a sufficiently small order of magnitude (by experiment seems to be ~1e-4) or large order of magnitude (by experiment seems to be ~1e7), the shortest path solution is no longer correct (and, incidentally, appears to revert to a solution that traverses the least number of nodes, rather than minimizing total impedance, though my example doesn't explore this aspect of the problem).Environment
Operating system: Windows 10 Enterprise
Python version: 3.9.10
Pandana version: 0.6.1
Paste the code that reproduces the issue here:
The above example produces the expected solution.
Now, use exactly the same nodes and edges, but scale the impedance values down by a factor of 10:
In the second example, clearly the more expensive and incorrect route has been chosen. The same behavior is observed at the larger end of impedance values also: for example, using the above example, when the impedance values are 1e7 instead .0001, and 2e7 instead of .0002, the same behavior occurs. I'm at a loss as to why this is happening?
Thank you for your help!
The text was updated successfully, but these errors were encountered: