Allow u-turns only at dead ends #2883
Conversation
…y ran before, but this is not needed)
# Conflicts: # core/src/main/java/com/graphhopper/routing/util/VehicleEncodedValues.java
# Conflicts: # core/src/main/java/com/graphhopper/routing/util/VehicleEncodedValues.java # core/src/main/java/com/graphhopper/routing/weighting/SpeedWeighting.java
# Conflicts: # core/src/main/java/com/graphhopper/routing/DefaultWeightingFactory.java # core/src/main/java/com/graphhopper/routing/weighting/DefaultTurnCostProvider.java
|
|
||
| import static com.graphhopper.routing.util.EncodingManager.getKey; | ||
|
|
||
| public class DeadEnd { |
There was a problem hiding this comment.
In case there will be u-turns other than dead-ends that we want to explicitly allow in the future, maybe we should use a more general name(?).
There was a problem hiding this comment.
Information. Sorry as (non dev) GPS user I have to describe it less technically.
U-turns are sure very useful.
In the Kurviger and Cruiser app 180° u-turns are very usefully used.
See example in the image and attached gpx navigation track.
By Notepad++ or gpx editor, find turn instructions in trackpoints.
Cruiser_GraphHopper planning.
- This 180° u-turn example here is indeed correctly placed and you indeed are expected to make a -u turn at this location. A such 180° U-turn NOT defined to be a Left nor a Right u-turn command.
- U-turns are shown as a red Icons in the Cruiser turnlist.
- U-turns can usefully be used as alert signal that a shaping or via point may have been falsely placed onto a side road in the planner and causes false annoying turn commands immediate than to be corrected by an 180° u-turn.
Cruiser_Brouter planning.
Same as above but with an extra.
A "correct misplaced via points" tool can presumably thus automatically prevent false out and return track glitches with 180° u-turn commands. The correction distance is adjustable between 0 and 100m (default 40m).
Provided additional shaping point, a 180° u-turn can still be enforced even in this correction range.
Cruiser_Brouter navigation.
If you ignore the u-turn command during navigation, the system does not insist on a 180° u-turn but suggests a forward alternative (large diversions if necessary). As a person, you can of course still turn back.
RouteYou website planner. (osrm router).
Sure allows 180° U-turns. In addition, there is a "correct misplaced via points" tool. The correction distance at which the tool intervenes is 100m. Track glitches shorter than 100m are so automatically prevented.
Usefull u-turn navtrack.gpx.txt
# Conflicts: # core/src/main/java/com/graphhopper/routing/ch/CHPreparationGraph.java
# Conflicts: # core/src/main/java/com/graphhopper/routing/DefaultWeightingFactory.java # core/src/main/java/com/graphhopper/routing/util/VehicleEncodedValues.java # core/src/main/java/com/graphhopper/routing/weighting/DefaultTurnCostProvider.java # core/src/test/java/com/graphhopper/routing/weighting/FastestWeightingTest.java # core/src/test/java/com/graphhopper/routing/weighting/custom/CustomWeightingTest.java
karussell
temporarily deployed
to
benchmarks
GitHub Actions
Inactive
karussell
temporarily deployed
to
benchmarks
GitHub Actions
Inactive
This is based on #2882.
So far we allowed u-turns at every junction, which in some cases yields suboptimal routes. The number of suggested u-turns can be reduced by increasing the u-turn costs, but it is still debatable if suggesting a u-turn at any junction is useful. The better default might be to only allow u-turns at dead-ends, where they are required when curbside or heading parameters are used. In this PR I added a new turn cost encoded value that marks dead ends and adjusted the turn weighting such that u-turns are only allowed at these dead ends.