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.
Change get_next_turns_and_lanes (unused) to not take intersection, then fix uses of get_turns_from for sidewalks to use it
Add get_next_turns_and_lanes_for and use for floodfill
Don't create duplicate crosswalks in edit_movement
Remove other_crosswalk_ids and switch to make_walking_turns_v2
Allow make_shared_sidewalk_corner and make_crosswalks to work in either direction with a point order check
Don't skip rendering some corners since they're no longer duplicated
Draw sidewalk corners the same regardless of lane direction with a point order check
Only make one crosswalk at dead ends and degenerate intersections
Make footways only get sharedsidewalkcorner turns
Don't panic on bad sharedsidewalkcorner geometry
* Also implement ContraflowMovement for pathfinder v2
* Change uses of Turn to Turn | ContraflowTurn
* Reverse contraflowturn geometry when tracing pathstep
* Don't start or end a path in a ContraflowTurn either
