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
- Procedurally generate houses there, so the automatic travel demand
model doesn't produce totally silly patterns.
- Disable parking
- Allow vehicles to enter the intersection even when it looks like they
might get stuck; this lets the default scenario complete without
gridlock.
- Prebake the scenario, so a researcher can make edits and use all of
the A/B testing data viz.
The home-to-work scenario produces laughably bogus patterns... everyone
working at Bank Sepah.
any trips snap successfully to buildings, so we wind up with 0-trip
people that break some UI logic.
Reimported all actdev scenarios. Hopefully there weren't any cases like
this in the Seattle data, but I'll do a full regeneration later tonight
anyway...
The deadend trimming is too enthusiastic, getting rid of some unsnapped
cycleways and things connecting to the map border. Will iterate on it
this week; net benefit for now.
dramatically improve time to import and edit maps.
The fix helps all maps that use extremely high edge weights to prevent
people from cutting through private roads. There may be a more robust
fast_paths fix later, but I want to reap the benefits for tomorrow's
release.
The dramatic numbers:
- importing huge_seattle: 893s down to 108s
- editing huge_seattle: 102s down to 19s
Query speeds didn't appear to substantially change.
lane that they're stuck behind them. Only record a risk exposure event
the first time, but let passing happen anywhere. #382
Also add scenario name to PrebakeSummary, to disambiguate the Poundbury
results.
fixes a very dramatic problem in the Green Lake map.
Regenerating everything...
Also added total trip time to the prebaked summary, to get a quick sense
if a change net helps or hurts and have a record in version control.
- handle when the equiv_pos of a driveway gets too close to the edge of
another lane
- make the updater workflow handle files from S3 that're a bit older
- remove pathfinding_avoiding_roads
- strip out old vehicle capping from map edit JSON, then fix up
proposals
- delete old capping API example
- temporarily give up on phinney; it starts gridlocking
- add broadmoor proposal link in-game
