Also has the happy side effect of preventing modal filters from being
put on roads that lead to no-car roads (which're effectively dead-ends
for cars).
Regenerate everything
preparation for modifying them in the LTN tool.
Regenerated everything. This had some effects on overlapping road
shrinking, mostly positive. Screenshot diffs all changed, since I
switched laptops again.
First time regenerating everything on another laptop; there may be some
weird changes unrelated to stuff here (like montlake prebaked data?),
but nothing that seems problematic
There were 3 manual steps here:
1) Tag sidewalk=left,right,both along many one-way streets in OSM where
the inferred value was very wrong, and causing a large difference
from smp_sidewalk_widening
2) Clear out smp_sidewalk_basemap, broken by OSM ID changes. This has
never actually (and still does not) contain real baseline sidewalk
widths, but still might eventually.
3) Manually update smp_sidewalk_widening, broken by OSM ID changes.
The simulation results with the proposed edits now don't cause as many
spurious route changes.
The main reason is to unblock osm2lanes cutover by avoiding
https://github.com/a-b-street/osm2lanes/issues/153. A secondary reason
is to pull in fixes in SLU for #818.
But of course grabbing fresh data wasn't straightforward:
- Need to collapse small junction=circular ways just like roundabouts,
or else Montlake starts gridlocking. And so actually, regenerating all
maps, in case any happen to use this.
- Had to update a bunch of proposals since OSM IDs changed. I just used
the automatic repairs with some edits filtered out. Fixing edits
really is quite tedious when IDs change; we need something more
robust. (Just give up, describe geometry, and always snap to the best
match?)
- Had to update the one baked-in traffic signal for similar OSM ID
reasons, with similar hassle.
limiting how long a crowd can enter a crosswalk. #517
Removing Tehran from prebaking; it starts gridlocking. I didn't
investigate why; making SMP realistic unfortunately takes priority right
now.
We need this because we have a data source for SMP that we can use with
extra attribution, but not upload to OSM.
This whole commit is gross hacks; going forward, we need a proper
process for upstreaming stuff in OSM.
by chance in #870.
A vehicle exits a driveway and blocks a lane on its way out. When we try
to clear the static blockage, the queue calculation recurses to resolve
distances on the queue where that vehicle is entering. But since we
temporarily don't have the car in the list of cars (for the borrow
checker), it was crashing.
One of those "2 hours to figure out, 30 seconds to fix" bugs.
Transit stop IDs previously were tied to LaneIDs, but those can easily
change with edits to the number of lanes on a road. We still may need to
re-snap transit stops (if the driving position or sidewalk changes), but
this prevents one more common type of problem.
This requires regenerating everything, since it's a binary schema
change...
And clean up some other things that RDP does better.
Fallout from regenerating everything:
- Enfield borough crashed, so removed it
- All UK scenarios are now much bigger, due to the changes in #853 being
picked up
- Poundbury gridlocks now due to that
too far, by not trying to trace near railways or cycle-only
bridges/tunnels. This is an imperfect heuristic, but it makes
significant progress in most maps.
intermediate results can't be turned into a polygon. It'll break
something later. #841
There's a particular bug where a perimeter can be turned into a polygon,
but after collapsing internal dead-ends, it can't.
If we don't do this, the LTN select boundary UI crashes, and reasoning
about block -> neighborhood mappings gets very hairy. I'd like to
address all the root causes of failing to make a polygon, but until
then...
TRADE-OFF: it _really_ slows down the select boundary UI.
along the perimeter of broken intersections.
There are cases where intersection geometry is a little bit broken,
jutting out a bit and touching a road. It's more robust to still produce
a reasonably shaped block in these cases, instead of totally give up.
Visual inspection and the goldenfile VASTLY improved!
1 lane (usually a cycleway or footway). This correctly produces a few
more blocks in some maps -- as the goldenfile diff (and manual
verificaton) shows!
Also allow jumping from LTN browse to debug mode, to conveniently work
on blockfinding problems.
