But, aren’t those “sidewalk” highway=path also mostly mapped with bicycle=designated (or bicycle=yes)? While most of those “forest path” highway=yes where oneway=yes is intended to apply to pedestrians lack bicycle=designated?
And if so, shouldn’t only combination of highway=path + bicycle=some_positive_value be considered for oneway=* to apply to vehicles only, and in other cases (i.e. highway=pathwithout tagged bicycle or other non-pedestrian access restrictions) we should prefer oneway:foot / oneway:bicycle etc. to avoid ambiguity?
Oh, I absolutely agree with you that “meaning of the oneway tag should not change”; in the same meaning that I agree that there “should not be wars”.
Sadly, reality in both cases is that it does (often) happen, regardless of our wishes and best efforts.
Thus, taking into account unavoidable future where our (shared) wishes will be disregarded by many; some pragmatic solution for handling that problem of tagging amiguity in more usable way (i.e. making the tagging non-ambiguous) should be devised (thus: oneway:foot and similar proposals)
(but hey, if you have some magical way to make every mapper becoming instantaneously enlightened and starting tagging as it should be done, which does not involve OSM becoming dictatorship and ruling with iron fist; I’m all ears!)
Otherwise it will introduce errors when mappers refine footways with steps or vise versa.
Surely, mappers “refining footways” should look at the things that they are modifying, right? Also, what exact problem for such refining do you forsee that using oneway:foot=* will not make better (as opposed to using only oneway=*)
Sorry but one is the definition and the other is current usage. We need to have a clear definition and give more help for correct tagging. If tagging is ambiguous according to this clear schema, there should be warnings and a request for clearer tagging should be made.
However, the schema does not become clearer and simpler for mappers if it assumes a different meaning for oneway depending on the highway value or access tags.
There is no question that data users have to react on supposedly incorrect tagging regardless of this.
I would be happy if we could continue to exchange friendly, factual arguments.
I think we should discuss the pros and cons of all possible solutions.
After this statement I no longer understand what you are getting at.
I have nothing against oneway:foot
I only say we should handle footway and steps the same.
Some are completely happy with oneway=yes on pure pedestrian infrastructure (footway, steps) and see no problem in the fact that the meaning then depends on the highway value and all possible access values.
Point 2: ambiguous oneway.
There are different approaches to resolving the potential ambiguities.
We ask the mapper to clarify with oneway:foot=yes/no
we generally require oneway:<travel_mode>=yes for each effected travel mode
we also prohibit the potentially ambiguous oneway=yes on these paths
Point 3: There is still a discussion about which highway types need to be included:
Yes, if we accept this, then we can approve oneway:foot and simply say: whenever a way is legally accessible to some form of vehicle and one-way for pedestrians, use oneway:foot. When a way isn’t legally accessible to any vehicles, using oneway to mean pedestrians is fine. But that would mean that data consumers such as pedestrian routers would need to look at vehicle access tags to figure out if a way is one-way for pedestrians… this is rather counterintuitive!
In contrast, with my proposal, a pedestrian router only ever needs to look at oneway:foot (leaving aside the question of highway=steps, =via_ferrata, =corridor, … for a minute).
Some think I’m going too far in suggesting that we deprecate oneway on footway, others think I’m not going far enough because they want to get rid of oneway altogether.
The proposal is meant to be a compromise, a middle ground. Overall, do people find it acceptable, even if it’s not everyone’s favourite solution?
I’m still planning to strengthen the motivation part of the proposal by adding more pictures and examples that demonstrate the main problem: that pedestrian-focused data consumers that see oneway on a footway don’t know what to do with it, because they don’t know what the mapper meant. This is mostly for the benefit of people who haven’t followed these threads.
We maintain that oneway=* without :foot does not apply to pedestrians.
We suggest validators warn if they encounter a oneway=* which appears to be intended for pedestrians, for example on a highway=footway or highway=path without vehicular access. Such a warning can be resolved by explicitly tagging oneway:foot=*.
The exact criteria of when to show a warning can be left to validators, and these can be fine-tuned over time. No formal deprecation of tag combinations is needed.
It may be fine in some situations, if oneway:foot=* is also present to avoid the ambiguity.
With the proposal it becomes possible to choose between oneway:foot=yes or foot:backward=no. This is no different than other modes (e.g. oneway:bicycle=yes or bicycle:backward=no). Based on context/signage you can choose which tagging is more appropriate (e.g. consider whether you, standing at one end, can see whether you are allowed to enter from the other end).
I can see this working. It’s a combination of my proposal and what @Langlaeufer proposed further up in this thread.
On footway, oneway=yes by itself is unclear, but oneway=yes oneway:foot=no is clear, as is oneway=yes oneway:foot=yes.
With the proposal approved, there will be two ways of tagging oneway on footway unambiguously. One is avoiding bare oneway= and just tagging the mode-specific one-way tags, e.g. oneway:foot= and oneway:bicycle=. The other is generic oneway= plus oneway:foot=.
The implications of both tagging options for editors and data consumers are the same: bare oneway without oneway:foot should be flagged by validators. Presets should discourage mappers from setting just oneway=. (Only talking about footways here.) Pedestrian routers and pedestrian maps only need to look at oneway:foot.
… but only insofar as highway=footway, as I understand the latest proposal? E.g. on (highly popular for pedestrians) highway=path, pedestrian maps/routers would still have to consider and guess other tags (like oneway), right?
Well, I agree that trying to get rid of oneway altogether is too ambitious, but dropping highway=path makes the proposal quite much weaker for little benefit. (there is huge amount of highway=path + foot=yes|designated - more than 1.5 million, as those are basically semantically the same as highway=footway so it makes no sense to treat them completely differently).
But those sidewalks are then usually marked with bicycle=designated|yes, aren’t they?
I’d suggest that oneway:foot should be recommended not only on highway=footway, but at least1 also on those highway=path which don’t have bicycle=yes|designated explicitly specified (as that is by far most common vehicle that would be used/mentioned on such paths).
I would think that such concession should allow highway=path back into proposal?
1 - I personally would prefer for oneway:foot to be recommended on allhighway=path too, in addition to highway=footway, but I can understand the opposition…
By default, highway=path allows bicycles, so the meaning of oneway=yes is well-defined there[1]. You can always turn any highway into a “footway” by adding access=no + foot=designated[2], but that should not automagically change the meaning of oneway=* – which is an important point in the proposal. Again: access tags should not change the meaning of oneway=*
Even if it seems to make this a weaker proposal, there’s a big movement to rework the whole highway=path-chaos, which might end up splitting off a bunch of new highway-tags which would also fall into the category of ways that should require oneway:foot=* to be set. To me, that seems to be a better step forward.
I do agree, that in general, a good validator should throw a warning for any highway that doesn’t allow vehicles due to access tagging that has oneway=yes. But deprecating the tag on highway=path in general? Rather not.
I am aware that in Australia, the default access of a highway=path excludes bicycles, but that seems to be the only exception. ↩︎
just adding foot=*would still allow bicycles, and a lot of these paths will have bicycle=designated in addition to foot=designated, so 1.5 million is a bit far-fetched ↩︎
What I would really like to avoid is a situation where pedestrian routers need to look at bicycle/vehicle access tags to find out if the oneway tag is likely to apply to pedestrians. That’s basically the current situation and what we should move away from.
In the current proposal text, path is treated like a street, so oneway only ever applies to vehicles, never to pedestrians. Therefore pedestrian routers only need to look at oneway:foot. Whatever the highway type, if it’s one-way for pedestrians, then oneway:foot is the recommended way of tagging that.
The difference in the proposed treatment of footways on the one hand and paths, cycleways and and streets on the other hand isn’t huge. It’s simply in whether a bare oneway tag is considered acceptable, or whether we prefer mappers to clarify the situation by adding/using more specific tags such as an explicit oneway:foot and oneway:bicycle.
The 1.5M highway=path foot=designated examples you quote will include a lot of paths that also have bicycle=designated and segregated=yes/no. That’s the main way to map designated shared-use paths in some countries, e.g. Germany. A lot of them are oneway for bicycles but not for pedestrians and the most common way of mapping that is using oneway=. I spent some time checking on Overpass and that made me realise that they far outnumber the one-way hiking paths where mappers used oneway= to mean pedestrians.
Therefore I think on path, a validator should flag oneway= when they think it is likely that the mapper meant pedestrians, e.g. when oneway= appears alongside sac_scale= on the same path, or even any path without bicycle= access tags, how to identify that while minimising false positives is up to them. The message could read something like “hey are you sure you really meant oneway and not oneway:foot? The convention is that on highway=path, oneway only applies to vehicles, so if you meant one-way for pedestrians please use oneway:foot”). But at the same time it is OK for the proposal to reaffirm the convention that oneway on path only applies to vehicles. Does that make sense to you @Matija_Nalis?
Integrating ideas from @JeroenvanderGun and @Langlaeufer, I’m no longer proposing to deprecate oneway on footway. More specific tags e.g. oneway:foot should be used, but this can be instead of or in addition tooneway.
And following comments by @Dieterdreist, the proposal now says that data consumers should continue to support foot:backward.
I’ve also added a table of examples.
I think the proposal is nearly ready for a vote, so I would appreciate any final comments!
