* 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.
data.' This makes it slightly less jarring to click on a specific trip
in a table or matrix, then return to the dashboard. Future work will
also remember filters/pagination of individual tables, maybe! (Since the
dashboards change over time, this might be weird.)
This also required adding a proper way to pick the dashboard from two of
the full-screen map dashboards. Otherwise, somebody would pick them and
get stuck!
- Add optional clickable labels to DrawWithTooltips
- Wire up problem_matrix to remember the list of trips associated with
each cell
- When clicking a cell, just open one arbitrary example trip
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.
Previously, this was done through an incredibly complicated dance of
loading the map file again when needed. This was slow (especially on
web!), made the InfoPanel API have a bizarre edge case, and even had
some way of crashing if you open a trip panel in some situation.
Rip all that nonsense out. The unedited map can just be cloned before
applying the first edit.
