times in the past, I've also tried doing this for other roads, but wound
up reverting for reasons only git remembers. But it seems like an
obvious win for bike paths; especially around Seattle, the ways are
split because of all of this raised curb data we're ignoring anyway.
Tested manually around Montlake.
Finally regenerating all data... Only Phinney breaks. One for tomorrow.
https://www.openstreetmap.org/changeset/105381427 mapping a turn lane is
the fix, preventing crazy U-turns using the service road. Not sure how I
missed that lane when looking here before. I made the edit to .osm
locally instead of grabbing fresh data for all of Seattle.
for people that leave one border, then re-enter a different one. #664
Alternative considered: insert a dummy remote trip between the two
borders. We used to do something like this at non-trivial code
complexity expense and having to explain the trip in the UI.
Regenerated all scenarios and prebaked data.
- Modest file size increase, as expected. Montlake scenario goes from
1.3MB to 1.5, downtown from 37MB to 43MB, all Seattle scenarios from
280MB to 327MB
- Eyeballed a few of the previously broken trips; they work now!
- Montlake goes from 3127 cancelled trips to just 302!
- No new gridlock, except in Rainier Valley -- disabling that for now
- I discovered missing validation in Poundbury for no-op trips between
the same building. I'll filter those out and restore prebaked results
there in a followup.
way, we have trip stats for people starting near the end of the day, and
we stop incorrectly showing failed trips when comparing.
Prebaked data: no change in size (245MB)
Montlake: 3135 "cancelled" trips -> 3127
Lakeslice: 6766 "cancelled" trips -> 6647
First time doing this in about a week. Trevor's new amenities should
show up, and lane widths are now adjusted. Haven't yet regenerated
the screenshot diff, because it's segfaulting (!!) for some reason. And
Seattle's popdat.bin and ALL of the scenarios are temporarily hosed. So
if you pull from git head and run the updater, expect some weirdness.
Working on fixing this.
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.
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.
Regenerate all maps. Gridlock-wise, Rainier and Poundbury broke, but
Wallingford started working again. Acceptable cost for a change this
useful; I'll work on fixing those maps later.
stop importing golf cart paths, even though they would be kind of
interesting to use for this proposal...
Interventions needed to keep lakeslice running, of course
Instead of just picking the intersectin closest to the origin or
destination, calculate the full path length, and take the one with the
shortest distance. This fixes some of the weird problems routing around
Broadmoor. Regenerate all prebaked data.
Also fix the original request for paths involving zones, so tracing it
later works.
