Hi folks. Wondering if anyone knows the answer to this. I was just trying to plan a route from a vacation home to another city, and I was surprised that cycle.travel wouldn't do it. It couldn't connect the locations as they were linked by roads it appears not to use in the routing engine. It shows these roads as a gray dashed line, presumably inaccessible to the planning engine, which I don't understand (and doesn't seem to be in the key). I'm an OSM editor, so I checked the roads, and they were tagged "residential" and didn't have pavement tags of any kind. I updated them to reality, and I understand it'll take time for that to be pushed out to OSM servers.
However, I'm wondering if the engine excluded these roads because of the lack of pavement info, or the residential tag -- or something else entirely. For what it's worth, using other OSM-based routing engines (Garmin connect being just one example), the roads show up as normal and route just fine even before I updated the tags to match reality. (Most of these "residential" roads are actually tertiary, but I think that under normal circumstances, residential roads should be preferred connections for cycling as they're normally in good shape and low on traffic.)
Comments
This is a slightly complex one!
OpenStreetMap’s US data originally came from TIGER, the Census Bureau’s (rather approximate) map data. In many urban areas this has been updated and checked, but in rural areas it often hasn’t.
A particular road class in the TIGER data (A41: “Local, neighborhood, and rural road, city street, unseparated”) was brought into OSM as highway=residential. So in rural areas of the US, OSM residential roads are usually just TIGER A41-class roads.
The problem with this is that TIGER really isn’t that good as a navigable map database. There are thousands, perhaps millions of A41-class roads which in reality are just dirt tracks, forest paths, or completely imaginary.
So cycle.travel is deliberately cautious about these. It has a bunch of heuristics to work out whether a particular rural highway=residential is actually likely to be a paved road, but it always errs on the side of caution. Generally it will avoid these ‘unsurveyed roads’ because it doesn’t want to route you down an impassable drainage ditch.
The upside of this is that when you ask cycle.travel for a route in the US, the result should be one you can actually ride! The downside is that, as in your example, it will sometimes miss good roads. This happens most in the Midwest where there are lots of paved roads but also plenty of dirt (or non-existent) ones.
You’re absolutely on the right lines by adding surface tags. cycle.travel will pick up on these next time it takes a map data update (roughly monthly and I’m overdue for one at the moment). You can also change the road type to one which is assumed paved, such as highway=tertiary or highway=unclassified.
Cool, thanks. I have been updating a lot of these. I saw in the OSM notes that the TIGER import had overweighted those to "residential." I'll switch the ones I know are good at least to tertiary, and do the pavement if I know (or can see it). Entire towns in this area with paved roads are listed as unknown surface residential, which is too bad.
We cycle a lot in the midwest and don't end up on disappearing roads too often, but it has happened. Usually it's sort of fun -- but that was when we had the right bikes and everything we needed.
This site is awesome for finding better roads, that's for sure. The other day Google tried to put me on a trail that is a sand ATV trail that would be a challenge even for a fatbike! (Odd since they actually have imagery of the trail, but apparently connecting one source of data with the other doesn't happen for that circumstance.)