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.
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.
limiting how long a crowd can enter a crosswalk. #517
Removing Tehran from prebaking; it starts gridlocking. I didn't
investigate why; making SMP realistic unfortunately takes priority right
now.
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.
Transit stop IDs previously were tied to LaneIDs, but those can easily
change with edits to the number of lanes on a road. We still may need to
re-snap transit stops (if the driving position or sidewalk changes), but
this prevents one more common type of problem.
This requires regenerating everything, since it's a binary schema
change...
And clean up some other things that RDP does better.
Fallout from regenerating everything:
- Enfield borough crashed, so removed it
- All UK scenarios are now much bigger, due to the changes in #853 being
picked up
- Poundbury gridlocks now due to that
too far, by not trying to trace near railways or cycle-only
bridges/tunnels. This is an imperfect heuristic, but it makes
significant progress in most maps.
intermediate results can't be turned into a polygon. It'll break
something later. #841
There's a particular bug where a perimeter can be turned into a polygon,
but after collapsing internal dead-ends, it can't.
If we don't do this, the LTN select boundary UI crashes, and reasoning
about block -> neighborhood mappings gets very hairy. I'd like to
address all the root causes of failing to make a polygon, but until
then...
TRADE-OFF: it _really_ slows down the select boundary UI.
along the perimeter of broken intersections.
There are cases where intersection geometry is a little bit broken,
jutting out a bit and touching a road. It's more robust to still produce
a reasonably shaped block in these cases, instead of totally give up.
Visual inspection and the goldenfile VASTLY improved!
1 lane (usually a cycleway or footway). This correctly produces a few
more blocks in some maps -- as the goldenfile diff (and manual
verificaton) shows!
Also allow jumping from LTN browse to debug mode, to conveniently work
on blockfinding problems.
* add turn_on_red config option which is false for nyc
* when making stages, don't add movements that don't share a stage with a protected movement
* Fix a renamed DirectedRoadID field from
cb3693bd7a and the new turn_on_red field
in the test crate
* Update all map config files with the new option
for x in importer/config/*/*/cfg.json; do
cat $x | jq '.map_config += {turn_on_red: true}' > tmp
mv -f tmp $x
done
(And then undoing NYC)
* turn on red banned on all non-us maps
* regenerate all maps
Co-authored-by: Marcel Dejean <marcel@dejean.nyc>
Co-authored-by: Dustin Carlino <dabreegster@gmail.com>
near OSM highway=crossing nodes. #795
Not enabled anywhere, because it doesn't seem to produce good results.
Possibly footway=crossing ways need to be used for this as well.
Had to regenerate all maps, since the binary format changes.
