This seems to be a Tagging general discussion topic rather than Help and support. Can someone with the relevant permissions move it? It might get more eyes over there.
2 Likes
This reminds of a certain notorious user who mapped everything they could in Hesse as buildings, from buildings parts (kind of understandably, at least, but as individual buildings and not building:part=yes as expected) to… just everything else which looks remotely like a building (included cars, underground parking garage entrances and steps).
1 Like
How about closing it instead? When answers start going off-topic, I know it’s time to move on.
I got some great suggestions for alternatives and aIready explained how I’ll use them. No, I won’t be documenting a new unconfirmed:highway tag, thank you!
2 Likes
I need to bring up this issue again because I’ve discovered that most outdoor apps I’ve tried (like AllTrails, OsmAnd, Strava) renders highway=road as a paved road.
Even though we shouldn’t tag for renderers, fixing them could take too long, and some commercial apps might not even bother. Now, instead of showing isolated paths, users would see stretches of paved roads in the middle of nowhere, which makes things worse.
Saying we shouldn’t add unconfirmed data to OSM seems a bit of a stretch. In Thailand, most initial highway versions, including corporate imports, were added based on imagery alone. Even if there has been quality issues, maps are consistently being refined and have improved a lot thanks to armchair mapping.
But I get that users want to see only confirmed, ground-surveyed data. Right now, highway=road is used inconsistently. What should I do?
- Keep using
highway=roadand ask apps to hide them by default? - Remove isolated segments?
- Leave them as they are?
- Ask apps to hide
highway=roadby default?
Have you tried reporting this bug to them as the first step?
In general if data consumer has such bug in processing OSM data it does not seem like a valid reason to change our mapping, especially if they were never notified about problem.
4 Likes
Not yet because I just discovered it and I naively thought they would follow wiki guidelines 
I was just commenting on my previous experience of asking commercial outdoor renderers to render unpaved roads (e.g unclassified/tertiary) differently from paved roads.
Well, I would not expect miracles but paved vs unpaved is more of feature request.
Like this is closer to a blatant bug - even if they do not differentiate in styling between different road types at all then displaying highway=road like others is asking for a trouble.
1 Like
I submitted and documented five bug reports, linking to the wiki page and this conversation. I’m confident the open-source ones will fix it quickly. The others might take longer, but it’s a good start.
4 Likes
Of the closed-source ones, one actually has a pretty good reputation of trying to “get things right” when interpreting OSM tags. It might also be worth having a look at the links from https://wiki.openstreetmap.org/wiki/Foundation/Local_Chapters/United_States#US_Trails_Stewardship_Initiative - there’s a US-based group that has been trying to improve the way that some apps handle OSM data - they’ve been working with at least one of the apps on your list, and have done a really good job to raise awareness of things.
1 Like
highway=road indicates that the type of road is unknown, fixme=continue indicates that the course/location from that point on is unknown, those are two different things.
1 Like
Wiki says fixme=continue should be used on nodes, not the actual segment sharing the highway=road tag.
1 Like
“wiki says” a lot of things. That doesn’t mean that it reflects reality, or that reality that disagrees with the wiki is necessarily “wrong”. 
In this case this recommendation seems to be a good idea, I had too many cases where it was not clear where supposed continuation is supposed to happen
1 Like
Andy is correct: there is long-standing tradition and practice that while our wiki is a valuable resource, sometimes it does not reflect reality, as either our map data are “ahead” of what the wiki says, or the wiki is “predicting” or “prescribing” that data should be a certain way (in our map database), but they aren’t (yet).
Most wiki are (intended to be) “descriptive” of the data that are in OSM. Some wiki (and in my opinion, should really be clear when they do this) are more “prescriptive,” meaning “here is how you should tag in our map.”
The result of this is that “wiki chases map chases wiki chases map chases wiki chases map…” is a reality. Downstream OSM data consumers (like those who make your listed hiking / other use-case apps) don’t slavishly follow wiki 100%. And/or, wiki editors may edit / tweak wiki entries so they (slightly, sometimes not-so-slightly) cause some drift of what is in the map and what is “said to be” (or “said to be done in an ideal world”).
This is OSM, and it may seem like a bunch of hopelessly moving targets all conflicting with one another. But I must say after 15+ years in this 20-year project, it really isn’t all as bad as that. We have some work to do to harmonize our wiki with our data (with our data with our wiki…) but we do improve things. Andy’s mention of the USA initiative to improve trails by some of the big trail data consumers is an example big step in a right direction. It may seem like slowly, but our data (and downstream toolchains) DO get better.
1 Like
The wiki is big, and easy to modify, you can find incoherent stuff, for sure.
But it’s always a bad practice to misuse a concept, here creating a concept of a possible thing, by misusing a another concept. Here the lifecycle. What @julcnx wants to describe has nothing to do with the lifecycle of the object. Dot.
1 Like
Yes, @trial, correct.
I see fixme=continue on a node, I know it means “unknown beyond this point” (relative to the path of the way). I see it on a way (not node), well, that’s rare, but I’d treat the entire way as vague. I wouldn’t look this up in the wiki to make sure, I am purposefully cautioning on the side of “expand the geographical scope” (of what is to be fixed, so that “continue” becomes broad as in “please better complete this, future mapper” as vagueness and ambiguity, like slow poison to a map, are resolved).
I believe it is best to not promulgate such vagueness to future mappers, I have done so when I must, we do as a project, though I utmost minimize these; my motto is “map well.”
I’ll say it repeatedly or explicitly and for other excellent reasons already cited here: the topic is a bad tag, as it is nonsensical that the concept of “unconfirmed” has anything to do with our lifecycle-tagging. That’s a non-starter and enough to dismiss this tag. I have learned things here, I hope others have, too. Thanks to everybody who contributed to this topic.
We do sometimes tag fixme or note to boldly and honestly enter into our map that some vagueness (deliberate, hopefully with more value as good data than ambiguity) has crept in. I believe OSM strives to minimize these data.
I welcome outstanding data entering OSM which are best-sourced and best-entered by OSM contributors who sign our names to them. Is “too much” vagueness creeping into your data entering OSM? If so, do better, please.
Expecting downstream parsers and you using these as a data consumer to perform a certain way for say, highway=road not quite to your liking, no. You can’t falsely pervert our lifecycle tagging for a concept (unconfirmed) that doesn’t fit into either it, or OSM’s basic tenets of data entering. (We enter data that are there, on-the-ground, with some exceptions, like borders, which we agree to put into our map as “existing” for us here and now in these data). We are deliberate how we do this, while we broadly and widely listen, coach, disagree and agree.
2 Likes
Yes, please re-read the thread, they are 2 different topics. It’s about highway=road + fixme= , not fixme= on end point.
2 Likes
OK, road data are inconsistent. That’s a widely used tag, we understand.
What you should do is listen to how we use the map. We know there are many successful roundtrip experiences of users entering, editing data and watching it blossom on “their” map (preferred method of viewing mapped data). Your experience seems to include not liking how highway=road enters vague data (how we do what you say you want to enter) renders on a particular renderer. So, your “roundtrip of success” seems imperfect to you, due for improvement perhaps, we understand.
Here is how to improve it: discover contradiction in your thinking, like that highway=road bits and pieces (of data) are “make things worse.” From one way of looking at it, such data make things a bit better, perhaps by adding them (there’s a good plan to improve, is one excellent example of why and when). Perhaps not. Perhaps you discover a way to add some path or road data you are privy to somehow (and wish to add) could be made a bit better, by making them reliable and not a road. This is one of the few explicitly-fuzzy tags we have, and it is old, though it means a specific thing. Maybe it is better that you do add these data. You do seem to be asking “how to tag.” This is a tag with a future, best with a plan to improve it.
When you say “leave them as they are?” with a question mark and that outdoor apps render as paved, I’m not sure what problem you are trying to solve. They can and are indeed sometimes used as a way to build a skeleton and network of paths, tracks, streets, ways often connected to each other. That is part of what we build here. Sometimes we do it with highway=road, simply a method by which data enter the map. One of the few tags we nod that are (deliberately) vague.
Edit: Can you attest it to being (at least) a highway=path from imagery? I have found that where building “paths from imagery” (even faint-ish surface=dirt highway=path) (you attest are at least this as you enter these) can be segmented or end with fixme=continues tags. Maybe cloud cover or forest / trees covers the path, but it’s clear up until there. OSM is OK entering these if imagery is “accurate enough” to do so. You wouldn’t be using highway=road, you’d be using highway=path, maybe surface=dirt, a lowly, though verifiable (if only through imagery, can be decent, can be shoddy) data entry on a way you can see in your imagery. See, they are confirmed, by you, as entering as accurately as you can, tagged properly, including as something real, though likely disconnected. They are confirmed data, they politely also have fixme=continues in places where appropriate (though, I only enter this tag when hiking on the ground and I hit something like a locked gate with No Trespassing signs on a hiking trail).
We get it: you see something from imagery and wish to tag it something, yet you don’t like the way that commercial trail rendering outdoor apps present these data to you (as paved, which they aren’t, as you map them from imagery). We’ve explained it to you: the breakdown is in some contradiction in your mind. Like that “unconfirmed” trails visible to you in imagery be added. Think first about how to best do that, and fight it out with highway=road, the latter seemingly coming out the winner (of “how we tag ways of this imaged, vaguely imagined stuff”). You don’t like that commercial apps show this as paved? Ha, that’s funny. See what we mean?
Listen to Mateusz, many others here. Ask your commercial providers to explain the toolchain to you different from how I have so it makes sense to you.
@Woazboat said exactly the same, no need to tell them to reread the thread.