search

abrensch / brouter

configurable OSM offline router with elevation awareness, Java + Android
MIT License
489 stars 117 forks source link

Routing bug concerning closed highways #425

Open zieglerdo opened 2 years ago

zieglerdo commented 2 years ago

When going through the BRouter suspect list, I stumbled across this example involving a turning loop mapped as a closed (tertiary) highway: http://brouter.de/brouter-web/#map=18/63.37895/10.34700/standard&lonlats=10.347871,63.37902;10.346793,63.378821&profile=car-eco Apparently, the router won't give a route into the loop, which I think is a bug in the BRouter routing engine. However, routing out of the loop is possible: http://brouter.de/brouter-web/#map=18/63.37895/10.34700/standard&lonlats=10.346793,63.378821;10.347871,63.37902&profile=car-eco The problem seems to occur with any profile (not only car). I had a look at the OSM data in JOSM and it appears to be correct. There are no access or oneway tags set on any of the ways. The start and end node of the closed OSM way is also the one that connects the loop to the highway leading to it.

polyscias commented 2 years ago

Yes, I can reproduce the problem on brouter-web and indeed strange.

I am wondering if this is a side-effect of Douglas-Peucker transfer-node elimination, see d2aaeb2 and aa7bb37

polyscias commented 2 years ago

With the trekking profile I could trigger even more strange behavior:

http://brouter.de/brouter-web/#map=19/63.37879/10.34758/standard&lonlats=10.346938,63.378979;10.34704,63.378981

That can not be due to Douglas-Peucker transfer-node elimination.

quaelnix commented 1 year ago

This no longer seems to be the case, do we know why?

afischerdev commented 1 year ago

Yes, I think so. When I played with this problem there wasn't a way around. Now the street is splitted. The way has changed 6 month ago.

But the issue with loops is still present. Please see this forum entry.