Behaviour on roundabouts
Sparrow0hawk opened this issue · comments
Whilst having a look at lane layers I noticed that if you draw a route around a large roundabout route snapper defaults to picking a route that as a road users would be incorrect. Actually having lane layers makes this more obvious, but road users have to travel around the roundabout in a clockwise fashion. I presume this is because of the logic of how we're determining a shortest route.
Steps to reproduce
- Navigate to Warren Vale/Wentworth Road roundabout
- Draw a new route that enters the roundabout starting east on Wentworth road and ends travelling south on Warren Vale
You'll get a route that isn't quite right with the rules of the road.
That's because the route snapper ignores all "semantics" of existing roads; it's doing an undirected graph search over the raw geometry, with only distance as a cost function. The original motivation for that is that while sketching a potential new route, someone might want to ignore the current reality, because they intend to change the road to support what they've drawn. So in this example, maybe the user is imagining a new parallel cycletrack that skips the junction entirely:
This decision was an older one that @Robinlovelace and I discussed; it's a good idea to revisit it. Should the tool work this way? Should it be configurable; should we have a checkbox saying "follow current one-way restrictions"? Maybe at minimum, we should somehow communicate that a route drawn goes against the current lane configuration and will require some kind of changes. That's kind of the direction we're going with the lane layer -- after sketching the desired route shape, we'll go through and analyze what's there currently, how much width is available, and try to guess what kind of changes will need to be made.
Another example of why it can be useful to ignore current direction: contraflow cycle lanes on existing one-way residential streets are increasingly common. It'd be useful at the very least to make it clear to the user where those currently exist and where they're missing/potentially needed
Understood, and totally get why it behaves the way it does, I think I just wasn't expecting it (or hadn't realised till lane layer appeared that this was the case).
I think potentially down the line it would be nice to enable the option of following the flow of the road but perhaps for now making it clear to the user that the Draw Route tool will go against one-way restrictions would be good to have short-term.
Agreed this is surprising behavior. How should we make that clear to the user? In all the UX study videos I watched, nobody even expands the Help text, let alone reads it :\
Relatedly, right now we include different types of rail in the route snapper. This can be very surprising when you suddenly warp across London in bizarre ways! The motivation was originally that some existing aboveground rail might be suitable to build along? That kind of rails-to-trails thing happens sometimes in the US, but is it as relevant here? Should we remove this from the route snapper's graph?
Should we remove this from the route snapper's graph?
Yes let's remove rail. Thinking was that it could be good to highlight potential for routes parallel to railways, a la methods @mem48 and I discussed back in the day in this zombie paper: https://github.com/robinlovelace/infra-active#a-typology-of-active-transport-impacts-of-major-transport-infrastructure-projects
However, it's now clear that the negatives of having lots of weird routes outweigh any potential benefits, especially when you consider than railways are generally straight so easy to sketch with the non-snapping routes.
Rail removed by commit above. I'll regenerate all the files later
Rail should be removed now. https://acteng.github.io/atip/scheme.html?authority=Southwark
Looks good. We can add documentation to ATIP describing the functionality also at some point.
Another example of why it can be useful to ignore current direction: contraflow cycle lanes on existing one-way residential streets are increasingly common.
Another example is hiking routes 😃
I think this issue is fixed: the most useful behaviour for most use cases is for the shortest path to be taken. That's what the tool does. So can we close this?
Agreed. Could be worth adding an option to change the routing algorithm in the future to respect direction or use something other than distance, but no use case for that