Pass additional variables to turn_function

[danpat]

This PR is to address #1735, and hopefully make turn penalties better by considering the approach/exit speeds for each turn. As pointed out on #1735, doing a u-turn on a 70mph (112km/h) road should be super expensive. On the car profile, currently we only penalize this turn by 3.3 seconds, and most 60km/h 90 degree turns are penalized by ~0.8 to ~1.2 (left vs right, depending on the bias).

This turn penalty calculation only occurs during osrm-extract, this PR will not include a mechanism to adjust the turn penalty if traffic data updates are used in osrm-contract.

My plan is to update the turn_function for the car.lua profile only. Other profiles are probably a bit less affected by this, although @emiltin, any thoughts you have on how this might apply to the bike turn penalty would be appreciated.

Tasklist

• Test coverage
• Do some test driving to get some better values for the car profile
• Do some test riding?
• review
• adjust for for comments

References

http://nacto.org/docs/usdg/effect_of_radius_of_curvature_for_right_turning_vehicles_wolfe.pdf
http://onlinepubs.trb.org/onlinepubs/conferences/2011/RSS/3/Wolfermann,A.pdf
http://www.istiee.org/te/papers/N55/ET_2013_55_1_Mehar.pdf

Other useful factors

#592

[TheMarex]

Few notes here:

• the current implementation breaks the API and would require a major version bump. (not sure how lua feels about optional arguments but that could be an answer)
• keep in mind [Not ready] Weight edges #1614 modfies the signature of turn_function drastically

[danpat]

@TheMarex AFAIK, Lua has no concept of function overloading, so the following works:

$ lua5.1
Lua 5.1.5  Copyright (C) 1994-2012 Lua.org, PUC-Rio
> function test(a)
>>   print "hello"
>> end
> test(1,2)
hello

The additional arguments passed by luabind to the function should just be ignored by older profiles that don't implement them. This should only require be a backward-compatible minor version bump.

[daniel-j-h]

clang-format-3.8 all the things

[emiltin]

I think turn penalties for bikes could be improved quite a bit. however i think the type of road your turning from/to might be more important that the approach/exit speeds. The typical example is that turning left form a big road into a small road at a intersection without traffic lights should incur a much more significant penalty that turning left from a small road into a small road, since you often will have to wait for a gap in car traffic before you can turn.

Similarly, the penalty for doing a u-turn depends more on the type of road that the speed of the bike traffic, since doing a u-turn typically implies crossing the road.

This is why is suggested in #592 that the way type are passed to the penalty function. An alternative is to only depend a real-world measurements, but of course that requires sufficient data.

Turn penalties for bikes could perhaps be improved a bit by using approach/exit speeds, but I don't think it's worth it.

[danpat]

Some further discussion on this one has happened in other forums. Some points that were raised:

• it might be useful to apply no penalty when the turn instruction is "continue" - implying that the travellers is staying on the same road and likely does not need to slow down, even if the road curves at the intersection.
• does the turn happen in across non-stopping traffic, and if so, how many lanes - this would be useful for both cars and bikes

[MoKob]

I've pulled this into #2912. Closing here in favour of a structure based approach (instead of passing single parameters to the function).