U-turns being forbidden at barriers, leading to no-routes when inputs force conditions that would require a u-turn

[danpat]

Issue

Not 100% sure what the issue here is yet, but this test case demonstrates the problem. When you use type=break_through at waypoints, and a u-turn is required at a dead-end, a NoRoute result is the outcome.

I'm not sure whether it's the break_through that's the root cause, or the access=no on the necessary u-turn location in this test, but the test shows the problem.

cc @gknisely

Tasklist

• Add tests
• Add #fixes with the issue number that this PR addresses
• Update the docs with any new request parameters or changes to behavior described
• Update the changelog

Requirements / Relations

Link any requirements here. Other pull requests this PR is based on?

[kevinkreiser]

yeah break_through means you cant turn around at the snap point. it means you at least have to go to the end of the edge, ie continue through the snap point. its basically a way of saying "break" (i want you to make a new leg here) but "go through" (i want you to keep going in the same direction, no immediate uturn at the snap point). but yeah if that leads you into a black hole then i could see why that'd be a problem 😄

[kevinkreiser]

@danpat im a bit confused though. i think recently we (@danpaz) changed this behavior to allow a uturn even where the node has no access: https://github.com/valhalla/valhalla/blob/master/src/thor/bidirectional_astar.cc#L142

🤔

[danpaz]

The change in bidirectional at https://github.com/valhalla/valhalla/pull/2705/files#r534545579 was meant to address cases like these, by allowing a uturn at nodes where access is disallowed. Essentially we now enqueue the reverse edge, where before we were bailing and returning a NoRoute. Now it seems we're back to the old behavior.

It seems like there was a regression around that code, or around the special case handling uturns just below it.

[mandeepsandhu]

When routing with multiple waypoints, do we have to start at the same location the previous leg ended on? Is it not acceptable to, say snap to a different edge if its not possible to continue on the edge the previous leg ended on?

[kevinkreiser]

so currently the code will look at the edge the last leg ended on and remove all candidates but that one when its a "*_through" location. for other types i forget if it does weed them out or not. but if it didnt the route would be pretty wild in that there would be a teleport between snap locations

[danpat]

To be clear - the test isn't expecting a u-turn at the middle waypoint (1) here - it's expecting to continue through the waypoint, then perform the u-turn at the barrier=fence,access=node at the end of the street. For some reason, it's not doing that.

I'm wondering whether use of heading and heading_tolerance could be used to force the same situation without the use of a break_through waypoint. I will try, and push up an additional test if so.

[kevinkreiser]

@danpat yep that is what i understood from your description. i think the changes @danpaz and i linked should account for that but im not sure why it still fails!

[danpat]

Just pushed an additional test using heading - confirms it's not the type=break_through, but the u-turn at the barrier.

[danpaz]

Thanks @danpat !

[danpat]

Did some cleanup on the test - @mandeepsandhu @danpaz @kevinkreiser anyone mind 👍 on this again?

[kevinkreiser]

thanks again!