the infrastructure around and to keep the Arboretum map running
smoothly.
The immediate reason is that the new deduplicated crosswalk change
invalidates all of the old JSON files, because they contain extra
crosswalk movements. We could create a compatibility layer and deal with
this, but it seems like more trouble than it's worth.
And more generally, this traffic signal data getting out of sync when
OSM IDs change, or we start importing new footways or service roads, has
proven to be really unmaintainable. We also haven't prioritized running
simulations without gridlock in a while.
lakeslice gridlocks, because a traffic signal marked on a footway near
23rd and Judkins gets assigned to an alleyway. Worth fixing later.
And wallingford crashes the sim; I think more lane-changing bugs
exposed. It's kind of freeing to not worry about maintaining the
simulation right now...
I have some fuzzy vision of declaring all importer pieces as a dependency graph, with optional caching of some input, that would express this kind of thing better. But... in the meantime.
Now regenerating everything...
stop importing golf cart paths, even though they would be kind of
interesting to use for this proposal...
Interventions needed to keep lakeslice running, of course
scenarios, so we can run A/B tests with map edits. cyipt/actdev#114
To fix it up, I hand-timed
https://www.openstreetmap.org/node/2124133019, which could have smarter
heuristics as a button-operated half-signal in the future. And allowed
blocking-the-box on some small intersections near that area.
Added an extra step to classify service roads as running through a
parking lot, to prevent them from being treated as regular roads.
Had to fix up a few prebaked traffic signals. lakeslice falls back into
gridlock; will fix separately -- too much effort behind this change to
stop.
geometry), don't generate crosswalks or stop signs. In reality, these
usually represent the middle of a complicatd intersection. Ideally these
cases would be merged into a single intersection, but before that's
feasible, at least improve some of the inferred things nearby. #457
a hard error when they become out-of-date going forward.
Better heuristics make some of these unnecessary. And now the the JSON
files are in this repo, updating files manually when pulling down new
OSM data becomes less tedious.
Originally it was split out to organize a separate volunteer mapping
effort, but that never took off, and it's unlikely to happen. When we
have to occasionally update the prebaked signal data for some
intersections, it's unnecessary friction to update the other repo.
