Open-Harbor/osrm-backend
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 3 Wiki Activity
d51631401e
osrm-backend/features/car/traffic_light_penalties.feature

346 lines
12 KiB
Gherkin
Raw Normal View History

Apply traffic light penalty also for non-turns
2017-04-19 10:47:35 -04:00
@routing @car @traffic_light
Feature: Car - Handle traffic lights
Background:
Given the profile "car"
Scenario: Car - Encounters a traffic light
Given the node map
"""
a-1-b-2-c
d-3-e-4-f
g-h-i k-l-m
| |
j n
"""
And the ways
| nodes | highway |
| abc | primary |
| def | primary |
| ghi | primary |
| klm | primary |
| hj | primary |
| ln | primary |
And the nodes
| node | highway |
| e | traffic_signals |
| l | traffic_signals |
When I route I should get
| from | to | time | # |
| 1 | 2 | 11.1s | no turn with no traffic light |
| 3 | 4 | 13.1s | no turn with traffic light |
| g | j | 18.7s | turn with no traffic light |
| k | n | 20.7s | turn with traffic light |
deduplicate geometry
2017-07-24 06:47:23 -04:00
Support OSM traffic signal directions (#6153) 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.
2022-08-30 05:36:49 -04:00
Scenario: Car - Traffic signal direction
Given the node map
"""
a-1-b-2-c
d-3-e-4-f
g-5-h-6-i
j-7-k-8-l
"""
And the ways
| nodes | highway |
| abc | primary |
| def | primary |
| ghi | primary |
| jkl | primary |
And the nodes
| node | highway | traffic_signals:direction |
| e | traffic_signals | |
| h | traffic_signals | forward |
| k | traffic_signals | backward |
When I route I should get
Fix adding traffic signal penalties during compression (#6419) Weight and duration penalties are flipped in the lambda function that applies penalties from traffic signals. Duration is in deciseconds, whilst weight is multipled by 10^weight_precision, with weight_precision being 1 by default. Therefore, for default routability profile, the penalties end up being the same, hence why no tests picked this up. If distance weight is used however, it will incorrectly apply an additional penalty to the weight, and not add the traffic signal delay to the duration in the routing graph. To confuse things further, in some API responses the values are correct because they use geometry data instead, but it's still possible that a sub-optimal route was selected. However, given the distance weight is in meters, and the additional penalty per traffic light would be 20, it's unlikely this would have changed the routing results. In any case, we correct the function to apply the arguments correctly.
2022-10-23 09:59:12 -04:00
| from | to | time | weight | # |
| 1 | 2 | 11.1s | 11.1 | no turn with no traffic light |
| 2 | 1 | 11.1s | 11.1 | no turn with no traffic light |
| 3 | 4 | 13.1s | 13.1 | no turn with traffic light |
| 4 | 3 | 13.1s | 13.1 | no turn with traffic light |
| 5 | 6 | 13.1s | 13.1 | no turn with traffic light |
| 6 | 5 | 11.1s | 11.1 | no turn with no traffic light |
| 7 | 8 | 11.1s | 11.1 | no turn with no traffic light |
| 8 | 7 | 13.1s | 13.1 | no turn with traffic light |
Scenario: Car - Traffic signal direction with distance weight
Given the profile file "car" initialized with
"""
profile.properties.weight_name = 'distance'
profile.properties.traffic_light_penalty = 100000
"""
Given the node map
"""
a---b---c
1 2
| |
| |
| |
| |
| |
d-------f
"""
And the ways
| nodes | highway |
| abc | primary |
| adfc | primary |
And the nodes
| node | highway |
| b | traffic_signals |
When I route I should get
| from | to | time | distances | weight | # |
| 1 | 2 | 100033.2s | 599.9m,0m | 599.8 | goes via the expensive traffic signal |
Support OSM traffic signal directions (#6153) 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.
2022-08-30 05:36:49 -04:00
Scenario: Car - Encounters a traffic light
Given the node map
"""
a f k
| | |
b-c-d h-g-i l-m-n
| | |
e j o
"""
And the ways
| nodes | highway |
| bcd | primary |
| ace | primary |
| hgi | primary |
| fgj | primary |
| lmn | primary |
| kmo | primary |
And the nodes
| node | highway | traffic_signals:direction |
| g | traffic_signals | forward |
| m | traffic_signals | backward |
When I route I should get
| from | to | time | # |
| a | d | 21.9s | no turn with no traffic light |
| a | e | 22.2s | no turn with traffic light |
| a | b | 18.7s | turn with no traffic light |
| e | b | 21.9s | no turn with no traffic light |
| e | a | 22.2s | no turn with traffic light |
| e | d | 18.7s | turn with no traffic light |
| d | e | 21.9s | no turn with no traffic light |
| d | b | 11s | no turn with traffic light |
| d | a | 18.7s | turn with no traffic light |
| b | a | 21.9s | no turn with no traffic light |
| b | d | 11s | no turn with traffic light |
| b | e | 18.7s | turn with no traffic light |
| f | i | 23.9s | no turn with no traffic light |
| f | j | 24.2s | no turn with traffic light |
| f | h | 20.7s | turn with no traffic light |
| j | h | 21.9s | no turn with no traffic light |
| j | f | 22.2s | no turn with traffic light |
| j | i | 18.7s | turn with no traffic light |
| i | j | 21.9s | no turn with no traffic light |
| i | h | 11s | no turn with traffic light |
| i | f | 18.7s | turn with no traffic light |
| h | f | 23.9s | no turn with no traffic light |
| h | i | 13s | no turn with traffic light |
| h | j | 20.7s | turn with no traffic light |
| k | n | 21.9s | no turn with no traffic light |
| k | o | 22.2s | no turn with traffic light |
| k | l | 18.7s | turn with no traffic light |
| o | l | 23.9s | no turn with no traffic light |
| o | k | 24.2s | no turn with traffic light |
| o | n | 20.7s | turn with no traffic light |
| n | o | 23.9s | no turn with no traffic light |
| n | l | 13s | no turn with traffic light |
| n | k | 20.7s | turn with no traffic light |
| l | k | 21.9s | no turn with no traffic light |
| l | n | 11s | no turn with traffic light |
| l | o | 18.7s | turn with no traffic light |
Scenario: Traffic Signal Geometry
deduplicate geometry
2017-07-24 06:47:23 -04:00
Given the query options
| overview | full |
| geometries | polyline |
Given the node map
"""
a - b - c
"""
And the ways
| nodes | highway |
| abc | primary |
And the nodes
| node | highway |
| b | traffic_signals |
When I route I should get
| from | to | route | geometry |
Fix distance calculation consistency. (#6315) Consolidate great circle distance calculations to use cheap ruler library.
2022-08-19 17:31:40 -04:00
| a | c | abc,abc | _ibE_ibE?gJ?eJ |
Test with a traffic update on an edge with traffic signal
2017-08-02 07:19:22 -04:00
Support OSM traffic signal directions (#6153) 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.
2022-08-30 05:36:49 -04:00
Scenario: Traffic Signal Geometry - forward signal
Given the query options
| overview | full |
| geometries | polyline |
Given the node map
"""
a - b - c
"""
And the ways
| nodes | highway |
| abc | primary |
And the nodes
| node | highway | traffic_signals:direction |
| b | traffic_signals | forward |
When I route I should get
| from | to | route | geometry |
| a | c | abc,abc | _ibE_ibE?gJ?eJ |
Scenario: Traffic Signal Geometry - reverse signal
Given the query options
| overview | full |
| geometries | polyline |
Given the node map
"""
a - b - c
"""
And the ways
| nodes | highway |
| abc | primary |
And the nodes
| node | highway | traffic_signals:direction |
| b | traffic_signals | reverse |
When I route I should get
| from | to | route | geometry |
| a | c | abc,abc | _ibE_ibE?gJ?eJ |
Test with a traffic update on an edge with traffic signal
2017-08-02 07:19:22 -04:00
@traffic
Scenario: Traffic update on the edge with a traffic signal
Given the node map
"""
a - b - c
"""
And the ways
| nodes | highway |
| abc | primary |
And the nodes
| node | highway |
| b | traffic_signals |
And the contract extra arguments "--segment-speed-file {speeds_file}"
And the customize extra arguments "--segment-speed-file {speeds_file}"
And the speed file
"""
1,2,65
2,1,65
"""
And the query options
| annotations | datasources,nodes,speed,duration,weight |
When I route I should get
| from | to | route | speed | weights | time | distances | a:datasources | a:nodes | a:speed | a:duration | a:weight |
Fix distance calculation consistency. (#6315) Consolidate great circle distance calculations to use cheap ruler library.
2022-08-19 17:31:40 -04:00
| a | c | abc,abc | 60 km/h | 24.2,0 | 24.2s | 400m,0m | 1:0 | 1:2:3 | 18:18 | 11.1:11.1 | 11.1:11.1 |
| c | a | abc,abc | 60 km/h | 24.2,0 | 24.2s | 400m,0m | 0:1 | 3:2:1 | 18:18 | 11.1:11.1 | 11.1:11.1 |
Support OSM traffic signal directions (#6153) 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.
2022-08-30 05:36:49 -04:00
@traffic
Scenario: Traffic update on the edge with a traffic signal - forward
Given the node map
"""
a - b - c
"""
And the ways
| nodes | highway |
| abc | primary |
And the nodes
| node | highway | traffic_signals:direction |
| b | traffic_signals | forward |
And the contract extra arguments "--segment-speed-file {speeds_file}"
And the customize extra arguments "--segment-speed-file {speeds_file}"
And the speed file
"""
1,2,65
2,1,65
"""
And the query options
| annotations | datasources,nodes,speed,duration,weight |
When I route I should get
| from | to | route | speed | weights | time | distances | a:datasources | a:nodes | a:speed | a:duration | a:weight |
| a | c | abc,abc | 60 km/h | 24.2,0 | 24.2s | 400m,0m | 1:0 | 1:2:3 | 18:18 | 11.1:11.1 | 11.1:11.1 |
| c | a | abc,abc | 65 km/h | 22.2,0 | 22.2s | 400m,0m | 0:1 | 3:2:1 | 18:18 | 11.1:11.1 | 11.1:11.1 |
@traffic
Scenario: Traffic update on the edge with a traffic signal - backward
Given the node map
"""
a - b - c
"""
And the ways
| nodes | highway |
| abc | primary |
And the nodes
| node | highway | traffic_signals:direction |
| b | traffic_signals | backward |
And the contract extra arguments "--segment-speed-file {speeds_file}"
And the customize extra arguments "--segment-speed-file {speeds_file}"
And the speed file
"""
1,2,65
2,1,65
"""
And the query options
| annotations | datasources,nodes,speed,duration,weight |
When I route I should get
| from | to | route | speed | weights | time | distances | a:datasources | a:nodes | a:speed | a:duration | a:weight |
| a | c | abc,abc | 65 km/h | 22.2,0 | 22.2s | 400m,0m | 1:0 | 1:2:3 | 18:18 | 11.1:11.1 | 11.1:11.1 |
| c | a | abc,abc | 60 km/h | 24.2,0 | 24.2s | 400m,0m | 0:1 | 3:2:1 | 18:18 | 11.1:11.1 | 11.1:11.1 |
Reference in New Issue Copy Permalink