about what cities somebody has opted into downloading to JSON and a more
common place. #326
Note this is a breaking change for this config file, but I don't think
many people have started using this yet.
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.
Uploading files individually to Dropbox is flaky, and the unique URL per
file complicates data/MANIFEST.
While we're at it, start carving aside a directory structure for keeping
data for the last few releases.
[rebuild] to make sure github actions can download everything
This file is used in step 6 of the tutorial.
As a desktop app, we had a bunch of files we just read from disk when
needed. Translating this to web requires some thinkging (things are
slower, they can fail, etc.).
As a first step we simply agglomerated all the files into the wasm
binary, but since some of the files are rather large, we tried to only
include the essential and small files.
This one was missed. Though some of the prebaked results files are very
large, this one is a mere 5k.
showed this is faster than downloading the uncompressed files, but of
course it probably depends on network speed vs CPU. #326
Also cut over the updater to use gzipped files using flate, instead of
single-file .zip's. [rebuild]
native, only look at local files -- so now importing new maps locally
works again. On web, look at statically bundled files AND remote files
declared through the manifest.
In the future for native, we will also want to sometimes show remote
files available and integrate part of the updater, but only in a
specific view, not in general for all files.
* On the web, load different maps by making asynchronous HTTP calls. #21
This is a very strange, specializd approach; it's unclear how it'll
generalize to reading scenarios and prebaked results. Ideally we could
call abstutil::read_binary as we currently do and somehow hide this async
trickery underneath, but I'm not sure how yet. In the meantime, this
moves us forward with the hack well-contained.
Next steps for web: stop bundling in all of data/system in the .wasm,
now that we can load from HTTP.
When I added web support in February, it was easier to get started with
stdweb, since it has the nice cargo web tool. However, stdweb is
unmaintained, winit is deprecating support for it, and the next steps
for web (downloading maps dynamically) have better support for web-sys.
With Alvin's guidance, I got
https://github.com/dabreegster/minimal_websys_winit_glow_demo working
first. This PR cuts A/B Street over too.
I tested abst and the widgetry demo in both native and web. The only
major regression from stdweb is the canvas placement and size. I
attempted some fixes, but at this point, I'll leave it as a smaller
followup instead.
raw string" stuff from the previous commit.
Add tests of a few interesting intersections. The results right now
aren't ideal, but this sets things up for fast iteraton.
proles: account for work capacity
previously all residents went to work on the map, but if the
neighborhood is mostly residential that meant they were "competing"
heavily for the scarce jobs available on the map.
with this commit, we do a better job of spreading worker/residential
demand to account for what is available, and fill in the gap with
off-map trip origins/desitinations.
e.g. if a neighborhood is mostly residential, we have folks commute off
of map. If a neighborhood is mostly commercial, we have folks commute
into the map.
