Route found is not optimal.

[N40]

Issue

Abstract:

A route is obviously not optimal with regards to its arrival orientation. A obviously better routing option is not chosen.
Adding an arrival bearing or adding an additional step decreases the duration.

Example

• Case A-B: 262.6s http://router.project-osrm.org/route/v1/driving/10.92775739,49.90174097;10.90822200,49.89178000
• Case A-B-C: 233.7s http://router.project-osrm.org/route/v1/driving/10.92775739,49.90174097;10.90822200,49.89178000;10.90816281,49.89148290
• Case A-B*: 226.2s http://router.project-osrm.org/route/v1/driving/10.92775739,49.90174097;10.90822200,49.89178000?bearings=;180,30

Steps to reproduce

See Links above

Specifications

/

[jcoupey]

You're only reporting route duration values, but internally OSRM miminizes weight, which can differ from duration. The purpose of weight is to be able to apply penalties in the profile while not messing with actual travel times.

What you're seeing is that for the route you get, duration and weight are identical, while for the alternatives weight is much higher despite duration being smaller.

So it is definitely not an OSRM bug, it's more related to the weighting decisions inside the routing profile. This is what would need investigating if you think the profile can be improved in some way. Maybe worth looking closely at the debug map around that area.

[danpat]

I think the main issue here is around what to do when a point is dropped close to an intersection.

A few things are confounding each other here:

1. OSRM finds the distance to the nearest edges and sorts them by distance, and picks the nearest.
2. It doesn't care about precision - if the math says it's 0.01mm closer, it'll pick that. If there are several edges that are equi-distant, then the one picked depends on the packing order in the R-Tree that we searched, which is effectively random.
3. This coordinate looks to be dropped near an intersection - mapping precision is not in the sub-mm range.
4. It's working out that OSRM thinks it is closest to the outgoing road heading south-east.
5. By default, u-turns are not performed at waypoints in the car profile.

There are a few ways to address the problem:

1. Move the coordinate a bit so it's not so close to an ambiguous point.
2. Add continue_straight=false to your API calls (although you'll still get some funny instructions about turning left, etc along the way)
3. In theory, OSRM could do some special handling when we snap very close to the start of an edge - we could add several nearby edges as potential candidates for the destination. This old ticket kind of describes the problem and what needs to get implemented: Make route selection consistent #3991
4. If this happens to you a lot, and your routes are short, try using the /matching API instead along with the waypoints= parameter - it kind of performs the logic in (3) and you can probably get OK results.

[N40]

@jcoupey Thanks for the hint to investigate the weight

I found out that there is a 3000ish weight surplus due to a single road being entered. Here is an example where a detour an alternative detour is thus viable.

http://router.project-osrm.org/route/v1/driving/10.908039808273315,49.89198032006379;10.908088088035583,49.89192848119509

I suppose that either of

access = permissive
highway = service
vehicle = destination

is causing the penalty.

I will look into using weight='duration' as profile.

Thank you!