I’ve been exploring a lot and adding missing trails in my area.
One effective technique I use before exploring is to add visible trail segments based on old imagery, especially in forested areas. Sometimes these segments connect and are useful, but other times they turn out to be abandoned or never existed.
There’s a misconception among some users that maps only contain roads and paths that are 100% verified and usable. I’ve seen a few complaints about non-existent trails. However, this is a very small minority, and the outdoor communities has appreciated the hundreds of kilometers of confirmed trails I’ve added over the years.
To address this issue and reduce clutter on the maps, I’m thinking of creating a new lifecycle tag, e.g., unconfirmed:highway. This way, unconfirmed segments won’t appear on standard maps but can still be enabled in custom renderers in OsmAnd.
My plan would be to document this tag in the wiki, enable it in OsmAnd, and manually convert my own unconfirmed trail additions that lack GPS verification.
Do you have any suggestions or concerns?
Update: I changed the title to match the original post’s purpose. It looks like most people agree that highway=road is the way to go, so I won’t be using a lifecycle tag.
Also, armchair mapping isn’t frowned upon as some seem to suggest, so we’ll keep adding ways visible from imagery. Please keep your suggestions and comments concise and on topic. Thank you!
Overlap with the use of highway=road and further I’m not convinced that using OSM data proper as a notepad makes sense, particularly as there are multiple ways to have nearly the same workflow that avoid it.
If you aren’t confident to add them as =road , they shouldn’t be added to OSM directly. Consider eg uMap to use yourself, or share with others.
Also, they may be waterway=stream or something else. You could split the =wood area if they are significant gaps. That would allow further investigation if interested.
For most of these, I’m confident. I agree that it might be best to remove the ones I’m not sure about.
At the same time, many of these segments have been useful to other explorers who use the maps to connect routes and upload their traces via OSM or Strava Heatmap.
Having them in a separate application wouldn’t have allowed me and others to connect the dots and improve the map further.
That’s it them. I always thought highway=road was not meant for paths/footways but wiki says otherwise. OsmAnd already supports it. Thanks!
> A road/way/street/motorway/etc. of unknown type. It can stand for anything ranging from a footpath to a motorway. This tag should only be used temporarily until the road/way/etc. has been properly surveyed. If you do know the road type, do not use this value, instead use one of the more specific highway= values.*
It isn’t suitable for something that might not be a “highway”, so it doesn’t solve that issue.
It depends naturally on how you go about actually confirming if the way exists, but you can generate geojson, GPX, KML and even OSM format data for the geometry, and just integrate once you have confirmed that it is actually what you thought it was.
I would only use it for disconnected segments that are clearly visible as paths or tracks on satellite imagery.
And I would use this technique for any annotations I overlay on my navigation app. I usually confirm the existence of trails via GPS traces that I either collect myself on the ground or obtain from other contributors, like OpenStreetMap GPS Traces or Strava Heatmap.
I appreciate your issue and I think it is a not a bad idea to start entering these unconfirmed track segments as “road”. I would additionaly add a fixme=* for additional information.
Even if by checking on the ground you or some other mapper may find out that this track has overgrown or been washed away by heavy rain you can still keep it in the map with a lifecycle prefix as “disused” or “abandoned”. If there had been a track once it may well be there will be a new one in future again.
And in case the imagery fooled you and you will find a stream instead of a track (or both) you can still go ahead retagging the way you entered.
I think it’s a bad idea to map objects at all if you can’t even tell if they’re paths, tracks made by animals, streams, former paths or any other type of linear feature that can exist in a forest. As others have mentioned you can map these data on a local file and only upload them to OSM once you actually know for sure what they are.
That sounds like a great idea to me, if indeed you mean tagging only the recognisable sections as highway=road and not everything that looks vaguely linear.
What you’re doing is a form of armchair mapping which is a major source of contributions to OSM. It’s a good idea to indicate that you’re not 100% sure of the accuracy of what you’re mapping, but I doubt if a new tag should be created for it. As suggested by @Map_HeRo , if you’re quite sure that what you’re adding is some form of road, tag it as highway=road, and add a fixme=* tag to explain the uncertainty and the need for survey.
I’m against use of the fixme tag. It’s indeed armchair mapping and then asking others to “fix” things. Don’t ask others to fix problems you created. I won’t fix anything.
Regarding the 1st post, if there’s a chance people may need those unverified tracks, I’m not against mapping those.
I won’t do it, but let me frame it better: On one hand, the fixme= is useless, as =road is already something to fix, and you can use note= . On the other hand, fixme= on =road can be immediately ignored, and software could prioritize them the lowest.
Sure, but not every mapper knows that and a fixme offers space for a short explanation, same as a note.
No it does not mean that, it’s nothing but a hint to everyone exploring this place, including the author of the fixme himself, as @julcnx has explained here.
The wiki states that fixme isn’t necessary since highway=road already serves as a warning in iD and JOSM. However, I’d consider adding a note instead for other mappers.
By adding something that was missing on the map while not being sure about its exact nature, you partially solve a problem. I see no problem in asking others to complete the solution by adding a fixme that describes well what is still missing.
The idea sounds intriguing. Yet I will not do this but will stick to drawing a crude way from remote sensing in my editor, save it as GPX to my device, go there, look it up or fail to do that. And only upload confirmed trails.
“To be or not to be?” OSM prefers our data to be “what are.” Especially single, neighboring-data-sparse way elements such as a relatively isolated path.
Now, for a set of things, like members of a route relation or network of bus_stops, you might get to a hazy 90% on your way to finishing the set (if 85%, OK, but do soon get around to upping this, please). I always strive for 100%, but I know if I get to A-minus with 90% as I mean to finish the set of things soon, I’m OK with that, so is OSM. B-plus (or less, with an “actively under construction to complete” note), well, that’s good, though, let’s get 'er done, please. “Unconfirmed” is not part of any lifecycle.
A highway you are imagining into existence as data in our map (database), BEFORE you know it exists? Tagged (blatantly, I must say) “unconfirmed”? No, thank you. OSM eschews such data. Do as Asa and I (and many others) do and confirm data which are unconfirmed, first. Then, after data are confirmed, feel free to put your signature on changesets which include them. But not until then, please. That’s how we do it.
And, there is highway=road which might work as intended in this case (thanks, Simon). It is widely acknowledged that highway=road is a “temporary wound” on OSM’s data integrity, as what entering speculative unconfirmed data does is lower our quality (in the short term, hopefully).
