- Stop importing rail in Tempe. Not simulating anything on it yet, and it complicates gridlock. #672
- Update the GMNS timing.csv import based on slight format change. #626
running out on my current machine. Fixes#671.
Finally regenerate screenshots for the first time in ages... just
blindly accepting everything, because the slightly different screen size
means everything was slightly shifted down.
count incoming roads when figuring out if an intersection is degenerate.
Also make link roads (on/off ramps) lower priority than the main part of
the road.
Regenerated everything.
(and fixing up the cloud scripts)
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.
So far, just call it for Seattle maps. Store the data sources in S3.
Note this'll only run on my machine right now, unless you also build the
Docker image locally. Failures in elevation should be skipped for now.
Before: time starts when the vehicle reaches the front of the queue and
first requests their turn
After: time starts when the vehicle first becomes blocked on the queue
leading to the intersection.
Regenerate prebaked data.
wind up looping back on themselves in a nonsensical way, causing
vehicles to visually glitch when moving through.
This was started in 081819d86b, but it
used to gridlock 2 maps. All the recent roundabout fixes seems to have
resolved those! And adjusting offstreet parking for two maps.
But wallingford does regress; plunging forward for now.
scenarios, so we can run A/B tests with map edits. cyipt/actdev#114
To fix it up, I hand-timed
https://www.openstreetmap.org/node/2124133019, which could have smarter
heuristics as a button-operated half-signal in the future. And allowed
blocking-the-box on some small intersections near that area.
1) If a car is blocked by a conflicting turn and is part of a cycle,
wake up the car blocking it. In some cases, this wakes it up faster
and unsticks things. Otherwise, it just wastes a little bit of time.
2) If a car is part of a cycle, allow blocking-the-box.
3) Continue sorting people at a stop sign by the time they've been
waiting. But for cars "overflowing" their current lane, move them to
the front of this ordering. It unsticks one particular situation.
4) Fix wakeup_waiting entirely. Before, it was waking up protected turns
before permitted, but otherwise the ordering was arbitrary. Now actually
respect stop sign ordering. I expect this to improve many other
situations than the one I was checking.
This was all motivated by one particular roundabout in Poundbury. It
doesn't solve gridlock there, but it gets past a major blockage.
If a study area exists for the map, make a copy of the base/active
scenarios with the background traffic mixed in. Also remove people
living in the site, since they're redundant.
Ran it like this: for city in `ls data/system/gb/`; do ./import.sh
--scenario --city=gb/$city || break; done
attention to which intersection is being destroyed. Fixes#527 --
montlake and phinney both look correct now.
Regenerating everything. Actually, Phinney now runs, so adding a 4th
prebaked map!!! But Rainier regressed -- there's an issue with the
signal heuristics that's now a problem; I'll fix later.
I experimented on the Rainier Valley map, which recently started
gridlocking due to too many cars doing this, to tune the value. Got it
running again! The two other maps keep running, with some trips on
average getting a little slower.
Added an extra step to classify service roads as running through a
parking lot, to prevent them from being treated as regular roads.
Had to fix up a few prebaked traffic signals. lakeslice falls back into
gridlock; will fix separately -- too much effort behind this change to
stop.
be more careful with nodes representing uber-turns. Even if that vehicle
type doesn't use an uber-turn, we still need to force the nodes to exist
and match up between input graphs.
Although this really only fixes gb/charleville_mezieres/secteur4, it
potentially affects all maps, because the node map changes. So
regenerate everything...
City names are now disambiguated by a two-letter country code. This
commit handles almost everything needed to make this transition. Main
next steps are fixing up map edits automatically and making the city
picker UI understand the extra level of hierarchy.
A little bit of fallout: lakeslice gridlocks again; this regression is
actually from the recent traffic signal changes, but I'm just now
regenerating everything. Will fix soon.
use the site name as the city, instead of picking the "closest" major
city. This is introducing too much friction in automation.
cyipt/actdev#65
There will be a few awkward results -- cambridge gets renamed, and lcid
gets disassociated from leeds. Worth it for now.
source to augment the ones in OSM. For
https://github.com/cyipt/actdev/issues/53 -- sometimes the buildings
just haven't been mapped in OSM yet, other times the buildings are part
of a future development site. In either case, we can procedurally
generate some houses, so this is a way to include them in the map.
Start doing this for Chapelford. But first, adjust the generated house
sizes -- they were WAY too tiny.
Also prep for [rebuild] [release]
The roads that cross the light rail tracks wind up gridlocking horribly.
For this case study, we actually just care about Rainier Ave.
The scenario still gridlocks, but due to tiny traffic circles breaking.
Going to try automatically converting those to a single node.
to match.
Originally these were introduced to deal with merging intersections
between dual carriageways. But inadvertently, lots of left turns got
reclassified as u-turns. That's caused various headaches, most recently
the lakeslice gridlock. That's fixed again!
Fix a bug with the previous commit (lanes=1 on a two-way). Now regenerate.
... Unfortunately lakeslice now gridlocks due to a turn generation bug.
Temporarily removing the prebaked results there so I can push these last
few changes through. Will resolve this before the next release.
The Xi'an map isn't being regularly used, and it has some issues
(boundary is too large, OSM is missing buildings in most of the area).
The zcool font enables Chinese characters to render, but costs 6MB in
the binary files, slowing down wasm loading time. Eventually, we can
support async loading fonts and passing them to widgetry when loading a
map requiring them. For now, cutting down wasm size is a bigger
priority.
game wasm from 18MB to 12MB. Not bad!
Also give living_streets in Krakow shoulders, so foot routing works
better there.
Now regenerate everything. Actually messes up routing for Trumpington;
71 cancelled trips up to 101. And have to intervene to keep lakeslice
not gridlocking, as usual.
For the moment, this is the simplest way to allow foot traffic. This
breaks down in places like
https://www.openstreetmap.org/way/49207928, where the road gets an
inferred sidewalk and the separate cycleway on each side is
bidirectional with shoulders on each side.
Down to 71 cancelled trips in the baseline for cyipt/actdev#32.
geometry), don't generate crosswalks or stop signs. In reality, these
usually represent the middle of a complicatd intersection. Ideally these
cases would be merged into a single intersection, but before that's
feasible, at least improve some of the inferred things nearby. #457
This will make it easier to visually track the progress improving the
import. Originally London was added to have one left-hand driving map
under the test, but Cambridge works for that too, and it also includes
separate cycleways.
Also fix a crash when trying to draw very very tiny arrows.
Small adjustments to unzoomed rendering and stop sign placement.
Regenerate all maps because of the format change, but only Cambridge
changes. Since we're doing this anyway, also pull in leisure=garden.
