One of the fundamental problems we have with the “problem child” highway=path is that people use it for things that aren’t in any regular sense paths - like dangerous mountain ascents and snorkelling routes. That was the driver to stop using highway=path for some of those (highway=scramble was suggested). The advantage of a different highway key is that app developers at the shallower end of the app development gene pool** would “fail safe” - they wouldn’t include “paths that are not paths”, because they would not be tagged as paths.
** this is being slightly unfair to app developers, since those people who insist on using highway=path in OSM for widely different real-world objects are the ones causing the problem.
Oops, I meant commonly used renderers. I can’t speak for bicycling apps, but I’ve tested dozens of the most downloaded outdoor apps (for hiking, MTB) and didn’t find any.
You missed the point about rendering support. The new tags aren’t meant to differentiate physical attributes, but rather focus on usage or function, like any other high-level tags.
There’s definitely a growing consensus to find a solution, but I haven’t seen agreement on the best approach yet. Update: created a survey to get a better sense where everyone stands.
Unfortunately, this isn’t an overwhelmingly positive story about these keys. As taginfo also shows, highway=path is understood by quite a few more renderers and routers than either key.
As you suggest, taginfo project listings are hardly representative of the OSM ecosystem. Taginfo mostly tracks which editor presets include a given tag, and to a lesser extent which open-source and personal projects consume it. Very few proprietary applications and websites have shown an interest in documenting their behavior. In some cases, we’ve resorted to doing our own investigations and posting it on the wiki.
The existence of trail_visibility=*-supporting renderers mainly tells us that we can’t deprecate or redefine that key without causing pain, particularly on your part, but I don’t think anyone is suggesting to do that. Instead, we’re seeing straw man arguments about unwieldy tag values.
Primary and secondary keys are both useful tools, because we don’t have an overarching junk drawer of a type=* key like Overture does. How do we decide when an aspect of a feature rises to the level of a primary feature tag? In my view, we would ideally coin a primary key when the feature’s identity depends on some characteristic, when that characteristic is the answer to the question “What is it?” and there isn’t a more generic answer.
Even without considering backwards compatibility, this can be very challenging, because every culture has different ideas about umbrella terms for concepts. Humanity can’t even agree on a set of basic colors, let alone whether glacial erratics and other large boulders have anything to do with each other in a layperson’s eyes. On the one hand, we ground these discrepancies in a traditional preference for British English, and on the other hand, we compromise with other cultures to avoid major usability problems or fill in gaps in English vocabulary. Neither approach requires us to make up new concepts and jargon gratuitously.
Anyhow, we are so far along that any notion of linguistic elegance might as well be feedback for an OSM-based tile schema rather than OSM itself. If we choose to shunt some subset of highway=path to a different highway=* value or a different key altogether, we should consider it a workaround with the express purpose of forcing data consumers to opt back in, not the opening salvo in a top-to-bottom overhaul.
I agree, I am definitely not part of any consensus to include pathless paths under the highway=path key, even with a clear subtag.
Unfortunately I think two distinct problems have been lumped in together, and they may well not have the same solution.
Problem 1 is the use of highway=path for things that are not regular physical paths. As mentioned, this can have severe consequences. This problem affects only a small proportion of things that are or might be mapped as paths.
Problem 2 is that even within “regular paths” there is a huge variation of functionality, access, and physical characteristics, with no obvious defaults for most of these. This variation occurs even within small geographical areas. This local variation contrasts with many road types. The wiki definitions for trunk/primary/secondary/tertiary/unclassified are almost hilariously vague. But the influence of official classifications tends to hide this vagueness, so that objects tagged highway=secondary within a single country end up being reasonably similar even without any other tags. The fact they may be very different on a worldwide basis doesn’t matter for many uses of the map. Whereas with path, two very different kinds of path may well intersect each other. Unlike problem 1, any solution to problem 2 potentially affects all paths (and maybe footways and cycleways and bridleways).
Of course there is a grey area where these problems overlap, perhaps somewhere at the point where you need to use you hands just a little bit to make forward progress. But I still think these are essentially different issues, and trying to devise a “consensus approach” to solve both at the same time risks solving neither.
That is the point: they treat the same ways differently, and on top of that they treat different ways as equal.
At the mapping end, mappers are struggling to map and tag the objects consistently, which results in a multitude of consistencies. A limited number of clearly different types or categories can help mappers to map more consistent, without having to know all the scales and physical descriptors. So the information gets better, which helps data users to use the information as intended, thus improving maps and navigation.
And they will continue to do that. I don’t think you can find a solution that forces them not to do that. You can offer an alternative that can easily be rendered differently (which could be: not rendered on general purpose maps and not routed for regular transport profiles). Then, it’s not OSM’s fault if people get into trouble, it’s the mapper’s or app’s fault.
Without clarity, you can try to convince all mappers and data users not to use highway=path for this, without offering an easy alternative.
I am tempted to a bet… I’ll stake a king size bowl of popcorn!
But at the same time the confusion increases, why those ways are not appearing on “the map” and especial inexperienced mappers want to see the result in “the map”. So either they will map the way then like nowadays or they will stop mapping them. I don’t see, how mappers at the moment get’s confused about second level tags. Tag’s like surface, smoothness, width, sac_scale, trail_visibility are quite easy to understand. Still mappers would need to understand those things in the future, as the new tags are just a highway=path with some of the above have different default values.
?
If highway=path gets a subtag path=, nothing changes on a map that don’t look at the subtag. Maps can improve the rendering by looking at the subtag, but they will not stop looking at the main tag.
All extra tags can still be set, if mappers want to take the trouble. But setting the path= tag can save them a lot of attribute tagging.
Tags like surface, smoothness and width are easy to understand, but often not so easy to verify and to map accurately, because most mappers do not want to explore the whole path and cut it into sections whenever the width, smoothness, surface, difficulty level or visibility level changes.
We’re not talking about one path or type of path with a special fan group of users and mappers, but the whole spectrum that currently gets tagged highway=path.
Yes… but that’s nothing new. Maps can already nowadays look at subtags like sac_scale or trail_visibility to detect “dangerous paths” and render them differently than the sidewalk. Your path=* would just be a preset of all the already existing tags.
, but they don’t, generally. Combinations of subtags are not exactly what data users want. One main tag, one modifier tag seems to be the max they can/will easily handle. Totally understandable. And then they tend to summarize, e.g. the range of surfaces can be reduced to paved surfaces/unpaved surfaces, and access types can be reduced to yes/private/no. Just examples, I’m sure some data users do a lot more for a particular purpose, and maybe nothing is it doesn’t fit the purpose.
I think mapping should strike a balance between regular handling capabilities of data users, and the need for details for special purposes.
If you think about it, it could be hard to render something like surface=asphalt + smoothness=excellent + sac_scale=difficult_alpine_hiking. The point is: the more subtags you look at, the higher the chance they contradict each other.
For sure, data users will summarize our data. But each of them might want to do this differently. A map for wheelchair users will do it different than a map for ordinary person and a hiking map will have another approach.
We mapper shouldn’t summarize our information. First then above isn’t possible, second every mapper will summarize it in a different way. The mapper on a Sunday afternoon stroll might have a different view on a way than a “professional” hiker.
I don’t get your point. A map not intended for hiking purpose might will ignore that way due to the sac_scale and that’s ok. A map for cyclist might show that way as it most likely will not consider sac_scale. A mapper or user might notice the discrepancy and correct the data.
Where do you see a difference to surface=asphalt + smoothness=excellent and path=hiking_trail or however the value of path=* for your “difficult hiking trail” would be defined.
There’s different goals. One, easy categories for general(ish) purpose maps and routers. Two, detailed attributes for specialized maps and routers.
Specialized data users may also profit from the easy categories, by pre-selecting the most fitting category which may already determine/estimate most of the details.
Out of curiosity, do you think that many of the earlier tagging conventions for highways in OSM were mistakes? Does it make sense to have highway=living_street rather than just using secondary tags with highway=residential? Or to summarise certain specific kinds of service way as “highway=track” and others as “highway=service”? Or to classify roads between population settlements as primary/secondary/tertiary based on vaguely defined distinctions? Or treat steps as a whole class of their own rather than adding steps=yes?
Moving away from highways, does it make sense to have a different main tag for each of restaurant, cafe, bar, fast food, pub? Aren’t these just summarizing “places that serve food and drink” into general types with vaguely defined boundaries?
I think this is a recurring theme that adds difficulty to many of these discussions: some people are trying to extend and improve tagging by, as they see it, following similar principles to existing tagging. But the objectors to new main tags also feel they are supporting existing principles. Or do they? Maybe some of the objectors feel that main tags have already proliferated too much and are trying to stop a rot that they perceive as having set in some time ago. I think it would be helpful to people trying to propose new tags to understand this. As it stands, some responses come across as “OSM has magically arrived at exactly the right number of main tags at this exact point in time and no new ones should be added”.
There are also some concerns beyond the ones you listed above. One such fairly fundamental concern was raised by @Langlaeufer earlier in another thread.
I’d also argue that the counterexamples of living_street, etc do not really apply here. At least in Finland, the value of e.g. living_street follows primarily from traffic_sign=FI:E24 and encodes multiple restrictions enshrined in law. Similar considerations, though mutatis mutandis of course, apply to restaurants vs cafes. In most cases an unambiguous decision between amenity=restaurant and amenity=cafe can be made just by looking at the name of the establishment.
I’d argue that at least some of the vagueness in the use of the path tag is due to the vagueness inherent in the paths themselves. In my humble opinion the best way to deal with this would be to use the descriptive tags, whose values exist on a gradation, and thus allows one to express the vagueness directly.
This is of course not to suggest that none of the backlash for new highway values might be due to people like me just being the fogies and neckbeards of OSM .
.