Effect of oneway on pedestrians?

IMHO all or nearly all of them. oneway situations for pedestrians don’t regularly occur they are intended for vehicles. Interpreting oneway=yes as restriction for pedestrians would definitely cause more problems than it would solve (for the area I know), even more if it is a highway=pedestrian, for which oneway is a more common situation, oneway=yes on footways is 16k of 23.7 million highway=footway | Tags | OpenStreetMap Taginfo
on pedestrian highways it is 13k of 800k: highway=pedestrian | Tags | OpenStreetMap Taginfo

From the kind of situation I can imagine for footways that may only be taken in one direction, I would guess most of them do not allow bicycles at all.

I have mentioned several times that there are quite a few contradictory or conflicting descriptions within the OSM wiki, but given the reality that there is no authoritative coordination body, it seems difficult to fix them in a short period of time. Nevertheless, I would like to mention this in the context of recognizing that we should all recognize this.
In the ‘Key:oneway’ section, I could not find any agreement that it should be used only for vehicles, and there is only the vague expression ‘for vehicles as appropriate’.
On the other hand, the ‘Pedestrians’ subsection describes that it can be applied to pedestrians quite specifically.
In light of this, I believe that the ‘Key:oneway’ key can be used for pedestrians as well, and in fact, it is used a lot and explicitly.
In fact, it is not a legal requirement, but it is quite common in certain cultures to implicitly follow the direction of entry.
(For example, it is common for the direction of entry to be implicitly applied at the entrances and exits of authoritative palaces or religious temples.)
Therefore, I think that we should reach an agreement so that the ‘Key:oneway’ key can be applied to pedestrians as well.

Oneway is used fo a lot of streets, shared or combined foot/cycleways, where it doesent effect the pedestrians. It is not possible to use it generally also for pedestrians without destroing all this data. Of cause there are a lot of mappers doesnt know about this and using it wrong. And of cause we have to fix documentation and wrong tagging.
But we need a consese about this.
And one could start with looking the numbers of usages meaning pedestrians or not.

It seems to me like there is consensus (here) that the oneway tag does not affect pedestrians whenever other travel modes are also allowed. Very clearly for something like highway=residentials that are even used by motorized vehicles, but also for smaller ways like footway or path that are used by bicycles. But unfortunately this ‘vehicle-only’ definition of oneway becomes blurry as for ways that are only used by pedestrians the oneway tag is used more freely (the extreme case being via_ferrata where oneway=yes is even suggested in the wiki). But luckily the cases where the travel direction for pedestrians is actually restricted are rather rare, so maybe by improving the documentation it could be realistic to establish the usage of foot:backward=no for these cases, rather than the ‘abuse’ of oneway=yes?

2 Likes

Looking at highway=footway in areas I know, I think “all or nearly all” is too strong. For ways that are part of the public road network, it’s probably true that oneway=yes on footways usually refers to bicycles (and is almost always accompanied by bicycle=yes or bicycle=designated).

But a lot of footways are not part of the usual public road network, and in many of those cases the tag clearly means one way for pedestrians (e.g. stadium entrances, border control lanes, hiking trails):



image

image

But this use-case (foot-only ways that shall be used in only one direction) could easily be covered by foot:backward=no, which would avoid the confusing usage of oneway=yes.

After looking at cases of way[highway=footway][oneway=yes][!bicycle] this is my impression as well. However, I’m not sure if this should really justify using oneway=yes, because the situation could be described just as easily using foot:backward=no, which would avoid further confusion about the meaning of oneway=yes. But of course this is only in theory. In reality foot:backward=no is hardly used at all. But maybe this could be improved with better documentation?

It probably wouldn’t be enough on its own. Even mappers who do check wiki documentation don’t recheck it for every type of object every time they map, so are unlikely to notice a few sentences changing in the wiki.The proposal process is far from perfect but at least it spreads knowledge of wiki changes a bit more broadly, e.g. through WeeklyOSM.

Yes, how about this approach?

  • look at actual data of how oneway=yes has been used on different highway tags, around the world (not just in one country). By looking at the map and changeset comments, Mapillary, it’s often possible to make a guess as to what the mapper meant (pedestrians too or only vehicles)
  • document findings on the Wiki
  • where results are generally consistent (e.g. 95% of uses on highway=pedestrian had the same meaning, the other 5% are weird edge cases / exceptions / nonstandard tagging), the few exceptions could be retagged over time - we could leave a note and ask local mappers to find a better tag
  • where findings are inconsistent (e.g. if 60% of uses on footway meant pedestrians, the other 40% meant bicycles and other vehicles), we could ask validators to add warnings that the tag is ambiguous and a more specific tag should be chosen. Maybe even formally deprecate the combination
1 Like

I would be optimistic that such tagging rules are adopted by the mapping community (at least in the long run), if they make sense to most people and are explained well. In contrast, the current oneway wiki left me rather confused and under the impression that there is no set of rules yet that has been agreed upon and/or works for all situations. It rather seemed out-of-date, not really maintained, and when comparing it to the actual data overall not to be trusted :slight_smile:

Hot take: foot:backward=no will never catch on, because it sounds like you’re not allowed to walk backwards :joy: It has only 500 uses while oneway:foot has over 7,000.

2 Likes

I’d still go for foot:backward=no, because oneway:foot is so close to oneway that it would again weaken the strict ‘vehicle-only’ meaning of oneway.

1 Like

I’m not so sure about this, the fact that it is close means people are more likely to find it when searching for the right tag. How would people even find foot:backward=no? You might be able to persuade editor maintainers to alert mappers that oneway=yes is ambiguous, based on current usage, and propose an alternative tag. But for that alternative tag, why would editors promote the minority foot:backward=no versus the far more popular oneway:foot, which may not be very elegant but as far as I can see has a clearly defined meaning?

2 Likes

The same way they would find oneway:foot, I guess? By looking at the documentation about tagging footways, or other cases on the map.

Right now oneway:foot is more frequent, but to me it seems neither of the two is really ‘established’, yet, so it seems to be too early to choose one over the other based on the current stats(?)

The meaning of foot:backward=no is also defined quite clearly, isn’t it?
Speaking of clear definitions, here we are talking about highway=footway+oneway=yes not meaning that this is a pedestrian way that can be only used in one direction (for pedestrians). That is very bad naming if you ask me. If it was highway=footway+oneway:foot=yes one would still have to explain why the :foot suffix is necessary. highway=footway+foot:backward=no, however, leaves hardly any questions, doesn’t it?

But of course I’m not entirely sure about the naming, either. And to me it wouldn’t matter that much. What matters a lot more in my opinion is that there are easy to find guidelines that explain what to do depending on the situation in a convincing way.

A lot of mappers would use presets (in JOSM) or search for e.g. “oneway” in ID, rather than referring to documentation directly. And mappers who have already mapped similar things are unlikely to look at documentation again so won’t be aware of wording changes.

In general I am unsure if you are talking about a formal proposal process, or only rewording wiki pages.

And for foot:backward you have to explain what backward means - many mappers would have never had any reason to consider “forward” and “backward” on ways. So I don’t think there is much difference here.

this is surely not an argument for using “oneway” in this situation, is it?

Ok, I’m probably the wrong one to ask how to establish such a new tagging scheme. All I can say is that from a data consumer point of view the current situation is a mess, because on the one hand it is argued that oneway only affects vehicles, while on the other it is often used (and apparently accepted) in supposedly ‘pedestrian-only’ situations (which are hard to identify by solely reading the tags). The current wiki page for oneway raises more questions than it answers if you ask me.

Some questions that might need to be answered:

  1. Should the oneway tag be used for pedestrians in ‘pedestrian-only’ situations (like highway=via_ferrata where the ‘pedestrian-only’ character is rather clear, but also in cases this is not so clear like highway=footway where the ‘pedestrian-only’ character depends on other tags like bicycle=yes)

  2. If oneway=yes should be used for pedestrians in ‘pedestrian-only’ situations how are data consumers supposed to identify the ‘pedestrian-only’ character?

  3. If oneway=yes should not be used for pedestrians in ‘pedestrian-only’ situations, what should be used instead? Some of the suggestions so far seem to be foot:backward=no and oneway:foot=yes.

  4. Bonus: What would be the correct replacement for aerialways+oneway=yes if oneway=yes should strictly be only used for vehicles?

The problem with only answering the “should” questions is that the wiki isn’t just documentation for new mappers on how to tag things, it’s also documentation for data consumers on how to interpret the existing data.

For new mappers, it might be sufficient to write down clear rules on how to tag things and put them in the Wiki, but for data consumers this won’t do. If you invent new rules without checking the data, then suddenly a lot of existing data is tagged “wrong”. So the documentation needs more nuance, in my view.

This is how you end up with documentation like:

“For footways, the oneway tag can be ambiguous: it is unclear whether it only applies to vehicles (such as bicycles which may be allowed to use the footway but only in one direction) or does it also apply to pedestrians? There are more specific alternatives, such as oneway:foot, oneway:bicycle and foot:backward that are less ambiguous, but are not widely used on footways yet, as of 2024. In a recent community forum discussions, most mappers agreed that XYZ (Insert should language here).”

2 Likes

Ok, sure. But there is nothing that holds one back from making this clear in the wiki. For example there could be a section explaining rules that are thought to yield consistent/usable/correct data (for mappers), and another, well separated, section explaining the current situation and recommendations how to make best use of the current data (for data consumers). Maybe plus some kind of migration guidance how existing data can be fixed. But none of this is possible before there is a tagging scheme that works and has been agreed upon.

2 Likes

I agree, that would be great! And the migration would be easiest if we start by looking at how things are currently tagged.

1 Like