-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Start handling highway=crossing nodes #247
Conversation
} | ||
} | ||
CrossingKind::Unmarked => { | ||
for polygon in draw_unmarked_crossing(self, intersection) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideas for rendering styles welcome, especially for unmarked crossings -- by definition it's quite unclear how to indicate them! Of course these are going to be region-dependent; I'm starting with something simple and we can add configurability later (along with region-specific lane colors, default widths)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably just a void with no road markings would suffice, unless there are regions where it’s normal for a centerline to continue uninterrupted past an unmarked crossing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tough to do today, because osm2streets doesn't know how to continue any road markings into the "intersection polygon" area that gets calculated. That's something @BudgieInWA was working on remedying by detecting "intersections" that're really just merges / forks. I'll keep it in mind as an idea, thank you!
if node.tags.is("highway", "crossing") || node.tags.is("railway", "crossing") { | ||
let kind = match node.tags.get("crossing").map(|x| x.as_str()) { | ||
Some("traffic_signals") => CrossingKind::Signalized, | ||
Some("uncontrolled" | "marked") => CrossingKind::Marked, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on my understanding of https://wiki.openstreetmap.org/wiki/Tag:highway=crossing?uselang=en
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Kind of. The history around crossing classification is quite muddled and quickly devolves into a blame game. Some mappers strongly believe uncontrolled
should mean marked/signposted/unsignalized. Others point out that, in some regions such as the UK and U.S., uncontrolled
was historically largely used on unmarked crossings, due to plain language in both dialects of English. I think it’s fair to say that the former faction is winning, but only because the latter has moved on to crossing:markings=*
and crossing:signals=*
. At this point, a new renderer or router would be better off supporting crossing:markings=*
and crossing:signals=*
, which are less ambiguous in practice and cover the unmarked/signalized case.
Looks amazing. Maybe in the future we could render those details for crossing nodes as well, similar to how Mapbox Streets renders them. |
This PR starts a fresh attempt to handle pedestrian crossings in osm2streets. Previously, I think @BudgieInWA and I have thought about these as movements/turns across an intersection, having some influence on stop lines, etc. This new approach is much simpler, exploiting the fact that we already have separate Intersection objects that exactly correspond to a
highway=crossing
node such as https://www.openstreetmap.org/node/2819230451. So all we have to do is plumb along some per-Intersection info and render it as markings.This approach makes sense only in the context of using separately mapped sidewalks (which is kind of the way things are going anyway). Looking at the image above, the idea of a larger "junction" that groups the big Intersection and all of the things around it starts to look a bit more clear. But going back to an old idea with Ben, let's first get the "one-to-one" OSM representation to be pretty good, then we can think about higher-level "views" on top of it.
This is a simple first step, some next steps are in #246. Comments welcome from anyone, particularly @andrewphilipsmith, @ginnyTheCat, @hungerburg (dredging up a-b-street/abstreet#795 -- no more inferred anything!), @SupaplexOSM. (I might merge quickly so osm2streets.org is updated for convenience, but happy for feedback whenever)