Tell me more ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.
up vote 3 down vote favorite
1

This question already has an answer here:

I've just observed something quite odd.

I have created a table with data for routing, and this table contains data for a graph over six different hour conditions. So when performing shortest_path, I select only the segments that corresponds to the "hour" column that I currently want.

I have created an index on the hour column but not on the source/target columns, and afterwards performed an analyze.

But when querying for shortest_path, I was NOT getting the shortest path, but a path where the route was lead through edges with extremely high weights (1,000,000 (created to tell not to go this way) where other weights are in the range 1-100).

After a lot of debugging (and blaming both my own graphs, pgrouting and everything else), I tried to perform a "Vacuum Analyze" on the table, and suddenly the results are correct.

So it seems like PostgreSQL had some problems that lead to pgRouting determining the wrong shortest path.

Now I ask you, if you have seen something like this before, and how to make sure this does not happen? The creation task of the graph table is automatized and I can see that analyze was actually performed after creation of the table.

share|improve this question
That should not be possible. What is possible is that your cost UPDATE was still running or data was not committed when you tested shortest_path and it used "old" data. – simplexio Feb 1 at 8:10
How did you create your routing table? If you used @assign_vertex_id@ make sure that the unit of your network (degree/meter) suits to the snapping tolerance of the function. – dkastl Feb 1 at 10:29
@simplexio: There should be no problem with "old" data - I first observered the problem yesterday, and restarted the DBMS this morning, and the problem still existed. – xcalibur666 Feb 1 at 11:46
@dkastl: I created the table using a "Create table as " script, that just creates a table with the following columns: (id, source, target, cost, reverse_cost, hour). When querying I just use the simple shortest_path from pgrouting.org/docs/foss4g2008/ch07.html and sets directed and has_reversed_cost to True. – xcalibur666 Feb 1 at 11:49

marked as duplicate by underdark♦ Apr 2 at 14:31

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

1 Answer

up vote 0 down vote accepted

I found the problem. I have some edges that are going between the same vertices, hence I run into this problem, that a random edge will be chosen, and not the "shortest" edge.

Thank you though for the time you have taken.

Why doesn't pgRouting return the best path?

share|improve this answer
Thanks for following up with an answer, please mark it as accepted. – Kirk Kuykendall Apr 2 at 14:29

Not the answer you're looking for? Browse other questions tagged or ask your own question.