True for OSRM and GraphHopper. These ways are probably being removed from their routing graph during preprocessing, since neither routing system directs cars over highway=track + tracktype=grade3 even with a very explicit motorcar=yes (example). This makes the speeds defined in the source code for these grades a mystery, likely a remnant from when they did not enforce this strict blocking.
Organic Maps and CoMaps strongly avoid that route, but not strictly:
Valhalla has been down since early 4 May, I’ll re-check when it comes back online. (Still offline by 5 May. The only working public instance is their demo, where it does route cars over that track, although it strongly avoids it.)
The MapBox Directions API is not on the main website, but it routes over these tracks when “driving mode” is selected, although, like Organic Maps, it strongly avoids them.
In Germany and Brazil, the recommended default is motor_vehicle=destination,[1] while in Tyrol, Denmark and Norway it is motor_vehicle=no. However, in many countries, motor_vehicle=yes is currently suggested as the default, perhaps due to broader regional interpretations.
Both OSRM and GraphHopper will route cars over grade2, grade1 or without tracktype, they do not assume destination nor no car access on tracks.
Although in Brazil the ideal would be motor_vehicle=no since tracks are almost always private, this is still awaiting some local debate. ↩︎
I could not make much sense of that phrase. But playing around with the online mapzen resource: As soon as one of the end-points is on the public infrastructure, the detour is made. This suggests to me, *=destination|start as guiding the valhalla router regarding use of tracks. That said, the router wants to get its users out of track space as quickly as possible, this though not in absolute distance, but in weighted distance, that is what you meant with the phrase?
Now not in the mood to re-tag those tracks to unclassified to test the influence of tracktype on router suggestions… Reading what is written above, tracktype is of negligent influence compared with highway value?
Yes. More precisely, these routers are assigning these ways a high cost (weight), so, while searching for the lowest cost route, they are avoided as a consequence of the assigned high cost, but in some situations, they may still be chosen (ie. if they’re a useful shortcut and the next best alternative route is much, much longer, resulting in an even higher cost). A strict ban (access=no) is usually dealt with by removing edges (ways) from the routing graph, producing an effect similar to assigning them “infinite” cost. In this case, these ways are never chosen, no matter how long the next best route around them is; the user can’t even route to or from points along them (as these ways are not even present in the internal representation while projecting the origin and the destination in the resulting road mesh).
Different routing systems handle access=destination differently: some just assign them a very high cost (which rarely may treat them incorrectly as through ways); more sophisticated systems delete them from the routing graph before any optimization (eg. CH) but then dynamically add edges back if the origin or destination lies next to one of such ways.
So the effect of tracktype can be modeled either as a high cost or as an access restriction (either like no or like destination). I see the routing weights in the source code, but no code for the preprocessing/data extraction step where edges are removed/filtered out - this is probably being done by some external too that is not in the same repo.
Valhalla is back, and, like Organic Maps, it chooses to direct cars along these ways with a strong avoidance.[1] So, OSRM and GraphHopper completely avoid highway=track + tracktype=grade3, but Valhalla (and other systems) do not.
Some quick testing seem to suggest it is assigning a cost at least 20 times higher for each metre along the track relative to typical unclassified ways. ↩︎
