How should a slip lane's way be mapped?

Help and support
,
1

2025-04-24T19:28:01-0700
2025-04-24T19:28:01-07001677Ă—1034 331 KB

Should slip lane ways be mapped as blue, or red (or perhaps something else)?

Conversely, should the entrance slip lane be mapped as red or blue:

2025-04-24T19:30:15-0700
2025-04-24T19:30:15-07001858Ă—740 259 KB

1 Like
2

Red

lanes=6
lanes:forward=4
lanes:backward=2
turn:lanes:forward=left|through|through|right
turn:lanes:backward=none|merge_to_left
change:lanes:forward=no|not_left|yes|yes

(when you aren’t dividing the major road yet)
Is it really the case the westbound will merge to become single lane only?

1 Like
3

Is there a specific reason why I shouldn’t do it like blue?

4

OSM strives to represent a single carriageway as a single object, where multiple/special lanes are indicated by tagging (e.g. turn:lanes). Only the red part is physically separated from the main carriageway.

This is necessary for data consumers to have a detailed understanding of what lanes there are on a road, to understand where lane changes are physically possible and where they are allowed.

2 Likes
5

There are some practical arguments

  1. You are allowed to change lanes over the entire section, as a parallel merge/diverge. It’s not a direct taper merge/diverge.
  2. Applications should already know when to properly give guidance. Announcing too early is confusing and doesn’t work in more complicated layouts.
  3. Prevents warning other drivers of merging traffic, or slowing down of diverging traffic
  4. Limited GPS accuracy makes this useless, and will even mess up positioning/snapping/matching

Here, it would be outright wrong and false on the westbound. Either a fake merging lane is created, or the main side lost a lane.

6

Because slip lane is not a separate carriageway.

We split on a physical separation. For example, if slip lane would be separated by jersey barriers then it could be mapped as a separate line.

In OSM such lines are for separate carriageways, so road with multiple lanes should not be represented as separate line for each lane. Also, road with two carriageways should not be mapped as a single lane.

7

On this point, support for change:lanes=* and connectivity relations among major routers is still nearly nonexistent. Instead, navigation systems have been relying on guesstimated assumptions about lane change restrictions and hard-coding them into instruction timing. For example, the Valhalla-based Mapbox Directions API varies the location at which to start announcing a turn based on the estimated speed and the classification of the road the user is currently on, plus some fudge factors.

Thanks to explicit mapping of turn:lanes=* and change:lanes=* in OSM, it’s possible to statistically prove that classification-based timing is an ineffective approach in most regions. As coverage of these tags improves, we can make a better case for routing engines to support them in both routing and guidance generation. That requires consistent adherence to the physical separation principle, only modeling a parallel way when there’s a physical barrier or a marking pattern that’s tantamount to a physical barrier.

1 Like
8

shakes fist at sky

The more I come across intersections like this on mapping the more I only want to use change:lanes and nothing else to show separations. It’s clear to anyone that it’s not a separate road or way, it is just an area you can’t change lanes in.

Controversial opinion: only motorways should have links for their exit ramps and even then should be called ramp not links. :popcorn:

1 Like