It is supposed that for using Shooting star function in pgrouting, we need to have RULE and TO_COST fields in our table, but OSM2PO hasn't created those fields. what must i do for OSM2PO takes into consideration the turn restrictions?
[GIS] Does OSM2PO take into consideration turn restrictions
osm2popgrouting
Related Solutions
Yes, we have just implemented a turn restricted shortest path (trsp). I think it has been checked into a git branch at origin/trsp. It is not documented yet. If you have questions or need help ask on the pgrouting list, because that is where I hangout.
-Steve
Problem with pgRouting performance seems to be that new pgr_astar and pgr_dijkstra use whole graph (which guarantees solution if there is one). Simple solution to get better performance is limit used graph to smaller area. It has it own problems like sometimes it may create graphs that cannot be solved
(SELECT ST_Expand(ST_Extent(geom_way),0.1) as box FROM hh_2po_4pgr as l1 WHERE l1.source =7 OR l1.target = 12)
Creates BBOX over source and target collection and expands it 0.1 degrees, then same query is used to limit graph size in pgr_ query
Dijkstra from 1.2s to ~65ms
SELECT seq, id1 AS node, id2 AS edge, g.geom_way as the_geom
FROM pgr_dijkstra(
'SELECT id, source, target, cost FROM hh_2po_4pgr as r,
(SELECT ST_Expand(ST_Extent(geom_way),0.1) as box FROM hh_2po_4pgr as l1 WHERE l1.source =7 OR l1.target = 12) as box
WHERE r.geom_way && box.box',
7, 12, false, false
) as r INNER JOIN hh_2po_4pgr as g ON r.id2 = g.id ;
A* from 2s to ~50ms
SELECT seq, id1 AS node, id2 AS edge, cost
FROM pgr_astar(
'SELECT id, source, target, cost, x1,y1,x2,y2 FROM hh_2po_4pgr as r,
(SELECT ST_Expand(ST_Extent(geom_way),0.1) as box FROM hh_2po_4pgr as l1 WHERE l1.source =7 OR l1.target = 12) as box
WHERE r.geom_way && box.box',
7, 12, false, false
);
osm2po was used to import data (finland-latest) into postgis table. gist index added to geom_way column and full vacuum analyze run for database. shared memory 1G . workmem 512M
Best Answer
osm2po exports data compatible with pgRouting's shortestpath and shortestpathastar. Hence turn restrictions are not directly supported. But there is a hidden feature which at least give you some more information: Have a look into the osm2po.config file and search for this line:
uncomment it by removing the "#" and osm2po will provide a second table of vertices. In this table you'll find a rather informational field called "restrictions". You'll recognize values like this one
9231, 12704, 10841, 12704 denote IDs in the network table. A minus (-) means "NoTurn" a plus (+) means "OnlyTurn" In words: Coming from Segment ID 9231 you must not turn to 12704 and coming from ID 10841 you may only turn to 12704, other combinations in this link are not allowed.
The latter is the most difficult part because you'll have to analyze the entire crossing in order to change OnlyTurns into NoTurns.
In addition these rules only refer to the corresponding vertex (table row).
You see, the only missing part is a small SQL/StoredProcedures which does this job ;-)