I am proposing to replace the highway=road tag with highway=unknown for roads of uncertain classification that need surveying.
The current highway=road tag has caused confusion among mappers, but also end-consumers, as many renderers mistakenly display it as highway=unclassified.
This proposal aims to clarify tagging and reduce misinterpretation. I believe this change will improve both rendering consistency and mapping quality with minimal impact on existing tools.
While it is not the most problematic issue in the highway classification, highway=road can indeed be misinterpreted. Using highway=unknown would indeed reflect more accurately the current usage of highway=road.
However i think that you’re rational could use some work, it leans to much on style and paved vs unpaved rendering. Only until recently does OSM carto have any unpaved rendering, and others don’t distinguish paved from unpaved.
You are right, most of these renderers do not support surface, and actually looking again at many examples, they seem to render highway=road the same as highway=unclassified leading to further confusion.
Surprisingly to me, the tag already has some usage.
Edit: Since this thread is very likely to become popcorn-worthy, how about everyone who posts here has to find a highway=road that they can replace with a more sensible tag? Many of these date from decades ago and can be reviewed from imagery.
This is a mischaracterization of the proposal. The rationale is to use a value that is less confusing, both for mappers and also for consumers. The goal is not to remove it from renderers.
Some of the “renderers” you’ve identified are merely sites that embed maps from providers that don’t give their customers the option to distinguish highway=road from highway=residential or highway=unclassified. Those tile providers would’ve been in a better position to respond to your inquiries, although to set expectations, few of them ever devote resources to following the OSM tagging debate du jour.
Even so, this proposal does have an undue emphasis on renderers. If the motivation is that highway=road can potentially represent a rugged walking path, then routing engines should be considered too. Most routing engines offer a walking or hiking profile. For example, OSRM’s default driving profile excludes highway=road but its default walking profile includes highway=road. Absent any changes, this proposal would effectively promote tagging that excludes pedestrians, seemingly contrary to your intention.
This was not a concern for previous proposals for new highway=* values, such as highway=busway, because there was an expectation that none of the “standard” modes of transportation should be routed along them by default.
The aim isn’t to eliminate highway=road, but to make better use of it. Asking armchair mappers to reclassify roads without local knowledge doesn’t make things better.
This tag should encourage others to survey them in person and add more detailed information. With a clearer name, more people would likely use it.
Great. Except this proposal would do exactly that. If you were to bulk change every existing =road to =unknown, they would summarily disappear from many renderers. It is better for these roads to remain visible so they can be corrected to some other highway value.
Most of these sites are just front-ends for their main product, which is a mobile app (Android, iPhone, or both). My focus has been on rendering support for the apps, not the maps on their websites, which are often based on Mapbox. I’ll make this clearer in the table.
Good point! I didn’t expect routers wouldn’t already exclude highway=road. I’ll make sure to include this in the proposal.
The three I identified also use Mapbox in their mobile applications, for what it’s worth. The OSMUS Trails Working Group has been trying to encourage mobile applications to support other important tags such as access=private and access=no on paths, with limited success because of a reliance on upstream tile providers that don’t honor these tags.
Thanks. The general principle is that router developers realize that OSM tagging is always incomplete, but highway=road especially so. They can’t be confident that the road is passable, or that it even exists. For better or worse, the assumption seems to be that typical pedestrians are more flexible about grading and surfacing than standard motor vehicles. I would hope that any wheelchair router, on the other hand, would avoid such ways.
Something to be aware of if anyone is looking at examples: StreetComplete is defaulting to highway=road when a mapper indicates that construction has finished and there is no construction= tag on the existing way - see Construction quest answers · Issue #4817 · streetcomplete/StreetComplete · GitHub. I discovered this when 2 of the first 6 examples I looked at in Ireland and Spain turned out to be recent StreetComplete edits. (In fact all 6 were recent edits - I have contacted the mappers for the other 4 to see if there is any other pattern, but my initial impression is they may be just oversights).
I was surprised by the distribution of this tag in Europe - it is very rare in Spain, Portugal and Ireland, but seems relatively common in some other countries.
Having looked at all cases of highway=road in Spain and Ireland, its use turned out to be almost directly the opposite of what I expected - it’s good to have your preconceptions challenged!
Most cases resulted directly from an on the ground survey (I only found one example of the tag being used for its stated purpose where the mapper couldn’t classify the road based on imagery).
Most cases had been added quite recently.
Reasons for the use of this tag included:
the StreetComplete quest mentioned above, where the mapper updated the construction tag based on a survey, and was probably unaware this would result in an undetermined road type
“slip of the mouse” type errors when editing
uncertainty about how to tag old bits of road separated from the main network after nearby construction
uncertainty when actually surveying a road about whether it was public or private (changed to a driveway after discussing with the mapper, who was quite new and glad to have the chance to discuss it).
Quite a few of these could be resolved via changeset discussions or were obvious from aerial imagery (in combination with tagging of adjoining roads).
However, I assume the pattern must be different in countries with more widespread use of this tag - it doesn’t seem like the above could give rise to usage on the scale I see in some other countries,
When hiking, I’ve noticed ways that had clearly been drawn from nothing but the Strava heatmap, or worse, nothing but a single hiker’s GPS trace. They were tagged highway=path. Sometimes there was an actual path there, sometimes not (picture a difficult mountaineering route only usable a few months a year, and only with ice climbing equipment).
In my view, it wouldn’t hurt OSM if people used a tag like highway=unknown or unconfirmed:highway instead, inviting hikers to go and survey them before tagging them with something that suggests to data consumers that it’s possible to walk there.
According to the Wiki, we can already use highway=road for paths, not just for roads, but I’ve never seen that and it seems counterintuitive: it would lead to them showing up in maps more prominently than paths. So maybe highway=unknown is the solution to this problem?
Things for which the only source is Strava should not be in OSM.
If someone does it, please explain to them why it’s a bad idea (starting with what you’ve described above). If they persist, report them to the DWG so that we can persuade them.
There are oodles of ways of storing “this might be an interesting place to survey” and also plenty of ways of sharing it (uMap et al). OSM is not the place for speculative new “I don’t know whether there is a path here or not”.
