Ha, no. It might work for car routers (and we know what we can do with cars, don’t we kids), but it doesn’t work for bike routers. The problem is that cycleways do often have silly sharp 45° turns. So if you implement intelligent heuristics to smooth out these phantom turns, you also generalise out a whole lot of genuine ones too. As ever, you really don’t want to see the amount of code cycle.travel has to cope with this stuff…
I’d say there’s a simple best practice guideline: don’t create fake geometries. A 45° angle when no one is making a 45° turn is a fake geometry.
highway=* ways model vehicle trajectories, but only sort of, because they also model topology. When does the topology become so pedantic that we can handwave it in service of clarity about vehicle trajectory? There isn’t one clear answer because OSM data serves a variety of use cases and modes of transportation simultaneously.
Reducing small islands to points can lose other information besides geometry. Mapbox apparently thought this channelizing island is for traffic calming purposes. Maybe others here would consider it a refuge island instead. But the most likely reason for the island is to physically enforce a pair of no left turn restrictions entering and exiting this school parking lot. traffic_calming=island misses the point and crossing:island=yes doesn’t tell the whole story.
I think we’ve previously established that common sense would have us bend the physical separation principle to accommodate a whole virtual traffic island, especially if the geometry is nonobvious or there’s some obstruction inside, no matter how small its footprint. This solitary stop sign has stood as my high water mark of absurdity for some time:
For me it’s an example where someone took “physical separation” too seriously. I’d be pretty confused seeing such ‘slalom’ road on my SatNav. Especially when in reality it’s just a completely straight road for the driver.
I did! Maybe I was gearing up to make a point on the forum five years later, or maybe I was planning to tell the city council that they’re being silly.
The physical separation principle is pretty much a consequence of mapping dual carriageways as parallel lines. If we had a traditional GIS concept of layers, maybe we’d map the road twice, once as lanes representing vehicle movement and a second time as a topology graph. As it is, we routinely make exceptions at -shaped intersections, so I could’ve gotten away with just tagging the presence of traffic islands all along. But few navigation systems understand the implications of turn:lanes:both_ways=*, let alone a stray traffic_calming=island somewhere along it.
By mapping dual carriageways, we assume that renderers would generalize the geometries as needed. That’s still an outstanding issue for most renderers. It’s been 15 years since @migurski wowed us by labeling dual carriageways along central reservations in Stamen Terrain using straight skeleton and route relations. Unfortunately, this approach has been mostly forgotten. Since then, we’ve become so accustomed to seeing labels alternate between both carriageways or leave one side unlabeled that we don’t expect any better of renderers. But it’s considered pretty sloppy outside of the OSM ecosystem.
Generalization would also make the archipelago on Junipero Serra Boulevard look a little less intimidating. It’s just one more special case.
Short of an algorithmic solution, here are some simpler workarounds that renderers can implement while they wait for us to radically reshape our data modeling conventions:
A hyperrealistic map could depict each three-lane segment three times as wide as a one-lane segment.
A more functional map that depicts streets as fixed-width lines could still make two-way roadways wider than one-way roadways.
I would support this change. I believe crossing:island=yes adds much more information than splitting the road into two, and adding 2x crossing. First of all, from a ‘law’ and ‘common sense’ perspective (at least in Poland, not sure about other jurisdiction) it is just one crossing, not two, so probably mapping one crossing split into two violates ‘One feature, one OSM element’ rule. - Albeit I know some users would disagree. Second of all, crossing:island=yes means that a pedestrian can stand in-between lanes, micromapping loses that information. It is also MUCH easier to interpret by data-consumers. It is also MUCH easier to maintain good quality in OSM then.
That’s completely wrong approach, for which the rule of ‘physical separation’ exists. How would you want to make a lane-aware navigation? How would you support changing lanes?
For clarity, I don’t prefer the “more complexity is more better" approach - I would quite like a “simple is preferable to complex” rule which would, in this case, support simplification of the island into a tag on a node with relevant features/attributes attached to it.
What I’m saying is that a consistent approach either way is preferable to the status quo.
This is the same issue we have already with separated sidewalks, and the best solution is to create “fake crossings" at any point where you might want to cross (or, in this case, change lanes). So e.g. where a road starts marking/signing that different lanes are going in different directions, you’d create a set of nodes and connect them with a way similar to crossing=unmarked but for lane changes.
Again, not something I’d prefer, but it would work at least as well as crossing roads work - and it would solve the absurd misrepresentation of the road geometry that we see above.
the tag describes a crossing of a footway or cycleway with a highway, and it doesn’t violate the rule you mention to have one element for each crossing of a carriageway.
Another way of putting it is that the same legal code probably also considers there to be only one street, but we map two parallel ways. Conversely, we usually map a single way even if legally there are two carriageways.
OSM’s goal is not to have the same number of highway=crossing nodes as there are legal crossings in local law. Otherwise the tag would become meaningless in jurisdictions where a legal crossing exists at any street corner regardless of infrastructure, let alone in jurisdictions where pedestrians can cross anywhere at all.
You are wrong then. Commonwealth laws disagree with you. Having a refuge island means it’s considered as 2 crossings, most relevant to the rules of Zebra Crossings.
2.1. The most micro is splitting out the footway=crossing to eg footway=traffic_island
2.2. Simply another crossing:island=* is needed for easy use
2.3. I don’t understand what difference exist for QA
That’s depending on how you view the data. crossing:island=yes is a pretty simplistic way to express all kind of possible traffic islands. Whether you need to go straight or in a zick-zack way. How large the island is. Also think about the kerb, tactile_paving,… surface of the traffic island. But for sure, you would be right from the car-routing perspective, though that’s not the only use case of OSM.
Over 10 years ago, I asked on the forum “what is the ideal level of detail for curves in OSM?”, using a small roundabout as an example. Having received answers ranging from “no limit” to “an editing application uses about 19 points for small circles”, I arrived at a rule of thumb of at least 20 points per circle (in addition to a max 3m offset for wider curves), which results in an angular resolution of about 18°, which I also use as a criterion for “smooth transitions” (not too jarring for the end user). So, yes, I prefer modeling as in this image.
Some mappers in my region (including some involved with Kaart and Apple) would have modeled this as completely divided from the eastern intersection and as a (still divided) “transition” further east, where there is no physical separation. I think this is incorrect, and when I find this sort of artificial division in the data, I remove it.
I don’t mind tapering out the ends of the island a bit more in this case. However, inevitably, topological accuracy sometimes leads to awkward geometries. There are cases where a cross street, like the the driveway you see in the lower-right corner of the photo, would be even closer to the end of the median. This would require either a steep angle or three ways forming a triangle that has no relation to the reality on the ground. (See also the debate about “pencil tips”.) So data consumers probably have to cope with edge cases one way or another.
Agreed. In this example in particular, you can drive down the center lane in either direction in order to join or leave the street. So it’s more than just a pedantic difference between a physical barrier and a road marking.
Pros: accurate representation of physical separation; simplicity/maintainability
Cons: sharp turn angles that are not close to the real turn angles (some routing systems use the angle to determine instructions such as “turn right” vs “turn sharp right” vs “turn slight right”; in this case, this would affect both vehicle and pedestrian routing instructions)
In this specific example, I would prioritize smoothing the angles on the main roads (east-west and vice versa) by moving the traffic lights on the east side a little further from the intersection and a little closer to the centerline (possibly sacrificing some of the other angles if necessary, as these tend to be less traveled), within certain precision limits (e.g., up to 3 m away from the absolute ideal position). The result is a thinner and longer pencil tip. As I generally map the sidewalks as tags when that’s sufficient (and separately only if necessary), in this case I would also have grouped the car and pedestrian traffic lights into a single traffic light in the center of the intersection with highway=traffic_signals + crossing=traffic_signals, allowing a little extra leeway to make those angles match reality even further. (I would only map crossing lights separately, as in this example, at a more complex intersection requiring separate pedestrian crossings and/or sidewalks. You can judge me if you want. This mixed approach to mapping pedestrian infrastructure can avoid recurring headaches in many cases in my area.) The idea is that neither mode of transport should be drastically affected by the mapping style; instead, within a limit of accuracy, I seek a balance that minimizes the worst issue for any of the modes involved in each case. At least in my area, I’ve found that both car-focused and pedestrian-focused mappers tend to tolerate this well, and to them there’s little gain in the effort of modifying the map to achieve an ideal geometry that exclusively benefits its own use case at the expense of others, so the data usually remains stable (this doesn’t stop them, however, from making new mappings expressing their own priorities to the detriment of other map users).
Cons: additional data complexity (a bit harder to maintain); extra route instructions that may seem weird to the user (e.g., “turn slightly right and then turn right” in some turns, such as south to east, or “turn right and then slightly right” from north to west).
Pros: the angles are mostly smooth, so the end result is visually more pleasing. Still, it can look strange in certain movements (e.g., a route drawn from south to north would still have a small deviation that could confuse a lay user).
Interestingly, this is the approach recommended by MapBox. I imagine this is because their business is providing rendered maps, so they prioritize visual quality over other uses of the map.
-shaped intersections, so I could’ve gotten away with just tagging the presence of traffic islands all along. But few navigation systems understand the implications of 
