In an ideal world, everybofy including renderers would study wiki and other information thoroughly. In real world, they are lazy. The name now is misleading. The new name would be much better in that regard. Change to renderers would not be very disruptive since by definition, whatever they now render is wrong anyway.
The only question is if it should cover paths too. If the parallel effort to estabilish pathway=* as a primary tag suceeds, it would make sense to have pathway=unknown too. In case of doubt (i think satellite imagery usually tells if something is for roads or not), road could have both tags.
That might be difficult to know for something as intentionally ambiguous as highway=road. I can say that there are three fewer paths tagged highway=road than there were before this RfC started:
In this case, I suspect the mapper really thought these were somehow disconnected, asphalt-paved road bridges, as opposed to the nearby, interconnected golf cart paths that they had tagged highway=pathgolf=pathfoot=designated â and neglected to connect to each other. It goes to show that highway=road ways may be poorly mapped in addition to being incorrectly classified.
2,324 (5%) have name=*, which we can examine for names that sound like roads or streets.
1,437 (3%) were likely mapped as part of a series of HOT Tasking Manager projects focused on mapping roads in the aftermath of a major earthquake. One of these projects came with an instructional video that advised mappers to tag âmain roadsâ as highway=road so that others could come along later and fill in the classification.
Presumably a highway=road that connects to a road-like way is more likely to be a road than one that only connects to path-like ways. According to QLever, highway=road is 15 times more likely to be connected to a road-like way than a path-like way. By comparison, there are less than five times as many road-like ways as path-like ways.
3,238 intersections between highway=road and highway=bridleway/cycleway/footway/path/steps:
49,479 intersections between highway=road and highway=motorway/motorway_link/trunk/trunk_link/primary/primary_link/secondary/secondary_link/tertiary/tertiary_link/unclassified/residential/busway/bus_guideway/service/living_street/track/raceway:
There are some patterns in these query results that warrant further investigation. For example, 60 highway=road ways in Finland branch off of trunk roads and the like; they could be low-hanging fruit for a resurvey.
Thatâs exactly the kind of advice I was expecting earlier, but instead, I got told to either not add the data, or that this is exactly what highway=road is forâŠ
Great finds, but itâs no shocker that highway=road hasnât been used consistently for paths. Other than osm-carto and Tracestrack, I havenât come across any renderers that show highway=road differently from highway=residential or highway=unclassified.
And those renderers intentionally make highway=road look like a road rather than a path. Still, look how these subsets of highway=road were introduced seemingly without any consideration for rendering. Rendering isnât actually the big deal one imagines it to be at first.
Should we cut our losses and revert back to the original definition of highway=road, for consistency with seemingly the whole OSM ecosystem apart from the wiki? Do you think we have a fighting chance of de-skunking this tag by reverting the wiki edit? It would be a lot simpler than trying to convince data consumers to adopt a new, aggressively questionable primary tag.
Well. As I have read first time (ok, irony (or the possibility to emphatize the argumentation was not so good for you)
SoâŠ
Is there any new feature to map with this? (probably not)
Is there any new micromapping or micromapping situation with this? (probably also not)
We can read in your proposal:
Although the wiki currently mentions that the âtag is used for a road/way/path/street/alley/motorway/etc. with an unknown classification,â the initial highway=road proposal and early wiki changes specifically excluded pathways and footways.
SorryâŠbut Can you show us in which line and revision of the highway=road page is saying that exclusion?
We can read in the wiki: Anything which has been tagged highway=road can basically be any kind of âroadâ from the smallest footpath to the largest motorway (from 2016). I donât see specifically any exclusion.
But ok, letâs play:
Now, we would change highway=road for highway=unknown and then we would change highway=unknown for highway=yes or highway=whatever because:
-pathways were covered with old proposal (no new thing)
-there were not intended to routing (no new thing)
-is a temporary measure (no new thing) - : "As soon the road type is known, use one of the more specific values of highway=*. "
-Renderers does not follow the linesâŠso you will fix that because you will make accomplish that any render can not missunderstand highway=unknown as they do with road
-Confusing name for mappersâŠso you will fix that because mappers would continue not reading the wiki and making changes in the middle without any discussion in it. Iâm from Spain, for a non-English country. For people unknown or road would be the same if we donât have read the wiki before.
-Lack of usage⊠so you will find the motivation for the mappers for using itâŠalthough this proposal was accepted from 2008 and it is missused (you have said).
Why donât encourage to use the existing tag with the same effect rather than adopt a new without anything new?
Donât get me wrong but I see future with three different tags (probably one yours) to describe the same. Three new standards. Is there a better offer?
Youâre quoting from the 2016 edit that unilaterally redefined the tag, whereas this proposal is referring further back, to the original 2008 proposal. The highway=road proposal only mentions âroadsâ and never mentions âpathsâ. In the discussion that preceded voting, the proposalâs author declined to call it highway=yes or highway=unknown, explaining:
The highway tag covers a number of non-road features, such as footways, bridleways, etc. Specifying highway=unknown doesnât tell you what the way is - if you know it is a road, then why not tag it as a road. I certainly care more about whether I can drive down a highway than whether it is primary, secondary or tertiary, so would like to know that a way is a road, even if the contributor didnât know the classification.
Voting on highway=road began and ended while a vote on the highway=path proposal was still underway. A majority voted in both proposals, so they were aware that the two tags would coexist.
This new proposal would replace highway=road with highway=unknown, effectively discarding any judgments that a way represents a road as opposed to some kind of path. The question is whether that judgment on its own, without a more precise classification, is worth preserving in a tag that has software support, or whether we should formally conflate these likely roads with likely paths in a tag that wonât initially have any software support.
Good for history.
We are in 2024. We have a key=value called highway=road to represent all highway that we donât know the kind of way it is (and not using other tag). Now we have a proposal with same key but other valueâŠto define the same with the same conditions (unknown kind of highway) ?
May I understand correctly that?
Thank you.
Right, in other words: if you believe that the wikiâs current definition is the source of truth, or an accurate reflection of how the tag is being applied and interpreted, then the only effect of this new proposal is to force software developers to opt back into this tag. Like, are you sure you want to render these roads similar to residential roads?
On the other hand, if you think the wikiâs current definition is just another example of âwhat one person thought one dayâ, then this new proposal also makes some ambiguous roads into even more ambiguous roads-or-paths.
I donât know if it is the source of truth or the Bible of OSM. I know that when I donât know how to map something the place when I can find an âaccepted by the communityâ explanation is the wiki. And people should read it before mapping something with some tag that they donât know. And of course developers of âbig software for OSMâ should follow it before inventing tags or making duplicate schemes. Because if an article from 2008 and with no big modifications from 2016 has to not be followed and then we have to replace it with something very similar or exactly the same 8 years later probably is better to close the wiki and problem resolved.
I think I agree with your conclusion but not your reasoning. Our wiki is an approximation of whatâs accepted by the community, but like every wiki, it has imperfections. Weâre dealing with miscommunication, not misbehavior.
Software developers (editors, renderers, routers) did the right thing. They went to the wiki, read the definition, and followed the documentation more or less accurately based on their use case. The only problem is that they all did this sometime before 2016. They had no way of knowing that the definition would change subtly but significantly in 2016. For that matter, I didnât notice that change until this discussion, and I read the wiki more closely than most mappers.
These problems arose often enough that, a few years ago, some users started to compile a changelog. Mappers and software developers can periodically check the changelog for anything that might affect them. If a changelog had existed back in 2016, thereâs still no guarantee that @Wuzzy wouldâve updated it, but maybe someone else wouldâve spotted the change and had an obvious way to alert the rest of the community.
Accepting the change is one option, but it means we have extra work to educate people about a counterintuitive tag value. Another option is to revert the change, hoping that no one depended too much on the previous definition. So far, based on the analysis Iâve done, a revert doesnât seem like it would be very disruptive, but I invite others to look into it too, in case I missed anything.
Yes it would make things easier, but if we leave pathways out of highway=road, there needs to be a documented consensus on how to tag pathways of unknown classification. Iâve put together a survey for this:
