Open dabreegster opened 3 years ago
Intersections with >4 legs are riskier. We may need to do more work on intersection merging to pick up all of these.
FYI - the "number of legs" metric also applies to cyclists.
the "number of legs" metric also applies to cyclists.
I still haven't sorted out which of these ideas should apply to pedestrians and which to cyclists, but this is a helpful clue -- thanks!
There's lots of ideas here; I'll probably start specifically with
Recording and displaying data for an individual walking/cycling trip. We could show "green/yellow/red" parts of the route, and maybe explain why we classified each segment that way when you mouseover.
I think there's a couple of broad approaches that we could take. One would be to devise our own classification metric as you've suggested here. Getting into our own classification system is interesting, but sounds like a big endeavor, and one more likely to be controversial - there's entire huge projects dedicated to the nuance of this kind of classification.
An alternative would be not to surface any purported notion of "overall risk", which I think a green/yellow/red implies, but instead to start by surfacing the raw underlying metrics.
For instance, my understanding of Seattle's safety analysis's approach, was that they classified discrete events and counted them.
This person crossed a wide road 3 times and travelled through 2 intersections which had more than 4 legs.
So, a potential design solution might be:
In the same way we have an aggregate "trip duration" metric, we'd have a "wide road crossings" count and a "many-legged intersection crossings" count. You could compare these before and after.
For individual trips, maybe we annotate their timeline with a badge at the time indicating when the event happened.
Potentially there'd be a "jump to this event" for the badge, similar to how you can currently "jump to beginning of trip" and "jump to end of trip"
To me, this still seems like a useful way of exploring potential safety related effects of changes to the infrastructure without overstating our case or expertise in what is "good / bad / ugly".
Another thought - if you are tied to the design of presenting an interface whose goal is to highlight an overall "this is a good road" / "this is a bad road", I think a less controversial way to achieve that would be to directly surface the metric from an established more comprehensive model, like: https://www.seattle.gov/transportation/projects-and-programs/safety-first/vision-zero/resources/bicycle-level-of-traffic-stress
there's entire huge projects dedicated to the nuance of this kind of classification directly surface the metric from an established more comprehensive model
Agreed -- I was hoping we could just implement the metrics that other established projects are using, like BNA. But I haven't looked into this in detail yet, so it might not be so clear-cut.
In the same way we have an aggregate "trip duration" metric, we'd have a "wide road crossings" count and a "many-legged intersection crossings" count. You could compare these before and after.
Counting individual events sounds good to me; it's easier to explain to users, and kind of easier to define metrics for -- no normalizing by trip length / duration or anything.
How' this revised initial plan sound: start measuring individual events (wide road crossing for pedestrians, many-legged intersection crossing for bikes+peds, car-wants-to-overtake-bike for bikes), display them for individual trips, and show counts for aggregate dashboards.
How' this revised initial plan sound: start measuring individual events (wide road crossing for pedestrians, many-legged intersection crossing for bikes+peds, car-wants-to-overtake-bike for bikes), display them for individual trips, and show counts for aggregate dashboards.
I like that plan. :+1:
If anyone's interested in this:
1) Join the #cyclability
channel in OSM US Slack (https://openstreetmap.us/get-involved/slack/)
2) Check out https://od2net.org -- it's using a traffic stress definition from https://maps.bikeottawa.ca/lts/ in a routing engine very similar to Ungap the Map
It's time to measure more than just travel time! Here's an attempt to summarize a whole bunch of ideas from Slack, many from Michael:
One thing I'm puzzling over is how to use these cost functions. At first we're going to expose new metrics in the UI for individual agents and in aggregate, and as new layers on the map. But we could also use them to change the pathfinding cost functions, making people avoid "dangerous/loud" roads some amount. There's a tension there -- if everybody avoids them too much, we won't measure much "danger." Ideally we could calibrate the routing score function to match what people do in reality, and then take measurements.
There's lots of ideas here; I'll probably start specifically with 1) creating a new static map layer to rank road stressfulness, using one/multiple of the ideas for classification 2) Recording and displaying data for an individual walking/cycling trip. We could show "green/yellow/red" parts of the route, and maybe explain why we classified each segment that way when you mouseover. 3) Figuring out how to summarize this per-trip data in the trip table and the trip summary dashboards, alongside travel time.