Proposal:Right left

Key suffixes '':right'' and '':left''
Proposal status:	Proposals without post-vote cleanup
Proposed by:	DimitriJunker
Tagging:	...:right=...
Applies to:
Definition:	Limits a tag to one side of a way
Statistics:
Rendered as:	depends on key
Draft started:	2008-12-31
RFC start:	2009-02-15
Vote start:	2010-11-01
Vote end:	2010-11-15

Description

Users should, when they wish to be more specific and to define asymmetric (side-dependent) features, be able to append :left and :right to the tag key to restrict interpretation of the tag as a whole to just a single side.

Rationale

Many keys apply usually to both sides/directions of streets, but sometimes it would be useful to limit them to one side. For example a cycleway may only exist on one side, or on one side as cycleway=lane and on the other as cycleway=track.

Establishing this already in-use scheme as a common pattern for development of later tags helps

Tagging

This is a generative scheme, and can be used with any other key/value pair, denoted <key> and <value> in the table below.

Key	Value	Element	Comment	Rendering	Photo
<key>:right	<value>		The key <key>=<value> applies only to the right-hand side of the way, with respect to the direction of the way's direction.	N/A, or possibly altered way casings.	File:Cycle trackinroad.jpg cycleway:right=lane?
<key>:left	<value>		The key <key>=<value> applies only to the left-hand side of the way, with respect to the direction of the way's direction.	N/A, or possibly altered way casings.	cycleway:left=track?

Interpretation

If a way is tagged both foo:left=bar and foo:right=bar for the same foo and bar, it would be simpler to merge them and just tag the way foo=bar: this by definition has the same meaning.

Corner case: if a way is tagged both foo=bar and foo:left=qux, then the bar value applies only to the right side and the qux value applies only to the left side. In other words, the more specific suffixed version overrides the less-specific unsuffixed version.

Examples

Tagging	Explanation
highway=tertiary cycleway:right=track	There is a cycle path along the right-hand side of this carriageway.
highway=residential name=Cod Street name:left=Fish Finger Terrace	For a short stretch, the road has a second name, applicable only to house addresses on its left.

Current usage

• Not that widespread yet, understandably.

• In the UK Tagwatch, there are examples of name:{left,right}, county:{left,right}, landuse:{left,right} and a similar scheme for abutters.

Consequences for taggers

• Very few. This scheme is deliberately backwards-compatible.

• Some extra complexity when entering data, but this could be alleviated with a presets system offering a left/right/both toggle.

Consequences for software

• This pattern has a defined, way-dependent meaning and a fairly strict syntactic form, so editors can be coded to automatically change :right to :left and vice versa if the direction of a way is reversed by the user, in a similar way to their current handling of oneway=*.

• Routing software may have to score ways differently in both directions for some or all ways.

• Rendering software may end up largely unchanged, but if special casings are applied to the sides of a road for a given tag, this will need to be restricted to just the left or right casing. User:Artemp assures me that this is possible for Mapnik, at least.
  • No renderer currently supports rendering in parallel to a way. Apparently this is very difficult to implement correctly. See trac bug #2195. ChrisB 23:15, 25 August 2009 (UTC)
  • For now, http://trac.mapnik.org/wiki/LinePatternSymbolizer could form the basis of a workaround. It already implements the "direction matters" thing, and it'd be less surprising that what we currently do for oneway arrows on the main site. Probably best suited to bitmap renderings and dashed lines; certainly not ideal. --achadwick 12:55, 26 August 2009 (UTC)

What about :forward and :backward?

Implies motion, even if their meanings are really "with arrow" and "against arrow". There's a proposal in the works to allow them to refine maxspeed and other access-limitation tags: see Proposed_features/Scope_for_access_tags. Perhaps a little outside the scope of this proposal.

This rather neatly leaves :left and :right for describing physical geography, extra lanes for specific vehicles types, name differences or whatever.

Discussion

Please use the discussion page.

Right now, it's less important to say whether you think :right/:left is useful for cycleway=* or any other specific key. For any key to use :right/:left we would need a separate proposal (or at least a discussed addition to any existing pages). The reason for this proposal is only to explain how to what the interpretation of a way with side-dependent tags should be before these are really used.

Opinion poll

Voting is not yet open, but please use {{Poll|yes}}, {{Poll|no}} to express what you think about this idea as expressed above.

• I like this proposal. I didn't make it, but I'm moving it forward because I think we need this for rendering cycleways effectively for the Oxford/Cyclox_map_2009. --achadwick 23:03, 15 February 2009 (UTC)
• I like this proposal. as it's been in use like that for a long time already. --Eimai 11:58, 16 February 2009 (UTC)
• I don't like this proposal. At this stage I am still concerned about the consequences of reversing a way - perhaps almost inadavertently, e.g. when combining ways - and thus the meanings of the left / right tags. However, I could be persuaded to reverse this opinion if I could get some reassurance about the software syntax from the coding community - i.e. an automatic (mapper / tagger independent) reversal of 'left' / 'right' whenever the sense of the way is reversed. --User:Mikh43.

I'd be happy to implement this for Osm2go at least, when time permits. --achadwick 13:28, 17 February 2009 (UTC)

Now implemented in Osm2go[1]. There is some sort of support for it in JOSM via [2], but I've not been able to get it to work for me: although tag-correction.reverse-way does appear to turn on proper handling of oneway, it doesn't appear to work for me for :left and :right. Oh well, their trac is → that way; let's go and add it. --achadwick 04:03, 22 February 2009 (UTC)

• I like this proposal. in general, however the details of tagging foot- and cycleways would still have to be defined. Also see Proposed features/Advanced footway and cycleway.
• I don't like this proposal, if several different lanes have different need for tagging, they should be mapped separately. That goes also for most features along any road. Only exceptions is for features that is natural to tag on a highway or similar, but only applies for one direction in a special occurrence, such as a bus stop. --Skippern 16:42, 17 February 2009 (UTC)

This would needlessly complicate matters, and go against years of established practice. It is currently natural to tag a highway with its number of lanes=*, for example, and we assume that footways and cycleway=*s are part of the way. Adding :left and :right into the mix would add new expressivity while retaining backward-compatibility. --achadwick 20:35, 21 February 2009 (UTC)

It's established in OSM to only map lanes separately if it's not physically impossible to travel from one lane to the next. i.e. if it's just a line painted on the ground, then you should not have separate ways. If there is a cycleway on one side the OSM convention is have a single way. To have separate ways for the road and the cycleway is a much bigger overhall than :left and :right tags. Rorym 17:34, 2 March 2009 (UTC)

I do not know if cyclelane=* is an approved tag, but a left/right value for that specific tag might be just as proper as a yes/no value, to add cyclelane:left and cyclelane:right is not the way to do it IMO. I have also learned after I wrote my opinion that highway=bus_stop is to placed at the side of the road, so no point in left/right there.

• I like this proposal. We need something, and this will work well enough. Socks 21:01, 17 February 2009 (UTC)
• I don't like this proposal. This does not help in relations, where there is no directions arrow. --Lulu-Ann 16:00, 20 February 2009 (UTC)
• I don't like this proposal. As this is not sufficient for groups of lanes. We need at least left1, left2, left3 etc. See problems for OSM for the blind.

--Lulu-Ann 16:33, 19 May 2009 (UTC) Opps! double dislike!

... But these tag suffixes are for ways, not relations! Could you reconsider please, or let me know whether you think it's a flaw that this proposal doesn't address relations? Thanks. --16:08, 20 February 2009 (UTC)

Furthermore we already have "forward" and "backward" as relation roles, we can add "left" and "right" to that list easily, but I think it's not really related to this proposal. --Eimai 16:16, 20 February 2009 (UTC)

Indeed. This is a proposal for tagging ways only. It would as nonsensical to apply it to relations as it would be to apply it to a node. Relation roles are something else again, but relations are outside the scope of this proposal. --achadwick 20:35, 21 February 2009 (UTC)

• I like this proposal. cause such a think is necessary. This proposal is general an powerful. --Patou 22:05, 22 February 2009 (UTC)
• I like this proposal. Renderers will always show roads wider than reality, so you need to be able to attach details to the main way, otherwise those details will be incorrectly placed in relation to the road. This proposal attaches one-sided details simply and efficiently. That may not be the easiest thing to render, but it'll be much easier than trying to make sense of multiple adjacent ways. Any tinpot graphic designer can draw a cycle lane or track in the casing on one side of a road; we need to be able to do that too.--RichardMann 13:44, 25 February 2009 (UTC)
• I like this proposal. I don't see any disadvantages. And I think it is a nice solution to render cycleways on one side of the road without overlapping roads. ∼ Wimmel 20:27, 28 February 2009 (UTC)
• I like this proposal. This makes mapping cycleways and footpaths much nicer, much simplier and much more elegant. —Preceding unsigned comment added by Rorym (talk • contribs) 18:31, 2 March 2009
• I like this proposal. The proposed feature helps to not map onesided cycleways as seperate ways. This should be sufficient for most cycleways and makes mapping of junctions much simpler without losing much information. Better simple than wrong.--Nhoffm 16:56, 7 March 2009 (UTC)
• I like this proposal. Streets often have two names, one for each side, which we need to support. This proposal is easy to understand, simple to use, and the only drawback (if tags have a meaning based on the direction of the way, reversing the way needs to reverse those tags) can easily be handled automatically in editors. The consequences of an editor not supporting this, and a direction-based tag like oneway/name:left/name:right not being reversed correctly, are no worse than the current situation where we're losing one of the street names. --Riad 12:40, 12 March 2009 (UTC)
• I like this proposal. Cycleways needs this to map on the correct side of a highway=*. It would also be needed in many other ways IMHO. All we need now is it to be rendered good to. --Startail 10:48, 28 March 2009 (UTC)

• I like this proposal. Especially for name=*. But how do we combine two suffixes like for internationalization ? name:lg:left or name:left:lg ? Btw, I also appreciate that you call all of this an opinion poll and not a vote. -- Pieren 09:05, 31 May 2009 (UTC)
• I don't like this proposal. At least not for lanes. It is not sufficient to express anything except the most simple information and will be lead to several incompatible solutions being in use. For names it's appropriate, but the order of suffixes needs to be defined. --Tordanik 09:42, 31 May 2009 (UTC)
• I like this proposal. In most cases it makes sense to map cycle-tracks separately and make cycle-lanes a sub-tag of the road. Just like on motorways were we do not map each lane, but two ways if the tracks are separated. They are just like their counterparts :forward and :backward but we need clear rules for parsing! Currently left/right is used on first, second and last position in keys and on last position of values. The best solution would be a protocol extension like:

  <tag k="cycleway" v="lane" d="right:3"/>
  

  As this is very unlikely to be implemented I think it would be good to have it on on the right end of the key, optionally postfixed by a number. cycleway:right:3=lane + maxspeed:right:3=80 + maxspeed:right:1-2=100 --Phobie 12:23, 31 May 2009 (UTC)
• I don't like this proposal. 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:37, 6 June 2009 (UTC)

All other solution I know of have more problems. Be constructive and show us how to do a better design! Since we really need this, we should use this scheme if no better one can be found. --Phobie 12:09, 12 June 2009 (UTC)

• I like this proposal. This is needed for a number of side-specific features. From a purist POV, yes, it would be less ugly if it went in the value, not in the name, but this would be no worse than other things we live with. It would be easy to make the editors warn you (or autoreverse the tags) on way reversal. We do need to specify the interaction between this and language-suffixes, though. --StellanL 01:21, 3 July 2009 (UTC)
• I don't like this proposal. In my opinion various lanes should be tagged as separate ways in parallel to each other, only reason to group lanes is when there are several lanes of same sort, and than it should be tagged with lanes=* in addition to the applying highway=* or similar tag. If other types of grouping is necessary, have a look at improving Lane Relations Proposal. This entire left/right/forward/backward thing is ugly coding and should be avoided as far as possible. --Skippern 01:34, 3 July 2009 (UTC)
• I like this proposal. But I think it shouldn't be for all tags, than the feature should precise witch tags is affected. Sarge 11:13, 17 August 2009 (UTC)
• I like this proposal. --Esperanza 11:43, 17 August 2009 (UTC)
• I like this proposal. (and as Lulu-Ann has said she doesn't like it twice, can I like it twice?) --EdLoach 16:06, 17 August 2009 (UTC)

Yeah, you can, if you give two reasons :-) Sorry for the double dislike! --Lulu-Ann 12:34, 26 August 2009 (UTC)

• I don't like this proposal. In my mind this should be a prefix, optionally followed by a number to attempt a solution to the multilane-problem altogether. I've done a bit of research into those proposals that currently touch the multilane-problem. --Cmuelle8 22:17, 29 September 2009 (UTC)
• I like this proposal.. At least for cycleway=*, as e.g. in Denmark cycle tracks are "glued" to the sides of many roads with easy access to the neighbouring car lanes and sidewalk. Sometimes they missing in one side - or bidirectional ("opposite") in only one side. This extension would be the most obvious way to include this information. Apart from cycleway, it could be useful for "foot=*" (alternatively "Proposed features/Sidewalk") tag for pedestrians. --Claush66 21:55, 30 November 2009 (UTC)
• I like this proposal. I need this for maxspeed tagging. Sometimes a speedlimit starts 300m before a crossing and ends after the crossing. So every side needs a diffrent maxspeed value. A value like left/right/both/none for maxspeed dosen't work in this case. --MarkusJ 20:39, 27 January 2010 (UTC)

left/right should be used for positional things (like cycle lanes, parking space), for directional things (like maxspeed, incline) please use forward/backward. You can imagine a oneway street to better understand the difference. --Kay D 19:42, 25 May 2010 (UTC)

• I like this proposal. But I'd like to see an extension to infix, see the section at the discussion page --Kay D 19:42, 25 May 2010 (UTC)
• I don't like this proposal. It doesn't provide a sufficient level of detail for use by people with disabilities, blind persons in particular. This user group needs very exact positioning of the pedestrian network to be able to navigate on it. The solution in Proposed_features/lane_and_lane_group should cover their needs, though, as it seems to be the most complete and flexible solution currently out there. D95marty 12:37, 9 August 2010 (BST)
• I like this proposal. I also like embankment=both/left/right/none and cutting=both/left/right/none --MattGPS 02:27, 15 October 2010 (BST)
• I like this proposal. Sarge 18:39, 16 October 2010 (BST)
• I like this proposal. In my town, there is a street where one direction may drive 70km/h and the other 90km/h. I would not know another way to tag it. --Sanderd17 14:29, 12 November 2010 (UTC)

Use :forward and :backward for that. See a few comments above for the reason. --Wimmel 18:21, 13 November 2010 (UTC)

• I don't like this proposal. BUT I like such kinds of proposals because I think that writing the following on the Belgian-French border without any indication of side is, well, funny. However, they must restrict usage to well determined cases. I'm not sure however that right/left is the correct solution. I prefer Nort South East West, and for the rare cases when the road has a U form both N-S and E-W, clockwise and anticlockwise (does anyone know an 8 shaped way?). France métropolitaine, Bachy, Tournai, France — Belgique / België / Belgien, Lille, Nord, Tournai-Hainaut, Nord Pas-de-Calais, Rumes, Communauté française, Mouchin, Hainaut, Rumegies, Wallonie, France-Belgique, Parc naturel régional Scarpe Escaut --A Pirard 21:26, 25 September 2012 (BST)

Voting

Please add your votes below using

{{vote|yes}},{{vote|no}}

. We would be glad if you would write your concerns here or on the talk page for later improvements.

pro

• I approve this proposal. --Esperanza 14:27, 1 November 2010 (UTC)
• I approve this proposal. --Pobice 18:46, 1 November 2010 (UTC)
• I approve this proposal. --Nfgusedautoparts 19:32, 1 November 2010 (UTC)
• I approve this proposal. --RichardMann 10:47, 2 November 2010 (UTC)
• I approve this proposal. --Sarge 15:55, 2 November 2010 (UTC)
• I approve this proposal. (But with the infix extension) --Kay D 16:04, 2 November 2010 (UTC)
• I approve this proposal. --Evod 08:24, 6 November 2010 (UTC)
• I oppose this proposal. koppenho 08:22, 7 November 2010 (UTC)
• I approve this proposal. --Seehundeführer 13:59, 7 November 2010 (UTC)
• I approve this proposal. --Supaiku 6:37, 9 November 2010 (UTC)
• I approve this proposal. --EAman 23:02, 8 November 2010 (UTC)
• I approve this proposal. --Fschmidt 16:09, 10 November 2010 (UTC)
• I approve this proposal. --achadwick 19:38, 10 November 2010 (UTC)
• I approve this proposal. --Computerfreaked 11:57, 12 November 2010 (UTC)
• I approve this proposal. --Sanderd17 14:32, 12 November 2010 (UTC)
• I approve this proposal. --Tizianos 14:48, 12 November 2010 (UTC)
• I approve this proposal. --Corriere 16:21, 13 November 2010 (UTC)
• I approve this proposal. --Monsieur a 23:37, 13 November 2010 (UTC)
• I approve this proposal. --Pieren 12:00, 14 November 2010 (UTC)
• I approve this proposal. --NicolasDumoulin 21:48, 14 November 2010 (UTC)
• I approve this proposal. -- Hasemann 09:05, 15 November 2010 (UTC)
• I approve this proposal. -- Kaylee 11:47, 15 November 2010 (UTC)
• I approve this proposal. --Diomas 10:49, 18 November 2010 (UTC)
• I approve this proposal. --Mapmann 18:21, 25 November 2010 (UTC)
• I approve this proposal. -- richardbrinkman 13:27, 18 January 2011 (UTC)

against

• I oppose this proposal. User 5359 06:29, 7 November 2010 (UTC)
• I oppose this proposal. Al3xius 10:47, 7 November 2010 (UTC)
• I oppose this proposal. See Skipperns opinion above --Errt 12:21, 7 November 2010 (UTC)
• I oppose this proposal. --Lulu-Ann 08:52, 9 November 2010 (UTC)
• I oppose this proposal. Pauluzz 10:25, 9 November 2010 (UTC)
• I oppose this proposal. --Christian 15:18, 9 November 2010 (UTC)
• I oppose this proposal. --Stephankn 09:21, 12 November 2010 (UTC)
• I oppose this proposal. --Will.i.am 18:18, 13 November 2010 (UTC)
• I oppose this proposal. I agree with Skippern's opinion. --Surly 15:13, 18 November 2010 (UTC)
• I oppose this proposal. People using these tagging, will tomorrow tag even the building on the way representing the highway. Such as highway:building:left:1st=residential. --Fabi2 21:58, 18 January 2011 (UTC)