If
oneway=yesshould not be used for pedestrians in ‘pedestrian-only’ situations, what should be used instead? Some of the suggestions so far seem to befoot:backward=noandoneway:foot=yes.
IMHO, oneway:foot doesn’t make sense because if oneway is applying to vehicles only, a subtag should be about a subset, not invert the meaning.
foot:forward / foot:backward on the other hand already should work out of the box because they follow established semantics, so this should be preferred.
Data consumers should surely apply a bit of common sense when processing the oneway tag? I’d absolutely expect to walk both ways along a residential road that has oneway=yes. I absolutely would not expect to be routed “the wrong way” on a oneway highway=footway.
I’d absolutely expect to walk both ways along a residential road that has
oneway=yes.
Yes, this is quite clear and I don’t think there is discussion about this.
I absolutely would not expect to be routed “the wrong way” on a oneway highway=footway .
So these are all tagging mistakes: way[footway=crossing][oneway=yes][highway=footway]? My point is that data consumers cannot rely on footway+oneway=yes actually meaning pedestrians can only walk in one direction.
I absolutely would not expect to be routed “the wrong way” on a oneway highway=footway.
just add foot:backward=no and you can remove the ambiguity 
Maybe you were trying to make a joke, but what ambiguity? There is literally only one mode of transport feasible there (my example is half-way up a cliff).
Why would those all be tagging errors? If you’re saying that “some footpaths are oneway” then I agree with you. Some may be mistaggings; I rather suspect that this is missing some tags and needs an update from a local rather than an armchair Facebook mapper.
Are you perhaps talking about where multiple transport modes are explicitly allowed, despite it being highway=footway? There are a couple of examples of those; like here.
My point that “Data consumers should apply a bit of common sense” obviously only applies where there isn’t ambiguity, like on the footpath halfway up a cliff. We don’t need to make tagging more complicated than it needs to be.
Maybe you were trying to make a joke, but what ambiguity? There is literally only one mode of transport feasible there (my example is half-way up a cliff).
if you assume that oneway only applies to vehicles, then it isn’t an error to have a oneway tag on a way which doesn’t allow vehicular traffic, it just wouldn’t have an effect. (although I agree in this particular context, a human looking on the map and assessing this specific situation will probably guess it is meant for pedestrians).
In other situations, maybe there was a highway=pedestrian oneway=yes and somebody retagged it to footway without touching the oneway restriction? You cannot generally assume that oneway on footways is meant for pedestrians.
I agree, but for me this means that oneway should have a clear meaning to whom it applies, and not depend on the situation (between 2 cliffs), or whether there is a bicycle=yes tag on a footway, or generally which kind of highway it is. Rules like this make tagging more complicated.
Because if you interpret footway+oneway=yes like you suggest for the cliff it would mean pedestrians can only cross the road in one direction which is probably wrong in close to all cases.
There might be no ambiguity if you look at the map and read the note, but data consumers are often not people looking at the map and reading the note. If the data were not easily machine-readable it would be useless for many otherwise possible use-cases. So how is a computer program supposed to distinguish this footway+oneway=yes on the cliff from a footway+oneway=yes elsewhere? If the aim wasn’t to make the data machine-readable we could just as well use written human-speech to describe each road (maybe that’s the future :))
I agree. And not just tagging but also using the data.
I think it is a translation issue. Full sentence is " The oneway tag is used to indicate the access restriction on highways and other linear features for vehicles as appropriate" and that “as appropriate” is redundant figure of speech in English, and only means that you:
oneway=yes where there are oneway restrictions, andoneway=no where there are no oneway restrictions.(which should be quite logical and straightforward and appropriate anyway; as surely one should never put oneway=no when they know it is oneway, right?)
In next sentence wiki even more clearly states "tag should be used when this way can only be used in one direction by vehicles" in less complex language.
On the other hand, the ‘Pedestrians’ subsection describes that it can be applied to pedestrians quite specifically.
Uh, are we talking about same page Key:oneway - OpenStreetMap Wiki here? It says exactly the opposite quite clearly right at the start of that section: “oneway restrictions do not apply to pedestrians”.
But yes, it does document some situations when people seem to have used the oneway tag in that contrary-to-the-documented way. Perhaps it should be more verbose that those situations are discouraged due to their ambiguity and should be (after checking the situation on the ground) replaced with non-ambiguous foot:backward=no or oneway:foot=yes or other tags (adding note=* if required for understanding)?
In fact, it is not a legal requirement, but it is quite common in certain cultures to implicitly follow the direction of entry.
oneway=*, like other access restrictions tags, is exclusively about legal restrictions.
If there is prevalent direction (due to practicality, or cultural norms, etc.) of using some way, some other tag should be used (see e.g. discussion about waterways where most commonly are used only in downstream direction, but as it is not prohibited by law, they use flow_direction=* instead of oneway=*).
Perhaps foot:backward=discouraged (or some other tag entirely) might be used if it is not a hard legal requirement. Although any such tags might usually suffer from verifiability problems if not signed on the ground…
Agreed. Unless it has explicit access=no + foot=yes, one could not assume that oneway=* is meant to apply to pedestrians (especially not on highway=* alone!)
I mean, why be intentionally ambiguous, when one can easily avoid any ambiguity by a simple act of adding an extra tag foot:backward=*?
Agreed. Also, if someone has a time machine 
, can we go back and never define oneway=* as a tag, but only use oneway: as a prefix (i.e. replace ambiguous oneway=yes with unambiguous oneway:vehicle=yes)?
That way we’d have simple, unambiguous and elegant solution of using oneway:vehicle=yes or oneway:foot=yes or oneway:bicycle=yes or any combination thereof.
I wonder whether we shouldn’t map a no-entry relation for pedestrians at the „end“ of the path to be sure 
Beware what you wish for: we already have (simpler solution; people are often not very fond of relations if they can be avoided) noexit=yes tag, so it’s not that farfetched that someone might document existing noentry=yes tag and it gathers wider acceptance…
But I’d still find access restriction tags on a way (e.g. motor_vehicle=no or oneway=yes) much more usable from consumer side than only restriction node (e.g. barrier=gate+locked=yes or noentry=yes on a nodes at the edges of the way).
Such nodes are IMHO fine as an addition, but not as a replacement for restrictions on a way… Doubly so for relations (e.g. relation restrictions are useful, but putting them on both sides of a way is not a replacement for e.g. oneway=yes on a way).
Ideally it should also explain why some situations are ambiguous and why the more specific tagging is needed/better, and in this context maybe also describe why some exceptions to these rules are still widely in use and/or accepted (if they are). Otherwise the wiki won’t be taken seriously. But again none of this will be of much use if there is no scheme most people agree with and to arrive at this a deeper look at the data will help as pointed out by @osmuser63783 above.
Yes. Or even better vehicle:backward=false. But I guess this is just a fantasy. However, it does help my understanding to simply think of oneway=yes as synonym for vehicle:backward=false.
I can sense the sarcasm, but just to be sure using a relation or node tags for something simple like a oneway constraint would be a terrible idea regarding simple consumption of the data (which I think is something OSM should always strive for).
The wiki is supposed to document how OSM mappers use tags. Sometimes, however, people like to update the wiki with how “they believe people should use tags” without actually considering how tags are actually used**. At the top of this thread there are a bunch of examples of perfectly valid oneway footways.
** and also the “solution” to this topic from 19 months ago, which adds a “summary” that does not reflect the real-world examples immediately above!
Ok, in my opinion ideally the wiki should both document a working tagging scheme (how to tag) and explain the current state of the database (how to use what is already there), with an explanation why there are still differences and some notes about how to do the migration, if necessary.
We need both. Yes, coming up with new rules on a blank sheet of paper without considering what is already there will hardly ever work. But if nobody ever proposed an improvement and only looked at the existing data the tagging would never improve, either.
IF people went outside and mapped things rather than fretting about silly tagging rules which allegedly imply “oneway=yes doesn’t actually mean oneway=yes” then the state of the data in OSM would be vastly improved 
Again both is needed: Active mappers mapping things and a working tagging scheme that encourages mappers to map and allows data users to build amazing things based on the data.
the problem is that this assumption is clearly not followed in general, and it seems that this claim was added to wiki in attempt to redefine how tagging is used (that has not worked, as usual)
disclaimer: I wrote previous version of wiki documentation that was reverted by this change
Unlike other tagging debates (abandoned railways?), this is one where we actually get incorrect routing results from various routers: some wrongly apply oneway tags to pedestrian routing even in cases where the tag was clearly meant to apply to vehicles only (Valhalla), while others (OSRM, GraphHopper, Komoot, Organic Maps) wrongly ignore the oneway tag on footways even in cases where the mapper clearly meant for it to apply to pedestrians. No router I’ve tried gets it right, so I am hopeful that better documentation will help.
After looking at examples of highway=footway oneway=yes around the world, some initial impressions:
bicycle=yes or bicycle=designated. It’s fairly clear from this context that the oneway was meant for bicycles only.bicycle tags, the oneway was probably meant for pedestriansbicycle=no, so oneway clearly meant for pedestrians. An underground cave. Airports again, amusement parks.