it as part of the Map. #852
This has an immediate use in the LTN rat run calculation -- share the
pathfinder across threads, avoid massive logspam.
There's a much larger refactor in another branch, but just starting with
this.
OSM and other raw input into and store, before later converting to a
Map.
Why?
- build-time performance: while iterating on geometry problems, map_editor in release mode took 33s to build before, 11s now that the crate is split
- better layering: operations on a RawMap are becoming increasingly distinct from later transformations on the bigger map model
- this helps tease apart the dependencies of the intersection polygon algorithm for #846
- this will make it simpler to cutover to osm2lanes for https://github.com/a-b-street/osm2lanes/issues/71
There's further reorganization in raw_map and map_model that'll follow,
but the main work is done here.
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...
Back in #819, I broke things by creating the sidewalk+transit graph
before transit routes had been set up. This causes immediate crashing
when editing the 2 maps with transit (Arboretum and SF).
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.
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!
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.
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
I have another branch that handles roads without sidewalks on one side
-- it helps in some cases, but regresses in others, so not merging it
yet. But taking a smaller step and bringing in some stricter common
endpoint logic from there.
Bringing in some useful intermediate changes
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.
- Don't allow filtering them
- Don't cross them when calculating cell connectivity
- Create special green cells for them, and don't count towards the
disconnected warning
Straight turns and u turns where the angle of the turn is approx 0/180
have control points placed in an (approximate) 1:2 rectangle (u turn)
or a trapezoid (straight/offset/lane change turn). Other turns have
control points located 2/3 from the intersection of the from/to lane
centers, which is equivalent to a quadratic bezier with the control
point at the intersection.
