Scenario and TripEndpoint have some methods defined on them that're
specific to sim. Do we rearrange these methods entirely or make some
kind of wrapper types?
crate, in preparation for future focus on travel demand models that
incorporate more per-person info.
Note: I'm also a bit tempted to try to further split sim into a
"high-level" layer that orchestrates spawning and different legs of a
trip, from the "low-level" layer that moves pedestrians and vehicles.
That could _possibly_ pave the way for someday using a different traffic
simulation backend with more realistic movement mechanics.
Step 1: just get the synthpop crate to build
Around 2x less paths to calculate.
Even though the deduplication throws away some info, the net effect for
measuring traffic volumes is practically equivalent, so it's a
worthwhile optimization. Used the new comparison UI to verify that!
- One batch for all neighborhoods
- One batch for all roads/intersections
- No pre-built tooltips
This all comes at more repetitive code. Need to make World generate some
stuff dynamically (#763)
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.
with only bike lanes and any walkable lane counts as a cycleway, for
rendering purposes. So if you change a road with sidewalks to only allow
bikes on the road, it shows up green in the unzoomed layer.
There's lots of nuance with footways that doesn't matter yet, because
we're mostly not importing those yet.
This was happening when trying to draw pedestrians sometimes.
Regenerate everything. Some maps/scenarios affected, but in tiny
imperceptible ways. No screenshot diff.
before/after. Road width is based on the baseline count, color is based
on the relative difference.
Lots of work needed, but this is probably a good way forward
Before, it was just a large 3 hour penalty for crossing a filter -- so
it shouldn't happen, but it was possible, and so some (but not all!) LTN
code had an extra paranoia step to filter out paths that crossed.
Now, actually make it impossible at the pathfinding layer.
Also, fix colors in the LTN pathfinding tool that were backwards
