* Added post process logic to collapse segregated turn instructions
* format updates
* Fixed coordinates to reflect reality
Updated left turn road name
* fixed coordinates to fix test
* Skip last step when processing segregated steps
* updated segregated turn test
* Updated segregated test
* Updated test: Segregated Intersection, Cross Belonging to Correct Street - features/guidance/collapse.feature:79
* Fixed all but one for features/guidance/collapse.feature:124
* Fixed Scenario: Partly Segregated Intersection, Two Segregated Roads, Intersection belongs to Second - features/guidance/collapse.feature:219
* Fixed 7 of th 9 failures for Scenario: Partly Segregated Intersection, Two Segregated Roads, Intersection belongs to Second - features/guidance/collapse.feature:219
* Fixed 7 of the 9 failures for Scenario: Segregated Intersection, Cross Belonging to Mixed Streets - Slight Angles (2) - features/guidance/collapse.feature:318
* Fixed Scenario: Segregated Intersection into Slight Turn - features/guidance/collapse.feature:581
* Updated Scenario: U-turn after a traffic light - features/guidance/turn-lanes.feature:1220
* Updated how we combine segregated steps
* Added test to Verify end of road left turn across divided roads
* Fixed divided highwat tests
* Fixed test failure
* fixed Scenario: Partitioned turn, Slight Curve - maxspeed - features/guidance/turn-lanes.feature:936
* Fixed Scenario: Partitioned turn, Slight Curve - features/guidance/turn-lanes.feature:961
* Added strategies to combine segrgated intersections
* Added setModifier alias for readability
* Added strategies to combine segrgated intersections
* Format updates
* Fixes segregated indentification to not mark `circular` edge as segregated
* Added intersection prior to turn so we still call out end of road
* updated expectation to be turn instead of continue
* Confirmed with @oxidase that the lane information if correct - updated the expectation
* Added logic to handle wider straights
Fixed tests
* Update CHANGELOG.md
Added #4925
* Removed TODO
* Process straight step prior to wider straight step
As a form of smoothing we use the previous speed value instead.
This makes sense because the zero duration segments have to be very
short, potentially also zero length.
- Adding sides parameter into base parameters, it can take the values SIDE, OPPOSITE or DEFAULT.
- Adding url parser for "sides" parameter, url values are "s" for SIDE, "o" for OPPOSITE and "d" for DEFAULT, example : "sides=s;s".
- Checking parameters, if "sides" parameter is used, the number of parameter is the same as number of location.
- Create a phantom to start at side driving or Opposite side driving.
Signed-off-by: FILLAU Jean-Maxime <jean-maxime.fillau@mapotempo.com>
The Map Matching plugin currently has issues with:
- high frequency traces and (performance)
- blobs, think noise at traffic signals (correctness)
This changeset implements trace-tidying transparently for the user.
We hopefully will see both performance gains as well as better matches!
- 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)
Adds an `generate_hints=false` option which lets us skip generating and
emitting hints for Waypoints. This can be used to decrease the response
size when the user does not need hints anyway.
We should think about making `false` the default here in v6.
instead of artificially removing lanes from a roundabout, we don't assing them in the first place.
this also prevents a problem where we would end up collapsing turns with lanes in a roundabout
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).
