Proposal talk:Right left

Alternative 2 is nonsense

Please note that (strictly speaking) there cannot be two tags with the same key value. So setting the "left" or "right" in the value part keeps us from setting a similar tag for the opposite side of the way. See you example with cycleway=track/lane. you would end up with cycleway=left:track and cycleway=right:lane. They use the same key value, which should be avoided. Please kick alternative 2 right from the start, it does not really help us out. --Bwurst 13:12, 31 December 2008 (UTC)

• I support giving up #2 for the same reason. It fails even in the simple cycleway scenario. --Tordanik 15:10, 31 December 2008 (UTC)

• +1 on removing Alternative 2 and just going with foo:right and foo:left. If nobody objects, I'll do this. --achadwick 11:39, 26 January 2009 (UTC)

Done: now done as pure tag suffixes. --achadwick 17:57, 28 January 2009 (UTC)

Semicolon-separation

AFAIK it is possible to separate different values for the same key by semicolon, so

cycleway=left:track;right:lane

would be possible --DimitriJunker 16:05, 1 January 2009 (UTC)

• Is there a difference in renderingspeed? If not, I'm all for alternative 1. And expansion :left :center :right :none. Using :both doesn't make sense to me, unless the default for something is not both. --Skratz 13:42, 11 January 2009 (UTC)

• +1 on not suggesting :both, and stating explicitly that the default unsuffixed version implies both :left and :right. --achadwick 11:39, 26 January 2009 (UTC)

• I hate the idea of prefixing within values (or really, having any sort of syntax at all within values that isn't pretty well established). Programmers will have to write their own parser for each new tag with a complex syntax. Let's stick to existing conventions. --achadwick 11:39, 26 January 2009 (UTC)

+1 and semicolon-separation is not so good ! (acctually it's hard to parce it with mapnik !). So I think that's

cycleway:left=track + cycleway:right=lane

is realy better. Sarge 13:56, 19 February 2010 (UTC)

• It's just convention for some tags that semicolons can be used to split up multiple values. But it really depends on whether support is implemented for this convention for the tag in question, in the software processing the data. And it's patchy: you can't do it for names, for example (use alt_name, old_name, etc. instead!) --achadwick

Watch the case

Please state in the text that lowercased values should be used. regular tag names are always lowercase. -- Bwurst 13:14, 31 December 2008 (UTC) Thanks, I´ll change it. --DimitriJunker 16:05, 1 January 2009 (UTC)

Expand this with forward / backward

The same semantics should be used for forward and backward tagging. Example would be maxspeed or lanes. -- Bwurst 13:16, 31 December 2008 (UTC)

+1, but with added care about when to use left/right and when to use forward/backward, given that you could often use both for something (the right side of the road applies to vehicles going forward, for example). --Eimai 14:24, 31 December 2008 (UTC)

This assumption is not very portable. :) Everything that is 'right of the way, should be right, everything that affects the forward traffic should use forward. There should not be assumed that the forward traffic is on the right side of the road. Many countries don't do that. :) -- Bwurst 14:35, 31 December 2008 (UTC)

So what? The way has a direction, so the right lane is foreward here in germany and backward in GB, but for any way there is a fixed relation right=foreward and left=backward ore viceversa --DimitriJunker 16:09, 1 January 2009 (UTC)

Exactly my toughts. That would then be for example maxspeed:right=70 and maxpeed:left=90. This doesn't say anything about the driving direction, right or left is about the direction of the way.--Skratz 13:25, 11 January 2009 (UTC)

So maxspeed:left=70 and maxspeed:right=50 would mean that I'm allowed to go faster than 50 if I'm overtaking another vehicle in the opposite lane? So for reasons like these we need proper definitions of when to use left/right and when to use forward/backward. Maxspeed signs apply to all vehicles moving into one direction, so that should only be used with forward/backward. Parking traffic signs normally apply to the side of the street that they're on, so should only be used with left/right. --Eimai 14:51, 11 January 2009 (UTC)

you very well know that is not what it means. Speed limits always apply to the direction you are driving, even if you are using the wrong lane for whatever purpose. --Skratz 15:41, 11 January 2009 (UTC)

Didn't I just say that above? I'm just saying that because of that we shouldn't use left/right on things like maxspeed. --Eimai 15:55, 11 January 2009 (UTC)

Sorry, but this is nonsense. Every normaly intelligent human and any software written by one will know, that speedlimits depend on the direction you are going, so maxspeed:left in Germany is the speedlimit for going opposite of the direction of the way. There is an easy corelation between right/left and foreward/backward, which does depend on the country. So we do not need both, but it would not be a problem to use both. There are some streets where the speed limit depends on the lane, but that is something different. --DimitriJunker 23:36, 18 January 2009 (UTC)

Even if I still see uses for 'both' it makes no sence to include it in this proposal, since the main objective of this is to enable editors to automaticly reverse right/left and both/none do not have to be reversed. So if wee need a cycleway:both=track for one-way streets, this can be easely discussed in a sepparate proposal. So I remove both/none from the main page--DimitriJunker 12:34, 3 February 2009 (UTC)

Too close to Proposed features/Scope for access tags, so -1 on that from me. IMO this proposal is better suited to expressing physical road layout, whereas the other proposal is good for access restrictions and maxspeed. --achadwick 22:40, 15 February 2009 (UTC)

Dirty Tagging

The usage of left/right/forward/backward opens up for dirty tagging. If you need to indicate closer than normal tagging allows, I suggest using Relations, key:left= and key:right= should be last resort. --Skippern 13:43, 31 December 2008 (UTC)

Do you have a specific idea or example how single-direction-maxspeeds can be set with relations? I don't really have a clue on how to do that... --Bwurst 13:50, 31 December 2008 (UTC)

Furthermore, the proposals for getting access tags in relations always allowed for a right/left/forward/backward thing like this, since relations would be overkill in many situations. --Eimai 14:22, 31 December 2008 (UTC)

Yes, this way of tagging is error prone and bad to parse. The value should not be the key! I also think a generic left/right/both/none-scheme ist needed, but it should be better designed. --Fabi2 14:31, 6 June 2009 (UTC)

Dirty Relations

The usage of relations for just about anything opens up for dirty relations. If you need to indicate closer than normal tagging allows, I suggest using well-defined Tag structures, relations should be used for expressing a relation between elements. (Sorry, couldn't resist.)

Relations are useful, but sometimes a few tags are easier to handle. More complex cases might benefit from relations of course. --Driver2 17:46, 1 January 2009 (UTC)

different rendering on different zoomlevels

In keys which will allow a :right and :left suffix, it would be possible to consider this information as a detail. So the :right/:left value is rendered only at the highest zoom level, and use the key without a suffix is used for the other zoomlevels. This requires that there is also a key without :right/:left tagged.

For example, on lower zoomlevels it is not important to know on which side of the road a cycleway is, it does not even needs to be rendered. In contrast a cycleway which is not besides a road should always be rendered. As far as I know it is currently not possible to accomplish the same in another way.

This would not apply to every key to use :right/:left, but it can be included in the proposal to use :right/:left for that key. ∼ Wimmel 20:25, 28 February 2009 (UTC)

Changing the direction of a one way street

... means, that you have to touch all objects. This is simply not acceptable.--Lulu-Ann 10:48, 4 March 2009 (UTC)

I still fail to understand. Please could you explain your objection in more detail, or maybe provide an example of what you mean? My main problem is what you mean by "all objects": all objects in what? BTW, this is just my opinion as a user and a programmer but map editor software should flip direction-sensitive tags and relation roles for the user when reversing any way. Making these changes to software is utterly trivial, trust me. --achadwick 15:20, 5 March 2009 (UTC)

I try again: We have a oneway street, which forces the arrow to point in the direction of where cars are allowed to drive. Now you assign lots of objects "left" and "right" viewing in the direction of the way given by the driving direction. Later the traffic planner changes his mind and turns the arrow around so cars must drive in the other direction (which is not as seldom as you might think). Now you need to touch all objects you have assigned "left" and "right" and change their side attribute to the opposite. Is it clear now? This proposal causes many tagging objects to depend on something that is not stable, and that causes an immense rework in case of a change. --Lulu-Ann 09:09, 6 March 2009 (UTC)

The oneway property of the street doesn't have anything to do with the direction of the way in OSM. The direction in OSM is completely arbitrary. It's just that quite often the direction of the oneway street and the direction of the way in OSM are the same, because it just makes sense, but it doesn't really depend on eachother. If a oneway street is reversed (in reality) then you can either change the oneway property to the opposite ("yes" to "-1" or vice versa) or change the direction of the way, in which case the program should either ask you which tags to reverse (and you can just tell it not to reverse the oneway-tag) or just reverse all tags, in which case you can just reverse the oneway-tag manually. Either way, as long as the program knows of the direction-dependand tags and automatically reverses them (and probably also warns the user), you don't have to mass-edit all tags, unless they have been tagged wrong in the first place or changes in the real world require it (in which case every tagging method would require some work). --Driver2 12:08, 6 March 2009 (UTC)

You do not have to look for other objects. The proposal allows to tag the way side dependant. If the way changes direction only tags for this way have to be changed, if they have the :right/:left suffix.--Nhoffm 16:37, 7 March 2009 (UTC)

Would Potlatch be improved to automatically switch these? --NE2 23:07, 16 February 2010 (UTC)

Left-right does not work, would need forward-backward also

I have a bridge here from north to south with a street in the middle.

On both sides of the street there are ways to walk or cycle.

The western way is pretty narrow.

(The eastern way is totally uninteresting because it is not connected to other ways and even more narrow.)

For the way in the west there are different signs in both directions:

If you go from north to south, you are allowed to walk or cycle (foot=yes, bicycle=yes).

If you go from south to north, you must get off your bike (foot=yes, bicycle=no/walk).

This case can not be tagged using left/right only.

Lulu-Ann

Extension to infix (xxx:left:xxx)

I am actually using your proposal in a parking lane proposal. It works nicely, see Proposed_features/parking:lane#Specifying_the_parking_space, but I need to ask for an extension of the scope. I do not only require :left and :right as a suffix, but also infix (substring), e.g. parking:condition:right:maxstay, please see Proposed_features/parking:lane#Example_tagging. It should be as "trivial" as for suffixes to consider these cases e.g. in JOSM by searching for :left: or :right: as a substring, too.

--Kay D 19:34, 13 May 2010 (UTC)