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.
the infrastructure around and to keep the Arboretum map running
smoothly.
The immediate reason is that the new deduplicated crosswalk change
invalidates all of the old JSON files, because they contain extra
crosswalk movements. We could create a compatibility layer and deal with
this, but it seems like more trouble than it's worth.
And more generally, this traffic signal data getting out of sync when
OSM IDs change, or we start importing new footways or service roads, has
proven to be really unmaintainable. We also haven't prioritized running
simulations without gridlock in a while.
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
Overall results still not right, but getting closer. Some "rat-runs"
retained will only be in the neighborhood out of "necessity" -- they
should maybe be totally filtered out for the heatmap counts.
definition finds all entrances and exits to a neighborhood, grouped by
the name of the perimeter road they connect to. Then the shortest
driving path between every pair is found, and the results are sorted to
emphasize paths that spend most of the time inside the neighborhood.
This new version doesn't crash and seems to produce reasonable results
everywhere I've looked.
It doesn't yet pay attention to the modal filters people have created,
or summarize which roads are likely to be quiet or not.
