Improve crosswalk heuristics

[dabreegster]

Most of the time, A/B Street importer only uses sidewalk=left/right/both tag on the main roads, and automatically infers this value for roads without it. Separately mapped footpaths are ignored, unless inferred_sidewalks is false (#161).

But regardless, the connections between sidewalks are always inferred; footway=crossing is not used at all yet. I'd love to dedicate this bug to exploring ways of improving those inferred crosswalks. Here are some problems/ideas:

At 90th/Aurora, the merged intersection there is actually missing the east/west crosswalks that exist in real life. This bug forces lots of foot traffic to cross elsewhere on Aurora (where it's unlikely/dangerous). So a good first step here would be fixing the missing crosswalk here.

Along Aurora, especially at the north end of the bridge, we have 3-way intersections where a dual carriageway joins/forks. So maybe in these cases, when all 3 roads have the same name and 2 are oneway, prune them out. In reality, it's just the middle of the road at a section where a median (often just a small raised cement cut) starts or ends.

At 3-way intersections when the intersection polygon is very small, maybe we could arbitrarily prune out one of the parallel crosswalks.

(This is the Fremont bridge and Dexter). More generally, is there a way we can prune some of the crosswalks when they're very close to other crosswalks? So that network connectivity still works out, but there are less places to cross.

Two ideas here: Unsignalized crosswalks across roads with many lanes are unlikely. And crosswalks at stop sign intersections very close to traffic signals also seem unlikely.

Note crosswalks in abst represent every possible place a pedestrian can cross the road. There doesn't need to physically be anything painted there. Maybe we want to more explicitly model (and display) two types of crosswalks, where pedestrians have less priority at unmarked ones. And to that point, there's a very big issue in the traffic simulation with how turn requests are granted. 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.

[dabreegster]

At 90th/Aurora, the merged intersection there is actually missing the east/west crosswalks that exist in real life.

I tried enabling https://github.com/dabreegster/abstreet/blob/16124f3f3b0cc04c9959ce550f16a4b528d0e091/map_model/src/make/walking_turns.rs#L169, which correctly infers these crosswalks. Consequently, the phinney map makes it through the full day without gridlocking! This v2 function was started a while back, but it introduces some new bugs that have to be worked through before cutting over to it. Mainly removing duplicate crosswalks: I understand why this happens, but haven't found a clear way of preventing/filtering them out yet.