There’s a quirky cycle routing issue on the Clonskeagh Road when using OSRM to route which I can’t figure out by reviewing the relations, nor dragging the start/destination pointers around.
Effectively traveling from the Bird Avenue junction of Clonskeagh Road to the Beech Hill Road junction, you’ll be routed through Laburnum Rd estate, rather than the direct route of Clonskeagh Road itself. Routing engines other than OSRM do not have this issue. It’s not an issue in reverse either, nor for motorised traffic or pedestrians. Leinster Lane and Laburnum Rd aren’t even tagged as a cycle route, which makes it all more unusual!
I figure it’s related to the slip-road which is designated as the cycle-lane at Roebuck Court, but I can’t identify any issue there.
I think the default OSRM cycling profile applies a penalty to main roads without cycling infrastructure. Maybe that is enough to favour the route via residential roads over secondary roads. But I haven’t checked if it is plausible in this case.
I’m not very confident in my own guess now - I thought that Clonskeagh Road lacked cycling infrastructure northbound, but I think that was because I happened to check the tags on that short section with the slip road. It seems odd that would be enough to flip to the residential roads.
I seem to remember a debug view where you can see the speeds OSRM is assuming for each section (after weightings etc) but unfortunately both my memory and search skills are failing me just now.
That bike-lane traffic light might be part of the issue alright. Plus the routing is wrong here as only S->N cycle traffic turning onto Wynnsward Drive would need to use the left-turn and light…
I’m not sure if there is enough information in the data for a router to know that. GraphHopper and Valhalla appear to ignore that lane completely for northbound cyclists turning right - possibly OSRM gives the best outcome in that situation?
Ok, I hit up ChatGPT for an answer and got the gist of it. These are weighted turn costs per junction, a composite of:
turn_angle — the geometric change in direction, in degrees.
cost — the estimated additional time/penalty for making that turn, normally in seconds.
weight — the routing weight assigned to the turn. This is the value actually used for routing, and it can differ from duration depending on the profile.
Easiest way for me to understand it is if you look at the simplest 90-degree cross-roads junction, such as this:
The turn cost of ~4 is for a 90-degree turn which does not require crossing any lanes. The turn cost of ~8 is higher in situations where lanes need to be crossed.
Except… Why if I’m cycling in Ireland would the turn cost be higher turning left than right (as we drive on the left) - ~8.5 to turn left where it’s ~4.5 to turn right? Is that an error in assumption on behalf of the engine?
Interesting. Look at line 540 of the car profile here - it explicitly reverses the turn bias calculation for left hand drive:
But lines 760 onwards in this bicycle profile don’t seem to have any equivalent;
So it looks like OSRM itself can properly reflect driving side in turn bias calculations, if the profile is set up properly… but the default cycling profile may not do this?
I’m not sure if this explains the initial issue though… the chosen longer route has more turns, and I would have thought that if turns were the problem, the shorter route would be favoured in at least one direction.
Now I’ve spotted something which goes against my theory that the cycle routing is right-hand centric, as if that was true then turning left going S->N here (effectively crossing the road) would have a greater cost than 2 - surely?
So that got me onto looking into how “right” and “left” are used to define the cycle infrastructure either side of a road. I found this in the wiki:
The terms “right” and “left” are relative to the direction in which the way was drawn in the editor, and not necessarily the direction of real-world travel. (In the iD editor, for example, the direction is indicated by arrows at the mid-point of each segment of the way.)
So by definition a road should be initially drawn in a singular direction for the ‘left’ and ‘right’ cycle infrastructure to be consistent - except Clonskeagh Rd is not consistent in this matter…
South of the junction with Wynnsward Drive the direction arrow is pointing up/north - hence left is left:
Yeah, with hindsight we should probably have started with the basic tagging of this stretch of road, with the help of a cycling renderer (example from CyclOSM here). Some of the “messy” aspects reflect the real world, such as bus stops interrupting the cycle lanes. But there are definitely some spurious switches from east to west, and a few other suspicious-looking things. Is “cycle track” overused in general here? From the aerial images it looks like it is mostly the same kind of cycle lane on both sides.
It’s also maybe a 45 degree angle so this might be right: 6 * (45/90) * (45/90) * 1.4 = 2.1.
(It doesn’t help that the debug map itself seems to be right-hand centric, in the sense that labelling is on the “wrong” side, which might be influencing our interpretation even though they are just labels that don’t actually influence the routing).
The road is my commute to work and it’s correct in that there is a well laid-out “cycle track” protected by a curb on the left of the north-bound side, but it’s pretty much a cycle-lane on the opposite side. So the tags do match the transitions as well as they can (other than being opposite directions as we discovered).
But again (to your point) is any of this related to my original issue - who knows!
I’ll do a clean-up on this stretch and re-orientate the roads if I can, but if it ventures too far into relations then I’ll struggle. I’ll retry the routing in both directions then tomorrow once OSRM has had time to reevaluate.
Right so, I’ve sharpened the angles of the left lane turn-off at the Wynnsward Drive to try increase the cost (to encourage the routing engine to stay on the road, whether it’s related to the issue or not).
I also corrected or updated much of Clonskeagh Rd to reflect the existing state of the cycle lanes, and orientated much of it northwards. There were a few mistakes alright, but again - not sure it’s related!
):
