Hi all!
I am using pgRouting with a road network imported via osm2pgrouting; including turn restrictions from OpenStreetMap. 
The setup works but in some urban areas; I’m noticing that the routing engine chooses routes that violate logical turn rules / produce paths that are clearly suboptimal including illegal left turns / looping around unnecessarily.
I have confirmed that the restriction data exists in the OSM source and is present in the restrictions table. I’m using pgr_trsp() with the turn restrictions enabled, but the issue seems inconsistent working fine in some parts of the city and breaking in others. 
It’s hard to tell whether the problem is with how the data was imported / with how the turn costs are being applied. Checked pgr_trsp - Proposed — pgRouting Manual (3.7) with Salesforce Admin Training guide related to this and found it very helpful.
Has anyone experienced similar behavior with pgr_trsp() or pgr_withPoints() when using OSM turn restrictions? I would really appreciate any guidance on verifying restriction logic; improving import accuracy, or alternative routing functions that better respect complex urban intersections.
Thank you !!
Hello @bevipen
I am happy to hear that someone is trying pgr_trsp.
A little bit of history about it:
The code was done during the GSoC program way back when I wasn’t even part of the pgRouting team.
Became “official” function in v2.0.0 back in 2013.
When I became member of the pgRouting team, in 2015, I noticed that the code (of all pgRouting functions) where building the graph wrong.
All the 2.x.y was to fix that on 11 routing functions.
One exception pgr_trsp.
Finally I reached a “stable point” on v3.4.0. Where by stable I mean:
- The graph is built correctly
- It runs a dijkstra and if the path contains a sub-path in the restrictions then it executes the original code.
The original code is still there.
- Has a lot of flaws. (Difficult to follow for me to answer the question: how the turn costs are being applied.)
- Does not use boost graph
- But what it can do is find a cycle
Based on this example from here:
A very simplified abstraction of that graph is:
pgr_trsp for that graph, first finds the results of dijkstra which are:
a → b → c → d → e
But the path: a → b → c is a restriction
Then the original code will find a cycle
a → b → x → y → z → b → c → d → e
Hope this explanation is good enough.
I would mention that the code could be improved. For that to happen:
- we need feedback.
- we need funding
Feedback from your part would be to send us the details of where you send the smallest possible edge table, the restrictions and the query that proves this 2 points:
- Inconsistent working fine in some parts of the city
- Breaking in others
