In this case, the lanes are physically separated for about 50 metres, however both lanes can be driven on by cars. It looks like this and has been mapped as so:
Ignoring for a moment that the lanes in one direction have been split, but not in the other…
The foremost issue I find with this mapping is that this is making OSM’s highway model creak, for very little practical gain. As mapped right now, only right turn is possible from the right lane, because left turn has been prohibited (makes sense, you can’t turn left from the right lane) and the way ends at the cross street. In reality, going straight from the right lane is legal and commonly done. It might be possible to amend the mapping by ending the right lane way at the main intersection node, but at cost of a “sharp right” being possibly instructed for a right turn. Meanwhile, the physical separation is of no practical importance, because there is no other way that can be possibly reached from one lane but not the other. Does it really warrant a separate way, wonky geometry, and two no-turns relations at each platform?
Does anyone find redeeming value in this kind of mapping, or can they be deleted?
Yes, that was kind of my point. It’s a tradeoff of how much effort it is to map it correctly, vs how much we care about the physical separation that changes nothing in practice.
Let me put the question another way - if no one else has time to fix the current (bad) mapping at the moment, should it be kept as is, or deleted?
Also considering that this has been mapped by Lyft and not an average user:
Have a discussion here incl. Lyft, come to a proposal and apply that.
Fore the time being, revert the changes.
I would say that separating the roads here is correct mapping since there is physical separation. I’ve seen this mapped as such elsewhere with light rail platforms in the middle of the street, such as in San Francisco: Way: Ocean Avenue (679075683) | OpenStreetMap .
If straight-through traffic from the right lane is permitted, I would suggest mapping the road as done here, with the roads coming together at the intersection, just like a typical dual-carriageway intersection, rather than one dead-ending.
That doesn’t seem like a problem to me, or rather, it seems like a GraphHopper problem. Maybe it isn’t properly condensing the intersection geometry. Notably, the other two routers on osm.org both instruct a normal “right” there rather than a “sharp right”. GraphHopper also incorrectly suggests a “sharp right” at a nearby typical intersection where a dual-carriageway switches to single-carriageway, while the Valhalla and OSRM suggest a normal “right”:
Meanwhile, at an actual sharp turn, all three suggest “sharp right”:
In any case, even if this weren’t a solved problem beside GraphHopper, IMO it would be Mistagging for the Router to omit the separation when it’s actually there just to optimize the routing instructions.
This is firstly an inconsistency problem. If it’s split on both sides of the intersection, the geometry should be less distorted. To further mitigate to even solve this, and minimize =tram crossed, you could play with placement= (it is unspecified now, and inaccurate when not centered)
The lanes=3 is missing lanes:forward= + lanes:backward=
Hi everyone, my name is Artsiom, and I am the OSM Curation Policy Lead at Lyft. Jarek, thank you for notifying us about the started discussion.
I apologize for the inconsistency in our edits, where different approaches were used in similar cases regarding highway class and road attributes. Upon closer examination, the approach suggested by willkmis seems more appropriate for mapping such cases, in our opinion. If there is agreement regarding this approach, we will adjust our edits accordingly. However, if any other approach on how to correctly map such cases is approved in this theme, we will revise our edits to align with the approved approach.
From the POV of a pedestrian / tram user, I think the split mapping makes a lot more sense than merging the two ways on either side of the platform, but (a) the way to the right of the tram stop should be extended past the intersection and merge smoothly with the main road and (b) the tram stop on the southwest side should be mapped the same way.
Doesn’t look far off from protected bike lane mapping where things merge/split from an unprotected, painted bicycle gutter style lane. It looks messy on the map because it’s messy on the ground. Toronto could fix the ground truth (and their own streetcar system) by kicking cars off the tracks (as is the case on East Burnside in Portland on the Burnside Mainline of the MAX, between 99th Avenue and Burnside and Ruby Junction Station; or the Westside Mainline in Hillsboro between Hatfield Terminal and Hospital Station).
Thank you. If you’re wanting to split roadways around streetcar platforms, then I agree that approaches shown by willkmis in post #7 and ToniE in post #4 would be best: making sure of proper lanes tagging including cycleway:left/right, merging the ways back into the intersection node, setting turn restrictions to prevent left turns from right lane way and prevent right turns from left lane way.
It’s not, though… Functionally, when driving, you drive straight on, and it’s little different from a solid line or a hatched area separating a left-turn lane that you’re not allowed to cross - and we don’t draw separate ways for that, at most tag a change:lanes=*. You stay in your lane and it doesn’t really bother you. When walking it doesn’t make a difference at an intersection. When boarding the streetcar, it’s a tradeoff between danger of standing on the platform next to left lane and danger of crossing lanes of traffic when boarding from curb.
OSM guideline is to use separate ways for any physical separation, but this kind of case is one of situations where the guideline is creaky. But if people really do want to strictly apply the guideline, at least do it well.
(People who are really keen can try to see how messy the situation is around Relation: 9441210 | OpenStreetMap with proximity of other intersections)
