Strange routes persist in 8 - possible reasons?

[subrina0013]

Hi, Using version 7, I was having strange routes, so I tried version 8. But I still have weird routes. For example: the route here with all the default settings…

using Google maps, the route looks like this

Looks like many others also have this problem (e.g., Strange routes at the border of dataset - #7 by Geoman, Strange routing - indirect route and more). What are the reasons that could be behind the weird routes? Sometimes, OSM tags show one-way which restrict direct route. What are the other possible reasons for these routes? How can we explain such routes? And how to solve/avoid these- any generic solution?

[otbutz]

Your destination isn’t directly reachable according to OSM:

The road around the facility is tagged with access=no and has additional barrier=gate nodes.

GraphHopper picks the nearest routable street which happens to be the nearby motorway:

GraphHopper Maps | Route Planner

GH yields a sensible route with a slightly modified destination:

GraphHopper Maps | Route Planner

[otbutz]

@karussell it would be nice if the snapping would be a bit smarter in that regard.

graphhopper/graphhopper/blob/49c456ddbba41a7f7e1a6efd8bcc41d113fe6be5/core/src/main/java/com/graphhopper/storage/index/LocationIndexTree.java#L284-L290

Instead of simply blocking trunk/motorway like we do it in the SnapPreventionEdgeFilter we could apply a factor to the normDist depending on the EdgeIteratorState.

e.g 2 * normedDist for trunk/motorway

Snap findClosest(double lat, double lon, EdgeFilter edgeFilter, EdgePriority edgePriority);

public interface EdgePriority {
    EdgePriority DEFAULT_PRIORITY = edgeState -> 1d;

    double priority(EdgeIteratorState edgeState);
}

[subrina0013]

Oh… thanks for the explanation.

[subrina0013]

@otbutz

Instead of simply blocking trunk/motorway like we do it in the SnapPreventionEdgeFilter we could apply a factor to the normDist depending on the EdgeIteratorState.

e.g 2 * normedDist for trunk/motorway

Why GH blocks motorway in SnapPreventionEdgeFilter? What does it actually do?

[otbutz]

Not by default. But you can tell it to:

https://docs.graphhopper.com/#operation/getRoute!in=query&path=snap_prevention&t=request

[karussell]

@otbutz

@karussell it would be nice if the snapping would be a bit smarter in that regard.

At the moment I don’t think a “smart” snapping would be an improvement. We have point_hints and snap_preventions for the /route endpoint, which should solve mostly all issues in this regard. For the public GraphHopper Maps I would keep it as it is (maybe in the future we add point_hints) but you can configure it and we e.g. already avoid ferries.

[subrina0013]

Dear @karussell and @otbutz

Any suggestion on how I should explain GraphHopper Maps | Route Planner? Looks like they are all residential houses with road connecting them, still GH chooses this route.

or this one? GraphHopper Maps | Route Planner. Why it is not taking the red highlighted path?

I think there is a road that merged with I66 but GH is not taking that one.

[karussell]

Those roads are private: Way: ‪Santeetlah Road‬ (‪6121527‬) | OpenStreetMap and then GraphHopper snaps to the nearest road on the other side.

[subrina0013]

Thank you so much for the explanation. Could you look at GraphHopper Maps | Route Planner? GH takes the blue path. But, the red path is also accessible and faster.

[easbar]

The red path requires passing this private gate: Node: ‪Kingman Gate‬ (‪1249946638‬) | OpenStreetMap

[subrina0013]

Thank you so much.
Could you please share what are the usual things that GH avoids?
Some are: when it is a private road/gate, HOV lanes. What else?

I used car as the only mode and found that GH did not use a pedestrian bridge over a road, rather took a long route to reach the dest by car. If, I could activate walk mode, would it be different and GH would take the bridge?

Also, I saw routes can be different and much faster in GH web version but much slower using source code. What is the reason for that?