[RFC] Feature Proposal - One-way for pedestrians

Matija_Nalis · 2024-09-27T02:00:10.374Z

osmuser63783:

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?

osmuser63783:

The very mixed reactions to my post about not deprecating oneway on path show that it’s not straightforward to agree on a solution here.

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.

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).

osmuser63783:

It’s not hard to find examples where the mapper clearly meant pedestrians when they used the oneway tag
[…]
They are far outnumbered by things like a sidewalk where the mapper clearly only meant bicycles

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 least¹ 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?

¹ - I personally would prefer for oneway:foot to be recommended on all highway=path too, in addition to highway=footway, but I can understand the opposition…

Nadjita · 2024-09-27T04:58:29.564Z

Matija_Nalis:

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).

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 ↩︎

osmuser63783 · 2024-09-27T06:26:54.286Z

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?

osmuser63783 · 2024-10-20T12:27:54.691Z

I’ve updated the proposal as discussed.

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 to oneway.

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!

SomeoneElse · 2024-10-20T12:40:23.722Z

osmuser63783:

the proposal now says that data consumers should continue to support foot:backward.

Speaking as a data consumer, I’ll continue doing what I always have done:

Looking at usage in the areas that I’m creating maps for
Trying to figure out what the mappers there probably meant
Largely ignoring the wiki where it diverges from that.

Langlaeufer · 2024-10-20T12:43:44.234Z

Yes this is the task of the data user we don’t have to care about and we don’t need to document. Our part is to document how it should be mapped.

osmuser63783 · 2024-10-20T13:29:56.357Z

Of course! At the end of the day, data consumers can and will do what they want. This is more about building and documenting consensus among mappers, including consensus about what we think the correct interpretation of a tag is. Maybe making the step of trying to figure out what the mappers probably meant a bit easier

okainov · 2024-10-21T08:27:35.540Z

osmuser63783:

More specific tags e.g. oneway:foot should be used, but this can be instead of or in addition to oneway.

This looks good to me
Just looked at some examples:

Designated shared-use paths, where pedestrians and bicycles have equal rights. Assuming that the way is tagged as highway=path, foot=designated, bicycle=designated:

oneway=yes by itself is sufficient.

I’m not sure, is it intentionally correct to say that your still aim to have simple oneway=yes in this case? I would expect similar tagging idea as in the case above it, like use oneway:bicycle=yes and oneway:foot=no (and still tolerate oneway=yes if it’s there).

dieterdreist · 2024-10-21T11:06:32.000Z

I wonder what the definition for oneway:foot is, just the same as oneway for vehicles but for pedestrians? When a vehicle enters a oneway road it must continue all the way in the direction of traffic once it is in. As a pedestrian on a “oneway“ stretch, won’t you be allowed to back up? Turn around and return from where you came? It may depend on the situation?

SomeoneElse · 2024-10-21T11:17:57.366Z

dieterdreist:

I wonder what the definition for oneway:foot is

(I’m not commenting on that specifically, but)

dieterdreist:

As a pedestrian on a “oneway“ stretch, won’t you be allowed to back up?

Generally speaking, I’d expect that you’re not allowed to do that. There may be something physically preventing that - in the Giddy Edge example there isn’t, but the implication is clear.

osmuser63783 · 2024-10-21T17:33:36.953Z

okainov:

I’m not sure, is it intentionally correct to say that your still aim to have simple oneway=yes in this case? I would expect similar tagging idea as in the case above it, like use oneway:bicycle=yes and oneway:foot=no (and still tolerate oneway=yes if it’s there).

If I was tagging it, I would put oneway:bicycle=yes, because it’s clearer. And an earlier version of my proposal suggested to avoid oneway=yes on highway=path. But there are a lot of highway=paths tagged oneway=yes where the mapper clearly only meant bicycles. So after a lot of discussion further up in the thread, I changed the proposal to say that on =path, like on streets, oneway only applies to vehicles. I’ve updated that example in the table to hopefully make that clearer.

dieterdreist:

I wonder what the definition for oneway:foot is, just the same as oneway for vehicles but for pedestrians? When a vehicle enters a oneway road it must continue all the way in the direction of traffic once it is in. As a pedestrian on a “oneway“ stretch, won’t you be allowed to back up? Turn around and return from where you came? It may depend on the situation?

Generally I think mappers will use the tag whenever there’s a clear and verifiable indication on the ground that the way is only meant to be used in one direction. The specifics of how that is enforced will vary.

dieterdreist · 2024-10-21T18:14:40.000Z

I wasn’t asking about enforcement, all oneway footway restrictions I have seen were actually places where the restriction was punctually, not linear. I have yet to see a linear restriction, but I don’t question they do exist.

Just because of the nature of pedestrian traffic, it is much more unlikely that you may really only walk into one direction on a linear way (because as long as 2 persons pass, you can usually back up), while it is quite common to have punctual restrictions, e.g. on turn stiles, entrances and exits and similar.

Mateusz_Konieczny · 2024-10-22T07:24:38.005Z

dieterdreist:

I have yet to see a linear restriction

You claimed it several times and got replies.

Hiking trails such as Orla Perć are an example.

Mateusz_Konieczny · 2024-10-22T07:25:24.599Z

dieterdreist:

e.g. on turn stiles, entrances and exits and similar.

In such case such short way would be tagged as one-way for pedestrians.

dieterdreist · 2024-10-22T12:55:21.000Z

we don’t usually map the thickness of walls or doors, turn stiles are typically mapped on nodes.
While it is not forbidden to map full height turnstiles on ways, it is done only 14 times, compared to 2851 on nodes (and I would expect all of these barriers (or nearly) to be oneway).
https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dfull-height_turnstile

In the case of a oneway entrance, the suggestion is to map something like a 4cm-long stretch of oneway? For such kind of restrictions the typical solution is restriction relations.

Imagine being one step on this bridge and asking your router for indications to somewhere which requires going back:

https://wiki.openstreetmap.org/wiki/File:One_way_for_pedestrians_on_Fye_Bridge_-geograph.org.uk-_6507482.jpg

Would you want to be taken over the bridge and make a detour, or would you make a step back?

okainov · 2024-10-30T16:59:38.074Z

dieterdreist:

Would you want to be taken over the bridge and make a detour, or would you make a step back?

So the question is whether you want to differentiate “physically-restricted oneways” (like some Via Ferrata linked above, or the famous narrow street with the pedestrian traffic light or whatever else where you either are not able to go back or doing this would put you and/or others in danger or so) and the ones which are “‘just’ legally restricted” (like the bridge you linked)

How is it done today for vehicles roads? I think there is no differentiation like this, it’s just oneway and yes, you expect your navigation device to guide you in a legally correct way (in many countries driving opposite of oneway is quite punishable). I’d say the same for pedestrian navigation - device should show you the legally correct way, and then you decide for yourself, how much you care about restrictions (same as somewhere you would drive opposite of one way just because it’s more convenient and in this given place there are no cameras, police or witnesses and you don’t care about breaking the law here)

Mateusz_Konieczny · 2024-10-31T10:48:14.473Z

For stiles I would put one-way on way segment that is enforced to be blocked.

If someone is nanomapping I guess that in some cases you could split way and mark only section within turnstile as one-way (the same applies no matter how you would tag it).

dieterdreist:

Imagine being one step on this bridge and asking your router for indications to somewhere which requires going back:

Note that it is likely not a legal restriction, just suggestion.

o_andras · 2024-10-31T12:10:21.842Z

looks like access=no to me

skyper · 2024-10-31T12:26:50.482Z

This is a no_entry sign. For oneway you need an additional sign that indicates the oneway restriction on the opposite side. Yes, we often cheat and use a small section with oneway=yes in this case, though in my eyes this is incorrect.

SomeoneElse · 2024-10-31T12:52:46.858Z

skyper:

For oneway you need an additional sign that indicates the oneway restriction on the opposite side.

Yes, there was one of those when I was last there.