From OpenStreetMap Wiki
Jump to navigation Jump to search

cycleway:left:oneway=* ???

  • Why is cycleway:left:oneway=* mentioned here with a link to a page without any word about it?
  • How is this key suppose to work? How should editing software treat this key when the direction of the way is reverted? Is it not smarter to use forward/backward, e.g. cycleway:left:bicycle:backward=* ? --Skyper (talk) 22:22, 3 September 2020 (UTC)
    • "How should editing software treat this key when the direction of the way is reverted?" - probably either switch left -> right or ask user what should be done Mateusz Konieczny (talk) 06:15, 4 September 2020 (UTC)
Mmh, did you test any? Usually, left/right is switched and the value of oneway=*. Special case for every software! --Skyper (talk) 12:14, 4 September 2020 (UTC)
  • "Is it not smarter to use forward/backward, e.g. cycleway:left:bicycle:backward=*" - why it would be? At least for me it is harder to understand meaning of it. Mateusz Konieczny (talk) 06:15, 4 September 2020 (UTC)
It works without changing the editing software!
So, it depends on the tagging style. I am completely into lanes-tagging and do not like the twist in directions as I did not get it right away. --Skyper (talk) 12:14, 4 September 2020 (UTC)

Why opposite_lane is supposed to be invalid value?

It seems perfectly fine to me as a value (I pinged edit author) Mateusz Konieczny (talk) 06:16, 4 September 2020 (UTC)

I think cycleway:left=opposite_lane should not to be used, it is too confusing and there are much better alternatives, but my first question would be what is the diference between cycleway:left=opposite_lane and cycleway:left=lane. -- Emvee (talk) 10:39, 4 September 2020 (UTC)
It is the same but both values are acceptable and defined through Forward_&_backward,_left_&_right. --Skyper (talk) 12:14, 4 September 2020 (UTC)
Yes, all values are acceptable, Any tags you like, but that does not mean everything is a good idea and not for nothing that page does refer to taginfo. If they mean the same the simplere, significantly more used value should be used and it is good practive to disencourage people using other values. -- Emvee (talk) 19:43, 4 September 2020 (UTC)
No doubt, but this should be written on the page and be explained. --Skyper (talk) 12:02, 5 September 2020 (UTC)
I oppose the statement that cycleway:left=opposite_lane and cycleway:left=lane are ident. The reason I deprecated the former is its unclarity about the reference direction the term opposite refers to. cycleway:left=* is a supplemental tag to any highway, it can occur in combination with oneway highways (with possibly 1+ lanes) as well as dual-direction highways.
While bicycle traffic on a cycleway:left=lane may run
  • opposing the direction to the closest-by vehicle-lane
  • within that direction or
  • even allow both
there is, by design, no direction indicated by value lane. It solely states that there is a cycle lane present to the left of the osm way. left suffix refers to the directionality of the geometry of the osm way, a direction provided by the untagged object, no additional logic considering tags involved.
Contrary, the opposite in opposite_lane (in cycling context) usually refers to the direction of the next-most vehicle-lane of a highway, which is not necessarily the same direction osm geometry points at. For example
  • on a oneway=1-tagged highway, cycleway:left=opposite_lane would usually mean bicycles on the left are to travel against the vehicle traffic flow, while
  • on a oneway=no-tagged highway (dual-direction traffic flow), it means bicycles on the left travel in the opposite direction of the traffic flow on the leftmost vehicle-lane (which in UK means a different thing than in most of the rest of the world; i.e. in UK against, in rest of the world within the direction of the osm geometry of dual-direction highway)
To remove the dependency on the directionality of the traffic-flow on the left-most vehicle-lane, which in turn depends on left-hand/right-hand side traffic rules, it is better to avoid opposite_lane values. Instead, seek a way to solely depend on the direction of the geometry of the osm way (as given by the plain, untagged osm way object), which is agnostic to (robust against)
  • left-hand/right-hand traffic rules issues
  • oneway/non-oneway (in vehicle context) highway cases
This is exactly the purpose cycleway:left:oneway=* serves: Unlike with opposite_lane it solely depends on the geometry-given direction of the osm way. For example, on any highway (regardless of vehicle oneway state, regardless of vehicle lanes),
I do not claim that all real-world examples you stumble upon cannot be encoded with a ruleset and the opposite_lane value alike, but it seems that an accompanying ruleset and side considerations are more complex. Also, from a human side, the benefits are not as big as to justify its added programmatic code complexity. Employing the value when mapping, one often has to think twice about the direction the term opposite refers to, it does not have an error-free intuitive use. If there are lot of voices claiming the opposite, we could only try doing another poll/vote for its usage. @Mateusz Konieczny: MAYBE there is a good and straight-forward way to document (and programmatically interpret) its usage, essentially negating the statements of this paragraph, but there was not at the time I deprecated it for :left and :right suffixed key combinations in this wiki.
If the text above is confusing to some extent or open to disambiguation, I suggest drawing a graphic representation of possible cases. --Cmuelle8 (talk) 20:31, 4 September 2020 (UTC)
"The reason I deprecated the former is its unclarity about the reference direction the term opposite refers to" - it seems to me that it obviously refers to the same direction as cycleway=opposite_lane would refer to. Mateusz Konieczny (talk) 23:17, 4 September 2020 (UTC)
cycleway=opposite_lane does not state explicitly that usage is exclusively reserved for oneway highways, lets hypothetically assume it does, then I agree. In this case the considerations of bidirectional highways made above become irrelevant. However, in practice I've seen the value opposite_lane in combination with bidirectional highways. If this is discouraged/unintended use, cycleway=opposite_lane should clearly say so in combination with a taginfo or overpass query to find possible erroneous usage.
I've not done a survey into editor usage (yet), but assume that editors do not currently restrict usage of that value to oneway=1 or oneway=-1 tagged highways. If they did (do?), this may simplify a lot of things and interpretation of the value may be done confidently without too much of a hazzle. However, if the bidirectional highways are to be spared out (assume for a moment they are), the need for cycleway:left:oneway=* remains to express contra- or same flow of cycle-lanes on non-oneway highways. ... but then, if we have that, it seems cumbersome to not use it consistently with the oneway highways as well. In that case
may be used interchangeably and express the same thing. If mappers are disciplined enough to not extend the value to places it should not be used at, tools/software can support both (depends on devs mindset about it). Neglecting the software support issue, it probably is intuitive enough to be used by all mappers this way, if the restrictions mentioned apply.
If the insights gained culminate in documentation on the tag description pages reflecting this, I do not strongly oppose usage of opposite_lane with the :left/:right suffixed key variants, but am still not convinced about its definitive need as long as cycleway:left:oneway=* variant needs to serve the non-oneway cases (but is by no means limited to solely these). --Cmuelle8 (talk) 05:52, 5 September 2020 (UTC)
The whole problem with cycleway=opposite* is that it is mixing access (oneway) and infrastructure, see also cycleway=opposite versus oneway:bicycle=no.
cycleway:left:oneway=* is decoupling that and makes things more flexible/logical -- Emvee (talk) 11:25, 5 September 2020 (UTC)
How about deprecating opposite_* and only using cycleway:left/right=lane/track --Skyper (talk) 12:02, 5 September 2020 (UTC)
The section Key:cycleway:left#Invalid values does currently deprecate it, however cycleway:left=opposite_lane is a redirect to cycleway=opposite_lane. While I am a supporter of deprecation, also for the same reasons Emvee mentioned above, keep in mind that the wiki is not a definitive authority - it only tries to appeal and give advice to mappers rather than enforcing rules. This is an accordance to automated edits considered harmful by the community, unless they had wide support and testing by individuals prior to their execution.
Thus, we can only hope that the current considerations about the tag usage makes sense to other mappers. If so, opposite_lane value will gradually be replaced. Also, consider that a bunch of tools may not yet support evaluation of :oneway suffixed keys - these are to some extent a showstopper of such gradual replacement and an argument for people to stick with opposite_lane. Despite its design flaw of mixing access/infra values, it has simply been around much longer in osm, so there may be usage/support in/at lots of places we simply do not know about or are unaware of. Just saying, that deprecation is simply said, but may be hard to realize. --Cmuelle8 (talk) 19:07, 5 September 2020 (UTC)
For a start, however, cycleway:left=opposite_lane could point to Key:cycleway:left#Invalid values instead of cycleway=opposite_lane. Atm the section and the redirect are semantically in conflict. --Cmuelle8 (talk) 19:12, 5 September 2020 (UTC)
Good idea to point cycleway:left=opposite_lane to Key:cycleway:left#Invalid values. I think it would be also good to indicate cycleway:left=opposite_track as Invalid value -- Emvee (talk) 14:59, 6 September 2020 (UTC)
Yes, probably. It will also better confine/bind the legacy opposite* values to the unaffixed cycleway=*, which was the original intention when introducing cycleway:left=* + cycleway:right=* anyway. Saying, if we have to live with them for historic reasons, we could try at least to not re-import them into newer tagging approaches.
There are taginfo/overpass queries in this wiki replying invalid or discouraged tags or tag combinations. Maybe it's a good idea to set up something like this on cycleway:left=* + cycleway:right=* pages, to ease maintenance. --Cmuelle8 (talk) 17:39, 6 September 2020 (UTC)
+1, let us show some numbers. Think a graph for the number in uses would help, too.

Using Map Feature templates

There is the template Map Features:cycleway. Think similar would make the maintenance of this page and cycleway:right=* easier and could even be integrated into "Map Feature:cycleway" template. This way all information would be in one place for all pages. --Skyper (talk) 11:20, 20 September 2020 (UTC)

I see the point, easier maintainance. An (easier) alternative would be to make cycleway:right=* a redirect to this page, cycleway:left=* -- Emvee (talk) 11:19, 26 September 2020 (UTC)
":right" redirecting to ":left" would be confusing and I strongly oppose this idea. Mateusz Konieczny (talk) 12:14, 26 September 2020 (UTC)