Note that in cases where physical separation is extremely short (for example island on a crossing) it is fine to omit splitting road into two. See crossing:island=yes for the most common case of such situation.
is it merely fine? I think that for small splits like island on crossing or toll gates on motorway it is in fact highly preferable to avoid splitting road (as it introduces a lot of extra effort AND geometries are quite wonky and poorly representing reality)
I propose to replace “fine” with “preferable”
Where the divided ways are parallel (often, but not always) their nodes should be positioned so that they are adjacent to each other.
is it really important or useful to bother with aligning nodes in pairs?
OpenStreetMap is not paired like this advise page demands, but due to sufficient node density it causes no problems whatosever
Re: #1. Strengthening the recommendation to not map divided highways with separate ways around traffic islands
I oppose changing the article to recommend against mapping at higher levels of detail.
I support minor updates to the wording, such as:
Note that in cases where physical separation is extremely short (for example, a traffic island at a crossing) it is generally considered acceptable to keep the briefly-divided highway represented as a single way. Refer to {{Tag|crossing:island}} for more information, including examples of traffic islands mapped using both approaches.
Detailed, separately-mapped traffic islands are necessary for enabling certain accessibility-focused routing use cases. Here’s an example of one intersection I’ve mapped - the details mapped here simply cannot be completely captured by tags on single ways. (No, this is not specifically an example of a divided highway as you’re talking about, but the same principle applies: Mapping at a low level of detail is fine, and mapping at a higher level of detail is even better!)
Re: #2. Removing the instructions around “pairing” nodes of dual carriageways
I oppose the complete removal, but support updating the wording to suggest instead of prescribe, such as:
Where the divided ways are parallel, some mappers prefer to align the nodes of the two ways in pairs. This is neither necessary nor incorrect.
Maybe that section could also link to a tutorial that shows how to easily make those parallel ways with paired nodes? I can make one, if you have a suggestion for where one should live. Here’s the images I created to be used, showing step-by-step usage of CreateCirclArc and Parallel:
Extra effort is a good reason not to absolutely strictly require short parallel ways – not to consider a single way to be an urgent error. However, it isn’t really an argument against mapping parallel ways. The very act of mapping requires lots of extra effort compared to not mapping.
Granted, the physical separation principle can sometimes result in seemingly absurd geometries, especially when a certain mapper () micromaps the contents of the median to prove a point. Just outside the Stanford University campus, Junipero Serra Boulevard used to have a continuous center turn lane down the middle. Wherever there’s a center turn lane, we must map a single carriageway, because cars can enter and leave the lane at any arbitrary point, just like on a multi-lane road. However, this lane was later interrupted by a series of short landscaped medians for traffic calming and beautification.
All I can say is that it’s accurate, albeit unfortunate. A renderer that needs a more realistic representation of the street could choose to draw streets thicker, obscuring the alternating effect, or something could smooth out the street’s overall geometry in postprocessing. After all, we tell data consumers to do postprocessing if they want to model vehicle movements and dislike that our link ways start too close to the gore. Otherwise, if we remap this street as a single carriageway continuously, then the features inside the medians would have an ambiguous relationship to the street.
Do you agree that in cases multiple ways make things worse?
but it is not doing this! It is against some very pedantic node matching and solving it by increasing detail, making such elaborate and time-consuming node placing unneded.
What you think about such geometries? Yes, it is less pedantic about centerlines but does not have sharp turns that misrepresent on-the-ground situation.
Do you mean that Junipero Serra Boulevard should be modeled as it is currently but with gentler angles? Sure, no problem. You can even smooth them into curves if you like, as some corporate mapping teams like to do. But I don’t really see a meaningful difference. The existing angles on this street aren’t that extreme compared to some I’ve seen at intersections where a median begins or ends. Your example on Zarzecze does have unnecessarily steep angles though.
When you say that the short dual carriageways “misrepresent the on-the-ground situation”, I would say the opposite is true. But really it’s a tradeoff: do we care more about topological precision or modeling realistic vehicle movements? In general, we’ve been prioritizing the former with only minor accommodations for the latter. If Junipero Serra Boulevard had had a median interrupted by conventional left turn lanes, I would’ve kept the dual carriageways straight through. It’s only due to the center turn lanes that I find it necessary to contort the street in this manner.
It’s really only the rendering that falls apart, but renderers frequently need to either perform some amount of postprocessing or paper over any unintuitive details. “Collapsing” the short dual carriageways would be a basic example of cartographic generalization. The fact that some popular renderers don’t perform so much generalization shouldn’t lead us to codify practices that prevent slightly more sophisticated renderers from performing the sort of generalization that’s commonplace outside of the OSM world.
This is a somewhat distinct case than the short medians in my earlier post, so I’ll address it separately. The fan-out before a toll plaza or border checkpoint often results in counterintuitive geometries if we follow the physical separation rule to a tee.
What most end users probably want in these situations is for each lane to be modeled as a parallel way from beginning to end – even far back when there isn’t even a lane change restriction. No amount of placement=* tagging can compensate for the atypical geometries of a fan-out, so a consolidated way loses a lot of information. On the other hand, modeling the lanes individually prevents us from associating the lanes with each other. Therefore, a common compromise is to split the lanes at the beginning of the lane change restriction, even though it’s just a painted line.
As a practical matter, most navigation systems have a fairly inflexible threshold beyond which the user is considered to have departed from the route, triggering a reroute. This usually works well, except along ferry lines and – surprise – at fan-outs. In principle, a triangular area:highway=* could give the software some additional tolerance in this case. But in plenty of other situations, there’s some extraneous protrusion of pavement that exists for no good reason, so it isn’t a perfect heuristic either.
Then there’s the issue of associating traffic congestion with the mapped ways. This is already an inexact science on a conventional street where the left turn lanes have a different traffic pattern than the through and right turn lanes, but it’s that much worse at toll plazas – where lane-level traffic data is that much more useful. Mapbox has given talks about this issue in the past, and will probably continue to do so until we come up with a less frustrating solution:
As mentioned, the same applies: Mapping all of the details of even this simple traffic island and navigation across it from a pedestrian perspective is not possible with a simple crossing:island=yes tag on a single way. It’s okay for someone to map it that way, and better if someone adds more detail via separating the highways, not worse!
No, I do not agree.
The quoted text refers to point #1 about whether or not to map divided highways as two ways, not to the part about paired nodes. I tried to make that clear with the section break horizontal line, but apologies if that wasn’t well-communicated.
Your suggestion to change “fine” to “preferable” would be adding a recommendation for mapping at a lower level of detail, which I do not support.
The question #1 is about changing the wording to recommend against mapping highways which are only briefly divided by a traffic island as two ways, and that is what I disagree with.
No, the way that those two in your image are mapped (without strictly paired nodes, such as those created by the use of the Parallel mode, but with enough nodes to cleanly render the curves) is perfectly fine.
I don’t think the existing two images on the Wiki are very helpful and don’t like the caption of the first one with unpaired nodes as “wrong” - to expect people to map perfectly paired nodes is ridiculous, especially since that’s not even possible with the most common editors.
Would these work as better examples for paired vs unpaired nodes, to be combined with an edit to the text indicating that the difference is mere preference, so long as both curves are detailed enough to accurately represent the curve?
I’d say as you, but there are people that are not satisfied with openstreetmap being mostly complete and in dire need of something to map. So that is what it looks like, when they get their go:
A 5m traffic island mapped as three separate areas, a road that does not exist on the ground and a road that crosses another one without a node at the intersection.
I gladly abstain from adding the missing node. Car routers just will have to get their smarts together and one of these days the can make sense of that: By just ignoring the mapping? While pedestrian routers will still pester their users with every single detail!
Mapping quality of a given location aside, I’d like to mention that it’s not just mapping for mapping’s sake - mapping at the higher level of detail can be the difference between “I know how I can get there safely” and “I don’t know if I can get there safely” for users such as blind/low-vision users and those in wheelchairs.
A simple highway=crossing+crossing:island=yes node is good - and the fact that more detailed representations are better when mapped well does not change that
It makes the data more difficult to interrogate and parse. It creates additional nodes/intersections that have to be implicitly calculated as a carriageway split. It creates phantom paths that routers use to create nonsensical turns
It makes the data harder to manage, because rather than a single node, you’ve got a connected web of crossings and ways.
It makes it harder to look at, because without knowing the specifics of why a carriageway is split most renderers will display a difficult to parse “blob.
If the crossing island is small, the crossing isn’t staggered and crossing is done in one manoeuvre, I usually map the crossing using a single crossing node and crossing:island=yes.
If the crossing is staggered and the crossing ways are mapped and connected to sidewalks, then I’ll split the carriageway around the island. It’s effectively two separate crossings which may have slightly different characteristics.
pedestrian_crossing) on the carriageway leaving the intersection. Routers may wish to assign different costs to these.
We already have dual_carriageway=yes for segments of highways with oneway=yes representing “real” dual carriageways. If we had something like dual_carriageway=crossing_island, car-centric renderers could choose not to show the results of nasty pedestrians spoiling the aesthetic of a nice clean road line.
It might also be worth thinking of something like dual_carriageway=roundabout_flare for another case where the carriageway is often split.
The same can be said of dual carriageways, sidewalks as ways, highway=traffic_signals at the stop line, and more. For that matter, cartographers used to get annoyed by OSM having too many little insignificant houses and ponds, but then someone micromapped the Berlin Zoo in stunning detail and people started to understand the advantages in lavishing attention on the world beyond what “normal” maps do.
The good news is that data consumers have had room for improvement. In the mainstream routers, phantom turns are not as common as they used to be, thanks to intelligent heuristics. Cartographic designers also have some options for papering over the weird, technically correct kinks in the road, in some cases without needing any major software improvements.
To give some perspective, we have a single set of highway=*_link tags for both freeway and expressway ramps and much more mundane slip lanes at intersections. Expressway-style ramps can sometimes occur on even highway=tertiary for silly historical reasons out of our control. These are very different kinds of features to a navigation system: different assumed speeds and potentially different guidance instructions. Routers use some combination of the link way’s length, its geometry, the classifications of the adjoining roads, and highway=motorway_junction to distinguish these two cases. Yes, ideally the link ways would be explicitly tagged, to eliminate the guesswork, but the guesswork works pretty well.
All the generalization of dual carriageways that I’ve seen was done by creating a second dataset, rather than running an algorithm on the dualized data. That’s why we don’t see it with OSM data.
Back in 2011, Stamen Terrain applied Skeletron directly to OSM data with some success. The main use case was avoiding redundant labels and shields along roads. I don’t know if that particular implementation would be suitable for linework, but would you rule out a polygon buffer and Voronoi diagram entirely?
(For linework, sometimes it’s enough to just make the roads much thinner so they look like a schematic diagram, or much fatter so they paper over any little island. What a lot of OSM maps have at high zoom levels is road widths that get the worst of both worlds.)
) micromaps the contents of the median to prove a point. Just outside the Stanford University campus, 
