My FIRST DRAFT for goals for highway=* elements would be:
All kinds of routes existing in any way shall be supported.
Like with the Wikipedia rule, they must exist or be defined in some way outside of OSM, typically visible on the ground (at least trail traces, trail signs, cairns, pitons, poles on a glacier) or regularly following the exact same route (for instance a snowmobile route used to supply an alpine hut in winter). I am not used to snorkelling or diving, maybe there are standard routes defined by any means and not just “hello world: this is where I crossed the ocean in 2024”
Routes can be given various attributes, for instance for the type of surface or the beauty of the scenery or whatever. But they must receive minimum tagging for security and accessibility, if they are not a safe walking path, or a road suitable for saloon car, or access is not permitted to the general public (on private land in countries like the USA, South Africa etc.). Of course, polygons marking non-accessible private land, national parks etc. are an alternative and equally sufficient solution to tagging individual paths.
The minimum tagging for security and accessibility should be globally standardized and simple to allow apps or map renderers to automatically filter and/or mark the routes worldwide. This means that a non-standardized tag like “for experienced alpinists only” is a no-go and a multitude of difficulty grading systems like the SAC scale T1…T6 which originates from Switzerland, but then Switzerland’s official trail difficulty blazing yellow, red, blue, UK grades 1, 2, 3, etc. (Trail difficulty rating system - Wikipedia) are a high burden for apps, even without considering mountaineering grades like the French Alpine System F/PD/AD/D/TD/ED, the UIAA I … XI, or the many more climbing grade systems. A global (OSM) standard may simplify things to some extent, because the different grading systems cannot simply be mapped to one another as they take different aspects into the consideration or balance them differently: technical difficulty, mental challenge, length/duration of the difficulties and remoteness/isolation (discovery and rescue chances in case of failure).
Each route being mapped shall create some advantage to some public user. I am not sure about all the many routes in a busy climbing garden starting all two to three meters from one another, sometimes leading diagonally or even crossing one another. I would be afraid of an unreadable mesh of lines. In a single-family home neighborhood, the many small paths and stepping stones along the houses from the front garden to the back garden are also not worth mapping. Sometimes less is more.
Great points!
Perhaps it is time we open a thread for solution proposals. I might do that on Sunday, after the weekend hike, if nobody beats me to it.
The original issue I had was that I wanted to mark a possible path in a risky area where 90% of the surface are cliffs. I’ve found some route descriptions online but the exact route needs to be found on the spot.
On the negative side, the day was cloudy and I was in fog for the first half.
On the positive side, it did clear up somewhat, before the most critical point of the route. I also ran into some cairns, confirming that others have passed the same way.
For me, marking such a route is very important. I’d like to do it in OSM, using a tag that won’t lead an average hiker there. If not, I can also keep a private collection of GPX routes, but that seems wrong.
Re: climbing routes
I would actually love to have the routes on the map. They will mostly be a point on the map, so won’t take that much space. But, knowing if the route is 5+ or 8- makes a big difference.
Yes, Alan, exactly. But remember that IdleLayabout asked whether he can just remove the path from OSM when a second time hikers needed to be rescued at Nursery Buttres of Table Mountain. This is why I suggest formulating goals or policies. They function as a test similarly to the categorical imperative of Emanuel Kant: “Act only according to that maxim whereby you can at the same time will that it should become a universal law.” I can imagine, that IdleLayabout would not have made his suggestion when he would have explicitly phrased the general goal or policy behind his request.
The de facto policy has been formulated time and again: Mappers add secondary tags to the primary highway=path tag and it is up to the intermediaries to convey contents to their users. I see no way that this principle can be overruled by internal mechanisms, support is too deep rooted in the community.
Maybe the OSMF introduce a kind of “quality seal” – This app is up to our goals and principles? But then, another seal same such for mappers, whether they add e.g. sac_scale=* to demanding paths called for too?
PS: Personally, I would find most useful something, that not only consumers unlikely to misinterpret, but also mappers not easy to mistag, and that needs concise descriptions readily understood.
I still think that highway=scramble has a chance of being widely adopted, if we can address the perceived shortcomings of the proposal. But it’ll take a lot of work and energy. Same for dedicated tags for rock climbing routes and mountaineering routes that needs specialised equipment.
For new routes, sure. It’s a bit more complicated with routes that are already in the database, isn’t it? Especially for popular ones. If they’re highway=path and I retag them, they’ll just disappear from a lot of OSM-based hiking apps, confusing people and it’s only a matter of time before someone reverts my change. I’m thinking we need a migration plan, where data consumers are notified ahead of time. And start small, bring the local community on board first. We could probably learn a lot from an experiment like that. If it works, that’s some of the main criticisms of the highway=scramble proposal dealt with.
That is why I am leaning to introducing pathway=scramble (and trail adn shared_use etc).
We could have a long transitino period when both could live together. So to highway=path that are scramble, we would add pathway=scramble. New ways would be recomended to be only pathway=scramble but if people also added highway=path, so be it. We would set a day, maybe 2-3 years in the future, when there would be a mass edit that would remove highway=path from all ways that were at the same time pathway=scramble. The same way for pathway=shared_use, pathway=pathless etc.
This would let people map in a new way but also provide for a much longer transitional period without any sharp changes for the prepared ones.
Of course, in pracice most people would ignore this and then the trouble of paths missing would just occur those 2-3 years later, but then they could be much moreplausibly blamed for their troubles and alsi I am sure there would be some that would be prepared. Maybe I am pessimistic and most would be prepared.
I am not sure if anything like this has ever been undertaken but to me it does not seem impossible.
No offence to you both, but this is what I meant by it’ll take work and energy - when you suggest something like that, someone will inevitably suggest an alternative and then you have to defend your idea or change the plan, and eventually you end up with something that looks rather different from what you initially proposed, and is probably much better than the first idea, but that’s often after weeks of discussion.
This is already happening. The discussions have been going for a while. There have been quite a few proposals and some didn’t quite make it. Which is also good because they highlighted certain issues and paved the way (path?) for even better solutions down the road (path?).
With the list of issues above, along with the photos of usage examples, I think certain profiles are clearly shaping. It may take some more time to brainstorm and come up with satisfactory solution proposals.
So far, I like the proposal with the secondary-turn-primary tags, along with the explanations in the wiki and the support in editors.
The clearly identified categories of current paths can be introduced immediately, while it also opens up the possibility to later introduce others that may not be so frequent (I.e. snorkeling, snowmobile).
I see that iD has decided to unilaterally deprecate highway=footway in place of highway=path. Could we go just one month without an arbitrary and unhelpful iD-ism being inflicted upon us?
is that it’s a highway=footway with foot=no. The intention is that you’re forbidden to walk on but it makes no sense otherwise, hence why iD suggests the more generic highway=path. Of course, this also has access=no so that foot=no is redundant and would make it clear you aren’t supposed to walk on it anyway (explicit restrictions override implicit ones).
Great example of a naive assumption leading to a wrong suggestion. If there is to be any issue flagged in a case like this it should be phrased as something like a potentially incorrect tag combination that could use a closer look, not outdated tags with an offer to upgrade them. That is misleading.
This is indeed a usability issue; iD should be showing more context to avoid sending the wrong message. The following issue was originally prompted by another deprecation rule (which happens to come right before it in the JSON file):
To be fair to the current iD maintainer, I suspect that language such as “outdated” and “upgrade” predates their stint as iD head honcho. It’s not the only example where iD suggests things that it shouldn’t, but it’s a genuinely difficult problem to solve to suggest what a (new) mapper should look at in order to figure out what “correct” tagging would be in a particular situation.
Another example suggested to me recently was to change an erroneous linear natural=water into an area. It was clear to me that what was mapped was a linear ditch, but it might have been the unclosed area of a lake.
The problem with this is that the highway=footway + foot=no may be a temporary closure (ideally there would be a fixme or a note, which wasn’t the case here), or it should have been tagged as something like foot=private.
Next time I’m running near St Katherine’s Dock, I’ll take a look at the footway in my example and hopefully tag approriately.
I see what you mean. The deprecation rule was originally added long ago as part of a suite of rules about contradictory tagging combinations. That’s another possible interpretation, just looking at the tags out of context. It’s another example of why the original path proposal should never have commandeered access keys for indicating the transport modes for which a path is “for”.
By the way, iD has a dedicated preset for highway=construction that can ostensibly be used for roadworks, though I’ve always found this awkward for long-term closures that aren’t being worked on.
