Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

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;

shooting*:

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!

share|improve this question
    
from your query, it looks like reverse_cost and to_cost have the same value. –  Allan Adair Sep 7 '11 at 12:06
    
if I set cost for to_cost, I have the same problem :s imageshack.us/f/263/costfortocost.png –  Michaël Mathieu Sep 7 '11 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. –  Allan Adair Sep 7 '11 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? –  Michaël Mathieu Sep 7 '11 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. –  Allan Adair Sep 7 '11 at 13:58
show 3 more comments

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.

share|improve this answer
    
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 –  Allan Adair Sep 7 '11 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. –  Michaël Mathieu Sep 7 '11 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 '11 at 14:11
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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