Prevent u-turns at tower nodes that are connecting different OSM ways

[camelCaseSucks]

This route includes an illegal u-turn in the middle of the bridge

https://graphhopper.com/maps/?point=45.501467%2C-122.661254&point=45.501237%2C-122.66142

OSRM returns the expected route

https://www.openstreetmap.org/directions?engine=fossgis_osrm_car&route=45.5015%2C-122.6613%3B45.5012%2C-122.6613

[easbar]

Thanks for reporting!

This seems to be a u-turn, because if I set u_turn_costs to infinity I get the same route as on OSRM:

https://graphhopper.com/maps/?point=45.501467%2C-122.661254&point=45.501237%2C-122.66142&ch.disable=true&u_turn_costs=-1

Apparently there is a tower node in the middle of the bridge, even though there is no junction. There is a region border though:

@karussell any idea why we get a tower node here?

Btw: I ran into another problem: When I click on the above link (in @camelCaseSucks comment) and then change the vehicle to foot and back to car again I get another route once again, because for some reason turn_costs=false is appended to the url...

[karussell]

@karussell any idea why we get a tower node here?

No, this looks strange. As this is the main issue for me here - should I rename the issue title?

because for some reason turn_costs=false is appended to the url...

outch, this is likely yet another bug in the UI :/

[otbutz]

@karussell any idea why we get a tower node here?

https://www.openstreetmap.org/way/587574521

[easbar]

https://www.openstreetmap.org/way/587574521

What do you think is suspicious here?

[otbutz]

It might be the line crossing the bridge

[easbar]

It might be the line crossing the bridge

Yes, it really looks like it is :) But this is just a region border, so it should not even be considered by our OSM parser? If it was a ferry I would totally understand what happens because this would create a 'ghost junction' : #1858

[boldtrn]

Isn't it because the way in OSM is cut at the region border, so we get a tower node by definition? If one wants to avoid that, you would have to merge the features in OSM.

[easbar]

When GH parses OSM it first checks which of the nodes are really junctions (it counts how many ways there are for every node). And only for real junctions (>2 ways) a tower node is introduced. Otherwise the ways are simply merged into one GH edge (at least this is what I thought so far). But sure you are right this merging would only work if the tags were the same. However, here it looks like they are:

https://www.openstreetmap.org/way/123374695

vs

https://www.openstreetmap.org/way/587574521

But I am pretty sure there are similar cases where the tags are different and then we would have the same problem despite the merging.

[karussell]

Ah, yeah. This is the reason ...

And only for real junctions (>2 ways) a tower node is introduced.

... as soon as 2 ways use the same node a tower node is introduced: https://github.com/graphhopper/graphhopper/blob/master/reader-osm/src/main/java/com/graphhopper/reader/osm/OSMReader.java#L550

and there is no merging code. And even if such merging code would exist the question is really how we could avoid tower node creation when the tags would be different.

Related #758

[easbar]

and there is no merging code

Ah ok so we never merge multiple ways, but we make sure that we do not split single ways when there is no real junction (and use pillar nodes instead). I think this is where my confusion came from.

Ok so in summary the problem is that there can be u-turns at nodes that are not junctions, simply because they connect two OSM ways.

[karussell]

We might have to rethink about when we can allow U-turns because this depends on many things like the vehicle, the circumstances at the junction, the road class (or width), the traffic (or average/max speed) and other things.

We partially already do that when we say that a U-turn is only possible at junctions (due to the space) but we do not make it vehicle-dependent which should be easy as well (e.g. motorcycle vs. car vs. bike). And the road-property-dependency is likely even more important (but probably a bit trickier to implement). E.g. in this issue here it is a primary road and we could say we do not allow U-turns even for junctions (at primary roads)?

[easbar]

Yes we definitely should make this more specific. This probably will decrease performance, but certainly leads to higher quality routing. For the present case we could use road_environment (no u-turns on bridges, ever)? But really we should probably start with a list of cases where u-turns should / should not be allowed (and at which cost).