Originally it was split out to organize a separate volunteer mapping
effort, but that never took off, and it's unlikely to happen. When we
have to occasionally update the prebaked signal data for some
intersections, it's unnecessary friction to update the other repo.
later overriding a .osm file with tags for these roads. This is a way to
test the effects of making simple OSM changes locally before
upstreaming.
Also handle repeated merging collapsing one of the roads. Not 100% what
happens here, but skipping the collapsed road works fine. The scary
Montlake intersections now look great with all the merging done, so
upstreaming the change! #114
everything along Aurora looks fine, but maybe I wrote the other way when
testing in Montlake earlier. Guess I'll find out soon. #114
Not regenerating all maps yet, since more churn is on the way.
Previously, dual carriageways (pairs of one-way roads in opposite
directions) mostly didn't get any signal templates successfully applied.
This change ignores outbound-only roads when applying the templates. In
one fell swoop, lots of previously broken signals along places like
Aurora Ave suddenly work reasonably.
generated incorrectly, but regardless, calling them TurnType::Left is
just confusing.
For the moment, always filter out U-turns from merged intersections.
When connections across merged one-ways are handled properly, we won't
need this, but in the meantime, it moves forward. #114
Not regenerating just yet, but will bundle it with the next commit.
in the interior of a big intersection. #255, #114
- No sidewalks or parking on it
- Automatically try to merge it
Bring in fresh Seattle OSM with a few places on Aurora tagged, for
further experimentation.
Also, there's some bug in the importer; Seattle maps didn't get
regenerated last change. Picking up the diffs now.
For the (still disabled) cases of merging short roads, this helps
immensely. It doesn't affect most other maps visibly. Makes a few
already broken things in Krakow and London slightly worse, but don't
care, because they didn't look sane before either.
map_editor. It was nuked in 182f5139a5,
when I decided the MapFixes approach wasn't worth it. #114
The restored version doesn't attempt to handle turn restrictions again
yet.
* Add a Variable phase
Variable provides a min duration, a delay duration, and an additional duration. The maximum cycle time is min + additional. Once min has been exhausted, if there is demand, the cycle is extended by delay until there isn't any demand or the additional duration has been consumed.
#295
degrees to 30 degrees. It works around the issue in #428, but it doesn't
solve the root cause there, so the unit test is also adjusted to provide
a way to solve the harder problem.
Regenerated all maps accordingly. Many traffic signals tended to
improve, with a straight turn marked protected, instead of permitted as
a "right turn."
saves lots of callers from cloning the request and separately plumbing
around the requested start/end distance. Also a step towards exposing
more granular distance crossed in a path for #392.
Still a few more places to simplify, but will do in a separate, smaller
change.
1. Allow lane changing in an uber turn. Because of the way uber turns
work, we lock in and commit to all the lane changes just before
entering the uber turn.
2. Avoid overzealous lane changing by combining number-of-lanes-crossed
and numer-of-vehicles-in-lane into a single cost, rather than always
preferring the least number-of-vehicles-in-lane.
3. Don't lane-change unless the candidate lane's cost is strictly better
than the current lane cost.
It'd be more efficient to terminate the Dijkstra's search directly, but
petgraph doesn't have an option for that, so we'll have to implement
Dijkstra's manually (shouldn't be hard).
struct. Whatever choices we make next about naming cities hierarchially
or not can be managed in just one place. #326
This is a pretty huge change, but the compiler gives reasonable
confidence it's correct. More bugs are likely to crop up in the next
step, when filenames start being namespaced by the city too.
intersection polygon in Krakow that has really bad geometry, and this
improves it. The extra check absolutely shouldn't be necessary, but of
course, all the core line intersection code is quite suspect! #161
Also gets rid of some annoying warnings about roads with missing names.
I could continue to skip the warning for more situations, but I think
this sort of data quality check could be done better in the OSM viewer.
order of vehicle deletion, we try to ask about stop sign and traffic
signal movements that may be deleted and would be irrelevant anyway if a
different deletion order happened. #312
We should really defer wakeup_waiting until after all cleanup is done,
but for now, willing to risk some stuckness at a stop sign...
imported, because they referenced way IDs from before the service road
import. That happened after a bad Cargo.lock merge undid the effects of
pinning to the latest seattle_traffic_signals.
only allow the leftmost source lane to turn to any destination lane. As
a future improvment, need to handle multiple explicitly tagged left turn
lanes, but this gets closer to reality, particularly helping some crazy
maneuvers along Mercer in downtown.
*or right
Also had to update lanes along Madison and fiddle a bit to keep
lakeslice running. Spotted some major traffic signal bottlenecks due to
stage generation falling back, will iterate on that separately.
lanes all lead to a single lane via left/right turn, and just keep the
left/rightmost lane.
Sanity checked at Rainier / S Massachusetts, and 23rd / S Massachusetts.
refactor, they complicate the function signatures significantly and have
no observable perf impact, since all of the methods just happen in map
importing.
- Temporarily workaround snap_cycleways crash in Xi'an
- Fix interpretation of blank turn restrictions. https://www.openstreetmap.org/way/739621435 was missing a right turn, which was causing vehicles to do this crazy loop to go from Madison EB to Lake Wash SB.
- Ignore turn restrictions when they don't match the number of lanes. https://www.openstreetmap.org/way/428090702 and similar need some updating.
Regenerate all data, but give up on lakeslice running fully. Going to
sacrifice that one for a bit to get new roads imported.
* Fixed ui being able to select traffic light times that are shorter than the time it takes to walk across the crosswalk
* Fixing operands and renaming
* Fixed spinner out of bounds issue
Traffic light generation now, ensures that there is enough time to cross the crosswalk
And enforces the minimum time duration
* Cargo +nightly fmt
* Request fixes: https://github.com/dabreegster/abstreet/pull/346
Still need some things to clarify:
Spinner checks on increment/decrement
Calling enforce_minimum_crosswalk_time inside get_possible_policies, requires the removal or modification of the validation function
* Moved enforce_minimum_crosswalk_time inside get_possible_policies
Now runs stage_time_validation at the end of get_possible_policies and removes invalid policies
Could do the same with the validation function as well?
* Fixing import order
* Fixed ui being able to select traffic light times that are shorter than the time it takes to walk across the crosswalk
* Fixing operands and renaming
* Fixed spinner out of bounds issue
Traffic light generation now, ensures that there is enough time to cross the crosswalk
And enforces the minimum time duration
* Cargo +nightly fmt
* Request fixes: https://github.com/dabreegster/abstreet/pull/346
Still need some things to clarify:
Spinner checks on increment/decrement
Calling enforce_minimum_crosswalk_time inside get_possible_policies, requires the removal or modification of the validation function
* Moved enforce_minimum_crosswalk_time inside get_possible_policies
Now runs stage_time_validation at the end of get_possible_policies and removes invalid policies
Could do the same with the validation function as well?
* Fixing import order
* Moving stage validation inside validation function
Co-authored-by: Sam <a>
clipping boundary. I don't remember why the more complicated thing came
about. This fixes a weird incoming border in SLU into an unreachable
intersection (which is more accurate) and doesn't seem to cause any
problems to normal or oneshot maps, with or without explicit clips.
uber-turns (sequences of turns through a few intersections) due to OSM
turn restrictions, we have to be a little careful how we sum up the cost
for the entire sequence, only rounding at the end.
controller terminology. Part of #197.
Holding off on touching PhaseType and all of the serialized
seattle_traffic_signals format, since this will all change in Kyle's PR
anyway.
not split by direction. Update many callers, and lock down the
visibility of the old methods.
Tested a few maps manually to make sure there's no behavioral diff. Only
problem right now is the z-order of adjacent lanes covering up half of
the white stripe sometimes. Have some ideas to fix that later, and not
_super_ important in the meantime.
multiple points. This was already handled when the roads went between
the same intersections, but I found a case in Ballard where the roads
are just really close to each other. Screenshot diff empty in Krakow,
but still related to #243
just does Dijkstra's. This has a few uses:
- When you import with --skip_ch, the resulting map will still work,
just more slowly
- For congestion capping experiments, we sometimes want to route around
a zone. Regenerating the contraction hierarchy for every combination
of zone being open/closed is likely more complex and expensive than
just falling back to A* for trips that cut through at least one closed
zone.
Not regenerating yet
a zone per hour. This is part of support for some kind of congestion
charging experiments. This step just rearranges the data to define the
cap and makes a UI to edit it. Not enforcing the cap yet.
one of the outbound roads. This was motivated by one particular example
in downtown, and per screenshot tests, doesn't have regressions
elsewhere. Also improves a few cases in montlake.
when allowing a car to start a turn. It causes
https://github.com/dabreegster/abstreet/pull/276#discussion_r470269394
and also the lakeslice scenario to gridlock (a regression that began a
few weeks ago). But keep the flag on for now, to keep the montlake
scenaro running at least.
https://dabreegster.github.io/abstreet/trafficsim/gridlock.html has
notes about the many different causes and in-progress fixes for
gridlock. This experiment hasn't been explained very well yet, but
roughly it treats a cluster of traffic signals as one, so that once a
vehicle gains access through the first light, they guarantee immediate
access through the entire sequence. This interacts with the "don't block
the box" behavior (don't start a turn if you might get stuck in the
intersection) strangely.
While attempting to get this rollback to work, I also had to manually
redraw the traffic lights for a few manually specified intersections.
They became out-of-date a few weeks ago when I cleaned up the OSM
geometry upstream and the referenced IDs changed, and I hadn't bothered
to re-time the signals. Luckily, with the new multi-signal editor,
redrawing the timing was much easier than originally!
Regenerated all data and lots of bus routes vanished. Plan to get back
to that project soon.
OriginalBuilding was to refer to buildings in a stable way across
different maps and across OSM updates. Recently, OsmID and friends
appeared. The double layer of wrapping is an annoying API.
Not regenerating map data yet; about to do the same thing for
OriginalIntersection
recording errors and falling back to circular geometry and not trimming
roads
also filter out highway areas like
https://www.openstreetmap.org/way/132705692, woops!
Manchester and NOLA now import...
now, just switched everything to must_* variants, but this paves the way
for handling failures.
... except for rendering pedestrian crowds -- I _think_ I saw a crash
from that, and it's easy to have a fallback there
seems pretty good for a few examples. not regenerating yet. still lots
of routes skipped because of edge cases, but now it's way more clear
how to work on those smaller problems.
ignoring parking spots if the parking lane is in the opposite direction.
workaround is to reverse the lane. dealing with that bug next though.
part of #64 and #176. fixes#109
will start/stop directly in front of a building driveway, when possible.
still need to handle the case when the bikeable position isn't connected
to most to the graph (for buildings accessible only by footway and for
things around the border)
connections to driving/biking. just store the immutable stuff -- whether
there's parking in the building, the connection to the sidewalk, and the
physical driveway line. compute all the rest dynamically, so it responds
to edits without effort.
shouldn't be major behavior changes yet (besides maybe fixing some bugs
involving edits)
parking on tiny roads. fixes some geometry in krakow. #230
(unrelated: add a debug layer to show parking blackholes, to work on
bike connections)
(also unrelated: better error message for #256)
- handle living streets that allow buses in berlin
- don't connect LeaveMap nodes to anything else; people were getting
creative and using them as shortcuts to effectively warp to a border,
then come back into the map
- make should_use_transit understand transfers (and still just return
the first leg)
- warp to bus routes by ID
still at least one weird bug left, seen in krakow. working on it next,
trying to keep these commits "small." not regenerating maps quite yet.
- don't infer parking lanes there
- sidewalks on both side of a one-way
- handle maxspeed with kmph
- no maxspeed on living_street is 20 kmph
still not regenerating maps
access restrictions. makes old town in krakow look much better and
brings in stay healthy streets in seattle. also commit some code related
to footways that isn't exercised yet.
- just generate every combo of turns from incoming->outgoing
- stop doing all of the weird bike->bike restrictions. that gets handled
anyway in later layers like pathfinding costs, opportunistic LCing,
and picking valid starting lanes
- rely on OSM for filtering out left/right turns from multiple lanes
- why was it useful at all to distinguish Straight from LCing turns?
scrap that
has the effect of eliminating a class of bugs where a driving lane is
sandwiched between lots of bus lanes and wasn't winding up with an
in/outbound turn
- interpret tags to make 3rd Ave bus-only. cars technically allowed
sometimes, but bus-only is more accurate for now.
- also remove austin from bundled maps. maintaining it has a cost, and
the point was just to have at least one non-seattle city kept up to
date. krakow now satisfies that.
* WIP set up plumbing for calculating building info in the Raw layer and using it later for #154
* WIP playing with processing modifications
* experiment with some possibilities for tag processing
* fix an embarassing typo
* enable busses in work-home traffic
* refactor, add multiuse
* seed more parking in Kraków
* parse integers properly - thanks for a help!
* rebalance generated trips
* add hack providing some background traffic
more realistic traffic
even mess realistic people
* attempt to further reduce parking deficit
* add TODO
Co-authored-by: Dustin Carlino <dabreegster@gmail.com>
modifying the low-level PathSteps. also make sure to not try LCing when
going into one.
on the cusp of being able to treat complicated intersections as one...
this is a complete guess, but seemingly a better one for some sample
cases in seattle and krakow. helps with #178.
also opt krakow into screenshot diff testing; it has enough different
things happening that it's worth watching more carefully how importing
changes affect it.
maps: 645mb -> 625mb
scenarios: 431mb -> 390mb (before all the u32 optimizations, this as
500mb!!!)
prebaked: 80mb -> 73mb
and while I'm at it, grab fresh OSM, with lots of manual lane fixes,
especially near divided highways
this actually disconnects the boyer roundabout (which is tagged
correctly in OSM, but not using the separate sidewalks yet). fine for
now, might add a temporary override later
sidewalks), not as the divider between the two directions. this
dramatically changes geometry everywhere for the better.
thanks to
https://wiki.openstreetmap.org/wiki/Proposed_features/placement for
clear explanations. will be looking next at interpreting this tag.
also temporarily removing screenshots, because uploading individual
files and waiting for dropbox to sync isn't sustainable
