Consider using infinite parking for some proposals

[dabreegster]

The Broadmoor access proposal winds up with this overall trip time distribution:

There's a ton of noise from drivers -- some short trips get pretty long, and some long trips get pretty short. Much (but not all) of this is due to parking. Because it's so scarce, some drivers spend lots of time looking for parking, until it dominates their trip time.

If we use --infinite_parking both for the baseline results and the edits, the results look more understandable: There are still some driving trips that're dramatically affected: But way less. I'll also dive into some of those to see why.

Parking scarcity and the tradeoffs of using street space for it are critical features of A/B Street, but they also require good data about the number of offstreet spots available per building and a good estimate on the total number of cars that need to park somewhere. We're making totally blind guesses about the first. The second is mostly a function of Soundcast, but since we don't distinguish car drivers and passengers, we might be trying to cram too many cars in. Any ideas for better off-street capacity estimates for Seattle specifically or in general?

And should we disable parking simulation for the purposes of the article? My experience in the area covered by the Arboretum map is that street parking is not hard to find, so it's pretty strange if our results are really sensitive to it.

[dabreegster]

There was a bug with infinite parking. Figuring out how to clean up the fix, but the results for drivers look way more expected -- the Broadmoor access edit with infinite parking basically doesn't affect trip times now:

[michaelkirk]

My understanding is that due to vastly undercounting offstreet parking, we'll get more realistic results with --infinite_parking, and that I should re-run the results / prebake with that option.

Is that right @dabreegster?

[dabreegster]

Correct. I started this work last week, then got bogged down trying to fix every last problem. (The "parking efficiency" layer is computed in a way that is often misleading -- the distance between a person and their car at any moment isn't useful to know; the distance from the next driving trip's start matters.)

I think we need to:

• decide how to mark a map or scenario as forcing infinite parking on
• prebake the results again
• sanity check what the outputs look like

I'm undecided where this bit flip should live. Either in the map or scenario will require rebuilding lots of files, so I don't want to change my mind in a few days. :) I think in the short term, I might hardcode it based on map name. I'll start something right now and hopefully send it by tonight.

[dabreegster]

As expected, being able to skip parking saves tons of time. This compares (no map edits, infinite parking) to the baseline of (no map edits, normal parking):

And the more relevant comparison, between (access broadmoor proposal, inf parking) and (no map edits, inf parking): Deselecting driving only modifies some of the short trips: Just to be sure what's going on there, the effects just on drivers:

And risk exposures:

I'll dig through some of the individual driving trips that got dramatically slower with the edits, but I think we should make this change and include it in the article. Then we don't have to justify the noise from bad data quality.

[michaelkirk]

And risk exposures:

Are those risk exposures comparing:

A: "Finite parking w/o Broadmoor edits" vs "Inifinite parking w/ Broadmoor edits" or B: "Infinite parking w/o Broadmoor edits" vs "Inifinite parking w/ Broadmoor edits"

Either is fine, but interesting that a few arterial crossings went up.

[dabreegster]

B: "Infinite parking w/o Broadmoor edits" vs "Inifinite parking w/ Broadmoor edits"

Indeed weird. I guess we don't have the trip table equivalent for finding example trips, so not sure what's happening.