I used osm2po to create a table for pgRouting. I notice a problem: for a route with dijkstra or a* the route is correct and respect the one ways. But with shooting*, it doesn't respect the one ways.

The route is from 11 baulacre geneve (46.2159082, 6.1394522) to coq inde cologny (46.2068106, 6.1919172).

Here are the queries: dijkstra/a*:

SELECT topo.id, topo.osm_name, topo.geom_way
FROM Shortest_Path('SELECT * FROM ch_2po_4pgr', 263951, 271357, true, true)
AS path, ch_2po_4pgr AS topo
WHERE path.edge_id = topo.id;


SELECT topo.id, topo.osm_name, topo.geom_way
FROM Shortest_Path_shooting_star(
   'SELECT *, geom_way as rule, reverse_cost as to_cost FROM ch_2po_4pgr', 321089, 309056, true, true)
AS path, ch_2po_4pgr AS topo
WHERE path.edge_id = topo.id;

Did you notice the same problem with shooting* in others situations?

Here is a picture. The orange line is for a*. The red line is for shooting*. Since with shooting* with use edge_id instead vertex_id, maybe the algo starts at the beginning of the way (starting point is in pink), but the problem with the one ways is in the pink circle: the red line uses the "rue des Alpes" which is a one way.

enter image description here

Thanks to all for your help!

  • from your query, it looks like reverse_cost and to_cost have the same value. Sep 7, 2011 at 12:06
  • if I set cost for to_cost, I have the same problem :s imageshack.us/f/263/costfortocost.png Sep 7, 2011 at 12:46
  • 2
    For one-way segments, it's a good idea to have a maxed-out reverse_cost assuming that the one-way segment is digitized in the same direction that the edge should be traversed. This will effectively restrict traversal in the wrong direction. There should be both a to_cost and a reverse_cost. Sep 7, 2011 at 13:13
  • I agree :) but it's strange that with the same data set, with a* it works, and with shooting* it doesn't. Anyone have a proposition to modify my query to fix the problem? Sep 7, 2011 at 13:37
  • Can you post some representative rows for bi-directional and one-way segments? I'd like to see what "Select *" is returning and the values for reverse_cost and to_cost. Sep 7, 2011 at 13:58

1 Answer 1


Just some ideas:

As far as I remember, the last two parameters mean "has_reverse_cost" and "bidirected". Don't know which one came first ;-( It means, that (if I'm not totally wrong) "true, true" expects a graph where each segment has to occur twice, except for oneways. Another reason might be the nature of the edge-based algo nature. It routes from segment to segment and not from vertex to vertex. As you have already found out, the traversing of the first edge might be a problem here.

  • The last two parameters should be "directed" and "has_reverse_cost". Setting it to "true, true" should allow it to establish direction and apply a reverse cost if the edge is traversed in the opposite direction. Here is a link to the docs (not always a great resource): pgrouting.org/docs/1.x/shooting.html Sep 7, 2011 at 13:55
  • Thank you Carsten, I join you with your second idea: the problem comes from the nature of the algo. I think that we need to use an algo on vertex based. Sep 7, 2011 at 14:00
  • sorry, I meant "directed". I'm not sure which is the correct translation but I assume it means that segments represent directed (one arrow) edges. Setting this to false means it will be traversed in both directions.
    – Carsten
    Sep 7, 2011 at 14:11

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.