Proposal:One-way for pedestrians

One-way for pedestrians
Proposal status:	Rejected (inactive)
Proposed by:	Osmuser63783
Tagging:	oneway:foot=* Data item
Statistics:
Draft started:	2024-08-23
RFC start:	2024-09-01
Vote start:	2024-12-08
Vote end:	2024-12-31

Proposal

• Formalise the existing key oneway:foot=* (on ways ), to be used for indicating that a way is one-way for pedestrians.
• The existing tagging convention is that the key oneway=* on streets (e.g. highway=service, highway=residential, highway=pedestrian), on cycleways (highway=cycleway), and on paths (highway=path) does not apply to pedestrians. No change to this is proposed.
• In the rare case that such a way is (also) one-way for pedestrians, it should (additionally) be tagged oneway:foot=yes.
• On highway=footway, do not use the key oneway=* by itself: it is ambiguous. Use more specific keys instead or in addition (see Tagging section below for concrete tagging suggestions). In particular, if it's one-way for pedestrians, use oneway:foot=yes, in addition to or instead of oneway=yes.

Rationale

Mappers are currently using three different keys for expressing that a highway=footway is one-way for pedestrians: some use oneway=*, others use oneway:foot=*, and yet others use foot:backward=*. Especially the use of the key oneway=* for this purpose is problematic because it can create ambiguity. After a long discussion in the community forum, this proposal presents a compromise between the different tagging schemes.

Issues with using oneway=* on highway=footway

The key oneway=* is most commonly used on streets (e.g. highway=residential, highway=service) where it means that vehicles can only use the street in one direction. It of course does not apply to pedestrians: they can walk against the direction of the way. This is how the tag works in the vast majority of cases it is used (over 98% of cases) and this proposal will not change this.

However, the key has also occasionally been used in situations where the mapper who put the tag meant pedestrians. This happens for example on highway=via_ferrata, on highway=steps, on highway=footway. Examples of this include hiking paths that can only be used in one direction (1, 2), entrances to zoos, amusement parks and tourist attractions (1, 2) and public transport (1, 2).

However, sometimes a footway can be used both by pedestrians and by some form of vehicle (usually bicycles). In such cases, the one-way restriction typically only applies to vehicles. A common example of this is a sidewalk on each side of a road (1, 2).

This introduces ambiguity: did the mapper who put the oneway=* tag on a highway=footway mean pedestrians or only vehicles? It's often possible for an experienced mapper to tell by looking at the other tags on the way and the context: If it's a hiking path in the mountains, the mapper probably meant hikers. If it's a sidewalk, pedestrians can probably walk both ways and the mapper who put the tag only meant cyclists. But having to look at other tags to understand how to interpret oneway=* is far from ideal, and even then there are situations where it is unclear.

There has been a lot of discussion on the community forum on the best way forward. Some people argue that the tag oneway=* only ever applies to vehicles, even on a footway. This would mean that a hiking path tagged oneway=yes has simply been tagged incorrectly and needs to be corrected, whereas using oneway=yes to mean one-way for bicycles is completely fine. Others argue that a footway tagged oneway=yes to mean one-way for pedestrians is completely fine, at least in situations where vehicles are not allowed. These two positions are the exact opposite of each other. This is an issue for pedestrian routing, because a data consumer cannot see which philosophy the mapper was following.

Therefore, this proposal represents a compromise between both positions: let's stop using oneway=yes on highway=footway by itself, and use less ambiguous tags instead or in addition.

Unambiguous alternatives

Over the years, two unambiguous alternatives for pedestrian one-ways have emerged: oneway:foot=yes and foot:backward=no. It's time to decide which one is preferable. At the time of writing, oneway:foot=* is vastly more popular among mappers (7810 vs. 505 uses; 81% vs 19% of votes in a community forum poll).

This proposal doesn't deprecate foot:backward=*. It's a valid combination of the foot=* access tag and the :backward suffix that has already been approved in a previous proposal. Data consumers should continue to support it. But it's time for the community to express a preference. This provides clarity for the developers of editor presets which tag we want to be supported.

What about highway=path?

Sometimes hiking trails are one-way, often for safety reasons. Mappers sometimes tag these as highway=path oneway=yes: examples 1, 2, 3, 4, 5. But overall this concerns a relatively small number of paths, compared with the many paths that have the oneway=* tag where the mapper only meant cyclists. Therefore, this proposal maintains that oneway=* on highway=path means vehicles, and oneway:foot=* should be used when pedestrians are meant.

Tagging

If the proposal is accepted, there is no change to the definition of oneway:foot=* or foot:backward=*.

The proposal adopts the following tagging recommendations.

1. Whenever a way (path, footway, street..) is one-way for pedestrians, use oneway:foot=yes.
2. If a street (e.g. highway=residential, highway=pedestrian) or a path (highway=path) is one-way for vehicles, but not one-way for pedestrians, use oneway=yes. No need to tag oneway:foot=no explicitly.
3. If a highway=footway is one-way for vehicles (e.g. bicycles), but not for pedestrians, either tag it with vehicle-specific one-way tags, e.g. oneway:bicycle=yes, oneway:foot=no, or tag it with a generic oneway=yes, and add a foot-specific oneway:foot=no.

Mappers will be discouraged from using oneway=yes on highway=footway without also using more specific tags that clarify its meaning. This can be achieved, for example, by expressing a clear recommendation on relevant Wiki pages and by implementing validator warnings that alert mappers that the tag, by itself, is ambiguous. Editor presets could stop offering oneway=yes and offer less ambiguous alternatives instead. Until the tag is widely adopted, data consumers will unfortunately still need to guess what the mapper meant (e.g. in a pededtrian router, ignoring oneway=* will lead to mistakes, and taking it into account will likewise lead to mistakes).

The oneway:foot=* key can be used with the same values as oneway=*, with the same definitions: yes, no and -1, but also alternating and reversible, if this situation exists somewhere.

Examples

Current usage

Some examples of oneway=* on highway=footway and highway=path were given above. More can be found with the help of Overpass Ultra: footway, path. This is helpful to get an impression of how inconsistently the tag is used. I highly recommend looking at different regions around the world. When I looked at examples of highway=footway with oneway=yes in Germany, almost all were shared-use sidewalks and the mapper probably only meant bicycles. Elsewhere - in the UK, US, and South America - the majority were in shopping centres, zoos, airports, museums, and the mapper probably meant pedestrians.

Proposed usage

Picture	Description	Proposed one-way tagging
	One-way hiking trail	highway=path and oneway:foot=yes
	One-way footway	highway=footway and oneway:foot=yes
	Footways that allows bicycles, but only in one direction	These are commonly tagged highway=footway, bicycle=yes. To indicate that the footway is one-way for bicycles, but not for pedestrians, use oneway:bicycle=yes and oneway:foot=no. Alternatively, use oneway=yes and oneway:foot=no. Avoid using oneway=yes by itself.
	Designated shared-use paths, where pedestrians and bicycles have equal rights, but bicycles are only allowed in one direction.	Assuming that the way is tagged as highway=path, foot=designated, bicycle=designated: To indicate that the path is one-way for bicycles, but not for pedestrians, use either oneway:bicycle=yes or oneway=yes. No need to add oneway:foot=no, as the oneway=yes is considered to apply to vehicles only.
	One-way streets	Tagged with the appropriate highway classification e.g. highway=residential, plus oneway=*. It is clear that the oneway=* tag does not apply to pedestrians e.g. on the sidewalk (no change).

Rendering and routing

Pedestrian routers need clarity whether tags are supposed to apply to pedestrians or not. Hiking and pedestrian-oriented maps may want to show which ways are one-way for pedestrians, while cycling maps will want to show which ways are one-way for cyclists. This proposal provides clarity to all data consumers, instead of having to guess what the mapper probably meant based on the context:

Anyone who wants to know if a way is one-way for pedestrians can ignore the oneway=* tag. Look at oneway:foot=* instead.

Features/Pages affected

• oneway=*
• oneway:foot=*
• highway=footway

External discussions

• Request for comments on the forum, September–December 2024
• Effect of oneway on pedestrians? community forum discussion that led to this proposal, Jan 2023-Aug 2024
• Which one is the better tag to say that a way is oneway for pedestrians?, community forum poll that led to the decision to promote oneway:foot=* over foot:backward=* in this proposal, Aug 2024
• How to map one way Cycle & Foot Path where only the cycleway is one way, community forum discussion, Feb 2024
• footway mit one-way=yes, previous discussion in German, Oct 2021
• Foot ignores one-way information, discussion on GraphHopper issue tracker, July 2024
• Misinterpretation of highway=pedestrian, oneway=yes discussion on Valhalla issue tracker, March 2023
• Footways where pedestrians may only walk in one direction: oneway:foot=yes or foot:backward=no? discussion on tagging mailing list, Apr 2020 (no clear consensus, just different opinions)
• How to tag oneway restriction applying to pedestrians? discussion on tagging mailing list, Jan 2020 (no clear consensus, just different opinions)

Comments

Please comment on the discussion page or in the community forum.

Voting

Voting closed

Voting on this proposal has been closed.

It was rejected with 35 votes for, 19 votes against and 5 abstentions.

Thanks for participating in the discussion. I'll post my summary in the community forum (where the discussion is ongoing).

• I approve this proposal. --Flo Edelmann (talk) 12:54, 8 December 2024 (UTC)
• I approve this proposal. --Mueschel (talk) 14:09, 8 December 2024 (UTC)
• I approve this proposal. --rhhs (talk) 15:09, 8 December 2024 (UTC)
• I approve this proposal. (though I am unsure is https://wiki.openstreetmap.org/wiki/File:One_way_for_pedestrians_on_Fye_Bridge_-_geograph.org.uk_-_6507482.jpg having any legal implications - is it maybe suggestion without any weight or randomly painted by someone?) --Mateusz Konieczny (talk) 18:07, 8 December 2024 (UTC)

I love how that person on that picture just walks in the "wrong" direction:-). Supsup (talk) 18:42, 8 December 2024 (UTC)

• I approve this proposal. Supsup (talk) 18:42, 8 December 2024 (UTC)
• I approve this proposal. --RedAuburn (talk) 21:28, 8 December 2024 (UTC)
• I oppose this proposal. The tag is already in use, so why does it need approval? I did not think it all through to the end, but from my limited point of view: At worst, it adds redundancy, while making life easier for both mappers and consumers, so an "approved" badge certainly in order: Mappers can be concise, consumers need not rely on heuristics. --Hungerburg (talk) 23:34, 8 December 2024 (UTC) Reading the forum talk, the proposal goes too far. --Hungerburg (talk) 17:25, 28 December 2024 (UTC) Changed my mind again, a proposal that declares highway=footway+oneway=yes as nonsense must not pass. I'd even extend that to highway=path, but that is is up to further discussion. --Hungerburg (talk) 23:59, 30 December 2024 (UTC)
• I approve this proposal. --Jofban (talk) 00:34, 9 December 2024 (UTC)
• I oppose this proposal. I don't think we should define a synonym for the standard foot:backward=no, and I perceive oneway:foot=* as troll tagging, given that oneway=* only applies to vehicles. Are you also planning to formalize oneway:horse? There the numbers are in favor for horse:forward and :backward--Dieterdreist (talk) 11:38, 9 December 2024 (UTC)
• I approve this proposal. --Ralley (talk) 18:22, 9 December 2024 (UTC)
• I approve this proposal. --Adiatmad (talk) 03:55, 12 December 2024 (UTC)
• I approve this proposal. But please avoid oneway:bicycle=yes and suggest at least oneway:vehicle=yes instead. If it's oneway for bicycles, it's oneway for all vehicles. Nadjita (talk)

depends on the jurisdiction and signs. --Dieterdreist (talk) 09:10, 13 December 2024 (UTC)

• I oppose this proposal. HellMap (talk) 10:49, 15 December 2024 (UTC)

I misunderstood the proposal originally. I thought the proposal was about preferring oneway:xxx=* over xxx:forward=* (since oneway=* is the accepted scheme for directional access instead of access:forward=*). I thought this was to clarify ambiguous cases, like pedestrian streets, not to remove any existing oneway=* values. oneway=* on highway=footway or highway=path is how it is de facto used for pedestrians (and anyone else allowed, like bikes, scooters, mobility, whatever) and I don't see a problem with that. It obviously doesn't mean vehicles (whatever the wiki says) if that mode is by default not allowed. Removing oneway=* completely just makes it more ambiguous or needs a second tag - e.g., are bikes one-way? It's like we have "top-level" access=* instead of adding every mode to every way. We have a top-level oneway=* and can add oneway:xxx=* as needed, which is what I thought this proposal was formalizing. Like explicitly adding oneway:foot=no to highway=cycleway that is oneway=yes by default for bikes only (and anything like ebikes, scooters, mobility, sports eq., wheelchairs, whatever). HellMap (talk) 12:12, 16 December 2024 (UTC)

Thanks for explaining @HellMap: The tricky part is "if that mode is by default not allowed". It means a pedestrian router needs to look at bicycle=* and other access tags to make an educated guess if pedestrians can be routed both ways or not. That's counterintuitive and I don't think it's going to happen. Also I'm very happy with people treating oneway=* as a top level tag and then adding oneway:foot=* for extra clarity, only when needed. Of course, I argue that on highway=footway, that extra clarity is always needed. Osmuser63783 (talk) 15:53, 23 December 2024 (UTC)

• I approve this proposal. Jean-Baptiste (talk)12:30, 15 December 2024 (UTC)
• I approve this proposal. --GanderPL (talk) 12:01, 15 December 2024 (UTC)
• I approve this proposal. -- Juliencouty
• I approve this proposal. I support this proposal although I even never see a pedestrian is oneway. But I guess this is helpful in other places of the world. --快乐的老鼠宝宝 (talk) 14:17, 15 December 2024 (UTC)
• I have comments but abstain from voting on this proposal. I understand the critic of Dieterdreist,but can live with both tagging schema. --Nospam2005 (talk) 14:21, 15 December 2024 (UTC)
• I approve this proposal. --Wolfgang8 (talk) 14:44, 15 December 2024 (UTC)

• I oppose this proposal. '"When I looked at examples of highway=footway with oneway=yes in Germany, almost all were shared-use sidewalks and the mapper probably only meant bicycles. Elsewhere - in the UK, US, and South America - the majority were in shopping centres, zoos, airports, museums, and the mapper probably meant pedestrians."' To me, this investigation shows that the worldwide consensus is to use oneway=yes to indicate pedestrian oneways, and that mappers in Germany are doing something irregular. I am thus opposed to formally changing the emerged consensus in most of the world to suit mappers in Germany. Why not simply tag footways that are oneway for bicycles but not for pedestrians as oneway:bicycle=yes? --Willkmis (talk) 15:02, 15 December 2024 (UTC)

Thanks @Willkmis:. I think you may be underestimating both how big the German community is and how well established the consensus is in this community that of course the oneway=* tag doesn't apply to vehicles. Also, I didn't look at other European countries e.g. Netherlands, Denmark. They may well be following the same approach. In short, I don't think there's a majority for declaring that oneway=*, on highway=footway, applies to pedestrians. I don't think there's a majority for declaring that it doesn't. So the only option that I think we have left is to declare that we don't know what it means, until you add oneway:foot=*. Osmuser63783 (talk) 07:50, 26 December 2024 (UTC)

• I oppose this proposal. Introducing a second variant to tag the seldom real world situation of oneway for pedestrians does not make it easier for mappers and consuming software. We already have foot:forward=no resp. foot:backward=no and our efforts should go into teaching mappers and consumers that oneway is not defined for pedestrians and to get editor software to support the keys foot:forward=* and foot:backward=*. --Skyper (talk) 16:13, 15 December 2024 (UTC)
• I oppose this proposal. There was no ambiguity when I mapped this footpath as a one-way based on a sign that the park put up saying to go clockwise around the lake. If oneway=* has been skunked in Germany, sure, use oneway:foot=* there as part of a regional cleanup effort with an eye toward eventually migrating the rare pedestrian one-ways back to oneway=* or foot:forward=* as the case may be. No need for a tag approval, because it fits an existing scheme. This proposal raises all sorts of questions about the plethora of other non-vehicular feature types (escalators and steps?) and modes of transportation (wheelchairs and strollers?) that suddenly stick out if we special-case feet on footways. – Minh Nguyễn ^💬 17:05, 15 December 2024 (UTC)
• I approve this proposal. --Walkingmage (talk) 19:01, 15 December 2024 (UTC)
• I oppose this proposal. I see no problem with using oneway=* on highway=footway or highway=path and I oppose the statement that this should not be done. More specific sub-tags like oneway:foot=* are of course also fine and no proposal is needed for them. -- Ezekielf (talk) 20:12, 15 December 2024 (UTC)
• I have comments but abstain from voting on this proposal. In the spirit of improving OSM, I would encourage anyone who thinks that foot:backward=no is a good and intuitive tag to find at least one use of hiking oneway=yes and add your preferred tag or find a local mapper and teach them to use it. Here's a freebie for the first person who sees it and here's an area with lots of others. --Jarek Piórkowski (talk) 02:36, 16 December 2024 (UTC)
• I approve this proposal. Rjw62 (talk) 13:26, 16 December 2024 (UTC)
• I oppose this proposal. no problem with the new tag, but its existence shouldn't require a vote and it should not preclude use of the unscoped tag. --Dschep (talk) 13:54, 16 December 2024 (UTC)
• I approve this proposal. --Brummelwuff (talk) 08:39, 17 December 2024 (UTC)
• I approve this proposal. Highly logical. --Pereric (talk) 10:13, 17 December 2024 (UTC)
• I approve this proposal. -- Something B (talk) 11:10, 17 December 2024 (UTC)
• I approve this proposal. --EneaSuper (talk) 13:14, 17 December 2024 (UTC)
• I approve this proposal. --R2d (talk) 13:29, 17 December 2024 (UTC)
• I approve this proposal. oneway=* is mainly used (and defined on wiki) for vehicle traffic, e.g. oneway streets. I therefore agree with the argument that oneway=yes on highway=footway should be replaced by a more specific key. --Discostu36 (talk) 14:32, 17 December 2024 (UTC)
• I approve this proposal. Even if oneway:foot is somewhat illogical (since :* restricts the previous value), the use of oneway is intuitive and :* can also be seen as an extension. I welcome it when there is a voted preferred tagging variant. --Robert46798 (talk) 17:20, 17 December 2024 (UTC)
• I oppose this proposal.The baseline semantics of `oneway=yes` on `highway=footway` are simple enough -- that footway is a one-way path for all footway users. (I actually have tagged this situation before, as some of the more sophisticated `railway=level_crossing`s in the US have "escape" swing gates that provide an escape route out from the crossing around the pedestrian boom gates, but prevent people from going around the boom gates on the way in.) This situation simply does not merit a global tag change. --UrbanUnPlanner (talk) 15:55, 21 December 2024 (UTC)
• I oppose this proposal. I agree with the concerns raised by Ezekielf and Minh Nguyễn. oneway:foot=* is fine for resolving ambiguity on shared-use ways, but there is no ambiguity in highway=footway + oneway=yes and I oppose deprecating that tagging. — Jake Low (talk)
• I oppose this proposal. I agree with the others opposed to this --Bradrh (talk) 00:41, 22 December 2024 (UTC)
• I oppose this proposal. I do not concur with deprecating oneway=* in favor of foot:oneway=yes/no. It's already assumed with oneway=* on a highway=footway that this applies to all users. --CurlingMan13 (talk) 03:36, 22 December 2024 (UTC)
• I oppose this proposal. I agree with everyone else opposing this. oneway=yes on footways is not ambiguous. This seems like overcomplication just to serve a relatively small set of features in a specific corner of the world. I also think we don't need to cancel one out to have the other. Joseph R P (T • C) 04:38, 22 December 2024 (UTC)
• I oppose this proposal. I don't see oneway as ambiguous on footways and think that a better first step would be starting to use the new tagging you propose without deprecating existing tagging that works well in most cases and is simpler for editors and data consumers to manage --Nicksantos (talk) 06:42, 22 December 2024 (UTC)

Thanks @Nicksantos: I think you've misunderstood. oneway:foot=* is already widely used, the proposal just confirms it and promotes it over worse alternatives. The proposal also doesn't deprecate any tagging. For example, I'm very happy with people using oneway:foot=* additionally, for added clarity, alongside oneway=*, on highway=footway. This makes things easier for data consumers to manage, because a pedestrian router only needs to look at oneway:foot=* and not oneway=*. The current situation is a nightmare for pedestrian routers because when they see oneway=*, they would have to look at vehicle access tags like bicycle=* to figure out if the footway is shared-use and the one-way probably doesn't apply to pedestrians. (Not one router I know of does this.) Osmuser63783 (talk) 07:39, 26 December 2024 (UTC)

• I have comments but abstain from voting on this proposal. I think there is some confusion regarding cycleways in the current proposal. In the Proposal text at the beginnibng, it is said that the current convention on tagging cycleways would not be changed. However, the examples list a (shared) cycleway in which the new scheme (oneway:bicycle=yes) would be introduced and the current convention (just using oneway=yes to indicate bicycle onewayness) deprecated. I'd be happy if the proposal would be updated so that it would categorically ONLY concern footways. The current convention (of oneway=yes applying by default to all vehicles, including bicycles, and not pedestrians) is clearer. --Tolstoi21 (talk) 09:00, 22 December 2024 (UTC)

Which example do you mean? There is no highway=cycleway in the examples section, and the proposal asserts / confirms that on cycleways, as well as on paths, oneway=* does not apply to pedestrians. Osmuser63783 (talk) 13:02, 22 December 2024 (UTC)

Oh, sure. You're correct. The proposal text says that "Assuming that the way is tagged as [path]". Where I hail from, that assumption would never hold. We tag ways with (Vienna Convention) blue roundels indicating a shared footway and cycleway as highway=cycleway. Ditto for the example below it. However, more generally, my objection is that one-way rules for pedestrians (regardless of the specific highway=* tag in OSM) are always very rare exceptions. Therefore I would accept the new schema for those, but would leave oneway-tagging otherwise untouched. Usually oneway legislation applies by default to all vehicles and never pedestrians. The exceptions should be tagged exceptionally. Where I'm from, there are e.g. exceptions (expressed by traffic signs) that allow bicycles two-way traffic on otherwise oneway streets. We tag these as oneway=yes + oneway:bicycle=no. It's the most efficient and curt way of expressing the general case and the exception. I argue that this idea should be adopted also for this (otherwise fine) proposal. --Tolstoi21 (talk) 07:37, 23 December 2024 (UTC)

I agree with you. That's exactly what I'm proposing. Following my proposal, on a highway=cycleway that is one-way only for bicycles, tag oneway=* only, no need for oneway:foot=*, unless it's also one-way for pedestrians (the rare exception), in that case add also oneway:foot=yes. There's no example of a highway=cycleway in the Examples section, but hopefully this should become clear from the Proposal section. If the highway=path foot=designated bicycle=designated tagging style isn't used on your country, you can just ignore that example. Osmuser63783 (talk) 14:49, 23 December 2024 (UTC)

Okay. I've changed my vote to abstention. The two examples were throwing me off. I do think that the third and fourth examples ought to be changed to reflect the proposal statement in the beginning. I.e. remove the oneway:bicycle=yes option, as oneway=yes already applies to all vehicles (regardless of the highway=* value) by default. Only tag the exceptions. --Tolstoi21 (talk) 07:17, 24 December 2024 (UTC)

• I approve this proposal. --Eagle314 (talk) 14:42, 22 December 2024 (UTC)
• I oppose this proposal. I don't see the point of recommending this as for me personally the :backward suffix gives me the possibility to be explicit not just for foot but I can use it also for hgv, bus, and everything else listed on the access wiki page. So I don't see why one way of tagging should have priority over the other, if any, I'd favor using the suffix system. Regardless we have both valid tagging in place, either we keep both or we formally make one approved and the other deprecated. Otherwise what's the point of "formalizing" one over the other? --Hike&Map (talk) 00:23, 23 December 2024 (UTC)
• I approve this proposal. --ratrun (talk) 05:40, 23 December 2024 (UTC)
• I approve this proposal. -- Oruk09 23:40 December 2024 (UTC+9) I agree! But I wish there were more alternatives to this, like marking lines at amusement parks --
• I have comments but abstain from voting on this proposal. I generally agree with formally introducing oneway:foot=yes, however I disagree with the generic preference over foot:backward=no that is expressed in the rationale. In my opinion, the choice between these two options should depend on what is more appropriate for the specific situation/signage, just like the choice for vehicles between oneway=yes and vehicle:backward=no. --JeroenvanderGun (talk) 18:44, 23 December 2024 (UTC)
• I oppose this proposal. Adding the new tag id great. Claiming that paths with oneway=yes are ambiguous is incorrect. They are, perhaps, underspecified but that can be helped by increasing the detail of tagging on those and leaving the rest alone. Would love to support this proposal without that caveat. —Preceding unsigned comment added by Watmildon (talk • contribs) 01:30, 25 December 2024‎ (UTC)
• I approve this proposal. --Timmy_Tesseract (talk) 08:59, 27 December 2024 (UTC)
• I approve this proposal. --Osmuser63783 (talk) 14:21, 27 December 2024 (UTC)
• I oppose this proposal. Tag is good for ambiguous cases, such as a road for cars. For `highway=path` or `highway=footway`, `oneway=yes` is unambiguous and I oppose mandating mode-specific `oneway` tags. --ZeLonewolf (talk) 18:10, 27 December 2024 (UTC)
• I approve this proposal. While I'm not happy with parts of the proposal (see community discussion) I think that net result is likely more helpful than problematic, and find it unlikely that better compromise will come along. For myself, I think (regardless of this proposal outcome) that whenever I'll want to tag oneway directions for pedestrians I'm going to tag both oneway=* and oneway:foot=* always to avoid ambiguity. --mnalis (talk) 00:15, 28 December 2024 (UTC)
• I oppose this proposal. I also do not think oneway=* is ambiguous on =path, =footway, etc. --Jmarchon (talk) 06:16, 28 December 2024 (UTC)
• I approve this proposal. I'd prefer to discourage "naked" oneway=* in all cases where some users of the highway are exempt, but this proposed change at least improves the situations which need it the most and doesn't rely on oneway=* magically changing its meaning depending on an open-ended set of other tags. --Tordanik 08:44, 28 December 2024 (UTC)

• I have comments but abstain from voting on this proposal. I think oneway:foot is a good intuitive tag while foot:backward=no is not because of the double negation. I am confused about highway steps. Why is it not mentioned in the proposal? To me, highway steps with oneway=yes is clear as oneway to the pedestrians. Is this so? If yes, we already have a precedent where oneway is for pedestrians and does not need oneway:foot. This case could be extended to footway in my opinion. I would not extend it to path though.--Nielkrokodil (talk) 09:00, 28 December 2024 (UTC)
• I approve this proposal. --Osmwithspace (talk) 21:42, 28 December 2024 (UTC)
• I approve this proposal. --Vincentius (talk) 11:29, 29 December 2024 (UTC)
• I approve this proposal. --JeroenHoek (talk) 18:52, 29 December 2024 (UTC)
• I oppose this proposal. --Quincylvania (talk) 16:02, 30 December 2024 (UTC)
• I approve this proposal. --Langläufer (talk) 19:14, 30 December 2024 (UTC)