It depends. A truck delivery dispatcher may want to get “no routes found” rather than a route that unavoidably traverses hgv=no. On the other hand, in some localities, it is legal for certain trucks to ignore hgv=no at the end of the route or within a certain distance of the destination. California even has a standard sign for where trucks may go a certain distance for specific services like gas and food but are otherwise prohibited from using the road. hgv:national_network=service_access has been proposed for this purpose, but it hasn’t been mapped yet.
If you’d like to test out routing edge cases with access=destination, there are some entire towns that apply destination-like restrictions to their residential streets, but our coverage of these restrictions may be incomplete. In some cases, it might be necessary for a local to enter and exit multiple destination “zones” to visit a friend across town.
The pin marks the position of an address, the line points to the position on the road network OSRM will send you to. This is the result for the /nearest api call in OSRM.
So whenever there is the slightest chance to send you to an address (whatever the cost is) you will be send to the nearest point. The long distances here are a result of road network not usable by car e.g. tracks, access=private and the like.
Thats correct. Thats why i produce this QA Map. But it shows that the nearest point on the reachable network will be navigated to. Not the one which is “reasonable cost effective”.
Yes, OSRM does ignore access restrictions like access=private if necessary for reaching the destination, and it is based on nearest neighbor search. I was merely pointing out that the expected behavior depends on the use case, especially when it comes to specialized vehicle types like hgv. Many truck restrictions exist not for the vehicle’s safety but for the comfort or safety of the neighborhood. Since the restrictions are based solely on law rather than any physical obstacle, there can often be very nuanced exceptions. I think it’s important to be aware that these nuances exist before jumping to the conclusion that a particular routing behavior is incorrect, for example.
Sorry - thats wrong. access=private or for your profile non existant (read: not usable) road segments fall of the graph completely. So the “nearest” api call search jumps to the nearest point on the next usable road which might be on the other side of the motorway, canal or rail track. To give you orientation the web framework draw you a line from the “nearest” result to the point you asked for. But thats far from “ignoring access restriction on the road network”.
That is the QA Map overlay i produce. An address, the “nearest” point on the usable road network (for that profile) and if they are >100m apart i draw it on the map because someone most like produced unusable roads. Made tracks to farmyards or sprinkled access=private all over the place.
OSRM shows you a “direct line” from the road to the final destination you tried to reach. But thats in a lot of cases a completely bogus assumption that that is passable.
This was a basis for my discussions on a “Navaid relation” a couple years back on the tagging mailinglist which was shot down. Problem persists in the map data and is by todays tagging/relation unsolvable.
I’m aware of the crow-flies line from the requested waypoint to the snapped waypoint in the returned route, but I was referring to the behavior of actually ignoring the access=private at the beginning and end of the route, as described in the Mapbox blog post I linked. Maybe I was mistaken in thinking that this behavior is part of the default OSRM car profile; it might’ve been specific to the custom OSRM profile that the Mapbox Directions API used until it migrated to Valhalla.
Relatedly, OSRM conflates private with destination, classifying both as restricted unless a service road is involved: