I was using the pgrouting plugin to display the shortestpath. I used the plugin as suggested by underdark to display the shortest path in qgis.

My source node is 283 and my target node is 172. When I used the pgrouting plugin to give me the shortest path I got one as attached in the screenshot.

enter image description here

However, when I queried the database of the graph which was generated by the tool osm2po. I found only one edge which was connected to node 283.

The result of the query is given in the figure below enter image description here

My question is if you look at the results of the query, the edge is from node 279-283 and is one way as well with 283 being the target. Now since I used qgis to show the shortest path from 283-172. There is no starting from 283 as source. So my assumption was it shouldn't have shown any path. So I was wondering if there are some issues with the pgrouting plugin.

How come it gave me the shortest path when there is no edge with 283 as source? As I have explained there is only one edge connected to 283, but 283 is target and also the edge is one way from source to target.

2 Answers 2


I guess that if only one way(but high reverse_cost value(1000000)) exists, shortest path(dijkstra) function use the way although it has high reverse cost.

Could you execute following query on phppgadmin for confirmation?.

SELECT route.vertex_id, route.cost AS route_cost, m_2po_4pgr.* 
FROM m_2po_4pgr 
JOIN (SELECT * FROM shortest_path(
 'SELECT id AS id, source::int4 AS source, target::int4 AS target, 
  cost::float8 AS cost ,reverse_cost::float8 AS reverse_cost 
  FROM m_2po_4pgr ', 283,172, True, True)) AS route 
ON m_2po_4pgr.id= route.edge_id
  • +1 That's the most likely explanation. One solution would be to check if the total route costs are over 1000000. Then the route should be discarded.
    – underdark
    Jul 13, 2012 at 10:34
  • Yeah I checked the total cost as well and it is above 1000000. So isn't it a bug in pgrouting? I mean it should have shown something like route not found or not connected, something liek that
    – user31820
    Jul 13, 2012 at 11:06
  • If you want to exclude those high cost value, update reverse_cost to negative value(like "-1"). (see pgrouting.org/docs/1.x/dijkstra.html). But, in windows, server process closed unexpectedly. And it seems that old bug has not been fixed. (lists.osgeo.org/pipermail/pgrouting-users/2010-May/000304.html). So currently it may be better to discard high cost value.
    – sanak
    Jul 13, 2012 at 11:33

There might be an ambiguity issue with [has_reverse_cost] and [directed] because a directed graph does not need a reverse_cost attribute.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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