This post isn’t a formal proposel per se, but intends to gauge opinions whether the new tag should be further pursued. This thread might be used as a basis for such a proposal.
Introduction
Situation
In recent times, there have been severaldifferentthreads concerning the meaning of the oneway tag. It has become clear that there is no consensus on that meaning, while mandating more specific tagging (oneway:foot / oneway:vehicle) in every case is also not feasible or desirable.
To help resolve the ambiguity within the oneway tag and aid verifiability, a new tag named oneway:type is defined. There are no current uses of this tag. This new tag does not deprecate oneway.
Previous work
This situation seems quite similar to the ambiguity presented by the Key:maxspeed - OpenStreetMap Wiki tag. There are various rules around which speeds are allowed where and it’s not always obvious how to tag those; to resolve that, there is Key:maxspeed:type - OpenStreetMap Wiki.
It hasn’t been without its own controversy, but I think it’s still a good starting point for our purposes.
Values
oneway:type=sign: There is some sign with authority that indicates oneway-ness. Since the sign can basically say anything, other tags have to be considered, e.g. traffic_sign. If all else fails, fall back to oneway. It is recommended to use the more specific oneway:* tags in this case.
oneway:type=entry_restriction: Many streets aren’t explicitly oneway, but disallow traffic from a certain direction. In this case, the oneway-ness is derived from the access restrictions (appropriately tagged with *:backward=no or *:forward=* or both).
oneway:type=dual_carriageway: The road is a dual carriageway. Implied by dual_carriageway=yes.
oneway:type=narrow: The relevant street or way is two-way, but quite narrow, only (physically) allowing one direction to pass at a time. Only to be used if not sign-posted otherwise. Similar to oneway=alternating.
oneway:{mode}:type=*: Theoretic extension to specify the type of each mode of transport if it differs. If you have an example where it could be useful, please reply below.
This list is not exhaustive. If you have ideas for more, feel free to discuss them below.
Use of these values allows more precise expression of why the way is “oneway” and helps future mappers to determine its meaning.
While the oneway:type tag ideally conveys the oneway-ness and whom it applies to, it is intended to support, rather than replace, the use of oneway. As such, tagging the latter is still useful and required for data consumers. The tagging practice around that is out-of-scope for this thread.
Also left undefined is how to handle single carriageways that, in OSM, have been split as if they are dual carriageways.
Overview of interest
The first poll is about the general opinion on this tag. Whether it should become a proposal is separate in the second poll. If you have questions or examples, or other feedback and suggestions, please reply below in addition to voting. Thank you for participating!
I think the oneway:type tag as presented here…
will achieve its goals.
can achieve its goals, but I have/need more examples.
is interesting, but I don’t have an opinion either way.
can’t achieve its goals, but I have suggestions for improvement.
won’t achieve its goals.
0voters
Now consider whether a proposal should be made for this tag.
I think a proposal should be made for this tag.
I don’t think a proposal should be made for this tag.
Is this tag meant for data consumers or – like maxspeed:type – for mappers? From what you wrote, it seems that the goal is to use oneway:type instead of oneway:<acces-tag>, did I understand this correctly?
Using oneway:<access-tag> would still be allowed alongside oneway:type.
I wouldn’t say that maxspeed:type is only for mappers, and in that same way oneway:type isn’t. Though admittedly, it might just become a validation tool for mappers. I don’t know of any router that parses maxspeed:type.
I only really had in mind that it should clarify the intentions, so primarily help mappers, but didn’t want to preclude any other applications.
It’d be fine with me to limit the target audience to mappers.
I would advise against oneway:type=<country_code>:<context>, and only keep oneway:type=sign. Otherwise, we end up tagging traffic signs in multiple tags, which is redundant. We don’t want oneway:type=DE:220 + traffic_sign=DE:220, do we?
Other than that: if you want it as a tag for mappers only, to clarify why something has been tagged oneway=yes, I’d use it as much as possible. I’m a big fan of maxspeed:type and traffic_sign to clarify “why” something was tagged the way it was tagged. The biggest enemy is always the armchair mapper.
Thanks, I see. I rewrote that section so it fits better:
I wanted to avoid large rewrites as to not void the voting, but I think it’s early enough to not be a problem.
Do you want me to add a section as to why oneway:type is a better name than oneway_type? But thanks, I somehow missed that. It’s undocumented. Seems to be used almost exclusively with roundabout flares, though.
Yes, that makes sense. What do you think about oneway:type=DE:roadside for roadside cycle tracks?
I would avoid country prefixes to keep the number of possible values low, and go for sidepath or sidewalk.
Learned a new word today. For me, roundabout flares and traffic island splits are sort of the same thing, but I’m not British. Definitely something to include on yuor list
Thank you so much for starting this refreshing discussion!
If this tagging scheme ends up being primarily for mappers rather than routers, then I wonder if sign could be sufficient with the expectation that more details would come from the traffic_sign=* node.
Not to mention source:oneway=*, which is used some 20,700 times and is documented, barely. Of course we’ve stepped into another debate along the lines of source:maxspeed=* versus maxspeed:type=*.
Same here. I thought about similar situations, but I don’t quite know how to describe them, because the carriageway they are a part of isn’t actually oneway, they are just drawn separately, and so the OSM ways are oneway.
The difficulty I have is that they aren’t in any way more “oneway” than if the median or traffic island wasn’t there, it just would be mapped differently. So the oneway-ness is more an artifact of mapping rather than something that really exists on the ground.
I’m not sure how prevalent that rule is in other countries, so the idea was to highlight that it is a country-specific rule.
I was thinking whether I should include discussion of that tag. In my opinion it fits well with the source schema (being unstructured text), though its use is entirely orthogonal to oneway:type. Since it’s used differently from source:maxspeed, I hope nobody will open that can of worms
I’ve removed that part about separate traffic sign tagging to simplify the description. It seems reasonable.
Yes, I suspect you’re right about that. Most of the usage indicates the imagery source, which is orthogonal to this discussion, though the fourth most common value is sign at 1,000 or so occurrences. road_marking also occurs less frequently. The two keys could potentially coexist, even with some redundant values.
I very much opt for a proper proposal for such a tag that mainly duplicates information from other, well-established tags traffic_sign, width and type=restriction.
I also don’t know how a onway:type=entry_restriction would make any sense - there is no oneway=yes in combination with it, because the restriction is mapped as a relation.
It does make sense, because the way is effectively one-way. It doesn’t have to be (in that case, oneway=no and no oneway:type), but often enough it is, practically speaking. Adding oneway:type then helps to determine what to look for: Oh, there might be a type=restriction relation somewhere. If there isn’t, then it might be worth investigating why.
There is a vote in the OP, 4 out of 4 voters are against making a proposal.
It seems you misinterpret the results. The voters who are against the proposal also said that this tag “won’t achieve its goals.”, i.e. making a proposal doesn’t make sense because the idea is not fit to get a positive voting result.
