Also has the happy side effect of preventing modal filters from being
put on roads that lead to no-car roads (which're effectively dead-ends
for cars).
Regenerate everything
preparation for modifying them in the LTN tool.
Regenerated everything. This had some effects on overlapping road
shrinking, mostly positive. Screenshot diffs all changed, since I
switched laptops again.
* Fixes issue #173 Part B
This commit changes the color of road labels to white, and adds a black
stroke. It also removes center line dashes from the beginning of the
road label to the end.
* cargo fmt and fix syntax warnings
* Adds changes from PR #917 Review
This commit adds the changes requested in PR #917.
* Rebase and cargo fmt
* A few cleanups:
- make render_center_line private
- make usage of the 0.1 factor more clear
- work in Distance::meters
* Disable the curvey label experiment before merging, but now we don't
need to draw the background for non-curvey labels either!
* Draw the full center-line when appropriate
* Screenshot diff
Co-authored-by: Dustin Carlino <dabreegster@gmail.com>
First time regenerating everything on another laptop; there may be some
weird changes unrelated to stuff here (like montlake prebaked data?),
but nothing that seems problematic
There were 3 manual steps here:
1) Tag sidewalk=left,right,both along many one-way streets in OSM where
the inferred value was very wrong, and causing a large difference
from smp_sidewalk_widening
2) Clear out smp_sidewalk_basemap, broken by OSM ID changes. This has
never actually (and still does not) contain real baseline sidewalk
widths, but still might eventually.
3) Manually update smp_sidewalk_widening, broken by OSM ID changes.
The simulation results with the proposed edits now don't cause as many
spurious route changes.
PolyLine instead of list of points.
This exposed two edge cases, fixed here:
1) While merging short roads near junctions, we sometimes create a loop.
Filter it out immeditely.
2) If an OSM way is physically sharing geometry with another one
invalidly, detect that and discard it much earlier.
The main reason is to unblock osm2lanes cutover by avoiding
https://github.com/a-b-street/osm2lanes/issues/153. A secondary reason
is to pull in fixes in SLU for #818.
But of course grabbing fresh data wasn't straightforward:
- Need to collapse small junction=circular ways just like roundabouts,
or else Montlake starts gridlocking. And so actually, regenerating all
maps, in case any happen to use this.
- Had to update a bunch of proposals since OSM IDs changed. I just used
the automatic repairs with some edits filtered out. Fixing edits
really is quite tedious when IDs change; we need something more
robust. (Just give up, describe geometry, and always snap to the best
match?)
- Had to update the one baked-in traffic signal for similar OSM ID
reasons, with similar hassle.
We need this because we have a data source for SMP that we can use with
extra attribution, but not upload to OSM.
This whole commit is gross hacks; going forward, we need a proper
process for upstreaming stuff in OSM.
by chance in #870.
A vehicle exits a driveway and blocks a lane on its way out. When we try
to clear the static blockage, the queue calculation recurses to resolve
distances on the queue where that vehicle is entering. But since we
temporarily don't have the car in the list of cars (for the borrow
checker), it was crashing.
One of those "2 hours to figure out, 30 seconds to fix" bugs.
