I have no problem with encouraging additional tags, and I often add many of these tags myself. But…
The devil is in the detail here. Which descriptive tags exactly? Of all possible tags mentioned in this and previous posts, only “surface” seems to me relatively unproblematic (provided we accept=paved and =unpaved as generic fallbacks).
Smoothness: defined for wheeled vehicles, which will be irrelevant for many paths, and even where it is relevant, should we force mappers who walk a trail to also consider conditions for wheeled vehicles at every point in a trail?
Width: often varies widely over short distances for “unbuilt” trails making it very time-consuming to survey and map. Sometimes hard to know where the edges of a path are, e.g. over grass or sand (and in those examples they often don’t matter much anyway).
Sac_scale: defined specifically for hiking, no appropriate value for many “easy”
paths.
Trail_visibility: defined for hiking trails, sometimes difficult to interpret (e.g. if the trail itself is worn away but markings are easy to follow).
Informal: often difficult to determine, and can’t really be validated unless we also force mappers to add formal=yes.
… and none of those even start to cover access.
So there is a danger that we are defining millions of objects as “invalidly mapped” where the solution requires a lot of survey, thought, and interpretation on the part of mappers. Constantly nagging mappers who improve the map in one way (e.g. correcting the position of a path) to improve it in other difficult and time-consuming ways seems to be going too far.
So in general mappers of ways for non-motorised transport have to tag 4 or 5 things at a time.
Meanwhile, mappers working on minor roads used or designed for 4-wheel motor vehicles get to choose between residential, living_street, track, service, busway, unclassified, pedestrian etc as top-level tags without being told their mapping is invalid. Or would you suggest similar treatment for those?
True that! You are absolutely correct to say that they aren’t erroneously tagged, as I suggested. Perhaps I should have emphasized that we ought to treat them as erroneously tagged.
The values of the descriptive tags are unknown only to an armchair mapper. Anyone who actually visits a pathway or cycleway has immediate access to fill all the needed descriptive tags. It might be possible to add the surface and width tags to well exposed and relatively wide paths from aerial pictures too.
Nagging the mappers about the absence of the descriptive tags might encourage them to (physically) revisit them. What might be other ways to do this? Maybe render all ways with only a highway=path or a highway=cycleway tag differently from all the other paths and cycleways?
Yes, agree fully! I never suggested that this would be an easy or fast approach. All the descriptive tags would have to be added case-by-case, and there might well be arguments over specific smoothness values, for instance. That would still be a massive improvement over the status quo.
In my previous post I suggested that we should try to discuss the issue further, and this time pivot the discussion towards e.g. coming up with at least minimal sets of useful descriptive tags to the (very) different types of paths.
Am I correct in understanding that in your opinion the problem with paths is just simply unsolvable? Specifically, I fail to see how trying to come up with new highway tags would be an easier option. Presumably, one would have to introduce a set of physical criteria (think: descriptive tags) to separate the different highway cases meant to replace paths (and have the problem of disruption eloquently expressed by @Langlaeufer above).
Surveying paths on foot is incredibly slow. My record for one day is about 40km, but that was on flat ground and good surfaces where a lot of surveying had already been done by other mappers. In a mountainous area 20km in a day would be good going - maybe less if not previous surveyed. And once you’ve done that, even adding the data can be slow and difficult. I often find that while I feel I have been taking photos at regular intervals, I didn’t actually take enough to properly map width, for example. Nagging me to spend every weekend for a year revisiting a mountain range because I didn’t consider smoothness for wheeled vehicles when I was hiking definitely won’t encourage me!
I see a lot of easy or urban hikes tagged as T1 and find it to be appropriate.
This is way too optimistic for the paths we are talking about under Pathless. The width ranges from 30cm to several hundred meters and the surface may change every couple of meters. Sometimes it is even hard to say what the surface is, as there is some dirt, lots of stones, and an occasional grass lump here and there, for example. Aerial pictures don’t help at all as the path(less) is not visible on them (nor is obvious in reality).
Here, here and here are some photos that describe what I’m talking about. I can share more, if needed. I was there recently and still would not be able to describe the attributes you’d expect.
I agree with Alan that requiring these tags would totally put me off from adding these routes (which also solves the problem, I guess).
I wasn’t suggesting giving up on additional tags, just that I don’t think it will be productive to nag mappers about them as if their absence is an error. Apps like StreetComplete do encourage some of these tags, not by saying they are errors but simply by including them in quests, and I think that’s a good thing. Also, StreetComplete has similar quests for other highway types/tags (e.g. surface on service roads), rather than treating cyclists/pedestrians as a special case.
On the more general question of the problem with path, it depends on which problem. I thought the highway=scramble proposal would have been a good start, by removing some of the potential confusion in the situations where it is most dangerous. But it didn’t get decisive enough support. (As someone else mentioned, most of the highway= values currently in use probably wouldn’t get enough support to be approved under the current proposal process - we would probably end up with highway=yes and everything else in subtags, which seems to be kind of what you are suggesting for foot/cycle ways).
I do that too, but for paths that in some way feel like “hiking” trails. But the context here is a proposal to enforce additional tags for all types of footway. I don’t think T1 is appropriate for a sidewalk, for example, as walking on a sidewalk is not hiking. So I don’t think sac_scale is a candidate to be a required tag. The point I was making is that if we are enforcing tags, all except maybe surface have problems.
This is a very valid point. Anyone who’s able to distinguish between a minor and a major road would, for sure, be able to distinguish between a Path and a Pathless way. (Or should they, instead, use highway=road and add surface, width, smoothness, lanes?).
highway=pathless – This would mostly cover also what highway=scramble wanted. It would imply trail_visibility=no
for what highway=scramble wanted to express, we could have an attribute like scramble=yes. This would allow for a smoother transition and who wants to warn about difficult passages could implement the tag.
I don’t think trail_visibility should be implied by other tags, there are many different situations in the world and we are better prepared if we encourage to tag the specifics explicitly.
We could also use highway=road with tags motorway=yes, driveway=yes, living_street=yes and so on. A renderer that wants to display a motorway differently from a living street could implement those tags.
OK maybe it’s a cheap point, but I think there is a genuine underlying issue. I have not seen a clear explanation why a lot of people seem to want to move to ever-more-generic top level tagging of foot and cycle ways, with all meaning in subtags, but there does not seem to be the same tendency for roads used by motor vehicles. Maybe if someone could articulate that more clearly it would help find a way forward.
Yes I agree. Most of highways, excluding path, is classified by there purpose or usage. But with highway=path the discussion seems to be about how to classify these by their physical preferences, not by their usage. Why this difference?
Amen… I was just about to make the same point. [sarcasm]Why use one tag when a dozen will suffice?[/sarcasm]
The national park near my city has ~1000 km of hiking paths. Vast majority of them are tagged only as highway=path and are included within route=hiking relation as appropriate.
Vast majority of them could be tagged with surface=ground, sac_scale=T1, mtb_scale=S0-S1, width=0.5-1.5, trail_visibility=good, foot=yes, mtb=yes, bicycle=dangerous… But I really can’t be bothered to revisit them all and add all that. Heck, in my country, and in 500 km in all directions around me, the above are average properties of a highway=path. I’m lazy, people are lazy, I want to have a “Hiking trail” preset and just click it. I’m not against additional tags, but those surely have to be optional, second-order ones, not mandatory.
And no, I don’t think that the current scope of path is akin to unclassified (which gives you a fairly good idea that you can drive your car there slowly, but safely) – it’s more akin to road (i.e. can be pretty much anything, and provides no guarantees even about safe walking).
It was an error made back in 2008 that we (re)defined path to have a ridiculously broad scope, unlike the fine classification we had for road vehicles. However, the genie is out of the bottle now. The best way forward is probably to refine them with a new path=* tag, with values such as urban, hiking, mtb, motorcycle, alpine, … and gradually classify the existing ones.
I am afraid that there are no other reasons for this than grandfather rights. OSM focused on highways and their needs before outdoor activities, and now finding solutions for paths would endanger the rather comfortable and stable situation that highways enjoy so far.
I’m not saying that out of spite, it’s just an observation that this is all about spreading the cost of change.
I would suggest that this difference lies in some sort of post-hoc rationalisation of what had been done previously for highways. What people do first is create categories based on intuitive premises, that can involve physical or usage attributes indifferently. Then, if they are asked about the rationale behind this they look at what they did and choose the most discriminating attribute that they can identify.
I was recently exposed to the strong opinion that “classification should rely on physical characteristics and not usage”, but it seems no more founded to me. Sometimes it’s more physical, sometimes it’s more usage or legal-oriented, sometimes it’s a balanced mix.
Parallel to all other possibilities of how to solve the path-issues, I would welcome a “task force” that would work in exactly this: a proposal of what types of path we have. Once we know the types we’re dealing with, we could try to group them into something meaningful, so that we end up with a few clearly distinctive categories that can be used as presets and maybe another sub-tag to go further into detail. And this time, we should be very thorough.
Even if we don’t end up using these as official tags, understanding the types of paths out there—whether we even want to call them paths—would be beneficial. Right now, the only consensus seems to be that highway=path isn’t helpful, but people have very different opinions what issues arise from it.
I know that especially @Hungerburg has been trying to do exactly this for quite some time now, and I like how diverse the opinions and examples have been so far
I think it is clear that none of the ideas presented so far, actually is a practical fix for the perceived highway=path ambiguity. Even if one method was chosen and pursued, highway=path without further tags would still exist in OSM for a very long time.
Which means that data users still need to figure out what to do with highway=path. Not displaying or routing them at all is one option, data users are free to decide that, but I would turn away from any renderer or router that does that before you can say “Iznogoedh”. I’m a hiker, and I need my paths!
That’s one of the things that surprised me most when getting to know the OSM community, by contrast with other ecosystems I have been involved in: the apparent absence of efficient forums to coordinate with data users