Driving Distance vs AStar Path issue #52
Milestone
Comments
|
Here is how to test this under pgr2.0: |
|
|
|
I must have fixed this when making other changes, because I have verified that both are generating the same results now. Closing. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Samuel Schembri reports on 2012-01-16:
I used pgrouting 1.02 on postgres 8.2.17. At this time, I can't update Postgresql.
There is a different comportment between 'shortest_path_astar' and 'driving_distance' functions when I use reverse_cost column.
Here are graphe conditions :
shortest_path_astar:
has_reverse_cost = false :
Edges with 'cost=-1' are forbiden and Pgrouting don't used them. 'Reverse_cost' information is not used.
has_reverse_cost = true:
Edges with 'cost=-1' are used if 'reserve_cost' is more than 0. Cost used by pgrouting is 'reserve_cost' column.
Edges with 'reverse_cost=-1' are used if 'cost' is more than 0. Cost used by pgrouting is 'cost' column.
T his computing is correct.
Driving_distance:
has_reverse_cost = false :
Edges with 'cost=-1' are forbiden and Pgrouting don't used them. 'Reverse_cost' information is not used.
has_reverse_cost = true :
Case one : Edge with 'cost=-1' and 'reverse_cost=length':
Edge can be traveled on digitalisation way ( cost =-1!!). Cost used by pgrouting is 'Reverse_cost' column.
Case two : Edge with cost=length and reverse_cost=-1:
Edge can be traveled on inverse digitalisation way. More, Cost used by pgrouting is 'cost' column.
In this two case, pgrouting don't respect restrictions. This computing is not correct.
Why I would like to used this method. I prefer driving-distance functions because when we must compute a lot of distances with same departure point, this method is more fast than 'shortest_path_astar' method. After, I can get distance with nodes directly.
Example : get distance between shop and 100 customers.
I can create little graphe ,function, and snapshot.
This is zip file with:
http://imaptools.com:8080/dl/pgRouting-bug52.zip
*Bug1.png You can see :
To go to vertex(48) since vertex (540), pgrouting is doing good choice because the edge (2: gid 51) has a big cost value . Full distance is 1159 meters.
*Bug2.png You can see :
To go to vertex(48) since vertex(540), pgrouting takes the edge (2) with big cost value and he used reverse_cost value to calculate full distance.
Distance vertex must be egal to 1159.
*Dump with my graphe . (create a tif1104 schema before import)
Query:
The text was updated successfully, but these errors were encountered: