* 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
