Hi, folks!

I want to share with you my blog post about mapping turn lanes

If you have any suggestions, you can write it here in comments

Mapping turn lanes in OpensStreetMap

Complex intersections often involve lane-specific turn restrictions. See for instance these overhead signs on Utah State Route 92, crossing Interstate 15 just south of Salt Lake City.

turn lanes sign

Lane signage on Utah State Route 92. Photo: Garrett.

We need turn restrictions for every individual lane to provide precise directions for drivers. In OpenStreetMap we model turn lane information with two tagging schemes:

Here is a guide on how to map turn lanes with OpenStreetMap’s JOSM editor. Note that type=turnlanes:turns is a proposed feature. You can join the proposal process by submitting your review on the relevant talk page.

Mapping Turn Lanes

First, install the turn lane plugin directly from JOSM’s settings panel. It provides support for both Key:turn tags and type=turnlanes:turns relations.

As an example, let’s look at how to map turn lanes in detail on this intersection alongside US 101 in South San Francisco.


Lane-specific turn restrictions along US 101 Exit 425B.

Enable the “Turn Lanes” panel in the “Windows” menu.


Identify the number of lanes on all the roads leading to and from the junction.


Add the number of lanes to the appropriate ways as a regular tag - for example, lanes=2.


Split the ways that will be parts of relations. Then, for each turn lane restriction, select the nodes and ways involved to define a rule. You should see the junction modeled as shown once the lane count for all the roads have been set.


Let’s start with the motorway link from US 101 leading into the junction.

exit_to=Oyster Point Boulevard; highway=motorway_junction; ref=425B

Initially this way has one lane which splits into three before the junction. At 141 meters before the junction, add the left lane. At 92 meters, add the lane on the right side. These lanes can be added by clicking the white plus button and setting the start position by dragging the blue marker back from the junction.


Add a lane to turn left for a small section of Dubuque Avenue. You can pan the model by dragging with the right mouse button.


Now create rules for the thoroughfare from motorway junction #425B with rules for each lane by dragging a route across the relevant junctions and lanes.


Add similar rules for all directions where applicable.

Now let’s check our work by selecting nodes and reviewing traffic flow. To cycle through all directions press Ctrl+A for an overview of all restrictions on the junction.


I hope you find these instructions useful to map detailed junctions in your area. If you have any questions or ideas on mapping turn lanes, drop me a line on Twitter or through my OpenStreetMap profile.

Header photo: Interstate 10 and Interstate 17 Interchange at Night by Alan Stark

Location: South San Francisco, San Mateo County, CAL Fire Northern Region, California, United States

Comment from Stalfur on 30 July 2015 at 10:16

Timely blog, been wondering about this myself, will give it a try.

Comment from escada on 30 July 2015 at 11:27

It is not clear for me how this relates to turn:lanes, change:lanes and placement tags.

The turn:lanes tagging is done all over Germany, it was a “week assignment” in November last year, but people continue to add them.

In Belgium, I have been mapping those things since April 2014, and according to the last statistics I saw on the German forum turn:lanes have been added extensively in Austria, Switserland and some other countries as well.

So if it is a “competing” proposal, I don’t know whether it will be successful in Europe.

One of the problems I see now is that you map the length of a lane as a tag. It should be mapped by splitting the road and tag the number of lanes on each part. There is no need to map the length as an attribute. Mapping the length of something as an attribute is always a bad idea, as the way might be split or merged and nobody will pay attention to adapt those length attributes.

I might have to study your proposal more thoroughly to see whether it bring additional benefits to the current model, which btw is also supported by OsmAnd.

Comment from rab on 30 July 2015 at 18:03

As mentioned before, there is already an approved way to map turnlanes in osm. This scheme is also supported by osmand and mapfactor since some time.

Comment from MKnight on 30 July 2015 at 19:01

Example for established turn:lanes without turn:lanes:turns-relations: [Alternativtext] ( (with lane-attribute-preset/stile)

For what for should i use the relations?

Comment from R0bst3r on 30 July 2015 at 19:29

Absolutely confused. Why another tagging scheme? Why a misleading JOSM Plugin for only a proposed feature? What about the other editors? iD isnot of great use adding such kind of relations. How serious is this proposal?

Comment from Nakaner on 30 July 2015 at 19:53

It is no good idea to use relations for turn lane mapping. Roads are very often touched by newbies. Newbies use iD and/or have no knowledge (iD does not help them to get it) about relations.

I hereby strongly suggest neither to use the plugin you promote nor to use relations for turn lane mapping!

Comment from robert on 30 July 2015 at 21:20

Mouth hanging open in amazement.

Comment from robert on 30 July 2015 at 21:46

One question: does the plugin work for countries that drive on the left?

Comment from mvexel on 31 July 2015 at 02:50

My observations:

1) Whatever is used significantly more should be the de facto standard. The turn:lanes schema wins here (turn:lanes on TagInfo versus turnlanes:turns on TagInfo)

2) Whatever is easier to map and maintain should be preferred, again, turn:lanes wins - BUT the fact that the relations proposal has JOSM plugin support makes it really attractive, so there is not a clear winner here.

3) From a routing engine perspective, the relations approach would be much preferred because it defines a clear from –> to relation, removing ambiguity on complex intersections.

I favor the relations approach, mainly because I deal with the routing engine dimension every day.

Comment from escada on 31 July 2015 at 03:21

@mvexel: As you can see in the above comments, there are already 2 navigations apps that support turn:lanes.

As a user of OsmAnd, I have to say that in general this works fine. I know of one case where the instructions of OsmAnd based on the turn:lanes is a bit confusing. And even that one could be solved by slightly modifying the value of the turn:lanes tag. No relation needed.

Comment from species on 31 July 2015 at 06:20

Is there ANY case that cannot be solved with turn:lanes key?

If yes, then go this way - for the special case. If not, please no more unneeded relations. It should be simple for the users, not for the routers. A router has only to be programmed once, the mappers have to do it every time.

And before investing time to write relation parsers for Routers, please invest the time to rewrite the JOSM plugin to support the turn:lanes scheme! It will save a lot more time worldwide - O.K., not your time, but the time of others - hey, we’re on OSM here, we’re doing exactly this thing the whole time - improve the map so a lot of other people benefit :-)

Comment from Aury88 on 31 July 2015 at 06:35

Hi all, this scheme imho is more flexible and (thank to the josm plugin) more noob-proof (like me) than the turn:lanes. I’m not an expert but I ‘ve some consideration about what other users say:

1)Whatever is used significantly more should be the de facto standard. The turn:lanes schema wins here

R:-yap,122 998 ways mapped with turn:lanes is a good number but not so big…in my opinion we can handle this number (today is better than tomorrow ;-) ) our tagging scheme can evolve and deprecate the old one if we gain more details/control over the data.

2)turn:lanes is supported by OsmAnd

R:- Is it possible to use this new scheme while maintain the old one and after a long enough time deprecate the old one? I don’t know how often OSMAnd update their maps but probably we can find a way to coordinate with them in this transition or better let them start support the new scheme and than start map with it…I think this scheme can be very useful for routing engine (mainly in the complex intersection) so for the OSMAnd team probably this can be a tollerable effort

3)problems I see now is that you map the length of a lane as a tag. It should be mapped by splitting the road and tag the number of lanes on each part. There is no need to map the length as an attribute. Mapping the length of something as an attribute is always a bad idea, as the way might be split or merged and nobody will pay attention to adapt those length attributes It is no good idea to use relations for turn lane mapping. Roads are very often touched by newbies. Newbies use iD and/or have no knowledge (iD does not help them to get it) about relations

R:- I don’t like also splitting the road so many time… easily a new and distracted user will join them. with the length tag if a user joins the way’s segments before the intersection or after the tag and the relation is still valid…the problem is when splitting the way before the intersection or when joining way’s segments before and after the intersection but I think those problems remain with the other scheme. Is there a way to add a warning when touching a way in a relation? how is the problem handled in the restriction relations ? Also why a new user would want to touch a (assumed by the presence of the turns description) good mapped intersection?

4) iD isnot of great use adding such kind of relations.

R:- this is the reason to use the iD for some works and other editors for others…I don’t think a newbie will try such a specific and fine mapping neither with the non-relation scheme.

personally I like the new scheme: it’s flexible, it’s very similar to the restriction relation and the plugin seems very easy to use. I really appreciate the “destinations” approach instead of the more generic and ambiguous directions approach

Comment from Dotevo on 31 July 2015 at 06:47

I added support to my bicycle website some time ago (for max zoom)

Comment from Dotevo on 31 July 2015 at 06:52

And screen shot :) Yuuuu

Comment from hurdygurdyman on 31 July 2015 at 06:59

To know what we talk about: Have a look here and try to find out what the up to four relations on some ways want to say to you without using that JOSM-plugin. Are you able to find out only by relations, which lane gides you best through crossing without Bing as background?

We should prefer solutions transparent enough to be created, read, changed and understood without any tools. Therefore this plugin isn’t suitable. Remember that most of people creating OSM-Data are volunteers and we should allways keep KISS in sight.

And just one question about length-tag: How do you get exact measure with that plugin?

Comment from escada on 31 July 2015 at 07:08

@Aury88: please add turn:lanes forward and backward to your numbers, it almost doubles. I spend over a year to add turn:lanes to half of Belgium. I hope almost all primary, link and trunk roads are done. Germany might be covered for 90% I don’t know. In order to know what 200.000 means, you need to know how many they are in reality.

Joining road by newbies A good editor will warn that both parts have different tags. JOSM already does this and I assume the other editors do this too (or to a certain degree). None of them supports length-tags. Adding length is just a stupid idea. Length has to be calculated from the length of the ways. How do you measure length in a curved road ? It is much easier to split a road where the turn:lanes changes than to try to measure this in the field or on a aerial images.

The scheme might look flexible, but what can you map that you cannot map with turn:lanes ? Did you ever do any turn lane mapping ? Did encounter something you cannot map ? I’ll agree that this plugin might make it more appealing, but that doesn’t mean that the underlying schema is better, more flexible, etc. Please do not be attracted by some shiny toy.

As for Osmand, I’ve read somewhere that the lead developer does not like relations, e.g. there is no support for the destination-relation, while there is limited support for the destination tag. So I would not bet on them supporting this scheme.

Comment from Aury88 on 31 July 2015 at 09:58

@ascada: at the period I saw this I didn’t map the turn lines but today I still don’t know how to map this situation: I encounter a semaphore intersection with three possible left turns (plus one or two straight forward and one for the right turn). in this case only the first line was usable for the first left turn the second for the second and so on…the first line and the second on the left are used to take a (two line ) common way that after 10m the intersection split in two distinct ways so the first line is used for the left-most one and the second for the right-most ( it’s forbidden to use the second line to enter the left-most and vice versa (I suppose for safety reasons). also the third was on slightly left the crossing and the straight forward was slightly right… sadly I don’t remember where it was (it was in china and find it thank to a near wrong element linked by mapproulette) and I didn’t touch it but see it in streetview (so we talk of 2-3 years ago, it’s a year a can’t use streetview and Gmaps )…I hope they put a roundabound junction meanwhile xD the situation was something similar to this sketch but probably there are some errors in the number of lanes on the other ways and definitely it was not oriented like in the sketch…I’m referring only to the lower highway in the sketch

Comment from hurdygurdyman on 31 July 2015 at 11:55

See what I found out about the founder of that plugin

He was active in OSM-wiki for less than four month in 2011

As far as I see he never mapped active

So please form your opinion ;-)

And as noted in the margin: In and arround San Francisco you find more than 400 ways mapped with key turn:lanes or turn:lanes:*

Comment from escada on 31 July 2015 at 14:25

@Aury88 for this scenario a relation might be easier, but not for the +95% (very rough estimate as most cases are pretty trival) of the other crossings & highway exits and entrances. So why should you complicate those cases ?

On the other hand I think that even your example can be done with turn:lanes and change:lanes, it depends a bit on how the way are connected in OSM.

Assuming that the top three ways join in 1 point, and the button three as well and there is a way between those points, I think it is feasible.

Comment from rab on 31 July 2015 at 15:19

When looking at this segment, one will understand that there are reasons for the wider usage of the *:lanes scheme. First: It is human readable. Second: It is simply extendable with common tags and therefore it it much more versatile as this aged zombie proposal. And by the way, simply counting relations and ways is like trying to compare of apples with oranges

Comment from escada on 31 July 2015 at 15:20

Actually, Aury88 your example is almost trivial, depends on where the 2 lanes for the way towards 1’o clock starts. Suppose for a moment that that road actually starts as a single lane. Then the number of incoming lanes equals the number of outgoing lanes and is lanes=6 enough for a router to divide the lanes properly over the outgoing roads. That’s a technique explained by a Dutch mapper name It’s so Funny, which can reduce the number of required turn:lanes that you have to map.

Comment from mvexel on 31 July 2015 at 15:25

The one case that I can’t see would be supported well by the simpler scheme is the complex intersection of the type Aury88 drew. This is where you would need a clearly defined relation between origin lane and destination way or even lane. From an application perspective, I would rather support one scheme that covers all possible cases. From a mapper’s perspective, I am all for keeping it simple however. Sometimes these two sides of me don’t come to an agreement.

Comment from DaCor on 31 July 2015 at 15:48

Given one option is used on a more wide basis, it seems that should be the default, as normally happens with tagging in OSM

However, this plugin makes the other option massively appealing. Seriously, it would be childs play to map a complex junction with something like this.

The obvious solution would be to depreciate the plugin and develop a new one with the turn:lanes tagging instead.

That way you get:

  • Standard tagging
  • Option for people to use the manual method as they’ve always done
  • Additional option to expand potential users by simplifying the task with the plugin
  • Much wider adoption of turn lane mapping in general

As to how this could be done in reality, the navigation reliant companies (Scout,, OSMand etc) should come together and split the costs of development as something like this would benefit them the most. What I mean is, this is pretty specialized mapping for general users and not likely to be high on the list of things to be mapped

Comment from rab on 31 July 2015 at 16:50

In some rare cases you might need to use relations. Please check this proposal, where some strange cases were highlighted. Here is an example of a simple crossing which incorporates 15 turnlanes:turn relations: The problem with that is not the tagging but the maintenance.

Comment from Aury88 on 31 July 2015 at 18:01

@escada: I think the way towards 1’o clock at first was the extension of the 6’o clock road (2 line both and the other direction physically separated also both with 2 lanes ) and then, some time later, were added the others roads…and it remain in its initial configuration…I suspect this is also the origin of the straight forward sign on the line to reach it (I would use the straight forward for the upper road and the right sign for the 1’o clock). I pretty sure of the number of lines in that way, but I don’t see how this can be problematic…I thought the main problem was with the difference between turn lanes and intersecting highways (and plus the strange geometry)

my idea is that such a relation could help in many ambiguous situation (number of ways different from the number of turn-lanes and strange intersection/way geometries/orientation) and so can be accepted as a alternative in those cases…

I’m pretty sure it is possible to add a warning if someone touch a relation and, I think, it’s hard that a not-so-expert user would touch a well mapped complex intersection, isn’t it?

about the length problem we can think to use a geometric solution like in the Key:turn (cutting the road based on its number of lines) or is it impossible in the relation scheme?

PS:I re-read my previous comments…I apologize for my really bad English. It is indicative of my state of confusion with the topic xD

Comment from RobJN on 31 July 2015 at 22:02

It’s an interesting plug-in. The bit I struggle with (other than the two competing tagging schemes which is never good for a mapper) is how did you know to that the lane split at “141 meters before the junction”? It seems difficult to get the split in the right place.

If this plug-in/proposal didn’t have this “length” element then it wouldn’t conflict so badly with the turn key. As it stands now the 2 tagging schemes conflict on the “lanes” key. This is the worst possible situation - all new proposals should ideally not break any existing scheme. Although it this case it looks like both were in development at about the same time.

This is a good case where the likes of Mapbox, Telenav, OSMAnd etc can help us. As data users they can spell out what they want/why existing schemes aren’t working from a data use point of view. We can do the same from a data production point of view and in the end we come to a better final implementation. Discussions need to be open and ideally avoid the “another ‘standard’” problem.


Comment from andygol on 5 August 2015 at 18:20

Thanks everyone for weighing in. Agreed that the turn:lane approach is the established one and also preferable to the extent that it’s simpler.

At complex junctions though the turn:lane approach just breaks down and it isn’t explicit enough to provide proper guidance. Take this example:

taganskaya sq example1

Try to make a solid instruction for driving from particular lane from points START-1 or START-2 to point FINISH with turn:lane isntruction. If drivers started from wrong lane they can’t be able to reach FINISH point, since they not allowed or haven’t possibilities to move to other lanes. Only lanes 2 and 4 can be used as guidance for driving to FINISH point, but other is fault. With relation turning:lane we can unambiguously indicate routes for each lane.

I’m seeing that of the 14,137 turn lanes, 3,335 (growth by 30.9%) are mapped in the last 6 months. So there is some momentum behind the turn:turnales proposal.


It seems for now it’s appropriate to use where the complexity of an intersection is just too high for the turn:lane approach?

Comment from andygol on 5 August 2015 at 19:06

UPD to my prev comment

At the last picture you can see a map of spreading relations turnlanes:lane worldwide

Comment from andygol on 6 August 2015 at 09:53

As a result of this discussion, I’ve updated the blog post with a description for turn:lanes style mapping.

Continuation of the discussion is encouraged.

Comment from DaCor on 6 August 2015 at 19:46

Just a side note, there would likely be a far larger adoption if the plugin could be configured for left hand driving

Comment from mvexel on 8 August 2015 at 17:28

From the perspective of a large scale data user (Telenav) - in the end we will just do whatever it takes to get the best coverage for our users. If this means supporting two competing conventions for a while, we will do that.

That said, we will always try to get wider support for a single tagging convention that ensures ease of use and consistency for mappers, but also covers more complex situations that simplified tagging schemes just cannot.

A good example is the exit_to versus destination discussion we had in the US last year, where I actively promoted switching to the much more flexible destination based tagging scheme for tagging motorway / freeway exit signposts.

If it means creating new JOSM plugins, or other tools, we will consider that. Message me if you have anything specific in mind that you think we may be able to help with.

Comment from rab on 8 August 2015 at 21:04

Complex junctions - With a lot of guesswork. If some one has local knowledge, we could adapt this to the reality. But it is generally not too complicated to map such complex junctions with the *.lanes scheme OSM-file

Comment from Baloo Uriza on 9 August 2015 at 00:55

The turn lanes plugin should not be used at this point, as it uses the scheme that Has Lost The War™. turn:lanes is the way to go, it’s the one that has consumer and rendering usage at this point, and the easier option to wrap your head around.

Comment from andygol on 9 August 2015 at 19:35

Here is the picture from comment above from rab

Comment from SimonPoole on 14 August 2015 at 10:01

@andygol how many of the increasing number of relation based turn lanes are from you and other Mapbox employed mappers?

Comment from andygol on 17 August 2015 at 13:19

Hi, Simon!
There has not been a mapping assignment at Mapbox to work on turn lanes, so this growth in relations is likely from participants of the community who use them for mapping. In the past, I had created a few such relations near where I live to better understand the schema. I explore these approaches to offer a scheme that combines these two schemes, or to find a compromise between them.

Comment from mvexel on 11 May 2017 at 18:33

My recent diary entry with a ‘mapping challenge’ for a complicated intersection is relevant to this topic. I’d appreciate your feedback!

Comment from mvexel on 3 October 2017 at 18:40

Another new diary entry that is related to this topic: Mapping Center Turn Lanes in the United States

Login to leave a comment