41

If a routing engine supports conditional restrictions, it will automatically also support oneway:vehicle. And not supporting conditional restrictions already leads to incorrect results in a lot of other situations. So it would not create any new work for routing engine developers. At most, it would create some extra pressure to finally do the work they should have done a decade ago.

We apparently want to introduce oneway:foot, which makes the existing assumption that oneway never applies to pedestrians kind of weird.

But I guess most people don’t see a problem with that and I have to live with my bruised aesthetic sensibilities. It’s not as if the OSM data model is otherwise an exemplar of elegant logic and consistency. sigh

2 Likes
42

A bit of a interesting question in regard to “vehicles” on walking tracks.

We went for a bush walk in a National Park yesterday. Walking out along the foot only track (not one-way! :grinning:) & found an NP Ranger coming back in towards the trailhead with something similar to https://www.edisons.com.au/baumr-ag-motorised-tracked-wheelbarrow-dumper-briggs-stratton-cr950-petrol-engine-500kg-capacity

Question - for OSM purposes, is that a “vehicle”? :thinking:

43

Question - for OSM purposes, is that a “vehicle”?

IMHO no, if you walk aside and yes if you sit on top

2 Likes
44

I assume that many software programs have so far only supported oneway and oneway:bicycle for cycle route planners, and that generic forms such as oneway:vehicle have not yet played a role (yes I think the do also not support conditional restrictions - this is a problem that they have to solve).

If you simply implement the logic of the data model then you get a lot in trouble with a lot of wrong tagging like:

  • highway=footway access=yes (mostly not vehicle=yes bicyle=yes is meant)
  • highway=path foot=designated (mostly bicycle=no and horse=no is meant)
  • highway=track access=no agricultural=yes (mostly motor_vehicle=agricultural)
    


What good is a clean data model if it isn’t guaranteed by consistency conditions? The current OSM data is not consistent to the data model if more pedestrians oneways are tagged with oneway=yes instead of foot:[direction]=no
oneway:foot is simply another exception in the data model but it makes it ab bit easier for the mapper.

45

I assume that many software programs have so far only supported oneway and oneway:bicycle for cycle route planners, and that generic forms such as oneway:vehicle have not yet played a role (yes I think the do also not support conditional restrictions).

there are already 62 uses though:
https://taginfo.openstreetmap.org/search?q=oneway%3Avehicle#keys

46

Another example: Way: 827853152 | OpenStreetMap. I don’t have a picture, but I tagged that one based on a sign indicating no entry to the labyrinth through that path.

47

yes I know, but this is nearly nothing compared with 24 mio footways or even with 64000 footways with access=yes

48

This. Basically, we have two options:

  • option (1): tag x=y, which is absolutely clear to 57% mappers to mean “A”, absolutely clear to 17% mappers to mean “B”, and unclear whether “A” or “B” is meant to remaining 26% mappers (unless additional clarifying tags are added)
  • option (2): tag z=w, which is clear to 100% to always mean “A”.

I really don’t see how hard a choice picking between those two options can be :smiley_cat:

(disclaimer: percentages might not be exact. Also, speficic values for `z` and `w` are to be determined here, but `x=y` is of course `oneway=yes`).
2 Likes
49

You don’t have to retag anything, you’d just use unambigious tags (e.g. oneway:vehicle=yes + oneway:foot=yes or whatever) in your presets on your new edits on all ways having some oneway where there is potential ambiguity (or easier: on all ways having some oneway - fullstop).

You could still leave existing oneway=yes in place to accommodate existing routers, while at the same time removing ambiguity. That way, nothing will go worse for existing use, and it is guaranteed to get better in the future.

2 Likes
50

You don’t have to retag anything, you’d just use unambigious tags (e.g. oneway:vehicle=yes + oneway:foot=yes or whatever) in your presets on your new edits on all ways having some oneway where there is potential ambiguity (or easier: on all ways having some oneway - fullstop).

if you think that oneway can apply to pedestrians, every oneway tag is potentially ambiguous, even oneway on motorways because there are motorways where pedestrians are allowed (3000+ according to taginfo)

51

I personally would not tag oneway=yes for limiting direction for pedestrians, but oneway:foot=yes (or, more precisely, I’d likely use both, as it maximizes router support without sacrificing clarity).
But it does not really matter what I would do – it is all about what many others would do. And it is hopefully clear by now to everyone that quite a lot would, but also quite a lot wouldn’t.
Thus, the problematic ambiguity which cries for some solution.

I’d say the point of why this RFC puts such limitations on its promotion is because this way it fixes the ambiguity in majority of the use cases, while keeping a wide common ground between two camps, thus maximizing chances of proposal success. That is smart.

Sure, ideally (ideally for one camp) it should be way more radical as that would fix 100% of the cases (instead of just say 90%), but then the other camp would heavily object, and proposal would likely fail. As the saying goes, “Perfect is the enemy of the good”, eh?

2 Likes
52

Yes, my proposal is much less ambitious than that. It doesn’t touch one-way tagging on roads, because for those, I think the tagging system has a clearly established convention: the mapper sees a familiar one-way traffic sign, sets a oneway=yes tag, and pedestrian routers know they can ignore the tag, because the one-way traffic sign doesn’t apply to pedestrians. Then there is oneway on the two ways of a dual carriageway, where the same convention applies even if there are no signs.

The ambiguity in the data is really limited to footway and, to a smaller extent, path. This is based on looking at dozens of examples of footways, paths, steps, cycleways, and pedestrian streets with the oneway tag with Overpass. On steps it is generally clear mappers meant pedestrians. On cycleway and pedestrian they generally meant vehicles. On footway and path it is more variable, and sometimes genuinely unclear even when a human looks at the tags, so this is what the proposal is limited to.

2 Likes
53

You’d be surprised how many official cycle routes go down/up stairs that have a oneway sign. Stairs with a step height of < 5cm are pretty common for these.
I would not exclude any by-default pedestrian-only “highways” from the proposal, but instead discourage the use of oneway=yes on all of them, and ask for the use of oneway:foot=*.

2 Likes
54

Oneway on steps should be included. Even when it seams to be clear that pedesrians are meant, it does not fit to oneway is only for vehicle.
The meaning of the oneway tag should no change when you change the highway value.
Otherwise it will introduce errors when mappers refine footways with steps or vise versa.

1 Like
55

I’ve made a change because of comments by @chris66, @JeroenvanderGun and @Nadjita : for highway=path the proposal is no longer to deprecate oneway but to treat it as applying to vehicles only.

path is a tricky one: It’s not hard to find examples where the mapper clearly meant pedestrians when they used the oneway tag. These are usually hiking paths (which tend to be mapped highway=path instead of highway=footway, regardless of bicycle access). Examples 1, 2, 3, 4, 5. But these examples are clearly in the minority. They are far outnumbered by things like a sidewalk where the mapper clearly only meant bicycles. There are also a lot of mountainbiking trails mapped as highway=path with oneway=yes where the mapper clearly meant bicycles (and I am unsure if pedestrians are allowed at all). So it might be better to say that on highway=path, oneway=yes is only for vehicles, and presets and validator warnings should warn people to use oneway:foot instead when they mean pedestrians.

5 Likes
56

We agree that one-way traffic on supposed pedestrian infrastructure is problematic. However, we are not yet entirely sure how to solve the problem.

Perhaps the proposal should be split into two parts

  1. The establishment of oneway:foot to specify one-way rules for pedestrians

  2. Dealing with oneway-Tag on supposed pedestrian infrastructure, how to proceed on which types of highway.

57

e.g. this https://www.openstreetmap.org/way/1068634195#map=19/44.395854/12.218579

I don’t think it is comparable to oneway on roads, you might not be allowed to enter at the exit or exit at the entrance, but on the way you very likely can walk back and forth. In a oneway street you may not drive against the direction, but on oneway paths you usually may walk against the direction (if other people allow for it, i.e. there is nobody behind you).

Your example called “Klettersteig” is a candidate for Via Ferrata.

58

This is a good example of incorrect use of access and oneway.

|highway|path|
|access|customers|
|oneway|yes|

Yes, you can assume with a high degree of certainty that only pedestrians are meant, but you can’t be sure that someone hasn’t used access and oneway correctly.

access=customers allows customers to use all types of transportation on that path.

We need more warnings from editors about all these access and oneway on footways, stairs and other paths that don’t normally have vehicle access.

59

access=* is almost always wrong if it’s interpreted literally according to the access tagging scheme. Data consumers should generally only use the access=* tag to further restrict access, not to make it more permissive.

60

Indeed - looking at the area, highway=footway would be a better option here. :smile: