When I first spotted it a few years ago, a mapper had represented the crossing vehicle movements as crisscrossing link ways while maintaining the turn lane as part of the main roadway. It produced misleading results in renderers and routers.
I untangled the mess by strictly applying the “physical separation principle”: separate ways if and only if there is physical separation. There was still a catch. If you change into the right turn lane, you have to turn right into Calvary Way, but if you merge into that same lane from the off-ramp, you can continue past that street and change into the through lanes. None of this was enforced by physical barriers, so I couldn’t express this using separate geometries. Turn restriction relations can’t distinguish between lanes, so I had to resort to a connectivity relation.
That was a satisfying result, until I noticed the other day that the county has reconfigured this interchange as part of a road diet. The quick build project only added painted road markings, no physical barriers. Instead of weaving in and out of the turn lane, traffic from the off-ramp now crosses the turn lane, briefly continuing as a virtual ramp. A new bike lane toggles between the main road and this virtual ramp.
I’m bummed to lose a clear counterexample of the Kreuz Köln-Sud solution and an interesting connectivity relation. But in return, we’ve gained yet another example of how tags on a single way are inadequate to express topology or geometry.
Amid all the complexity, I may have missed some obvious tags related to pedestrian or cycling infrastructure, so I’d appreciate some help with that.
I feel like you could go farther on this. I’m personally OK with mapping flush medians as medians, since that’s how they should be treated in practice when driving/cycling anyway (and thus the bike lane should be separated out where it is separated by flush medians).
By flush median, do you mean the areas set off by diagonal painted lines between the traffic lanes and bike lanes? I did consider extending the separate cycleway for consistency and also mapping the eastbound lane separately, but it becomes a rabbit hole pretty quickly farther away from this interchange. In that case, I’d probably also want to map the markings themselves to explicitly distinguish this situation from one involving concrete medians (whether nearly flush or more raised). San José has some quick build medians that consist of nothing more than asphalt covered in beige paint that always remind me of the mimics=* key.
Correct. Generally speaking, when an enclosed area has slashes across it, that’s supposed to be treated the same as a raised median (not usable as a lane, not allowed to turn across it or park on it). These areas are not guaranteed to be free of obstruction, either, and commonly contain street furniture at least seasonally (allowing for rapid removal for street festivals, parades, snow removal, etc. in more organized places; as well as being favored in places that tend to plan traffic control based on “throw things at the wall until it sticks” elsewhere).
Not MUTCD-“approved”, but a variation on the same theme.
I had always stated that painted traffic islands should be treated same as ones with a kerb and even if initially this causes more geometry, its tagging is far clearer. Additionally to that it is often rendered better.
This solves the issue of no tagging of separating traffic islands, its width and type between the tagged lanes.
Like it is important to know that the cycleway lane is beyond a wide separating painted island, but since this can’t be tagged? It’s likelly better to map it separatelly and then you can actually map the “crossings” and their length
Anyway, keeping it short, i congratulate those street paintings ;) Took your official long enough, but maybe they’re going to grow up to even better design in the future ;)
The physical separation principle really is about topology. But in the absence of traditional GIS layers, our topological graph has to accommodate a variety of coexisting modes of transportation and even topics beyond transportation. I would not reduce it to a question of where a driver of a passenger car can turn. That would be counterfactual in many cases involving barriers. Parallel ways would be appropriate even if a barrier only briefly splits two lanes going in the same direction or separates opposing traffic going under a bridge, or in order to map a pedestrian crossover island.
I can sort of relate to the awkwardness in the other thread. San Francisco’s Market Street has been a slow-motion edit war for years due to transit boarding islands flanked by traffic lanes. Every time I fix broken routing around that street, someone discovers another exciting new topological detail requiring even weirder geometry, or they misunderstand what they see in aerial imagery and flatten the whole thing into the pre-2010 traffic pattern.
I’m not so quick to give up on the physical separation principle. It’s a rule of thumb. No one is completely consistent about it. But it’s still a goal to strive for if we insist that the “Street” in OpenStreetMap isn’t a celebration of carbrainedness. I tend to only set it aside for inherent tradeoffs, when a simpler representation cannot fully express the reality on the ground or makes it impossible to distinguish between obviously different situations. If we figure out how to convincingly express all the geometric details in the original post while sticking to the physical separation principle, I would gladly revisit that interchange.
In particular, I would not bend the physical separation principle solely based on confusing guidance instructions. Guidance instructions are an art form – presentational, a kind of rendering. There’s always room for improvement, even with the data as it is.
and wondered, was there some motivation in the early days of OSM to save on vectors. Like each additional meter of vector was costing big money or something?
In general, the cost of a byte of storage per year[1] has gone down consistently[2] over the past 5 decades. So the general pressure to be mindful of how much storage you’re using has also gone down.
[1]: Yes, you must measure storage cost per unit of time.
[2]: There have been occasional spikes, and we haven’t yet seen the impact of a war targeting computer storage manufacturing.
Over OSM’s entire history, mappers have tried to justify various tagging methods by citing space concerns, but I think the fears over size have always been overblown. The planet is big and so is our database. Avoiding dual carriageways and separate sidewalk ways would have negligible impact on any consumption of OSM data, with the possible exception of loading certain queries in Overpass turbo.
In the early days, there were other reasons to prefer overloading the street centerline with parallel information or connecting it to landuse areas. No one had access to high-resolution aerial imagery or street-level imagery yet. Most people mapped at a lower zoom level than is common today. In any region that was starting out from scratch, rather than importing a complete basemap dataset, street centerlines were the highest mapping priority. We hung everything else off of that scaffolding. No one was using OSM for car navigation, let alone other forms of transportation.
What a difference a decade makes! Today many regions have amazing imagery by comparison. Mappers focus on a variety of things besides streets and are keenly aware that navigation systems use their mapping. We have these modeling debates and it’s almost like they don’t matter, because the map keeps humming along regardless.
