How would you map this?

Posted by mvexel on 11 May 2017 in English (English)

I am trying to figure out mapping complex intersections and I am a little stumped :) To completely represent all possible lanes and turns in an intersection, you would need to define:

  1. The lane layout (turn lanes, through lanes)
  2. The lane connectivity (which lane connects to which at the far end of the intersection)

If I asked you to map this intersection completely, how would you do it? Which (combination of) turn / lane tagging schemes would you use?


(If you’re interested, this type of intersection is a CFI or continuous flow intersection.)

Comment from Roadsguy on 11 May 2017 at 03:34

Is this an issue with CFI mapping in general, or just this one case? This one seems tight enough that the mapping for it might look funny and be pretty tightly squeezed in, but if CFI mapping is standardized enough, there shouldn’t be a significant problem.

Comment from mvexel on 11 May 2017 at 03:45

My question is not specifically aimed at CFI mapping. I just chose this intersection because it’s reasonably complex.

Comment from escada on 11 May 2017 at 03:57

  • dual carriage ways for N/S
  • are the cycleways tracks ? (hard to see on the picture) Would make tagging easier
  • W: lanes=8;lanes:forward=5;lanes:backward=3:turn:lanes:backward=none;none merge_to_left      
    then a shorter piece with 7 lanes, very similar but with turn:lanes:forward=left left through through right (if the arrows are indicated on the signs)
  • E similar to west
  • Since S/N are dual carriage ways, no need to split in forward/backward
  • N, similar for the top part, then split at the right turn + propably no right turn restriction at the actual crossing
  • O yes, and for the end of that right turn, a only_right restriction for going to W

I am not familiar with the signs on the 2nd lane from the right in S.

Comment from NunoCaldeira on 11 May 2017 at 04:05

nice challenge. i would use turn lane editor for the turn lanes in conjunction with turn restrictions to avoid bad routing. both in JOSM.

heres my suggestion. i wouldn’t use that common centre road with any turn restrictions, best solution would be to do a common vertice, theres no point of having it this way.

check my diary entry about how to use Mapillary, theres a few examples of how to use these JOSM plugins.

Comment from philippec on 11 May 2017 at 08:13

And what is the penalty for passing a full white line ? :)

Comment from escada on 11 May 2017 at 10:19

@NunoCaldeira I would add the turn lanes also to the way between the N and S ways. I do not understand your turn restrictions for the street from N. Only right & straight ? Your turn lanes tell me something else.

Comment from NunoCaldeira on 11 May 2017 at 10:28

@escada. You are correct, my mistake on the turn restrictions while coming from N road to W (lanes tells only straight and left and right the turn restrictions was wrongly applied as only straight and right instead of straight left).

I didn’t understood what you meant regarding the way “between N and S”. Did you mean E-W?

Comment from escada on 11 May 2017 at 11:13

@NunoCaldeira, sorry for the confusion, I’m talking about the small segment between the N-S ways of the E-W street. I now see that there are no lane markers, but isn’t it weird that the lanes do not continue there ? Sorry, I come from a European context, where the lanes really continue over the junction. So in this case one shouldn’t map the lanes there.

Comment from NunoCaldeira on 11 May 2017 at 11:18

@escada no worries, I’m also european. I never mapped something similar, from my perspective that way should be left without lanes (since there’s a multiple options and it would cause confusion.

Either this way or just remove that way making it a “traditional” intersection where Lane restrictions would be easy to be applied.

Comment from Paul Johnson on 11 May 2017 at 11:28

What’s the location? I can take a crack at this. I’ve had experience mapping a pretty big variety of intersections now as I try to lane-map every state highway in Oklahoma.

Comment from Canyonsrcool on 11 May 2017 at 15:26

3100 S needs to be divided out to a certain extent as there is physical cement barrier there, then lanes/turning lanes/turn restrictions can be modeled more accurately. North South looks pretty good as far as division goes. Same thing further south on 3500 S, but 3500 S doesn’t look to be divided. That’s where the lanes: tag will be used a lot for “forward” “backward” and then turning lanes, and turn restrictions. Good example!

Comment from Paul Johnson on 11 May 2017 at 16:34

OK, I’ve taken a crack at it. You’ll probably need to use JOSM with a lane-aware rendering style. Osmand should give proper lane-level guidance on this intersection now.

Comment from mvexel on 11 May 2017 at 18:31

Wow, thanks for all the feedback.

I am happy to see people seem to prefer the turn:lanes approach so far, which is simpler than the relation based schema I have also seen. Mapbox had a blog post that highlighted both.

One thing that would still lead me to want to use relations in some places is my second ‘requirement’ to correctly identify lane connectivity – exactly which (turn) lanes connect to which. So how to map that making a left turn here (1->2->3)


means that you have to go from lane to lane on the consecutive ways like this:


For that you would still need a relation, or is there a simpler / other / better way?

Comment from escada on 11 May 2017 at 18:52

Is there a turn restriction on the 3100 South with the one way coming from the north ?

Comment from Paul Johnson on 11 May 2017 at 18:57

@mvexel: This is where placement=* comes into play. Osmand generally assumes you will end up in the corresponding lanes once you get around the corner, which from my experience is a reasonably safe assumption (and follows either best practice or the law everywhere to the best of my knowledge).

This does mean that you sometimes have to work out the centerline of through lanes for miles at a time, something in my quick and dirty example I only did to a logical stopping point. And sometimes, switching the centerline location because, say, a new lane joins on the right, then miles later a lane gets dropped on the left. I usually make such a transition at the drop if possible, tagging which lane ends, with the end of the lane line starting a new segment with one fewer lanes, placement=transition. I also use a placement=transition for situations where one or more sides of a link face a flush median like a theoretical gore, and have the junction node even with the point that theoretical gore’s nose, ending at the ramp’s centerline start adjacent to the bullnose.

Comment from Paul Johnson on 11 May 2017 at 19:25

@Escada Which movement are you referring to?

Also, thanks for making me doublecheck, I forgot to tag the traffic light junctions. I see someone added a left-turn restriction, but I’m not sure if that’s actually the case or not (depends on if a U-turn is legal from 3100 south or not, and if not, then a couple more restrictions need to be added).

Comment from escada on 12 May 2017 at 03:17

@Paul Johnson, oh, I see it now, you model your u-turn via that way. It’s a bit unfortunate that it now seems like there are 2 places where one can make a u-turn coming from the east. But I see no better method to map the N-to-E way.

I would have mapped the traffic signals differently though (not that you did it). Not on the junction nodes, but on the ways approaching the junction in order to avoid that dumb data consumers would think I had to pass 3 traffic signals when travelling from E to W. (as explained in - tag all incoming one-ways).

Comment from Paul Johnson on 12 May 2017 at 05:58

If U turns are not restricted, it doesn’t make sense to add the restriction to either possible option, routing engines will universally pick the shorter option.

Also, yeah, I really would rather go with a relation for traffic signals on a situation like this, since node mapping fails highway=traffic_signals, highway=give_way and highway=stop situations in all but the simplest of cases, and would like to get more support for doing so. Until then…node tagging works as a placeholder and something a potential future MapRoulette challenge can latch onto.

Comment from mvexel on 12 May 2017 at 14:47

escada: I’ve seen transit – it looks more complex to me than turnlanes:turns for mapping lane connectivity. Can you help me out mapping this intersection using the transit schema? I think relations would be needed, but not sure how to map the transition for example from 1-2-3:


It looks like 1-2 can be done with ways, as indicated below, but I am not sure how to identify that the left turn lanes from 2 to 3 lead to the left two lanes of segment 3.



Login to leave a comment