-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
U-turns not prevented at split edges #5955
Comments
As discussed in todays developer meeting, the above routing behavior looks like a bug that should already be addressed in OpenTripPlanner/src/main/java/org/opentripplanner/street/model/edge/StreetEdge.java Lines 1069 to 1078 in 20fc8ce
However, this apparently seems not to work in case of split edges, where forwardEdge and backwardEdge are split by different splitNodes: |
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days |
Does it only affect cars? If I am driving a bike, I want to be able to U-turn to avoid these restrictions. |
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days |
Is your feature request related to a problem? Please describe.
As a driver, I usually don't want to perform a U-turn. OTP's
SimpleIntersectionTraversalCalculator
currently provides costs for safe and accrossTraffic turns, but not for U-turns.EDIT: U-turns are currently usually prevented by an
isReverse
check in StreetEdge.doTraverse() and state dominance checks. However, this fails under some very special conditions, e.g. when an edge is split by a linked transit stop and the dominance check allows visiting a vertex multiple times because the vertex is close to the request origin/destination. Splitting currently introduces two distinct split nodes so theisReverse
check does not recognize the split forward/backward edges as reversed (see comment below).Goal / high level use-case
Preventing U-turns.
Describe the solution you'd like
I suggest to add costs for U-turns (e.g. between 170 and 190 degrees) inSimpleIntersectionTraversalCalculator
.I suggest to use the same split vertex for forward and backward edge.
Describe alternatives you've considered
IntersectionTraversalCalculator
as Sandbox Feature, which would need an extension ofIntersectionTraversalCalculator.create
to be included.SimpleIntersectionTraversalCalculator
. Turning across traffic already has an additional cost while doing a U turn has not.Additional context
The city of Aachen, Germany wants to inform their citizen about upcoming super block turn restrictions. For this use case, a custom OSM extract was generated, which contains these restrictions. Evaluating these restrictions, OTP's routing circumvents some of them suggesting U-turns:
The text was updated successfully, but these errors were encountered: