Update turn penalty function to better fit some measured data.

[danpat]

This PR modifies the existing car.lua turn function to attempt to better model car turning penalties.

I went out driving and measured a bunch of turning movements:

The key observations from the sample data were:

1. We weren't penalizing 90 degree turns enough - typical values were from the 2-4 second range.
2. There is not as much bias from left-to-right as we applied.
3. Turns <45 degrees incurred relatively little penalty.
4. Traffic-control mechisms (lights, stop signs) play a big part in the cost of turns.

Our existing turn function only accepts an angle value. This PR updates the turn function (and default parameters) for the car.lua profile to attempt to get a slighly better fit. In general, turns >90 degrees should have significantly higher penalties (2x or more), and shallower angle turns should have smaller penalties. There is a left/right bias still, shallow-angle left turns (in right-driving countries) do incur an extra cost.

As can be seen on the plot above, turns that traverse intersections with traffic control (lights and stop signs) incur a higher penalty than those that do not. At this stage we don't have that data available to the turn function, so this change is incomplete.

This PR is intended as a stepping stone towards #2822 that will pass additional data to the turn function.

Tasklist

• review
• merge

[daniel-j-h]

Do we want to use the turn angles not only for penalties but also e.g. to prevent uturns at a road with high speed?

Can and should we use additional heuristics to influence the turn penalty, such as the road's width, lanes and other factors that may make a difference especially when the road is not modelled out in detail in the base map?

Can we add some Cucumber tests for this making sure the values make sense (+-) for certain turn angles? Mostly to catch regressions and to make sure this important part of the pipeline stays functional.

[danpat]

@daniel-j-h This PR is just a quick-fix - #2822 is the place to include a lot of the extra parameters you mentioned, and it requires more than just a profile change.

Doing a CucumberJS test for just this function would add the requirement of having a Lua interpreter installed - something we don't currently require (just the runtime libs). Given the limited scope of this change, I'd like to hold off investing in testing infrastructure until #2822 lands.

[willwhite]

Does this mean this function expecting input from 0 - 180? How does that reconcile with this comment about how turn angles range from 0 - 360?

Also, this comment implies that the turn function is passed negative values (e.g. turn_function(-135)).

In short, what is the range of possible values that can be passed to turn_function()?

[MoKob]

We have two different notations here. OSRM internally operates on turn angles from 0 to 360 with 180 going straight.

Now in the profile, we use -180 as u-turn to the left, 0 as going straight, 180 as u-turn to the right.