Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

marked as duplicate by underdark Apr 2 '13 at 14:31

This question was marked as an exact duplicate of an existing 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 '13 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 '13 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 '13 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 '13 at 11:49
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 '13 at 14:29

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