Bugs using bidirectional algorithms

[PhilHa]

for some routes there are suboptimal results for all bidirectional algorithms:

Note: to replicate this use these URLs and disabled contraction hierarchies: http://localhost:8989/?point=48.983206%2C12.140568&point=48.983438%2C12.136411&weighting=shortest&algorithm=dijkstra http://localhost:8989/?point=48.983206%2C12.140568&point=48.983438%2C12.136411&weighting=shortest&algorithm=dijkstraNative http://localhost:8989/?point=48.984428%2C12.144517&point=48.983146%2C12.136631&algorithm=dijkstra http://localhost:8989/?point=48.984428%2C12.144517&point=48.983146%2C12.136631&algorithm=dijkstrabi

But with contraction hierarchies there's something wrong too: http://graphhopper.com/maps/?point=48.983206%2C12.140568&point=48.983213%2C12.136266&locale=de

I've checked that it's probably not the algorithms fault, as the inEdgeExplorer does not even get the edge next to the destination point (the edge which is obviously the right one for best path) But the outEdgeExplorer is able to get this edge if moving the start point in a westward direction. So the bug may be caused by a wrong (directed) connection of destination querypoint with the neighbor nodes somewhere in QueryGraph.java

[karussell]

I have extracted the area but I can only reproduce the obstacle with dijkstraNative and will try to fix this now.

Would you mind to try with the very latest master, with CarFlagEncoder and see if you can still reproduce the issue with the other algorithms? Please make sure to clean and build to really ensure the latest master is used and only car. If you can still reproduce this would you send my the osm/pbf via mail? Or would you additionally try with the following extract.osm:

./graphhopper.sh extract "12.12985,48.98047,12.148283,48.992411"

[karussell]

Indeed this is an issue of the loop-alike street 'Hedwig-Dransfeld-Weg'

[karussell]

Please let me know if this is fixed now. Note that I renamed dijkstraNative to dijkstraNativebi

[PhilHa]

Yes, this is fixed!

[karussell]

Nice!