You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Not sure about Valhalla, but IIRC ORS has some kind of default threshold on allowed snapping distance. The result is that if one of the used coordinates is clearly outside the underlying OSM extract (it would require snapping to a "too far" edge), then a routing error is raised.
OSRM does not have this behavior, thus using plain wrong coordinates can slip unnoticed at the routing level. This typically occurs with switched lon,lat, resulting in all locations being snapped to the same point. This gets bad at the optimization layer, since getting matrices full of zeros result in arbitrary ordering decisions and inconsistent routes.
That last situation is always a pain to explain (see #921 and a bunch of older issues) and should definitely be fixed by issuing a plain routing error. It seems all we have to do is add radiuses options to OSRM queries. Hard-coding a sensible value would probably catch most of the problems.
The text was updated successfully, but these errors were encountered:
Maybe also a (future) case for #903 to add a radius to vehicles & jobs? Though a sensible default maybe makes more sense, less burden on users.
Valhalla is pretty sophisticated with "limits" on snapping:
radius: limits the search for correlated edges around input locations to the radius. Which will also mean it'll find multiple edges where it'll expand from all at once. Default is 0, which means, find the closest eligible edge fitting all other constraints (profile, params below, many others)
search_cutoff: similar to radius, just another constraint and esp useful when radius is 0. Default is 35 km.
minimum_reachability: limits how many nodes need to be minimally reachable from a correlated edge to not be considered part of a network island. Default is 50.
The Valhalla search_cutoff param sounds exactly like what I mentioned for ORS and what is missing in our current use of OSRM. My understanding is that we'd get that same behavior using the OSRM radiuses option. Except if I'm missing some subtlety related to the connected components logic.
Default is 35 km
Something like this would avoid being too strict on snapping (may maybe help for small connected components?) while filtering out obvious coordinates mismatch.
a sensible default maybe makes more sense
Agreed, especially since the defaults could be lowered at the routing stack level if need be.
Not sure about Valhalla, but IIRC ORS has some kind of default threshold on allowed snapping distance. The result is that if one of the used coordinates is clearly outside the underlying OSM extract (it would require snapping to a "too far" edge), then a routing error is raised.
OSRM does not have this behavior, thus using plain wrong coordinates can slip unnoticed at the routing level. This typically occurs with switched lon,lat, resulting in all locations being snapped to the same point. This gets bad at the optimization layer, since getting matrices full of zeros result in arbitrary ordering decisions and inconsistent routes.
That last situation is always a pain to explain (see #921 and a bunch of older issues) and should definitely be fixed by issuing a plain routing error. It seems all we have to do is add
radiuses
options to OSRM queries. Hard-coding a sensible value would probably catch most of the problems.The text was updated successfully, but these errors were encountered: