Accomplishing this through RoutingParams, rather than actually editing
the map. I don't want to commit to a map model representation of modal
filters and actually edit the map until we think through diagonal
filters. This effectively revives pathfind_avoiding_roads from the old
congestion capping experiment, but organized better.
- Use the new blockfinder to initially classify neighborhoods
- Calculate cells within a neighborhood, and update them based on road
filters
- For the moment, remove the tool that shows example rat runs
easily work with perimeters and only transform to blocks when we need to
last minute. As a happy side effect, it vastly speeds up blockfinding --
the slowdown was attempting to mangle geometry for the huge broken
perimeters near boundaries!
Also improve the incremental merge debug UI
skip them.
This partly works around a bug loading remote edits from r/seattlebike.
The workaround isn't great, because the edits there are uncompressed --
there are multiple commands modifying the same road. The workaround will
ignore all but the first version.
Move proposal management from explore to edit pane
Co-authored-by: Michael Kirk <michael.code@endoftheworl.de>
Co-authored-by: Michael Kirk <michael.code@endoftheworl.de>
To avoid needing 3 copies of the proposal for different splits of the
map, make loading edits "permissive" (filtering out unknown roads) when
loading from proposals.
The file mgmt and waypoints are part of the "trip"
The toggles and details are part of the route. I considered combining
the toggle section into the "route details" section but... decided
against it to delineate "input" from "output". I could be persuaded to
keep iterating on this...
* reorder tabs: plan trip before adding lanes
This order of tasks should be more logical for most people.
* Copy tweaks
"trip" is better than "route" since you don't pick the route, only the
start/end points. The route is inferred based on the available roads.
* Smaller elevation plot
it was much wider than any other UI element, meaning the column
dramatically jumps sizes when switching to this tab.
* better align line-plot x-axis
* Avoid jittering UI while switching through tabs.
* fixup! Avoid jittering UI while switching through tabs.
* fixup! Copy tweaks
* fixup! reorder tabs: plan trip before adding lanes
* fixup! Copy tweaks
to further organize them by purpose, but for the moment, two problems:
1) the city picker UI is getting way too crowded
2) on native, the initial download is up to 145MB
Removing:
- the 3 Aurora maps and Green Lake, added for the ARC workshop, but no
longer the most active of collaborations
- Ballard is now subsumed by central Seattle -- the only advantage would
be keeping its full scenario of walking and transit trips, but the
simulation is horribly gridlocked there anyway
- the Rainier Valley map, originally meant for an SNG traffic light
timing study
- the larger udistrict map
Change the styling for edited bike network roads -- just use bright cyan, not a texture on top of the different greens. Change route colors to not conflict with the cyan changed lanes. Adjust route waypoint colors too.
by squeezing some start-up performance of huge maps. #746
Shaving at least 1 second off quadtree initialization in huge_seattle
from this, no noticeable effects otherwise.
Previously, the undirected graph search would switch sides sporadically.
Now it sticks to one side.
Now we probably just need an option to also include the other direction,
to avoid having to sketch over Aurora twice.
Let the map be panned even when we're snapped to an intersection.
Previously it's super obnoxious to start drawing a route in a huge map.
Also I'd love to switch to the new World API and stop with this ad-hoc
logic, but slightly confused about how to do that here...
Also add a reset button, otherwise I just switch tabs to force a reset,
which is silly.
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...
The pattern is somewhat similar to how different components share a
Panel. The "outer-most" piece owns the World, calls into InputWaypoints
to fill out the World, and plumbs un-handled events to it.
Also handle a tricky low-level bug with ctx.normal_left_click() and
detecting drags vs clicks.
Now finally there's no buggy conflicts between dragging waypoints and
hovering on the alternate routes!
This one is the most complicated, and it's still not done, but it's not
any buggier than the ad-hoc implementation. I still need to figure out
how to merge the two worlds of waypoints and routes.
This one also required a large, but mechanical, refactor to lift
ToggleZoomed and the concept of unzoomed/zoomed from map_gui to
widgetry.
- 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.
