Open-Harbor/osrm-backend
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 3 Wiki Activity
0fc1aa2711
osrm-backend/features/guidance/anticipate-lanes.feature

846 lines
49 KiB
Gherkin
Raw Normal View History

Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
@routing @guidance @turn-lanes
Feature: Turn Lane Guidance
Background:
Given the profile "car"
Trigger lane anticipation based on distance, see discussion in #4260
2017-07-17 04:51:16 -04:00
Given a grid size of 100 meters
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
@anticipate
Scenario: Anticipate Lane Change for subsequent multi-lane intersections
Given the node map
cucumber: change syntax of node maps
2016-09-30 03:33:08 -04:00
"""
a – b – x
|
c – d – z
| |
y e
"""
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
And the ways
update cucumber to 1.2.1 and remove hack
2016-07-07 09:31:20 -04:00
| nodes | turn:lanes:forward |
| ab | through\|right\|right\|right |
| bx | |
| bc | left\|left\|through |
| cd | through\|right |
| cy | |
| dz | |
| de | |
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
When I route I should get
expose lanes as enums, adjusted for comments
2016-06-21 04:41:08 -04:00
| waypoints | route | turns | lanes | # |
| a,d | ab,bc,cd,cd | depart,turn right,turn left,arrive | ,straight:false right:true right:true right:false,left:true left:true straight:false, | 2 hops |
| a,e | ab,bc,cd,de,de | depart,turn right,turn left,turn right,arrive | ,straight:false right:false right:true right:false,left:false left:true straight:false,straight:false right:true, | 3 hops |
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
@anticipate
Scenario: Anticipate Lane Change for quick same direction turns, staying on the same street
Given the node map
cucumber: change syntax of node maps
2016-09-30 03:33:08 -04:00
"""
a – b – x
|
c
|
e – d – y
"""
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
And the ways
update cucumber to 1.2.1 and remove hack
2016-07-07 09:31:20 -04:00
| nodes | turn:lanes:forward | turn:lanes:backward | name |
| ab | through\|right\|right | | MySt |
| bx | | | XSt |
| bc | | left\|right | MySt |
| cd | left\|right | through\|through | MySt |
| de | | left\|left\|through | MySt |
| dy | | | YSt |
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
When I route I should get
respect difference between continue/turn on changing end-of-road
2017-08-11 10:35:39 -04:00
| waypoints | route | turns | lanes |
| a,e | MySt,MySt,MySt,MySt | depart,continue right,continue right,arrive | ,straight:false right:false right:true,left:false right:true, |
| e,a | MySt,MySt,MySt,MySt | depart,continue left,continue left,arrive | ,left:true left:false straight:false,left:true right:false, |
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
@anticipate
Scenario: Anticipate Lane Change for quick same direction turns, changing between streets
Given the node map
cucumber: change syntax of node maps
2016-09-30 03:33:08 -04:00
"""
a – b – x
|
c
|
e – d – y
"""
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
And the ways
update cucumber to 1.2.1 and remove hack
2016-07-07 09:31:20 -04:00
| nodes | turn:lanes:forward | turn:lanes:backward | name |
| ab | through\|right\|right | | AXSt |
| bx | | | AXSt |
| bc | | left\|right | BDSt |
| cd | left\|right | through\|through | BDSt |
| de | | left\|left\|through | EYSt |
| dy | | | EYSt |
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
When I route I should get
expose lanes as enums, adjusted for comments
2016-06-21 04:41:08 -04:00
| waypoints | route | turns | lanes |
| a,e | AXSt,BDSt,EYSt,EYSt | depart,turn right,turn right,arrive | ,straight:false right:false right:true,left:false right:true, |
| e,a | EYSt,BDSt,AXSt,AXSt | depart,turn left,turn left,arrive | ,left:true left:false straight:false,left:true right:false, |
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
@anticipate
Scenario: Anticipate Lane Change for quick turns during a merge
Given the node map
cucumber: change syntax of node maps
2016-09-30 03:33:08 -04:00
"""
a
\
x – b – c – y
|
d
"""
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
And the ways
| nodes | turn:lanes:forward | name | highway | oneway |
| ab | slight_left\|slight_left | On | motorway_link | yes |
| xb | | Hwy | motorway | |
| bc | through\|slight_right | Hwy | motorway | |
| cd | | Off | motorway_link | yes |
| cy | | Hwy | motorway | |
When I route I should get
expose lanes as enums, adjusted for comments
2016-06-21 04:41:08 -04:00
| waypoints | route | turns | lanes |
| a,d | On,Hwy,Off,Off | depart,merge slight right,off ramp right,arrive | ,slight left:false slight left:true,straight:false slight right:true, |
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
@anticipate
Scenario: Schoenefelder Kreuz
# https://www.openstreetmap.org/way/264306388#map=16/52.3202/13.5568
Given the node map
cucumber: change syntax of node maps
2016-09-30 03:33:08 -04:00
"""
a b – x
\ / i
c – d
\ j
"""
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
And the ways
update cucumber to 1.2.1 and remove hack
2016-07-07 09:31:20 -04:00
| nodes | turn:lanes:forward | lanes | highway | oneway | name |
| ab | none\|none\|none\|slight_right\|slight_right | 5 | motorway | | abx |
| bx | | 3 | motorway | | abx |
| bc | | 2 | motorway_link | yes | bcd |
| cd | slight_left\|slight_left;slight_right\|slight_right | 3 | motorway_link | yes | bcd |
| di | slight_left\|slight_right | 2 | motorway_link | yes | di |
| dj | | 2 | motorway_link | yes | dj |
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
When I route I should get
Implement Turn Lane Api
2016-06-15 08:38:24 -04:00
| waypoints | route | turns | lanes |
expose lanes as enums, adjusted for comments
2016-06-21 04:41:08 -04:00
| a,i | abx,bcd,di,di | depart,off ramp right,fork slight left,arrive | ,none:false none:false none:false slight right:true slight right:true,slight left:true slight left;slight right:true slight right:false, |
| a,j | abx,bcd,dj,dj | depart,off ramp right,fork slight right,arrive | ,none:false none:false none:false slight right:true slight right:true,slight left:false slight left;slight right:true slight right:true, |
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
@anticipate
Scenario: Kreuz Oranienburg
# https://www.openstreetmap.org/way/4484007#map=18/52.70439/13.20269
Given the node map
cucumber: change syntax of node maps
2016-09-30 03:33:08 -04:00
"""
i a
' . . '
j – – c – b – – x
"""
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
And the ways
| nodes | turn:lanes:forward | lanes | highway | oneway | name |
| ab | | 1 | motorway_link | yes | ab |
| xb | | 1 | motorway_link | yes | xbcj |
| bc | none\|slight_right | 2 | motorway_link | yes | xbcj |
| ci | | 1 | motorway_link | yes | ci |
| cj | | 1 | motorway_link | yes | xbcj |
When I route I should get
deprecate use-lane -- the information can be found in the intersections array
2017-07-10 06:46:18 -04:00
| waypoints | route | turns | lanes |
| a,i | ab,ci,ci | depart,turn slight right,arrive | ;,none:false slight right:true, |
| a,j | ab,xbcj | depart,arrive | ;;none:true slight right:false, |
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
@anticipate
Scenario: Lane anticipation for fan-in
Given the node map
cucumber: change syntax of node maps
2016-09-30 03:33:08 -04:00
"""
a – b – x
|
c – d – z
| |
y e
"""
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
And the ways
update cucumber to 1.2.1 and remove hack
2016-07-07 09:31:20 -04:00
| nodes | turn:lanes:forward | name |
| ab | through\|right\|right\|right | abx |
| bx | | abx |
| bc | left\|left\|through | bcy |
| cy | | bcy |
| cd | through\|right | cdz |
| dz | | cdz |
| de | | de |
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
When I route I should get
expose lanes as enums, adjusted for comments
2016-06-21 04:41:08 -04:00
| waypoints | route | turns | lanes |
| a,e | abx,bcy,cdz,de,de | depart,turn right,turn left,turn right,arrive | ,straight:false right:false right:true right:false,left:false left:true straight:false,straight:false right:true, |
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
@anticipate
Scenario: Lane anticipation for fan-out
Given the node map
cucumber: change syntax of node maps
2016-09-30 03:33:08 -04:00
"""
a – b – x
|
c – d – z
| |
y e
"""
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
And the ways
update cucumber to 1.2.1 and remove hack
2016-07-07 09:31:20 -04:00
| nodes | turn:lanes:forward | name |
| ab | through\|right | abx |
| bx | | abx |
| bc | left\|left\|through | bcy |
| cy | | bcy |
| cd | through\|right\|right\|right | cdz |
| dz | | cdz |
| de | | de |
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
When I route I should get
expose lanes as enums, adjusted for comments
2016-06-21 04:41:08 -04:00
| waypoints | route | turns | lanes |
| a,e | abx,bcy,cdz,de,de | depart,turn right,turn left,turn right,arrive | ,straight:false right:true,left:true left:true straight:false,straight:false right:true right:true right:true, |
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
@anticipate
Scenario: Lane anticipation for fan-in followed by fan-out
Given the node map
cucumber: change syntax of node maps
2016-09-30 03:33:08 -04:00
"""
a – b – x
|
c – d – z
| |
y e
"""
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
And the ways
update cucumber to 1.2.1 and remove hack
2016-07-07 09:31:20 -04:00
| nodes | turn:lanes:forward | name |
| ab | through\|right\|right\|right | abx |
| bx | | abx |
| bc | left\|left\|through | bcy |
| cy | | bcy |
| cd | through\|right\|right\|right | cdz |
| dz | | cdz |
| de | | de |
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
When I route I should get
expose lanes as enums, adjusted for comments
2016-06-21 04:41:08 -04:00
| waypoints | route | turns | lanes |
| a,e | abx,bcy,cdz,de,de | depart,turn right,turn left,turn right,arrive | ,straight:false right:true right:true right:false,left:true left:true straight:false,straight:false right:true right:true right:true, |
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
@anticipate
Scenario: Lane anticipation for fan-out followed by fan-in
Given the node map
cucumber: change syntax of node maps
2016-09-30 03:33:08 -04:00
"""
a – b – x
|
c – d – z
| |
y e
"""
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
And the ways
update cucumber to 1.2.1 and remove hack
2016-07-07 09:31:20 -04:00
| nodes | turn:lanes:forward | name |
| ab | through\|right | abx |
| bx | | abx |
| bc | left\|left\|through | bcy |
| cy | | bcy |
| cd | through\|right | cdz |
| dz | | cdz |
| de | | de |
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
When I route I should get
expose lanes as enums, adjusted for comments
2016-06-21 04:41:08 -04:00
| waypoints | route | turns | lanes |
| a,e | abx,bcy,cdz,de,de | depart,turn right,turn left,turn right,arrive | ,straight:false right:true,left:false left:true straight:false,straight:false right:true, |
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
@anticipate
Scenario: Lane anticipation for multiple hops with same number of lanes
Given the node map
cucumber: change syntax of node maps
2016-09-30 03:33:08 -04:00
"""
a – b – x
|
c – d – z
| |
y e – f
|
w
"""
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
And the ways
update cucumber to 1.2.1 and remove hack
2016-07-07 09:31:20 -04:00
| nodes | turn:lanes:forward | name |
| ab | through\|right\|right\|right | abx |
| bx | | abx |
| bc | left\|left\|through | bcy |
| cy | | bcy |
| cd | through\|right\|right | cdz |
| dz | | cdz |
| de | left\|through | dew |
| ew | | dew |
| ef | | ef |
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
When I route I should get
expose lanes as enums, adjusted for comments
2016-06-21 04:41:08 -04:00
| waypoints | route | turns | lanes |
Improves lane handling for subsequent going straight, resolves #2625 Before we only worked on subsequent quick turns, as in: `right, right` keeps the user on the rightmost lanes. This changeset modifies the logic to work on any subsequent steps that are "quick" and have lane information we can constrain later. Because we do not have a from-lane => to-lanes mapping we take the lanes left and right of the turn lanes into account when heuristically assigning the leftmost / rightmost lanes. There are some edge cases where this still does not give us the optimal solution but it gets close to what is actually possible at the moment without having a lane mapping in post-processing. References: - https://github.com/Project-OSRM/osrm-backend/issues/2625 fix rebase
2016-07-08 06:39:29 -04:00
| a,f | abx,bcy,cdz,dew,ef,ef | depart,turn right,turn left,turn right,turn left,arrive | ,straight:false right:true right:false right:false,left:true left:false straight:false,straight:false right:true right:false,left:true straight:false, |
@anticipate
Scenario: Anticipate Lanes for through, through with lanes
Given the node map
cucumber: change syntax of node maps
2016-09-30 03:33:08 -04:00
"""
f g
/ /
a – b – c – d – e
\ \
h i
"""
Improves lane handling for subsequent going straight, resolves #2625 Before we only worked on subsequent quick turns, as in: `right, right` keeps the user on the rightmost lanes. This changeset modifies the logic to work on any subsequent steps that are "quick" and have lane information we can constrain later. Because we do not have a from-lane => to-lanes mapping we take the lanes left and right of the turn lanes into account when heuristically assigning the leftmost / rightmost lanes. There are some edge cases where this still does not give us the optimal solution but it gets close to what is actually possible at the moment without having a lane mapping in post-processing. References: - https://github.com/Project-OSRM/osrm-backend/issues/2625 fix rebase
2016-07-08 06:39:29 -04:00
And the ways
refactor of post-processing - moves collapse into a dedicated set of functions / files - make collapse scenarios distinct (slight performance cost) - reduce verbosity for short name segments (now actually working, was supposed to do so before)
2017-02-15 09:12:24 -05:00
| nodes | turn:lanes:forward | name | destination | oneway |
| ab | | main | One | yes |
| bc | left\|through\|through\|through\|right | main | One | yes |
| cd | left\|through\|right | main | Two | yes |
| de | | main | Three | yes |
| cf | | off | | yes |
| ch | | off | | yes |
| dg | | off | | yes |
| di | | off | | yes |
Improves lane handling for subsequent going straight, resolves #2625 Before we only worked on subsequent quick turns, as in: `right, right` keeps the user on the rightmost lanes. This changeset modifies the logic to work on any subsequent steps that are "quick" and have lane information we can constrain later. Because we do not have a from-lane => to-lanes mapping we take the lanes left and right of the turn lanes into account when heuristically assigning the leftmost / rightmost lanes. There are some edge cases where this still does not give us the optimal solution but it gets close to what is actually possible at the moment without having a lane mapping in post-processing. References: - https://github.com/Project-OSRM/osrm-backend/issues/2625 fix rebase
2016-07-08 06:39:29 -04:00
When I route I should get
deprecate use-lane -- the information can be found in the intersections array
2017-07-10 06:46:18 -04:00
| waypoints | route | turns | destinations | locations | lanes |
| a,e | main,main | depart,arrive | One,Three | a,e | ;left:false straight:false straight:true straight:false right:false;left:false straight:true right:false, |
Improves lane handling for subsequent going straight, resolves #2625 Before we only worked on subsequent quick turns, as in: `right, right` keeps the user on the rightmost lanes. This changeset modifies the logic to work on any subsequent steps that are "quick" and have lane information we can constrain later. Because we do not have a from-lane => to-lanes mapping we take the lanes left and right of the turn lanes into account when heuristically assigning the leftmost / rightmost lanes. There are some edge cases where this still does not give us the optimal solution but it gets close to what is actually possible at the moment without having a lane mapping in post-processing. References: - https://github.com/Project-OSRM/osrm-backend/issues/2625 fix rebase
2016-07-08 06:39:29 -04:00
@anticipate
Scenario: Anticipate Lanes for through and collapse multiple use lanes
Given the node map
cucumber: change syntax of node maps
2016-09-30 03:33:08 -04:00
"""
e f g
/ / /
a – b – c – d
\ \ \
h i j
"""
Improves lane handling for subsequent going straight, resolves #2625 Before we only worked on subsequent quick turns, as in: `right, right` keeps the user on the rightmost lanes. This changeset modifies the logic to work on any subsequent steps that are "quick" and have lane information we can constrain later. Because we do not have a from-lane => to-lanes mapping we take the lanes left and right of the turn lanes into account when heuristically assigning the leftmost / rightmost lanes. There are some edge cases where this still does not give us the optimal solution but it gets close to what is actually possible at the moment without having a lane mapping in post-processing. References: - https://github.com/Project-OSRM/osrm-backend/issues/2625 fix rebase
2016-07-08 06:39:29 -04:00
And the ways
| nodes | turn:lanes:forward | name |
| ab | left\|through\|through\|right | main |
| bc | left\|through\|through\|right | main |
| cd | left\|through\|through\|through\|right | main |
| be | | off |
| bh | | off |
| cf | | off |
| ci | | off |
| dg | | off |
| dj | | off |
When I route I should get
deprecate use-lane -- the information can be found in the intersections array
2017-07-10 06:46:18 -04:00
| waypoints | route | turns | lanes |
| a,c | main,main | depart,arrive | ;left:false straight:true straight:true right:false, |
| a,d | main,main | depart,arrive | ;left:false straight:true straight:true right:false;left:false straight:true straight:true right:false, |
Improves lane handling for subsequent going straight, resolves #2625 Before we only worked on subsequent quick turns, as in: `right, right` keeps the user on the rightmost lanes. This changeset modifies the logic to work on any subsequent steps that are "quick" and have lane information we can constrain later. Because we do not have a from-lane => to-lanes mapping we take the lanes left and right of the turn lanes into account when heuristically assigning the leftmost / rightmost lanes. There are some edge cases where this still does not give us the optimal solution but it gets close to what is actually possible at the moment without having a lane mapping in post-processing. References: - https://github.com/Project-OSRM/osrm-backend/issues/2625 fix rebase
2016-07-08 06:39:29 -04:00
@anticipate
Scenario: Anticipate Lanes for through followed by left/right
Given the node map
cucumber: change syntax of node maps
2016-09-30 03:33:08 -04:00
"""
f g d
/ / /
a – b – c – x
\ \ \
h i e
"""
Improves lane handling for subsequent going straight, resolves #2625 Before we only worked on subsequent quick turns, as in: `right, right` keeps the user on the rightmost lanes. This changeset modifies the logic to work on any subsequent steps that are "quick" and have lane information we can constrain later. Because we do not have a from-lane => to-lanes mapping we take the lanes left and right of the turn lanes into account when heuristically assigning the leftmost / rightmost lanes. There are some edge cases where this still does not give us the optimal solution but it gets close to what is actually possible at the moment without having a lane mapping in post-processing. References: - https://github.com/Project-OSRM/osrm-backend/issues/2625 fix rebase
2016-07-08 06:39:29 -04:00
And the ways
| nodes | turn:lanes:forward | name |
| ab | left\|through\|through\|through\|through\|right | main |
| bc | left\|through\|through\|right | main |
| cx | left\|right | main |
| xd | | left |
| xe | | right |
| bf | | off |
| bh | | off |
| cg | | off |
| ci | | off |
When I route I should get
deprecate use-lane -- the information can be found in the intersections array
2017-07-10 06:46:18 -04:00
| waypoints | route | turns | lanes |
| a,d | main,left,left | depart,end of road left,arrive | ;left:false straight:false straight:true straight:false straight:false right:false;left:false straight:true straight:false right:false,left:true right:false, |
| a,e | main,right,right | depart,end of road right,arrive | ;left:false straight:false straight:false straight:true straight:false right:false;left:false straight:false straight:true right:false,left:false right:true, |
Improves lane handling for subsequent going straight, resolves #2625 Before we only worked on subsequent quick turns, as in: `right, right` keeps the user on the rightmost lanes. This changeset modifies the logic to work on any subsequent steps that are "quick" and have lane information we can constrain later. Because we do not have a from-lane => to-lanes mapping we take the lanes left and right of the turn lanes into account when heuristically assigning the leftmost / rightmost lanes. There are some edge cases where this still does not give us the optimal solution but it gets close to what is actually possible at the moment without having a lane mapping in post-processing. References: - https://github.com/Project-OSRM/osrm-backend/issues/2625 fix rebase
2016-07-08 06:39:29 -04:00
@anticipate
Scenario: Anticipate Lanes for through with turn before / after
Given the node map
cucumber: change syntax of node maps
2016-09-30 03:33:08 -04:00
"""
Trigger lane anticipation based on distance, see discussion in #4260
2017-07-17 04:51:16 -04:00
c g l
b d e h i
a f j
cucumber: change syntax of node maps
2016-09-30 03:33:08 -04:00
"""
Improves lane handling for subsequent going straight, resolves #2625 Before we only worked on subsequent quick turns, as in: `right, right` keeps the user on the rightmost lanes. This changeset modifies the logic to work on any subsequent steps that are "quick" and have lane information we can constrain later. Because we do not have a from-lane => to-lanes mapping we take the lanes left and right of the turn lanes into account when heuristically assigning the leftmost / rightmost lanes. There are some edge cases where this still does not give us the optimal solution but it gets close to what is actually possible at the moment without having a lane mapping in post-processing. References: - https://github.com/Project-OSRM/osrm-backend/issues/2625 fix rebase
2016-07-08 06:39:29 -04:00
And the ways
| nodes | turn:lanes:forward | name | oneway |
| ab | right\|right\|right\|right | ab | yes |
| cb | left\|left\|left\|left | cb | yes |
| bd | | bdehi | |
| de | left\|left\|through\|through\|through\|through\|right\|right | bdehi | |
| ef | | ef | |
| eg | | eg | |
| eh | | bdehi | |
| hi | left\|left\|right\|right | bdehi | |
| ij | | ij | |
| il | | il | |
When I route I should get
deprecate use-lane -- the information can be found in the intersections array
2017-07-10 06:46:18 -04:00
| waypoints | route | turns | lanes | # |
| a,f | ab,bdehi,ef,ef | depart,turn right,turn right,arrive | ,right:false right:false right:true right:true,left:false left:false straight:false straight:false straight:false straight:false right:true right:true, | |
| a,g | ab,bdehi,eg,eg | depart,turn right,turn left,arrive | ,right:true right:true right:false right:false,left:true left:true straight:false straight:false straight:false straight:false right:false right:false, | |
| a,j | ab,bdehi,ij,ij | depart,turn right,end of road right,arrive | ,right:true right:true right:false right:false;left:false left:false straight:false straight:false straight:true straight:true right:false right:false,left:false left:false right:true right:true, | |
| a,l | ab,bdehi,il,il | depart,turn right,end of road left,arrive | ,right:false right:false right:true right:true;left:false left:false straight:true straight:true straight:false straight:false right:false right:false,left:true left:true right:false right:false, | not perfect |
| c,g | cb,bdehi,eg,eg | depart,turn left,turn left,arrive | ,left:true left:true left:false left:false,left:true left:true straight:false straight:false straight:false straight:false right:false right:false, | |
| c,f | cb,bdehi,ef,ef | depart,turn left,turn right,arrive | ,left:false left:false left:true left:true,left:false left:false straight:false straight:false straight:false straight:false right:true right:true, | |
| c,l | cb,bdehi,il,il | depart,turn left,end of road left,arrive | ,left:false left:false left:true left:true;left:false left:false straight:true straight:true straight:false straight:false right:false right:false,left:true left:true right:false right:false, | |
| c,j | cb,bdehi,ij,ij | depart,turn left,end of road right,arrive | ,left:true left:true left:false left:false;left:false left:false straight:false straight:false straight:true straight:true right:false right:false,left:false left:false right:true right:true, | not perfect |
Improves lane handling for subsequent going straight, resolves #2625 Before we only worked on subsequent quick turns, as in: `right, right` keeps the user on the rightmost lanes. This changeset modifies the logic to work on any subsequent steps that are "quick" and have lane information we can constrain later. Because we do not have a from-lane => to-lanes mapping we take the lanes left and right of the turn lanes into account when heuristically assigning the leftmost / rightmost lanes. There are some edge cases where this still does not give us the optimal solution but it gets close to what is actually possible at the moment without having a lane mapping in post-processing. References: - https://github.com/Project-OSRM/osrm-backend/issues/2625 fix rebase
2016-07-08 06:39:29 -04:00
@anticipate
Scenario: Anticipate Lanes for turns with through before and after
cucumber: change syntax of node maps
2016-09-30 03:33:08 -04:00
Given a grid size of 10 meters
Improves lane handling for subsequent going straight, resolves #2625 Before we only worked on subsequent quick turns, as in: `right, right` keeps the user on the rightmost lanes. This changeset modifies the logic to work on any subsequent steps that are "quick" and have lane information we can constrain later. Because we do not have a from-lane => to-lanes mapping we take the lanes left and right of the turn lanes into account when heuristically assigning the leftmost / rightmost lanes. There are some edge cases where this still does not give us the optimal solution but it gets close to what is actually possible at the moment without having a lane mapping in post-processing. References: - https://github.com/Project-OSRM/osrm-backend/issues/2625 fix rebase
2016-07-08 06:39:29 -04:00
Given the node map
cucumber: change syntax of node maps
2016-09-30 03:33:08 -04:00
"""
a – b – q s h – i
\ / /
e – f – g
/ \ \
c – d – r t j – k
"""
Improves lane handling for subsequent going straight, resolves #2625 Before we only worked on subsequent quick turns, as in: `right, right` keeps the user on the rightmost lanes. This changeset modifies the logic to work on any subsequent steps that are "quick" and have lane information we can constrain later. Because we do not have a from-lane => to-lanes mapping we take the lanes left and right of the turn lanes into account when heuristically assigning the leftmost / rightmost lanes. There are some edge cases where this still does not give us the optimal solution but it gets close to what is actually possible at the moment without having a lane mapping in post-processing. References: - https://github.com/Project-OSRM/osrm-backend/issues/2625 fix rebase
2016-07-08 06:39:29 -04:00
And the ways
Turn Angles in OSRM were computed using a lookahead of 10 meters. This PR adds more advanced coordinate extraction, analysing the road to detect offsets due to OSM way modelling. In addition it improves the handling of bearings. Right now OSM reports bearings simply based on the very first coordinate along a way. With this PR, we store the bearings for a turn correctly, making the bearings for turns correct.
2016-08-17 03:49:19 -04:00
| nodes | turn:lanes:forward | name | highway | oneway |
| ab | through\|right\|right\|right | top | primary | yes |
| be | | top | primary | yes |
| bq | | off | primary | yes |
| ef | left\|through\|through\|through\|through\|right | main | primary | yes |
| fg | left\|left\|right\|right | main | primary | yes |
| fs | | off | primary | yes |
| ft | | off | primary | yes |
| gh | | top | primary | yes |
| hi | | top | primary | yes |
| cd | left\|left\|left\|through | bot | primary | yes |
| de | | bot | primary | yes |
| dr | | off | primary | yes |
| gj | | bot | primary | yes |
| jk | | bot | primary | yes |
Improves lane handling for subsequent going straight, resolves #2625 Before we only worked on subsequent quick turns, as in: `right, right` keeps the user on the rightmost lanes. This changeset modifies the logic to work on any subsequent steps that are "quick" and have lane information we can constrain later. Because we do not have a from-lane => to-lanes mapping we take the lanes left and right of the turn lanes into account when heuristically assigning the leftmost / rightmost lanes. There are some edge cases where this still does not give us the optimal solution but it gets close to what is actually possible at the moment without having a lane mapping in post-processing. References: - https://github.com/Project-OSRM/osrm-backend/issues/2625 fix rebase
2016-07-08 06:39:29 -04:00
When I route I should get
deprecate use-lane -- the information can be found in the intersections array
2017-07-10 06:46:18 -04:00
| waypoints | route | turns | lanes |
| a,i | top,main,top,top | depart,turn right,turn left,arrive | ,straight:false right:true right:true right:true;;left:false straight:true straight:true straight:false straight:false right:false,left:true left:true right:false right:false, |
| a,k | top,main,bot,bot | depart,turn right,turn right,arrive | ,straight:false right:true right:true right:true;;left:false straight:false straight:false straight:true straight:true right:false,left:false left:false right:true right:true, |
| c,i | bot,main,top,top | depart,turn left,turn left,arrive | ,left:true left:true left:true straight:false;;left:false straight:true straight:true straight:false straight:false right:false,left:true left:true right:false right:false, |
| c,k | bot,main,bot,bot | depart,turn left,turn right,arrive | ,left:true left:true left:true straight:false;;left:false straight:false straight:false straight:true straight:true right:false,left:false left:false right:true right:true, |
Improves lane handling for subsequent going straight, resolves #2625 Before we only worked on subsequent quick turns, as in: `right, right` keeps the user on the rightmost lanes. This changeset modifies the logic to work on any subsequent steps that are "quick" and have lane information we can constrain later. Because we do not have a from-lane => to-lanes mapping we take the lanes left and right of the turn lanes into account when heuristically assigning the leftmost / rightmost lanes. There are some edge cases where this still does not give us the optimal solution but it gets close to what is actually possible at the moment without having a lane mapping in post-processing. References: - https://github.com/Project-OSRM/osrm-backend/issues/2625 fix rebase
2016-07-08 06:39:29 -04:00
@anticipate
Scenario: Anticipate Lanes for turn between throughs
Given the node map
cucumber: change syntax of node maps
2016-09-30 03:33:08 -04:00
"""
q
|
a – b – c – s
| |
r d – t
|
e
"""
Improves lane handling for subsequent going straight, resolves #2625 Before we only worked on subsequent quick turns, as in: `right, right` keeps the user on the rightmost lanes. This changeset modifies the logic to work on any subsequent steps that are "quick" and have lane information we can constrain later. Because we do not have a from-lane => to-lanes mapping we take the lanes left and right of the turn lanes into account when heuristically assigning the leftmost / rightmost lanes. There are some edge cases where this still does not give us the optimal solution but it gets close to what is actually possible at the moment without having a lane mapping in post-processing. References: - https://github.com/Project-OSRM/osrm-backend/issues/2625 fix rebase
2016-07-08 06:39:29 -04:00
And the ways
| nodes | turn:lanes:forward | name |
| ab | left\|through\|through\|through\|through\|through\|right | main |
| bq | | off |
| br | | off |
| bc | through\|through\|right\|right\|right | main |
| cs | | off |
| cd | left\|through\|through | main |
| de | | main |
| dt | | off |
When I route I should get
deprecate use-lane -- the information can be found in the intersections array
2017-07-10 06:46:18 -04:00
| waypoints | route | turns | lanes |
| a,e | main,main,main | depart,continue right,arrive | ;left:false straight:false straight:false straight:false straight:true straight:true right:false,straight:false straight:false right:false right:true right:true;left:false straight:true straight:true, |
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
Close GH-2795: Rewrite cucumber test caching (and support logic). Fixes #2745
2016-09-19 17:13:44 -04:00
@anticipate @todo @2661
mark second case as todo, see https://github.com/Project-OSRM/osrm-backend/issues/2661
2016-07-15 09:04:01 -04:00
Scenario: Anticipate with lanes in roundabout: roundabouts as the unit of anticipation
Improves Lane Handling for Multi-Hop Roundabout Instruction This changeset implements Lane Anticipation on roundabouts, delimited by enter / leave step pairs. It does not handle lane anticipation within a roundabout. Lane anticipation happens on the granularity of a valid roundbaout: We discard partial roundabout (enter without exit or exit without enter) or data issues (no roundabout, exit before enter). Related: - https://github.com/Project-OSRM/osrm-backend/issues/2626 for lanes within a roundabout - https://github.com/Project-OSRM/osrm-backend/issues/2625 for handling going straight in lane anticipation
2016-06-30 06:10:48 -04:00
Given the node map
cucumber: change syntax of node maps
2016-09-30 03:33:08 -04:00
"""
/e\
a – b d – f
\c/
|
/g\
k – h j – l
\i/
"""
Improves Lane Handling for Multi-Hop Roundabout Instruction This changeset implements Lane Anticipation on roundabouts, delimited by enter / leave step pairs. It does not handle lane anticipation within a roundabout. Lane anticipation happens on the granularity of a valid roundbaout: We discard partial roundabout (enter without exit or exit without enter) or data issues (no roundabout, exit before enter). Related: - https://github.com/Project-OSRM/osrm-backend/issues/2626 for lanes within a roundabout - https://github.com/Project-OSRM/osrm-backend/issues/2625 for handling going straight in lane anticipation
2016-06-30 06:10:48 -04:00
And the ways
move hardcoded road priorities into profiles, change road classification
2016-06-24 10:06:45 -04:00
| nodes | turn:lanes:forward | highway | junction | # |
Fix tests after cucumber update and changed escaping.
2016-07-13 05:48:53 -04:00
| ab | slight_right\|slight_right\|slight_right | primary | | |
| bc | slight_left\|slight_right\|slight_right | primary | roundabout | top |
move hardcoded road priorities into profiles, change road classification
2016-06-24 10:06:45 -04:00
| cd | | primary | roundabout | top |
| de | | primary | roundabout | top |
| eb | | primary | roundabout | top |
| df | | primary | | |
| cg | slight_right\|slight_right | primary | | |
| gh | slight_left\|slight_right | primary | roundabout | bot |
| hi | | primary | roundabout | bot |
| ij | slight_left\|slight_right | primary | roundabout | bot |
| jg | | primary | roundabout | bot |
| hk | | primary | | |
| jl | | primary | | |
Improves Lane Handling for Multi-Hop Roundabout Instruction This changeset implements Lane Anticipation on roundabouts, delimited by enter / leave step pairs. It does not handle lane anticipation within a roundabout. Lane anticipation happens on the granularity of a valid roundbaout: We discard partial roundabout (enter without exit or exit without enter) or data issues (no roundabout, exit before enter). Related: - https://github.com/Project-OSRM/osrm-backend/issues/2626 for lanes within a roundabout - https://github.com/Project-OSRM/osrm-backend/issues/2625 for handling going straight in lane anticipation
2016-06-30 06:10:48 -04:00
When I route I should get
| # | waypoints | route | turns | lanes |
| right-right | a,k | ab,cg,hk,hk | depart,roundabout-exit-1,roundabout-exit-1,arrive | ,slight right:false slight right:false slight right:true,slight right:false slight right:true, |
| right-left | a,l | ab,cg,jl,jl | depart,roundabout-exit-1,roundabout-exit-2,arrive | ,slight right:false slight right:false slight right:true,slight right:false slight right:true, |
| todo exits | a,f | ab,df,df | depart,roundabout-exit-2,arrive | ,slight right:false slight right:false slight right:true, |
| todo exits | a,e | ab,bc,eb | depart,roundabout-exit-undefined,arrive | ,slight right:true slight right:true slight right:true, |
@anticipate @todo
Scenario: Roundabout with lanes only tagged on exit
Given the node map
cucumber: change syntax of node maps
2016-09-30 03:33:08 -04:00
"""
/e\
a – b d – f
\c/
"""
Improves Lane Handling for Multi-Hop Roundabout Instruction This changeset implements Lane Anticipation on roundabouts, delimited by enter / leave step pairs. It does not handle lane anticipation within a roundabout. Lane anticipation happens on the granularity of a valid roundbaout: We discard partial roundabout (enter without exit or exit without enter) or data issues (no roundabout, exit before enter). Related: - https://github.com/Project-OSRM/osrm-backend/issues/2626 for lanes within a roundabout - https://github.com/Project-OSRM/osrm-backend/issues/2625 for handling going straight in lane anticipation
2016-06-30 06:10:48 -04:00
And the ways
move hardcoded road priorities into profiles, change road classification
2016-06-24 10:06:45 -04:00
| nodes | turn:lanes:forward | highway | junction |
| ab | | primary | |
| bc | | primary | roundabout |
Fix tests after cucumber update and changed escaping.
2016-07-13 05:48:53 -04:00
| cd | slight_left\|slight_left\|slight_right | primary | roundabout |
move hardcoded road priorities into profiles, change road classification
2016-06-24 10:06:45 -04:00
| de | | primary | roundabout |
| eb | | primary | roundabout |
| df | | primary | |
Improves Lane Handling for Multi-Hop Roundabout Instruction This changeset implements Lane Anticipation on roundabouts, delimited by enter / leave step pairs. It does not handle lane anticipation within a roundabout. Lane anticipation happens on the granularity of a valid roundbaout: We discard partial roundabout (enter without exit or exit without enter) or data issues (no roundabout, exit before enter). Related: - https://github.com/Project-OSRM/osrm-backend/issues/2626 for lanes within a roundabout - https://github.com/Project-OSRM/osrm-backend/issues/2625 for handling going straight in lane anticipation
2016-06-30 06:10:48 -04:00
When I route I should get
deprecate use-lane -- the information can be found in the intersections array
2017-07-10 06:46:18 -04:00
| waypoints | route | turns | lanes | intersection_lanes |
| a,f | ab,df,df | depart,roundabout-exit-1,arrive | ,, | |
Improves Lane Handling for Multi-Hop Roundabout Instruction This changeset implements Lane Anticipation on roundabouts, delimited by enter / leave step pairs. It does not handle lane anticipation within a roundabout. Lane anticipation happens on the granularity of a valid roundbaout: We discard partial roundabout (enter without exit or exit without enter) or data issues (no roundabout, exit before enter). Related: - https://github.com/Project-OSRM/osrm-backend/issues/2626 for lanes within a roundabout - https://github.com/Project-OSRM/osrm-backend/issues/2625 for handling going straight in lane anticipation
2016-06-30 06:10:48 -04:00
@anticipate
Remove lanes from roundabouts, closes #2626 After half a day of looking at the tagging and the data came to the following conclusion: We can't keep the user to the innermost / outermost lanes depending on the exit the route takes: we found situations where both heuristics were wrong. Even on popular roundabouts the tagging is often wrong or in the best case not present at all. There are at least two different ways to interpret roundabout indications: 1/ where e.g. a right arrow on the lane indicates turn restrictions for the roundabout and the need to take this lane to exit the roundabout to the right (possibly skipping multiple exits) and 2/ where a right arrow just means this is a lane in a immediate right turn. Example: Australia marks lanes with arrows that seem to indicate "angles you can exit the roundabout from", for example, these two ways: - http://www.openstreetmap.org/way/320941710 - http://www.openstreetmap.org/way/42918021 Whereas Germany marks lanes with "directions you can travel in these lanes immediately after entering the roundabout": - http://www.openstreetmap.org/way/52578338 These two different interpretations of how to draw the arrows on the roads mean we have conflicting solutions to "which lanes can you use to take exit B from entry A" based on locality. Continuing to tag ways based on lane markings is no problem, but unfortunately, we can't reliably resolve good advice for navigation system users (like "use the inside lane to take the second exit at the roundabout"), there are too many situations that would generate bad instructions (instructions that tell users to go into a lane they shouldn't use).
2016-07-22 12:59:08 -04:00
Scenario: No Lanes for Roundabouts, see #2626
Improves Lane Handling for Multi-Hop Roundabout Instruction This changeset implements Lane Anticipation on roundabouts, delimited by enter / leave step pairs. It does not handle lane anticipation within a roundabout. Lane anticipation happens on the granularity of a valid roundbaout: We discard partial roundabout (enter without exit or exit without enter) or data issues (no roundabout, exit before enter). Related: - https://github.com/Project-OSRM/osrm-backend/issues/2626 for lanes within a roundabout - https://github.com/Project-OSRM/osrm-backend/issues/2625 for handling going straight in lane anticipation
2016-06-30 06:10:48 -04:00
Given the node map
cucumber: change syntax of node maps
2016-09-30 03:33:08 -04:00
"""
a
|
/b\
c g – h
/| |
| d f
|/ \e/ \
x \ y
"""
Improves Lane Handling for Multi-Hop Roundabout Instruction This changeset implements Lane Anticipation on roundabouts, delimited by enter / leave step pairs. It does not handle lane anticipation within a roundabout. Lane anticipation happens on the granularity of a valid roundbaout: We discard partial roundabout (enter without exit or exit without enter) or data issues (no roundabout, exit before enter). Related: - https://github.com/Project-OSRM/osrm-backend/issues/2626 for lanes within a roundabout - https://github.com/Project-OSRM/osrm-backend/issues/2625 for handling going straight in lane anticipation
2016-06-30 06:10:48 -04:00
And the ways
| nodes | turn:lanes:forward | highway | junction |
| ab | slight_right\|slight_right | primary | |
| bc | | primary | roundabout |
| cd | | primary | roundabout |
| de | | primary | roundabout |
| ef | | primary | roundabout |
Improves lane handling for subsequent going straight, resolves #2625 Before we only worked on subsequent quick turns, as in: `right, right` keeps the user on the rightmost lanes. This changeset modifies the logic to work on any subsequent steps that are "quick" and have lane information we can constrain later. Because we do not have a from-lane => to-lanes mapping we take the lanes left and right of the turn lanes into account when heuristically assigning the leftmost / rightmost lanes. There are some edge cases where this still does not give us the optimal solution but it gets close to what is actually possible at the moment without having a lane mapping in post-processing. References: - https://github.com/Project-OSRM/osrm-backend/issues/2625 fix rebase
2016-07-08 06:39:29 -04:00
| fg | through\|slight_right | primary | roundabout |
Improves Lane Handling for Multi-Hop Roundabout Instruction This changeset implements Lane Anticipation on roundabouts, delimited by enter / leave step pairs. It does not handle lane anticipation within a roundabout. Lane anticipation happens on the granularity of a valid roundbaout: We discard partial roundabout (enter without exit or exit without enter) or data issues (no roundabout, exit before enter). Related: - https://github.com/Project-OSRM/osrm-backend/issues/2626 for lanes within a roundabout - https://github.com/Project-OSRM/osrm-backend/issues/2625 for handling going straight in lane anticipation
2016-06-30 06:10:48 -04:00
| gb | | primary | roundabout |
| gh | | primary | |
| cx | | primary | |
| dx | | primary | |
| ey | | primary | |
| fy | | primary | |
When I route I should get
deprecate use-lane -- the information can be found in the intersections array
2017-07-10 06:46:18 -04:00
| waypoints | route | turns | lanes |
| a,h | ab,gh,gh | depart,roundabout-exit-5,arrive | ,;;;;;, |
Improves Lane Handling for Multi-Hop Roundabout Instruction This changeset implements Lane Anticipation on roundabouts, delimited by enter / leave step pairs. It does not handle lane anticipation within a roundabout. Lane anticipation happens on the granularity of a valid roundbaout: We discard partial roundabout (enter without exit or exit without enter) or data issues (no roundabout, exit before enter). Related: - https://github.com/Project-OSRM/osrm-backend/issues/2626 for lanes within a roundabout - https://github.com/Project-OSRM/osrm-backend/issues/2625 for handling going straight in lane anticipation
2016-06-30 06:10:48 -04:00
@anticipate
Remove lanes from roundabouts, closes #2626 After half a day of looking at the tagging and the data came to the following conclusion: We can't keep the user to the innermost / outermost lanes depending on the exit the route takes: we found situations where both heuristics were wrong. Even on popular roundabouts the tagging is often wrong or in the best case not present at all. There are at least two different ways to interpret roundabout indications: 1/ where e.g. a right arrow on the lane indicates turn restrictions for the roundabout and the need to take this lane to exit the roundabout to the right (possibly skipping multiple exits) and 2/ where a right arrow just means this is a lane in a immediate right turn. Example: Australia marks lanes with arrows that seem to indicate "angles you can exit the roundabout from", for example, these two ways: - http://www.openstreetmap.org/way/320941710 - http://www.openstreetmap.org/way/42918021 Whereas Germany marks lanes with "directions you can travel in these lanes immediately after entering the roundabout": - http://www.openstreetmap.org/way/52578338 These two different interpretations of how to draw the arrows on the roads mean we have conflicting solutions to "which lanes can you use to take exit B from entry A" based on locality. Continuing to tag ways based on lane markings is no problem, but unfortunately, we can't reliably resolve good advice for navigation system users (like "use the inside lane to take the second exit at the roundabout"), there are too many situations that would generate bad instructions (instructions that tell users to go into a lane they shouldn't use).
2016-07-22 12:59:08 -04:00
Scenario: No Lanes for Roundabouts, see #2626
Improves Lane Handling for Multi-Hop Roundabout Instruction This changeset implements Lane Anticipation on roundabouts, delimited by enter / leave step pairs. It does not handle lane anticipation within a roundabout. Lane anticipation happens on the granularity of a valid roundbaout: We discard partial roundabout (enter without exit or exit without enter) or data issues (no roundabout, exit before enter). Related: - https://github.com/Project-OSRM/osrm-backend/issues/2626 for lanes within a roundabout - https://github.com/Project-OSRM/osrm-backend/issues/2625 for handling going straight in lane anticipation
2016-06-30 06:10:48 -04:00
Given the node map
cucumber: change syntax of node maps
2016-09-30 03:33:08 -04:00
"""
/a\
x – b d – y
\c/
"""
Improves Lane Handling for Multi-Hop Roundabout Instruction This changeset implements Lane Anticipation on roundabouts, delimited by enter / leave step pairs. It does not handle lane anticipation within a roundabout. Lane anticipation happens on the granularity of a valid roundbaout: We discard partial roundabout (enter without exit or exit without enter) or data issues (no roundabout, exit before enter). Related: - https://github.com/Project-OSRM/osrm-backend/issues/2626 for lanes within a roundabout - https://github.com/Project-OSRM/osrm-backend/issues/2625 for handling going straight in lane anticipation
2016-06-30 06:10:48 -04:00
And the ways
| nodes | turn:lanes:forward | highway | junction | name |
| xb | slight_right\|slight_right | primary | | xb |
| dy | | primary | | dy |
| ab | | primary | roundabout | roundabout |
| bc | | primary | roundabout | roundabout |
| cd | left\|slight_right | primary | roundabout | roundabout |
| da | | primary | roundabout | roundabout |
When I route I should get
Remove lanes from roundabouts, closes #2626 After half a day of looking at the tagging and the data came to the following conclusion: We can't keep the user to the innermost / outermost lanes depending on the exit the route takes: we found situations where both heuristics were wrong. Even on popular roundabouts the tagging is often wrong or in the best case not present at all. There are at least two different ways to interpret roundabout indications: 1/ where e.g. a right arrow on the lane indicates turn restrictions for the roundabout and the need to take this lane to exit the roundabout to the right (possibly skipping multiple exits) and 2/ where a right arrow just means this is a lane in a immediate right turn. Example: Australia marks lanes with arrows that seem to indicate "angles you can exit the roundabout from", for example, these two ways: - http://www.openstreetmap.org/way/320941710 - http://www.openstreetmap.org/way/42918021 Whereas Germany marks lanes with "directions you can travel in these lanes immediately after entering the roundabout": - http://www.openstreetmap.org/way/52578338 These two different interpretations of how to draw the arrows on the roads mean we have conflicting solutions to "which lanes can you use to take exit B from entry A" based on locality. Continuing to tag ways based on lane markings is no problem, but unfortunately, we can't reliably resolve good advice for navigation system users (like "use the inside lane to take the second exit at the roundabout"), there are too many situations that would generate bad instructions (instructions that tell users to go into a lane they shouldn't use).
2016-07-22 12:59:08 -04:00
| waypoints | route | turns | lanes |
deprecate use-lane -- the information can be found in the intersections array
2017-07-10 06:46:18 -04:00
| x,y | xb,dy,dy | depart,roundabout-exit-1,arrive | ,;, |
Remove lanes from roundabouts, closes #2626 After half a day of looking at the tagging and the data came to the following conclusion: We can't keep the user to the innermost / outermost lanes depending on the exit the route takes: we found situations where both heuristics were wrong. Even on popular roundabouts the tagging is often wrong or in the best case not present at all. There are at least two different ways to interpret roundabout indications: 1/ where e.g. a right arrow on the lane indicates turn restrictions for the roundabout and the need to take this lane to exit the roundabout to the right (possibly skipping multiple exits) and 2/ where a right arrow just means this is a lane in a immediate right turn. Example: Australia marks lanes with arrows that seem to indicate "angles you can exit the roundabout from", for example, these two ways: - http://www.openstreetmap.org/way/320941710 - http://www.openstreetmap.org/way/42918021 Whereas Germany marks lanes with "directions you can travel in these lanes immediately after entering the roundabout": - http://www.openstreetmap.org/way/52578338 These two different interpretations of how to draw the arrows on the roads mean we have conflicting solutions to "which lanes can you use to take exit B from entry A" based on locality. Continuing to tag ways based on lane markings is no problem, but unfortunately, we can't reliably resolve good advice for navigation system users (like "use the inside lane to take the second exit at the roundabout"), there are too many situations that would generate bad instructions (instructions that tell users to go into a lane they shouldn't use).
2016-07-22 12:59:08 -04:00
| x,c | xb,roundabout,roundabout | depart,roundabout-exit-undefined,arrive | ,, |
deprecate use-lane -- the information can be found in the intersections array
2017-07-10 06:46:18 -04:00
| x,a | xb,roundabout,roundabout | depart,roundabout-exit-undefined,arrive | ,;, |
make roundabout maneuvers continuous with respect to lane changes
2016-07-15 08:14:06 -04:00
added a lanes test in clockwise roundabouts
2016-07-20 08:05:53 -04:00
@anticipate
Scenario: No Lanes for Roundabouts, see #2626
profiles api v2
2017-05-18 08:27:28 -04:00
Given the profile file "car" initialized with
Added profile files per test generation
2016-09-26 16:25:54 -04:00
"""
profiles api v2
2017-05-18 08:27:28 -04:00
profile.left_hand_driving = true
Added profile files per test generation
2016-09-26 16:25:54 -04:00
"""
added a lanes test in clockwise roundabouts
2016-07-20 08:05:53 -04:00
And the node map
cucumber: change syntax of node maps
2016-09-30 03:33:08 -04:00
"""
a
|
/b\
h – c g
| |\
d f |
/ \e/ \|
x / y
"""
added a lanes test in clockwise roundabouts
2016-07-20 08:05:53 -04:00
And the ways
| nodes | turn:lanes:forward | highway | junction |
| ab | slight_left\|slight_left | primary | |
| bg | | primary | roundabout |
| gf | | primary | roundabout |
| fe | | primary | roundabout |
| ed | | primary | roundabout |
| dc | slight_left | primary | roundabout |
| cb | | primary | roundabout |
| ch | | primary | |
| ex | | primary | |
| dx | | primary | |
| gy | | primary | |
| fy | | primary | |
When I route I should get
deprecate use-lane -- the information can be found in the intersections array
2017-07-10 06:46:18 -04:00
| waypoints | route | turns | lanes |
| a,h | ab,ch,ch | depart,roundabout-exit-5,arrive | ,;;;;;, |
added a lanes test in clockwise roundabouts
2016-07-20 08:05:53 -04:00
make roundabout maneuvers continuous with respect to lane changes
2016-07-15 08:14:06 -04:00
@anticipate
Remove lanes from roundabouts, closes #2626 After half a day of looking at the tagging and the data came to the following conclusion: We can't keep the user to the innermost / outermost lanes depending on the exit the route takes: we found situations where both heuristics were wrong. Even on popular roundabouts the tagging is often wrong or in the best case not present at all. There are at least two different ways to interpret roundabout indications: 1/ where e.g. a right arrow on the lane indicates turn restrictions for the roundabout and the need to take this lane to exit the roundabout to the right (possibly skipping multiple exits) and 2/ where a right arrow just means this is a lane in a immediate right turn. Example: Australia marks lanes with arrows that seem to indicate "angles you can exit the roundabout from", for example, these two ways: - http://www.openstreetmap.org/way/320941710 - http://www.openstreetmap.org/way/42918021 Whereas Germany marks lanes with "directions you can travel in these lanes immediately after entering the roundabout": - http://www.openstreetmap.org/way/52578338 These two different interpretations of how to draw the arrows on the roads mean we have conflicting solutions to "which lanes can you use to take exit B from entry A" based on locality. Continuing to tag ways based on lane markings is no problem, but unfortunately, we can't reliably resolve good advice for navigation system users (like "use the inside lane to take the second exit at the roundabout"), there are too many situations that would generate bad instructions (instructions that tell users to go into a lane they shouldn't use).
2016-07-22 12:59:08 -04:00
Scenario: No Lanes for Roundabouts, see #2626
make roundabout maneuvers continuous with respect to lane changes
2016-07-15 08:14:06 -04:00
Given the node map
cucumber: change syntax of node maps
2016-09-30 03:33:08 -04:00
"""
/a\
x – b d – y
| |
| |
| |
| |
Trigger lane anticipation based on distance, see discussion in #4260
2017-07-17 04:51:16 -04:00
\ /
cucumber: change syntax of node maps
2016-09-30 03:33:08 -04:00
c
"""
make roundabout maneuvers continuous with respect to lane changes
2016-07-15 08:14:06 -04:00
And the ways
| nodes | turn:lanes:forward | highway | junction | name |
| xb | slight_right\|slight_right | primary | | xb |
| dy | | primary | | dy |
| ab | | primary | roundabout | roundabout |
| bc | | primary | roundabout | roundabout |
| cd | left\|slight_right | primary | roundabout | roundabout |
| da | | primary | roundabout | roundabout |
When I route I should get
Remove lanes from roundabouts, closes #2626 After half a day of looking at the tagging and the data came to the following conclusion: We can't keep the user to the innermost / outermost lanes depending on the exit the route takes: we found situations where both heuristics were wrong. Even on popular roundabouts the tagging is often wrong or in the best case not present at all. There are at least two different ways to interpret roundabout indications: 1/ where e.g. a right arrow on the lane indicates turn restrictions for the roundabout and the need to take this lane to exit the roundabout to the right (possibly skipping multiple exits) and 2/ where a right arrow just means this is a lane in a immediate right turn. Example: Australia marks lanes with arrows that seem to indicate "angles you can exit the roundabout from", for example, these two ways: - http://www.openstreetmap.org/way/320941710 - http://www.openstreetmap.org/way/42918021 Whereas Germany marks lanes with "directions you can travel in these lanes immediately after entering the roundabout": - http://www.openstreetmap.org/way/52578338 These two different interpretations of how to draw the arrows on the roads mean we have conflicting solutions to "which lanes can you use to take exit B from entry A" based on locality. Continuing to tag ways based on lane markings is no problem, but unfortunately, we can't reliably resolve good advice for navigation system users (like "use the inside lane to take the second exit at the roundabout"), there are too many situations that would generate bad instructions (instructions that tell users to go into a lane they shouldn't use).
2016-07-22 12:59:08 -04:00
| waypoints | route | turns | lanes |
deprecate use-lane -- the information can be found in the intersections array
2017-07-10 06:46:18 -04:00
| x,y | xb,dy,dy | depart,roundabout-exit-1,arrive | ,;, |
Remove lanes from roundabouts, closes #2626 After half a day of looking at the tagging and the data came to the following conclusion: We can't keep the user to the innermost / outermost lanes depending on the exit the route takes: we found situations where both heuristics were wrong. Even on popular roundabouts the tagging is often wrong or in the best case not present at all. There are at least two different ways to interpret roundabout indications: 1/ where e.g. a right arrow on the lane indicates turn restrictions for the roundabout and the need to take this lane to exit the roundabout to the right (possibly skipping multiple exits) and 2/ where a right arrow just means this is a lane in a immediate right turn. Example: Australia marks lanes with arrows that seem to indicate "angles you can exit the roundabout from", for example, these two ways: - http://www.openstreetmap.org/way/320941710 - http://www.openstreetmap.org/way/42918021 Whereas Germany marks lanes with "directions you can travel in these lanes immediately after entering the roundabout": - http://www.openstreetmap.org/way/52578338 These two different interpretations of how to draw the arrows on the roads mean we have conflicting solutions to "which lanes can you use to take exit B from entry A" based on locality. Continuing to tag ways based on lane markings is no problem, but unfortunately, we can't reliably resolve good advice for navigation system users (like "use the inside lane to take the second exit at the roundabout"), there are too many situations that would generate bad instructions (instructions that tell users to go into a lane they shouldn't use).
2016-07-22 12:59:08 -04:00
| x,c | xb,roundabout,roundabout | depart,roundabout-exit-undefined,arrive | ,, |
deprecate use-lane -- the information can be found in the intersections array
2017-07-10 06:46:18 -04:00
| x,a | xb,roundabout,roundabout | depart,roundabout-exit-undefined,arrive | ,;, |
Improves Lane Handling for Multi-Hop Roundabout Instruction This changeset implements Lane Anticipation on roundabouts, delimited by enter / leave step pairs. It does not handle lane anticipation within a roundabout. Lane anticipation happens on the granularity of a valid roundbaout: We discard partial roundabout (enter without exit or exit without enter) or data issues (no roundabout, exit before enter). Related: - https://github.com/Project-OSRM/osrm-backend/issues/2626 for lanes within a roundabout - https://github.com/Project-OSRM/osrm-backend/issues/2625 for handling going straight in lane anticipation
2016-06-30 06:10:48 -04:00
adjust testscases for collapse of use lane
2016-07-22 03:08:40 -04:00
@anticipate @todo @2032
Remove lanes from roundabouts, closes #2626 After half a day of looking at the tagging and the data came to the following conclusion: We can't keep the user to the innermost / outermost lanes depending on the exit the route takes: we found situations where both heuristics were wrong. Even on popular roundabouts the tagging is often wrong or in the best case not present at all. There are at least two different ways to interpret roundabout indications: 1/ where e.g. a right arrow on the lane indicates turn restrictions for the roundabout and the need to take this lane to exit the roundabout to the right (possibly skipping multiple exits) and 2/ where a right arrow just means this is a lane in a immediate right turn. Example: Australia marks lanes with arrows that seem to indicate "angles you can exit the roundabout from", for example, these two ways: - http://www.openstreetmap.org/way/320941710 - http://www.openstreetmap.org/way/42918021 Whereas Germany marks lanes with "directions you can travel in these lanes immediately after entering the roundabout": - http://www.openstreetmap.org/way/52578338 These two different interpretations of how to draw the arrows on the roads mean we have conflicting solutions to "which lanes can you use to take exit B from entry A" based on locality. Continuing to tag ways based on lane markings is no problem, but unfortunately, we can't reliably resolve good advice for navigation system users (like "use the inside lane to take the second exit at the roundabout"), there are too many situations that would generate bad instructions (instructions that tell users to go into a lane they shouldn't use).
2016-07-22 12:59:08 -04:00
Scenario: No Lanes for Roundabouts, see #2626
Improves Lane Handling for Multi-Hop Roundabout Instruction This changeset implements Lane Anticipation on roundabouts, delimited by enter / leave step pairs. It does not handle lane anticipation within a roundabout. Lane anticipation happens on the granularity of a valid roundbaout: We discard partial roundabout (enter without exit or exit without enter) or data issues (no roundabout, exit before enter). Related: - https://github.com/Project-OSRM/osrm-backend/issues/2626 for lanes within a roundabout - https://github.com/Project-OSRM/osrm-backend/issues/2625 for handling going straight in lane anticipation
2016-06-30 06:10:48 -04:00
Given the node map
cucumber: change syntax of node maps
2016-09-30 03:33:08 -04:00
"""
a – b –x
|
/c\
d f – g – z
\e/ |
| h
y
"""
Improves Lane Handling for Multi-Hop Roundabout Instruction This changeset implements Lane Anticipation on roundabouts, delimited by enter / leave step pairs. It does not handle lane anticipation within a roundabout. Lane anticipation happens on the granularity of a valid roundbaout: We discard partial roundabout (enter without exit or exit without enter) or data issues (no roundabout, exit before enter). Related: - https://github.com/Project-OSRM/osrm-backend/issues/2626 for lanes within a roundabout - https://github.com/Project-OSRM/osrm-backend/issues/2625 for handling going straight in lane anticipation
2016-06-30 06:10:48 -04:00
And the ways
don't assign lanes on delayed turns
2016-07-08 05:45:36 -04:00
| nodes | turn:lanes:forward | highway | junction | name |
| ab | through\|right\|right\|right\|right | primary | | abx |
| bx | | primary | | abx |
| bc | right\|right\|right\|right | primary | | bc |
| cd | | primary | roundabout | cdefc |
| de | slight_left\|slight_left\|slight_left\|slight_right | primary | roundabout | cdefc |
| ef | left\|slight_right\|slight_right | primary | roundabout | cdefc |
| fc | | primary | roundabout | cdefc |
| ey | | primary | | ey |
| fg | through\|right | primary | | fg |
| gz | | primary | | gz |
| gh | | primary | | gh |
Improves Lane Handling for Multi-Hop Roundabout Instruction This changeset implements Lane Anticipation on roundabouts, delimited by enter / leave step pairs. It does not handle lane anticipation within a roundabout. Lane anticipation happens on the granularity of a valid roundbaout: We discard partial roundabout (enter without exit or exit without enter) or data issues (no roundabout, exit before enter). Related: - https://github.com/Project-OSRM/osrm-backend/issues/2626 for lanes within a roundabout - https://github.com/Project-OSRM/osrm-backend/issues/2625 for handling going straight in lane anticipation
2016-06-30 06:10:48 -04:00
When I route I should get
Be more aggresive classifying Roundabout Intersections. Roundabout Intersections are roundabouts with up to four ways and turn angles which makes the turns obvious, e.g. as in: ``` * * * * * * * * ``` but not ``` * * * * * * * * * ``` For Roundabout Intersections we issue instructions such as "turn <direction>" instead of "take the <nth> exit". At the moment we have a limit on the radius for these Roundabout Intersections of 5 meters. Which fails to classify a wide range of Roundabout Intersections in the US (with the US-wide streets). This changeset removes the Roundabout Intersection radius limit: - if the roundabout is larger than a threshold and is named we classify it as a rotary - if the roundabout matches our criteria for Roundabout Intersections we classify it as a Roundabout Intersection - else fallback to plain old Roundabout There is a second issue with determining a roundabout's radius. But that's for another pull request (tracking in #2716). References: - https://github.com/Project-OSRM/osrm-backend/issues/2716
2016-07-29 15:35:01 -04:00
| waypoints | route | turns | lanes |
Remove lanes from roundabouts, closes #2626 After half a day of looking at the tagging and the data came to the following conclusion: We can't keep the user to the innermost / outermost lanes depending on the exit the route takes: we found situations where both heuristics were wrong. Even on popular roundabouts the tagging is often wrong or in the best case not present at all. There are at least two different ways to interpret roundabout indications: 1/ where e.g. a right arrow on the lane indicates turn restrictions for the roundabout and the need to take this lane to exit the roundabout to the right (possibly skipping multiple exits) and 2/ where a right arrow just means this is a lane in a immediate right turn. Example: Australia marks lanes with arrows that seem to indicate "angles you can exit the roundabout from", for example, these two ways: - http://www.openstreetmap.org/way/320941710 - http://www.openstreetmap.org/way/42918021 Whereas Germany marks lanes with "directions you can travel in these lanes immediately after entering the roundabout": - http://www.openstreetmap.org/way/52578338 These two different interpretations of how to draw the arrows on the roads mean we have conflicting solutions to "which lanes can you use to take exit B from entry A" based on locality. Continuing to tag ways based on lane markings is no problem, but unfortunately, we can't reliably resolve good advice for navigation system users (like "use the inside lane to take the second exit at the roundabout"), there are too many situations that would generate bad instructions (instructions that tell users to go into a lane they shouldn't use).
2016-07-22 12:59:08 -04:00
| a,h | abx,bc,fg,gh,gh | depart,turn right,cdefc-exit-2,turn right,arrive | ,straight:false right:false right:false right:false right:true,,straight:false right:true, |
Improves Lane Handling for Multi-Hop Roundabout Instruction This changeset implements Lane Anticipation on roundabouts, delimited by enter / leave step pairs. It does not handle lane anticipation within a roundabout. Lane anticipation happens on the granularity of a valid roundbaout: We discard partial roundabout (enter without exit or exit without enter) or data issues (no roundabout, exit before enter). Related: - https://github.com/Project-OSRM/osrm-backend/issues/2626 for lanes within a roundabout - https://github.com/Project-OSRM/osrm-backend/issues/2625 for handling going straight in lane anticipation
2016-06-30 06:10:48 -04:00
Improves lane handling for subsequent going straight, resolves #2625 Before we only worked on subsequent quick turns, as in: `right, right` keeps the user on the rightmost lanes. This changeset modifies the logic to work on any subsequent steps that are "quick" and have lane information we can constrain later. Because we do not have a from-lane => to-lanes mapping we take the lanes left and right of the turn lanes into account when heuristically assigning the leftmost / rightmost lanes. There are some edge cases where this still does not give us the optimal solution but it gets close to what is actually possible at the moment without having a lane mapping in post-processing. References: - https://github.com/Project-OSRM/osrm-backend/issues/2625 fix rebase
2016-07-08 06:39:29 -04:00
@anticipate
Scenario: Anticipate none tags
Given the node map
cucumber: change syntax of node maps
2016-09-30 03:33:08 -04:00
"""
c g l
b – d – e – h - i
a f j
"""
Improves lane handling for subsequent going straight, resolves #2625 Before we only worked on subsequent quick turns, as in: `right, right` keeps the user on the rightmost lanes. This changeset modifies the logic to work on any subsequent steps that are "quick" and have lane information we can constrain later. Because we do not have a from-lane => to-lanes mapping we take the lanes left and right of the turn lanes into account when heuristically assigning the leftmost / rightmost lanes. There are some edge cases where this still does not give us the optimal solution but it gets close to what is actually possible at the moment without having a lane mapping in post-processing. References: - https://github.com/Project-OSRM/osrm-backend/issues/2625 fix rebase
2016-07-08 06:39:29 -04:00
And the ways
| nodes | turn:lanes:forward | highway | name |
| ab | none\|none\|right\|right | primary | abc |
| bc | | primary | abc |
| bd | | primary | bdeh |
| de | left\|none\|none\|right | primary | bdeh |
| eh | | primary | bdeh |
| ef | | primary | feg |
| eg | | primary | feg |
When I route I should get
| waypoints | route | turns | lanes |
| a,g | abc,bdeh,feg,feg | depart,turn right,turn left,arrive | ,none:false none:false right:true right:false,left:true none:false none:false right:false, |
| a,f | abc,bdeh,feg,feg | depart,turn right,turn right,arrive | ,none:false none:false right:false right:true,left:false none:false none:false right:true, |
@anticipate
Close GH-2795: Rewrite cucumber test caching (and support logic). Fixes #2745
2016-09-19 17:13:44 -04:00
Scenario: Triple Right keeping Left
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
Given the node map
cucumber: change syntax of node maps
2016-09-30 03:33:08 -04:00
"""
a – b – i
|
f – e – g |
| |
| |
j – d – – c
|
h
"""
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
And the ways
| nodes | turn:lanes:forward | highway | name |
update cucumber to 1.2.1 and remove hack
2016-07-07 09:31:20 -04:00
| abi | \|\|right\|right | primary | start |
| bch | \|\|right\|right | primary | first |
| cdj | \|\|right\|right | primary | second |
| de | left\|right\|right | secondary | third |
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
| feg | | tertiary | fourth |
When I route I should get
Improves lane handling for subsequent going straight, resolves #2625 Before we only worked on subsequent quick turns, as in: `right, right` keeps the user on the rightmost lanes. This changeset modifies the logic to work on any subsequent steps that are "quick" and have lane information we can constrain later. Because we do not have a from-lane => to-lanes mapping we take the lanes left and right of the turn lanes into account when heuristically assigning the leftmost / rightmost lanes. There are some edge cases where this still does not give us the optimal solution but it gets close to what is actually possible at the moment without having a lane mapping in post-processing. References: - https://github.com/Project-OSRM/osrm-backend/issues/2625 fix rebase
2016-07-08 06:39:29 -04:00
| waypoints | route | turns | lanes |
| a,f | start,first,second,third,fourth,fourth | depart,turn right,turn right,turn right,turn left,arrive | ,none:false none:false right:true right:false,none:false none:false right:true right:false,none:false none:false right:true right:false,left:true right:false right:false, |
| a,g | start,first,second,third,fourth,fourth | depart,turn right,turn right,turn right,turn right,arrive | ,none:false none:false right:true right:true,none:false none:false right:true right:true,none:false none:false right:true right:true,left:false right:true right:true, |
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
Improves lane handling for subsequent going straight, resolves #2625 Before we only worked on subsequent quick turns, as in: `right, right` keeps the user on the rightmost lanes. This changeset modifies the logic to work on any subsequent steps that are "quick" and have lane information we can constrain later. Because we do not have a from-lane => to-lanes mapping we take the lanes left and right of the turn lanes into account when heuristically assigning the leftmost / rightmost lanes. There are some edge cases where this still does not give us the optimal solution but it gets close to what is actually possible at the moment without having a lane mapping in post-processing. References: - https://github.com/Project-OSRM/osrm-backend/issues/2625 fix rebase
2016-07-08 06:39:29 -04:00
@anticipate
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
Scenario: Tripple Left keeping Right
Given the node map
cucumber: change syntax of node maps
2016-09-30 03:33:08 -04:00
"""
i – b – a
|
| g – e – f
| |
| |
c – – d – j
|
h
"""
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
And the ways
| nodes | turn:lanes:forward | highway | name |
update cucumber to 1.2.1 and remove hack
2016-07-07 09:31:20 -04:00
| abi | left\|left\|\| | primary | start |
| bch | left\|left\|\| | primary | first |
| cdj | left\|left\|\| | primary | second |
| de | left\|left\|right | secondary | third |
Anticipate Lane Changes
2016-06-06 07:52:41 -04:00
| feg | | tertiary | fourth |
When I route I should get
Improves lane handling for subsequent going straight, resolves #2625 Before we only worked on subsequent quick turns, as in: `right, right` keeps the user on the rightmost lanes. This changeset modifies the logic to work on any subsequent steps that are "quick" and have lane information we can constrain later. Because we do not have a from-lane => to-lanes mapping we take the lanes left and right of the turn lanes into account when heuristically assigning the leftmost / rightmost lanes. There are some edge cases where this still does not give us the optimal solution but it gets close to what is actually possible at the moment without having a lane mapping in post-processing. References: - https://github.com/Project-OSRM/osrm-backend/issues/2625 fix rebase
2016-07-08 06:39:29 -04:00
| waypoints | route | turns | lanes |
| a,f | start,first,second,third,fourth,fourth | depart,turn left,turn left,turn left,turn right,arrive | ,left:false left:true none:false none:false,left:false left:true none:false none:false,left:false left:true none:false none:false,left:false left:false right:true, |
| a,g | start,first,second,third,fourth,fourth | depart,turn left,turn left,turn left,turn left,arrive | ,left:true left:true none:false none:false,left:true left:true none:false none:false,left:true left:true none:false none:false,left:true left:true right:false, |
Consider number of lanes to cross, resolves #3025. Lane Anticipation currently triggers on quick steps with lanes. This changeset makes the "quick" part more dynamic by taking lanes left and right of the turn into account. The reasoning for this is as follows. The user can drive on the leftmost or rightmost lane and has to cross all lanes left or right of the turn, respecitvely. We scale our threshold appropriately, which now means the threshold describes the duration the user needs for crossing _a single lane_. Note: this is a heuristic and assumes the worst case. Which in my opinion is fine to do since triggering Lane Anticipation in complex scenarios is desirable.
2017-01-03 12:02:19 -05:00
@anticipate
Scenario: Complex lane scenarios scale threshold for triggering Lane Anticipation
Given the node map
"""
a – b – x
|
|
|
c
|
e – d – y
"""
# With a grid size of 20m the duration is ~20s but our default threshold for Lane Anticipation is 15s.
# The additional lanes left and right of the turn scale the threshold up so that Lane Anticipation still triggers.
And the ways
| nodes | turn:lanes:forward | name |
| ab | through\|through\|right\|right | MySt |
| bx | | XSt |
| bc | | MySt |
| cd | left\|right | MySt |
| de | | MySt |
| dy | | YSt |
When I route I should get
respect difference between continue/turn on changing end-of-road
2017-08-11 10:35:39 -04:00
| waypoints | route | turns | lanes |
| a,e | MySt,MySt,MySt,MySt | depart,continue right,continue right,arrive | ,straight:false straight:false right:false right:true,left:false right:true, |
reduce verbosity of use-lane in combination with lane-anticipation
2017-02-13 10:20:10 -05:00
@anticipate
Scenario: Don't Overdo It
Given the node map
"""
Trigger lane anticipation based on distance, see discussion in #4260
2017-07-17 04:51:16 -04:00
q r s t u v
a - - b - - c - - d - - e - - f - g - h - i
p o n m l k j
reduce verbosity of use-lane in combination with lane-anticipation
2017-02-13 10:20:10 -05:00
"""
And the ways
| nodes | name | turn:lanes:forward | oneway |
| ab | road | left\|\|\| | yes |
| bc | road | left\|\|\| | yes |
| cd | road | left\|\|\| | yes |
| de | road | left\|\|\| | yes |
| ef | road | left\|\|\| | yes |
| fg | road | left\|\|\| | yes |
| gh | road | \|\|right | yes |
| hi | road | | yes |
| qbp | 1st | | no |
| rco | 2nd | | no |
| sdn | 3rd | | no |
| tem | 4th | | no |
| ufl | 5th | | no |
| vgk | 6th | | no |
| hj | 7th | | no |
When I route I should get
deprecate use-lane -- the information can be found in the intersections array
2017-07-10 06:46:18 -04:00
| waypoints | route | turns | locations | lanes |
| a,i | road,road | depart,arrive | a,i | ;left:false none:true none:true none:true;left:false none:true none:true none:true;left:false none:true none:true none:true;left:false none:true none:true none:true;left:false none:true none:true none:true;left:false none:true none:true none:false;none:true none:true right:false, |
| a,j | road,7th,7th | depart,turn right,arrive | a,h,j | ;left:false none:true none:true none:true;left:false none:true none:true none:true;left:false none:true none:true none:true;left:false none:true none:true none:true;left:false none:false none:false none:true;left:false none:false none:false none:true,none:false none:false right:true, |
Adds lane anticipation Oak St -> Franklin St -> Fell St scenario
2017-07-21 13:04:55 -04:00
@anticipate
Scenario: Oak St, Franklin St
Given a grid size of 10 meters
Given the node map
"""
g
. . f
. d `
e ` .
.
.
. . c
. b `
a `
"""
And the ways
| nodes | name | turn:lanes | oneway | highway |
| ab | Oak St | left\|left\|left | yes | secondary |
| cb | Oak St | right | yes | tertiary |
| bd | Franklin St | left;through\|through\|through;right\|right | yes | secondary |
| dg | Franklin St | | yes | secondary |
| edf | Fell St | | | secondary |
When I route I should get
| waypoints | route | turns | lanes |
| a,f | Oak St,Franklin St,Fell St,Fell St | depart,turn left,turn right,arrive | ,left:false left:true left:true,straight;left:false straight:false straight;right:true right:true, |
Reference in New Issue Copy Permalink