Proposal talk:Add a systhematic location to put the merging node when merging exit ramps on motorways or other highways

Consensus

I completely agree that there should be a systematic location for the merging node. Where it goes seems to differ greatly by mapper so it would be great for a consensus. I don't really have anything to say as to where the merging point should be. -BubbaJuice (talk) 14:41, 3 May 2022 (UTC)

I agree that specifying it so consistency would be greater is a good idea. Though I strongly oppose mapping lane as a separate carriageway Mateusz Konieczny (talk) 14:51, 3 May 2022 (UTC)

I understand that we should not map lanes as separate carriageway, but we do so already. Not doing it at all would mean that we would trace a perpendicular lane to the main road just at the end of the physical separation, which would be really weird for rendering and routing. The matter here is just to decide on the merging segment length.

Yes, noone is proposing perpendicular zigzag at the end - but several hundred meters of parallel way is an another extreme. Overall I would describe current solution as splitting on physical separation, but preserving actual road geometry with offset in meters, not in hundreds of meters Mateusz Konieczny (talk) 15:10, 3 May 2022 (UTC)

"we"

"we started some years ago to map the ramp merging nodes at the end of the dashed lines instead of right after the physical separation" - can you clarify what you mean by "we"? Who is mapping in this unusual way? Mateusz Konieczny (talk) 14:50, 3 May 2022 (UTC)

We: Chaire Mobilite (myself and colleagues, on behalf of our partners: Quebec Ministry of Transportation and transit agencies in the Quebec province)

Have you listed this editing activity at Organised Editing/Activities? Have you submitted it for review and acceptance by existing mapping community in Canada? Mateusz Konieczny (talk) 14:54, 3 May 2022 (UTC)

Yes we are in the organised wiki since 2019: See "Cleaning and completion of the Quebec Province for routing and land use". We are in contact with almost all the most active local Montreal area osm users. This issue did not appear in the local community, which is mostly associated with cycling issues as of now.

Right now we do not merge at the end of the dashed lines, but at the theorical gore (most have been modified as of now). We still think we would need a consensus though. --Kaligrafy (talk) 23:38, 24 October 2022 (UTC)

image location

https://wiki.openstreetmap.org/wiki/File:Where_to_put_the_merging_nodes_for_the_highway_links%3F.png - what is the location of this image? Is there openly-licensed imagery of high quality available for that location? (I ask as I would prepare documentation how this place should be mapped according to the current standards).

This screenshot is from the id editor with custom css styles and Bing aerial imagery which is available for use in osm. I'll add the locations in the images captions.

I added {{Bing image}} (note that Bing gave permission covering solely tracing and excluded storing images, there is no blanked permission "for use in osm". At least for now such images are not deleted on OSM Wiki but it may change in the future) Mateusz Konieczny (talk) 15:13, 3 May 2022 (UTC)

Ideally I would use the same location, but I may end using some place in Poland (as for example Bing imagery has permission only for mapping, which does not cover documentation) Mateusz Konieczny (talk) 15:03, 3 May 2022 (UTC)

Thoughts from a Mapboxer

It looks like this proposal was occasioned by this lengthy changeset discussion. Thanks for writing out a proposal so we can discuss it outside the confines of that sidebar.

You aren't the first to grapple with motorway junction placement... A few years ago, a similar debate within Mapbox led to a discussion among the global community. [1] It reaffirmed the longstanding German consensus (the "Kreuz Köln-Süd convention"): place highway=motorway_junction at the theoretical gore point so that the link way only rejoins the physical roadway at the physical gore, and tag placement=transition between the theoretical and physical gore points.

This style differs markedly from commercial vendors such as HERE and TomTom. However, it's more compatible with the rest of the OSM data model. For example, turn:lanes=* and change:lanes=* can only be tagged accurately if everything up to the theoretical gore point is digitized as a single way. For all the frustration you must be experiencing about turn angle classification and maneuver timing, inaccurate turn lane assignments and missing lane change restrictions would surely be problematic too!

In practice, few mappers follow the Kreuz Köln-Süd convention strictly in North America. It's very common to place the junction node almost at the theoretical gore point but not quite, so as to avoid a perpendicular jog in the link way. Partly that's due to a lack of awareness about Kreuz Köln-Süd, but I think it's also because that style is suboptimal for MUTCD-influenced countries such as Canada. After all, it can't distinguish between parallel and tapered deceleration lanes (which don't occur in Germany), especially when the ramp is curved. [2][3]

Ultimately, for Mapbox, classifying turn angles more holistically addressed the motorway angle problem more robustly than any policy at the data level. [4] This heuristic also had the benefit of correctly classifying turns at intersections at the ends of dual carriageways. It may inadequate for those attempting to use OSM as an "HD map", but you should seriously consider it anyways.

No matter what style is used, there will always be cases where you can't correctly model both topology and vehicle movement at the same time. Here are just a few pathological examples from San José, California (where at least one project has experimented with OSM data for autonomous vehicles): [5][6][7][8] In an ideal world, there would be multiple representations of the same roadway, one of which would explicitly represent vehicle movement, but it would not be a highway=* way per se. We're already part of the way towards that micromapping future with area:highway=* and road_marking=*.

 – Minh Nguyễn ^💬 16:36, 3 May 2022 (UTC)

"reaffirmed the longstanding German consensus (the "Kreuz Köln-Süd convention"): place highway=motorway_junction at the theoretical gore point" - which of approaches listed there is this "Kreuz Köln-Süd convention"? Because version that I used does not really match either of presented and I am unsure is this proposal missing it, or is my mapping also not following general standards Mateusz Konieczny (talk) 18:03, 3 May 2022 (UTC)

Also, I am unable to track down this "Kreuz Köln-Süd convention" Mateusz Konieczny (talk) 18:04, 3 May 2022 (UTC)

@Mateusz Konieczny: This convention is visualized in [9] and was mentioned in [10]. As I mentioned above, it's presented as "the standard", but in reality only part of the standard predominates in OSM, the part about not positioning the junction node all the way back at the beginning of the turn lane. – Minh Nguyễn ^💬 19:50, 3 May 2022 (UTC)

Curvature first

Before we discuss how to balance shapes against the need to merge/diverge, I find it more important to not artificially add more geometry to the lines drawn in the first place. In your examples 2 and 3 File:Where_to_put_the_merging_node?_At_which_angle?.png File:Where to put the merging nodes for the highway links?.png to follow the lane, you have added extra curves and different angled segments to follow the vehicle path or to fit in the lane. This is unnecessary and complicating. It is also prone to misunderstanding by other users, who might be tempted to trace every vehicle paths exactly at junctions (cf recent example at Slack https://app.slack.com/client/T029HV94T/threads/thread/CCJ2P6KCH-1651541987.589359 for an intersection), making mistakes likely.
A straight line between the theoretical gore (or physical gore when absent as in Example 3) is simple and best to balance different needs. Ideally it follows the tangent of the merging/diverging curve, but in order to represent the relative topology or layout (as in the additional intersecting road in Example 1 downstream and 3 upstream), 45deg from the theoretical gore nose to cut it short is a good compromise. Or you might relax it to 30deg when the situation allows.
So by numbering from the physical gore nose, I would choose Option 1 for Example 1, Option 4 for Example 2, and Option 2 then somewhere between 2 and 3 for Example 3. I assume Example 3 need a turning restriction for the driveway.
Another criteria that can be followed is to stay right-angled to the give-way or stopping line and crosswalk border if there is one, especially at oblique and offset intersections.
Considering micro-details, an unspoken implication is line should not be drawn across the solid line neutral area (usually with chevrons, sometimes with delineators) Exception is when it is dashed, ie allowed to be crossed.
--- Kovposch (talk) 16:54, 3 May 2022 (UTC)

Proposed angle

After a long discussion with fellow mappers, I would suggest a default angle of 10 degrees (which is larger than you may think at first) and 20, depending on the space you have before the next connected node or distinct feature in the road. In OSRM routing engine at least, an angle < 20° would have negligeable effect on turning radius penalty anyway, so this seems good for now. We may discuss the edge cases with very limited space later on, but these edge cases would mostly apply in low speed environments anyway and not on motorways. —Preceding unsigned comment added by Kaligrafy (talk • contribs) 18:03, 3 May 2022‎ (UTC)

@Kaligrafy: I'm not sure I agree with the premise that link way angles should be predicated on the penalties in a particular routing profile. These profiles were based on a sampling of OSM data, not real-world conditions. On freeways and expressways, even a 90-degree angle is unlikely to result in a penalty large enough to significantly affect routing. (After all, such angles are not uncommon on expressway exits in reality.) OSRM applies penalties large and small for all sorts of reasons, including every bend along a winding road, but this is not in itself enough cause to change how roads are mapped. [11]

As it happens, OSRM considers a 25-degree angle to be straight. [12] So indeed you'd eliminate any penalty, but then the maneuver would be suppressed as a straight continuation rather than a turn of any sort. So such a conservative angle would be problematic even without considering the angle a distance away from the intersection, as OSRM and Valhalla do. [13][14][15]

 – Minh Nguyễn ^💬 20:17, 3 May 2022 (UTC)

Theorectical gore mapping

For the past years I've been using this way of mapping, allowing both smooth geometry and proper lane tagging while keeping the router happy:

• 

  Slip lanes at theorectical gore

• 

  With lanes

• 

  On- and off-ramp at theorectical gore

• 

  With lanes

--Riiga (talk) 19:53, 3 May 2022 (UTC)

@Riiga: This is a good illustration of the Kreuz Köln-Süd convention mentioned above. It would be helpful to collect statistics (somehow) on its prevalence versus other styles. Anecdotally, I can say that the Kreuz Köln-Süd style is rare in the U.S. outside of perhaps Oklahoma, but hard numbers would help us develop more formal guidance around this topic. – Minh Nguyễn ^💬 20:21, 3 May 2022 (UTC)

"It would be helpful to collect statistics (somehow)" - select random highway=motorway_junction edited between 2021-03-01 and 2022-03-01 worldwide and manually classify them according to state on 2022-03-01? Dates to avoid looking at stale outdated data and keep them easily downloadable with Overpass, upper limit to discourage editing to inflate statistic Mateusz Konieczny (talk) 20:25, 3 May 2022 (UTC)

@Mateusz Konieczny: I'm not sure this would result in a more representative sample than just getting a random selection of motorway junctions in general, since motorway junctions don't necessarily get edited on a regular basis. We can get a good sense of the prevalence of the strict Kreuz Köln-Süd style based on counting highway=*_link placement=transition combinations, but distinguishing the vehicle movement and 45-degree-angle approaches would be more difficult. – Minh Nguyễn ^💬 21:21, 3 May 2022 (UTC)

+1, I used something very similar. Presents real geometry, allows to map turn lanes, avoids fake carriageways. I always considered it as a standard Mateusz Konieczny (talk) 20:22, 3 May 2022 (UTC)

For a while, I tried drawing the link way directly over the neutral area in a couple U.S. metropolitan areas, but I kept on running into situations where it proved a poor fit for standard road geometry in the U.S. For example, when a multi-lane exit ramp has both a parallel deceleration lane and an optional lane (the norm across California and at major junctions elsewhere), the theoretical gore is located further back from the neutral area, sometimes by a significant distance, as much as 300 feet (91 m) (a few seconds at 55 mph), and that distance can sometimes coincide with a curve in the main road. Should the link way begin at the theoretical gore or at the tip of the neutral area? Either placement loses information (as would mapping the full deceleration lane as a separate way).

On top of that, California often builds complex merges where the Kreuz Köln-Süd style would result in drawing a link way directly across a different roadway, potentially breaking map matching. There are also situations with no right answers, like this expressway on-ramp where a vehicle movement approach would fabricate an intersection where there is none, and the Kreuz Köln-Süd style does not apply because there's no neutral area.

As counterintuitive as the 45-degree style may look on a raw rendering, it does have the advantage of accommodating both navigational details (like turn:lanes=*) and non-navigation details. In the long term, I think area:highway=* would help us move past these difficulties by allowing us to better express the fact that a highway=* is just one path within the roadway out of many.

 – Minh Nguyễn ^💬 20:59, 3 May 2022 (UTC)

That multi-lane merge/diverge layout with only solid line is simpler than ghost island. Lane gain with direct taper merge consecutive direct ghost island merge (there could also be a parallel section) --- Kovposch (talk) 02:34, 4 May 2022 (UTC)

I presumed highway=* should be kept within its area:highway=* and not drawn across other area:highway=*, so I don't do this. Sometimes there are extra physical obstacles in the neutral area, and also what about crash attenuators. --- Kovposch (talk) 02:23, 4 May 2022 (UTC)

Connecting on ramps later is incompatible with high detail mapping

Connecting on ramps to the motorway after the physical separation ends causes the following problems:

1) Breaks the established rule in OpenStreetMap that parallel lanes should be drawn separately only if there is a physical separation that prevents drivers from crossing between the lanes.

2) Navigating to a section of motorway just after it connects in real life, but before it connects in OSM will not work properly if the shortest route

3) Representing the lane layout just after they connect irl will be very difficult.

4) If the road becomes a bridge just after the on ramp connects in real life, but before it connects in OSM, then OSM will show two parallel bridges when there is only one bridge irl.

5) Harder to maintain in my experience.

Only benefit to connecting later is prettier rendering. For any non rendering usage of OpenStreetMap data, connecting later is worse.

My personal opinion is that the node where they connect should be at the point where the solid painted line between them becomes dashed, and that the angle between the motorway and on ramp should be about 30%. Doesn't look amazing on the map, but is really good for data consumers. LeifRasmussen (talk) 02:15, 29 May 2022 (UTC)

The point where the solid painted line becomes dashed, is often hundreds of meters away from the physical separation or "gore", at least in the US. That would probably make the ramps too long. 1T-money (talk) 23:55, 7 June 2022 (UTC)

Or about 100-200 meters actually. Hundreds of feet. But it would still be too long 1T-money (talk) 00:02, 8 June 2022 (UTC)

Very good point. What I meant was the point where the separation becomes just a painted line, solid or dashed. As soon as the road can be accurately mapped as a single way, it should be. Where I live, the solid line always becomes dashed as soon as the on ramp is next to the highway, so I forgot about the possibility of the line remaining solid for a while. --LeifRasmussen (talk) 08:38, 8 June 2022 (UTC)