snapping. Emit the KML debug file only when additionally flagged on. Add
more debug info there, to figure out why some paths are totally
disappearing... #330
- choosing some building colors
- proper unzoomed road/intersection outlines
- adjusting curb color based on road rank (for arterials, it was the
same grey!)
The deadend trimming is too enthusiastic, getting rid of some unsnapped
cycleways and things connecting to the map border. Will iterate on it
this week; net benefit for now.
* 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
