The v1 path that all callers need is available by transforming PathV2 to
v1. The plan is to now gradually change callers to natively use PathV2
instead.
This lets us clean up some of the old pathfinding v1 code, removing some
duplicate code!
Also improve that debugger to show a different cost for each side of the
road. The cost to turn around and reach a building on the other side of
the road may be high, so this really makes the debugger more
understandable.
No behavioral change here; this is a trivial transformation. If a
directed road has any walkable lane, then there's exactly 1 of them. I
verified by manually checking paths and also seeing prebaked results
having zero diff.
signals using uber turn groups. #555
This was an old half-baked experiment for handling a cluster of traffic
signals. Since then, merging intersections (by manually tagging them in
OSM for now, maybe automatically in the future) has proven better.
Removing this old code in preparation for pathfinding v2.
always tiny; Dijkstra's is fine. It costs a bit of file size to store
it. The huge leeds map goes from 160MB to 157MB -- not crazy savings,
but something.
Also fix a slight bug with 92d3a890ea that
caused some pedestrians to uselessly visit a bus stop node while
routing. (southbank crashes a few hours in otherwise)
This is simpler to reason about, allows the penalty for entering a zone
or taking an unprotected turn to be expressed in terms of a time
penalty, and is a step towards adjusting bike/foot routing for elevation
data.
When we later add things like "safety/quietness" for cycling, maybe we
can switch to using a (time, quietness) tuple, and transform into a
single number with a linear combination parameterized by that agent's
preference for time/safety. This change is compatible with that future
idea.
There are behavior changes here, particularly for zones and unprotected
turns. No new maps start gridlocking, and in fact, Rainier starts
working again.
"rise / run" calculation used the trimmed road center-lines, which don't
match up with the elevation at each original intersection point.
Also handle infinity in the output and reduce the resolution of the
query from every 1m to every 5m.
Regenerate all maps due to the map format change. Try bringing in
elevation data for all of Seattle using the LIDAR source, since
the data quality assessed in eldang/elevation_lookups#12 seems to be
similar, and LIDAR is way faster than contours.
