signals using uber turn groups. #555
This was an old half-baked experiment for handling a cluster of traffic
signals. Since then, merging intersections (by manually tagging them in
OSM for now, maybe automatically in the future) has proven better.
Removing this old code in preparation for pathfinding v2.
* root element id from Settings, respect element size
* Plumb assets root via settings
* adapt crates to new wasm api
* more FileLoader cleanup
* use tsc bin from node_modules
* avoid spurious unlink errors
GNU Make considers the src/*/wasm_pkg targets as intermediate build
files and attempted to `rm` them. We can stop that my marking them as
`.PRECIOUS`
https://www.gnu.org/software/make/manual/html_node/Special-Targets.html
* `open` doesn't work on Linux
We could do something with xdg-open, but meh, not worth having platform
dependent logic for this.
* fix typo, clarify instructions
* make server compatible with older python install on linux
* revert change - we dont want to include music on web
the leading "-" means exclude a subdir of an included dir.
* better wrap of comments
* fix misfire in copy/pasted comment
* update docs
Also split out some common code to a plots module. Fan charts and
scatter plots are still hardcoded to use Time as the X-axis and
duplicate lots of code, but this is a step towards refactoring
everything.
always tiny; Dijkstra's is fine. It costs a bit of file size to store
it. The huge leeds map goes from 160MB to 157MB -- not crazy savings,
but something.
Also fix a slight bug with 92d3a890ea that
caused some pedestrians to uselessly visit a bus stop node while
routing. (southbank crashes a few hours in otherwise)
This is simpler to reason about, allows the penalty for entering a zone
or taking an unprotected turn to be expressed in terms of a time
penalty, and is a step towards adjusting bike/foot routing for elevation
data.
When we later add things like "safety/quietness" for cycling, maybe we
can switch to using a (time, quietness) tuple, and transform into a
single number with a linear combination parameterized by that agent's
preference for time/safety. This change is compatible with that future
idea.
There are behavior changes here, particularly for zones and unprotected
turns. No new maps start gridlocking, and in fact, Rainier starts
working again.
* PERF: lower memory requirements for clip_osm
- don't accumulate things unless they are at least partially within the boundary
- accumulate id's, not entire objects.
This entails doing a second pass of the file, but keeps memory usage
much lower.
e.g. a largeish area of Los Angeles, covering east hollywood to downtown, clipped thus:
- north: San Fernando Blvd
- east: LA River east of Downtown
- south: the 10
- west: Western ave,
Before: importing the above stalled out for me during clipping, which
had ballooned into swap at more than 16GB.
After: in the above scenario, clipping peaks around 55MB, and the import
process as a whole peaks during pathfinding - at around 4.0GB.
* fixup! PERF: lower memory requirements for clip_osm
Remove unnecessary casting
"rise / run" calculation used the trimmed road center-lines, which don't
match up with the elevation at each original intersection point.
Also handle infinity in the output and reduce the resolution of the
query from every 1m to every 5m.
Regenerate all maps due to the map format change. Try bringing in
elevation data for all of Seattle using the LIDAR source, since
the data quality assessed in eldang/elevation_lookups#12 seems to be
similar, and LIDAR is way faster than contours.
* Import screen UI fixups
- even out the spacing a bit
- use underline style for "Alternate Instructions" web link
- left/right switch is more intuitive than right/left
- disambiguate label from toggle id
