When it comes to the safety concerns expressed in this thread, we’re not looking for a solution where paths can optionally be qualified with a subtype. In that scenario, we would still see dangerous paths mapped as highway=path with no subtype, which would make them indistinguishable from walk-in-the-park paths with no subtype.
To solve that problem, the information that this path is dangerous must not be an iterative refinement of “path”. Rather, this information must be part of the very first tag. The feature must be something else, such as a “scramble” or “dangerous_path”, instead of a “path”.
You’re pointing out the imperfection of a solution based on this classification. And you’re correct in that regard. But a solution doesn’t have to be perfect to be worth implementing. So this is not a valid argument against the solution unless you also have a better solution. Specifically, a solution for the safety risks, not for the various other grievances about path mapping.
Somehow I got the impression that we were talking about incremental refinement of highway=path. Qualifying paths with a subtype is aimed at that, and at the same time it can tackle the safety issue.
I think you need to read the title and the content of the first post in the thread to understand why the title has “incremental” in it. The post is saying (paraphrasing somewhat) “incremental refinement isn’t working, map makers still just show bare highway=path without warning consumers (with deadly consequences)”.
The title of the thread is “Incremental refinement of highway=path.” Perhaps it should be renamed “RFC: Let’s not use highway=path at all for dangerous trails.”, then.
I must say that pointing out things like:
confuses me even more when you’re trying to make your point. Most barehighway=paths are surely not lethally dangerous. Many of them are just inadequately tagged park pathways, etc.
It can only work if people do it. If there is no recognized, clear and simple method, people won’t do it and data users have nothing to go on.
In this case, some mappers expected, or rather hoped, that it would spontaneously solve a potential hazard. To reach that stage, the “incremental refinement” should reach near completion for this use case. In my experience, spontaneus adding of details never happens spontaneously; you (mappers) need to organize it. So, first thing is to design and test a viable solution (mapping method), second is to apply the solution systematically.
In this topic there were two viable solutions mentioned:
even with support of at least one renderer
and
Using the the second way one could begin with Step 4 and using path=scramble (or some other value like mountaineering or so) without highway=path and without a renderer support.
Please be aware that having no rendering support or the support of a special renderer that is aware of the implication of this tagging - “Be aware! This trail is very dangerous.” is good not bad, because these dangerous trails wouldn’t be shown to users not aware of the danger.
I think, there would be the need of adding a note-tag, for example note=Please don't change this way to highway=path or note=Please don't add highway=path to this way in the second scheme to avoid such changes to get this dangerous trail rendered in apps or maps that don’t know this tagging.
Carto and OrganicMaps for example doesn’t render highway=via_ferrata as was said in the discussion that @SomeoneElse mentioned, but render highway=path with sac_scale=demanding_alpine_hiking, see Key:sac_scale - OpenStreetMap Wiki the same way as a nice easy pathway in an urban park … Looking at the history of Way: Alpspitz Ferrata (B) (23971675) | OpenStreetMap you will see that it was rettagged once from via_ferrata back to path.
Yes, that’s no incremental refinement of highway=path.
I agree. There is no realistic prospect that a general renderer like OSM Carto is going interpret multiple tags to decide whether or not to render a particular highway=path. It might be feasible for a region-specific map where there is consistent usage.
Something like highway=scramble is needed to remove “things that are routes rather than paths” from highway=path to reduce the current over-broad scope of this tagging.
Sorry for the delay, contributing in spare time, mapping backlog and looking for stuff to explore prevented me from contributing here sooner.
Personally, I’d like this topic less focussed on dangers, hazards and such. As told, I consider scrambling (or pathless rambling much the same) a joyful leisurely pastime, and I do not want to spoil the fun I have in that. Trust me, with a bit of training it is no more dangerous than crossing a busy road mid-block.
I am with @Tordanik though on this issue: Mappers unwilling to contribute anything but the base tag will continue to do just that into the future; Obviously the wiki (quite clear now on this) not much consulted by mappers?
Unfortunately rings true, all of this refinement of little use. Some consumers care, a lots don’t. The archetype of path is: Where you can walk AND ride a bicycle AND ride a horse AND rollerskate AND you name it BUT MUST NOT drive a car. A quote that from back in 2022:
It still would never appear to me to map scrambles as climbing routes. But NOT putting them into highway key at all I nowadays consider the only way forward. All the bonanza about highway=via_ferrata aside.
PS: Last not least, it is not only scrambles, others may come up with other examples?
I should have phrased my statement differently: On a way mapped path with no attributes, I MAY do any of these things. I must not expect that I CAN do any or all of them. Brings us back on topic.
Should editors flag a warning when user creates or modifies path with no attributes? Requiring e.g. surface at least?
Well any high exposure path (aka misstep/slipping will get you at least injured). But that is essentially what killed highway=scramble the last time around so I don’t think we should venture there as it is extremely unlikely that there will be any consensus.
Which would mean that (to inform users correctly) either
All data consumers should apply Austrian defaults (and by consequence, all countryspecific defaults), so nobody needs to use access tags for inline skates;
or
Data consumers should apply world wide defaults, and where country specific defaults are different, those mappers should tag the exceptions explicitly.
Alas, I think you need to treat access defaults (internationally, nationally and regionally) with a huge pinch of salt.
As an example, the listed access defaults for the UK is wrong because legally there are no access defaults for the UK as a whole (they vary by country, and are unrelated to any OSM main tag). Once you get into “unusual” modes of transport you get into legal exceptions and edge cases, and an app provider needs to ask themselves about local law, not the OSM wiki.
Even in “right to roam” jurisdictions like Scotland, where you are allowed to walk / cycle is described by rules independent of any OSM tagging. You can guess, but it would only be a guess.
Non-local apps should not have to know local laws and regulations. The effects of laws and regulations should be translated into OSM tags by mappers who know these things, so that apps can inform the users correctly without knowing laws and regulations of all countries.
The alternative would be to devise a system by which apps can easily access local defaults. I think such a system exists only for left side vs right side driving. Maybe also country specific speed limits, as usually posted at borders?
Or we can continue to use the usual OSM-method: don’t even try.
You’re both right. Both craft tagging (tagging each individual feature explicitly) and armchair tagging (making pronouncements about default values on the wiki) have advantages and disadvantages depending on the situation. OSM clearly needs to record things that vary from case to case, for which hyperlocal geography is the most important factor. On the other hand, some regulations are based on factors other than geography or are too vague or nondeterministic for our empirical approach to mapping. At this point, I don’t know if I should rehash my criticism of implicit defaults in this thread or the one about harmonizing highway classifications universally…
You’re right - my earlier comment was correct, but what I didn’t say (and perhaps should have done) is that where access is complicated we should be tagging it directly on the OSM ways themselves. An example of that is here - I added a foot=yes tag there so that no “default” is used (that’s in England, and in the absence of other signage the default would be foot=no, despite what the OSM wiki says). There was previously a designation=public_footpath, which is a tag that impliesfoot=yes in England and Wales. People have argued that data consumers ought to know that designation=public_footpath implies foot=yes, but I’d prefer to explicitly tag it.
However - we’re now talking about legal access not suitability, which are often completely unrelated. The step from suitability to legality took place above; “what you are allowed to do” somewhere is different from “what that somewhere is” and “what you can sensibly do there” - it’s a bit of a cul-de-sac in the main thread.
