Open dabreegster opened 3 years ago
Some great reading material on this:
Factors influencing pedestrian safety: a literature review http://content.tfl.gov.uk/factors-influencing-pedestrian-safety-literature-review.pdf
after this came:
Pedestrian Count Down and Traffic Signals http://content.tfl.gov.uk/PCaTS-Note-3-PCaTS-Trial-Results-Report.pdf
then: A Review of Pedestrian Walking Speeds. https://www.livingstreets.org.uk/media/1796/review-of-pedestrian-walking-speeds-report-v4b-280814-docx-2.pdf
in Section 8 Recommendations :) for pedestrian crossing speeds.
There is also a report on pedestrian gap acceptance when crossing either at a designated area (not in the invitation to cross period) or away from a designated crossing area.
My thoughts are that there is a pedestrian queue, which if empty is created and a pedestrian added. if it exists, a pedestrian is added. It should be a single queue and only needed for stop-signs, encompassing both sides of the road. When created it has a max wait time, which when expired allows the pedestrian to walk. I'd expect the wait time to be around 5-10 seconds. While crossing the queue has a lifetime, where pedestrians can be added, I'd expect this to be about 3-5 seconds (1/3 of crossing time), after which a new queue needs to be created and pedestrians added to it. Yes, it's a bit complex, but I think allows for traffic to flow better. It embodies the notion that when a pedestrian gets to an intersection they spend some time trying to decide if it is safe to cross, this is reduced if others are crossing, and allows for a clustering of pedestrians who will cross together.
Regarding speed: There seems to be several different waling speeds. First, there is a speed for each pedestrian, which as was mentioned above, it is a uniform value between a min and max. Second, there is a speed used to calculate the minimum crossing time, which is set at 1.4 m/sec, this is the CROSSWALK_PACE. Then there is a speed used in walking_cost(), where the speed is 1.34 m/sec. The walking_cost() may be used in routing, but I haven't chased it down completely.
@christopherkettell Thank you for the references! Once we can measure the gap at different crossings, these params will save us some tuning.
Relatedly, I'd like to add a region-dependent option to specify the priority between vehicles and pedestrians. In London my observation so far is that there are very few marked zebra crosswalks and vehicles have effective priority except when at signalized intersections. There are also crossing islands to think about...
Additionally, there are regions where crosswalks turn all lights red and allow for unrestricted (diagonal) crossing. Last I looked, there was no way to handle such things. I also recall looking for a way to add pedestrian bridges and tunnels, as well as escalators, elevators and ped walks, similar to what you see in airports or Las Vegas.
There's at least preliminary support for "all-walk" stages -- "edit entire signal" > "add an all-walk stage at the end." We'd need to generate turns for all of the diagonal movements in that case. @mdejean is overhauling walking turn code right now, we should wait on that.
There are a few big steps for pedestrian-only paths like escalators, tunnels, etc. First the ones that already exist in OSM need to be imported and modeled reasonably. There's lots of unsolved questions about how to render these, how to model shared bike/foot paths. Then if people are interested in drawing entirely new ones, #67. Lots of this work has been done when we switched to the new lane editor a while back, but building entirely new roads and intersections means we have to think pretty carefully about how to manage RoadID
s, efficiently update pathfinding contraction hierarchies, and serialize map edits.
Copying partly from #485:
Turn requests are only made when a pedestrian/vehicle is at the end of the queue, ready to start the turn. And vehicles can instantly start/stop. So that means that at a big road, a pedestrian might reach a crosswalk a moment before a vehicle gets to the end of the queue. Even once we have the notion of a crosswalk where pedestrians yield to cars, the pedestrian won't see any conflicting turns and will just immediately proceed. We should fix that (in a separate issue; just starting the write-up here). I think it's only slightly tricky -- the lead vehicle in a queue will call ahead to the intersection and make the request. If the turn has higher priority but the vehicle hasn't arrived yet, then we have to calculate the vehicle's ETA to the intersection and figure out if there would be a conflict. Actually, the lead vehicle can give the ETA when they first make the advanced request. Because they're the lead vehicle and they know their own speed, it should be easy to estimate... I guess the only case is if there's another vehicle doing the same turn that they're blocked behind. Should work out; the ETA is a best case.
And @BruceBrown has some ideas about batching together a few pedestrians to cross together.
Also we identified that
rand_ped_speed
shouldn't be a uniform distribution between 2 and 3mph; most people are closer to 3mph.