Currently OSRM parses traffic signal nodes without consideration
for the direction in which the signal applies. This can lead
to duplicated routing penalties, especially when a forward and backward
signal are in close proximity on a way.
This commit adds support for directed signals to the extraction and
graph creation. Signal penalties are only applied in the direction
specified by the OSM tag.
We add the assignment of traffic directions to the lua scripts,
maintaining backwards compatibility with the existing boolean
traffic states.
As part of the changes to the internal structures used for tracking
traffic signals during extraction, we stop serialising/deserialising
signals to the `.osrm` file. The traffic signals are only used by
`osrm-extract` so whilst this is a data format change, it will not
break any existing user processes.
* Remove highway=bicycle safety bonus
This removes a bonus for a road class that doesn't exist (cycleway would
be correct), but the code was buggy since safety_bonus is nil and caused
an arithmetic exception. We only caught this 4 (!) years later since
recently a way was tagged with highway=bicycle and made it in our OSM
data leading to preprocessing failures.
* Handle maxspeed tags before surface and smoothness tags
Let's say we have a tertiary road with the following tags:
highway=tertiary
maxspeed=60
surface=gravel
smoothness=intermediate
While the maxspeed tag tells us the legal speed limit, the surface and
smoothness tags have much more effect on the real-world speed of a car.
We should process the maxspeed tags first, and then update the road's
forwards/backwards speeds according to any surface and smoothness tags.
For our hypothetical road the process in the car.lua profile now goes
like this:
1. Get default speed from profile (tertiary = 40 on line 150 of car.lua)
2. Change speed to 60 using maxspeed tag (WayHandlers.maxspeed function
in way_handlers.lua, lines 434-447)
3. Change speed to 40 using surface tag (WayHandlers.surface function
in way_handlers.lua, lines 360-363)
4. Check speed according to smoothness tag --- but because it's higher
than the speed according to the surface tag, leave the speed
unchanged (WayHandlers.surface function again, lines 368-371)
<ec36319232/profiles/car.lua (L150)>
<ec36319232/profiles/lib/way_handlers.lua (L354-L372)>
Note in step 3 above the speed's only changed from 60kph to 40kph
because it's a lower value. If the surface speed was higher than than
the previous value, the speed would remain unchanged. Another example:
highway=tertiary
maxspeed=60
surface=compacted
smoothness=intermediate
Here, although the profile's speed for compacted is 80, it would stay at
the lower value of 60 (see way_handlers.lua, lines 360-363).
<ec36319232/profiles/lib/way_handlers.lua (L360-L363)>
OSM data contains many mistakes that tag kerbs as highway barriers
when instead they are only describing highway crossings.
This PR updates the default car profile to handle these mistakes
and unblock routing on the affected highways.
Replaces references to
`include/extractor/guidance/road_classification.hpp` with
`include/extractor/road_classification.hpp`.
The latter is included in the project.
After run `lua5.1 profiles/debug_example.lua`, I got result:
```
lua5.1: debug_example.lua:41: attempt to call field 'way_function' (a nil value)
stack traceback:
debug_example.lua:41: in main chunk
[C]: ?
```
This is because Debug has not way_function in the module. This changes
change it to process_way and it's works!!
* In Belgium the maximum speed in rural areas is 70 in the region Flanders
* parse maxspeed using source:maxspeed and maxspeed:type tags
* add changelog
* make maxspeed:advisory more important than maxspeed
* add test for source:maxspeed
* upgrade to api version 4
* set bike pushing speed to 4km/h and add mode change penalty
* set cycleways for two-way and one-way roads according correctly
* add changelog
* adjust tests according to change of the walking speed
* adjust tests according to new behaviour of opposite, track and lane in one-ways
* refactor the cycleway identification
* comment to understand weird counterintuitive testcase
* adjust sliproad test because walking speed is now slower
