- choosing some building colors
- proper unzoomed road/intersection outlines
- adjusting curb color based on road rank (for arterials, it was the
same grey!)
The deadend trimming is too enthusiastic, getting rid of some unsnapped
cycleways and things connecting to the map border. Will iterate on it
this week; net benefit for now.
* Create new lane types to express different types of buffers for protected bike lanes. They're only created manually right now, to explore rendering.
* Update planter rendering
* Update planter - simplify
* fmt after merge
* Fixing up existing rendering
* Add curb buffer
* Adjust stripes
Co-authored-by: Robin Lovelace <rob00x@gmail.com>
intersection. This often happens with a group of 4 intersections (two
divided highways), and there may be many small segments embedded in the
middle for street car tracks and such.
Also bring in fresh OSM for Tempe, with one such intersection now
consolidated! #654, #672
- Grab fresh Seattle OSM, picking up https://www.openstreetmap.org/changeset/108071529
- Treat highway=footway, bicycle=dismount as a cyclepath, for now
- Treat service=driveway, bicycle=designated as a cyclepath
Since this requires regenerating all maps anyway, also include some
stuff to improve Aurora near Green Lake:
- stop making highway lanes super wide by default; they just make
divided highways overlap themselves
- filter out service roads with access=customers
But note the bridge from the Arboretum to Lynn is still disconnected,
because of detailed footway mapping that isn't tagged as
bike-accessible.
dramatically improve time to import and edit maps.
The fix helps all maps that use extremely high edge weights to prevent
people from cutting through private roads. There may be a more robust
fast_paths fix later, but I want to reap the benefits for tomorrow's
release.
The dramatic numbers:
- importing huge_seattle: 893s down to 108s
- editing huge_seattle: 102s down to 19s
Query speeds didn't appear to substantially change.
Several ways to output the results:
1) just write OSM tags to debug stuff, but keep the ways
2) write a KML file to visualize the perpendicular line checks
3) delete the cycleway and make it an attribute of roads instead
Many problems with the snapping heuristics, but enough progress to
commit disabled!
It maintains a JSON file of ways to merge that the importer also uses.
For maps fast to import, this is the nicest workflow. Unlike map_editor,
turns and trimmed roads can also be checked.
- initialization order
- reusing node ordering and applying edits
Importing, editing the map, and the basic scenario seem OK! --skip_ch
breaks, because of the lack of serialization
"engine" that just operates on raw usize IDs. Embed that enum in each of
the particular pathfinders. This way, we don't have to keep duplicating
logic to delegate requests, handle one-step edge cases, etc. And it also
sets us up to more easily try out other CH implementations like osm_ch,
without having to move around tons of code.
Still use fast_path's InputGraph as the "universal" format, for now.
This is a huge change... got map_model compiling at least. Some stubbed
out stuff.
now that my faster machine works again.
Running importer jobs in parallel is actually super hard, because
there's async stuff thrown in there now to download files.
fixes a very dramatic problem in the Green Lake map.
Regenerating everything...
Also added total trip time to the prebaked summary, to get a quick sense
if a change net helps or hurts and have a record in version control.
- handle when the equiv_pos of a driveway gets too close to the edge of
another lane
- make the updater workflow handle files from S3 that're a bit older
- remove pathfinding_avoiding_roads
- strip out old vehicle capping from map edit JSON, then fix up
proposals
- delete old capping API example
- temporarily give up on phinney; it starts gridlocking
- add broadmoor proposal link in-game
This collaboration is abandoned, the code slows down refactoring, and
if we started this idea again today, it'd be better to do it from
scratch anyway.
Regenerating everything.
we need to adjust the start position to account for the vehicle's
length.
Also add a very convenient debug tool to understand positions along
lanes.
This probably breaks static blockages; I'll check into that next.
- Adding an internal alt_start to PathRequest
- Using it for contraction hierarchy queries only (the Dijkstra
implementation now diverges!)
- Figuring out which start position was used
TODO:
- Fix the unparking position
- Make sure the simulation inserts static blockages
- Carefully check the same start/end road case
- Evaluate impact on gridlock / cancelled trips
- offstreet_parking_length in importer config
- backwards compatibility for map edits
- fixing up the baked-in proposals
- working around a few PolyLine bugs that happen with the new rounding
- Don't regenerate actdev scenarios yet -- the upstream JSON format is
out of date, will have to fix separately.
only. It has much simpler logic and produces correct results for these
intersections, but it has degradations in some cases -- so limit where
we use it.
But in the meantime, this makes realistic crosswalks over Aurora,
fixing crazy walking detours there.
Not regenerating yet.
- only triggered when a vehicle becomes Queued
- Only one adjacent lane, no contraflow (crossing the road's center
line)
- Don't return to the original lane after passing
- Using a static blockage in the old lane (so other vehicles will wait
too much)
- Only using the new lane to determine position (so visually a car will
clip a bike as they pass)
Haven't regenerated prebaked data. #382
containing some points. Happens at i524 in Arboretum and in the West
Seattle proposal.
I don't understand yet why this is possible in the first place, but
crashing is pretty bad in the meantime.
- arrays are now iterable directly
- switch to using BTree{Set,Map}::retain!
- a round of clippy
- regenerate scenarios and prebaked data; not sure why, but there's a
diff
- Support this at the pathfinding level, when transforming v2->v1
- Adjust how the vehicle's body is rendered as it exits a driveway onto
a farther lane
No support yet for blocking any intermediate lanes; vehicles may clip
through each other without any conflict. Planning to add that
separately.
Regenerating all scenarios and prebaked data...
toggle how many CPUs to thrash. We always use all of them, except for
one case, where a separately named method is more clear. Also make that
variation use all but 1 CPU, instead of just half.
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.
There are some caveats with the implementation commented inside.
Verified manually in Montlake -- down to just 122 cancelled turns!
Still not regenerating...
movements, make sure that a vehicle can access BOTH the source and
destination lane of a turn. #555
Without this fix, a turn from a bus lane to a driving lane is allowed
for cars at the pathfinding v2 level, but then it fails when converting
into v1 lanes.
(Next step: actually allow this for combination bus/turn lanes)
Not regenerating data yet
And fix an absolutely infurriatingly bad typo from the previous commit.
Now both the multiple_left_turn_lanes and divided_highway_split test
maps look great!
* More conventional spelling of acronym identifiers
* `new` -> `new_state`
* Remove redundant field name
* Remove needless `collect`
* `to_controls` -> `make_controls`
* Simplify long if statement
* Fix module inception
* Simplify chained if let
* Return directly instead of creating a binding
* Disable clippy warning about `borrow` method
Implementing the `Borrow` trait instead would result in excessive type
annotations.
* Fix most remaining clippy warnings
* Allow clippy::type_complexity
* Fix bad merge from web editor
* Run cargo fmt
* Suppress large_enum_variant warnings
* Rename FYI state to ShowMessage
* Fix upper_case_acronyms warnings
Co-authored-by: Dustin Carlino <dabreegster@gmail.com>
* Add craft and office to import and add/reorg AmenityType
* Remove bike rental/parking and rename BikeShop to Bike
* add in leisure and tourism tags, add more categories to AmenityType and remove lesser used tags
* add dependency on strum and strum_macros and removed some manual code for text display of Enum and Enum into string
* include lock file, fix color of buildings for amenity layer, fix formatting and use orders
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.
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.
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.
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.
intersections. They wind up looping back on themselves in a nonsensical
way, causing vehicles to visually glitch when moving through.
This causes lakeslice and rainier to gridlock, due to the magic of
emergent behavior. I think I upstreamed an OSM fix for lakeslice, but I
need to work on rainier before enabling this code.
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.
- Stop alerting when slow pedestrians can't make it through the minimum
crosswalk time
- Simpler iteration style in lagging_green.rs
- Totally delete the old brute force signal config code; it never worked
well, and the improved heuristics eliminate the need for it anyway
- Make a Duration::max function and use it in one case
* Create module from make/traffic_signals.rs
Most things are in mod.rs, lagging_green and brute_force are moved into their own .rs files
* pull more into brute_force.rs
Add a template for lagging green
Lagging green is variable. Crosswalks are also variable.
convert_to_ped_scramble() is refactored to allow a call that doesn't promote yield to protected; as this could unintentionally extend a variable phase.
This lets you live-tune routing parameters, then see how it affects the
total number of routes that cross every road, relative to the baseline
of the original parameters. We can also use it in the future to do the
same thing, comparing before/after some map edits.
* Skip all-walk if no demand
If you create an all-walk stage and make it adaptive, if there is no demand it will be skipped. Fixed crosswalks are never skipped, as they may be necessary for queue management.
u-turns, but recently, they're forced to left turns if the road names
don't match. Now be more specific and revert either a left or right
turn.
This fixes up https://www.openstreetmap.org/node/53089011, which now
acts like a 4-way intersection for signal heuristics!
Not regenerating everything yet.
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!
