OSM and other raw input into and store, before later converting to a
Map.
Why?
- build-time performance: while iterating on geometry problems, map_editor in release mode took 33s to build before, 11s now that the crate is split
- better layering: operations on a RawMap are becoming increasingly distinct from later transformations on the bigger map model
- this helps tease apart the dependencies of the intersection polygon algorithm for #846
- this will make it simpler to cutover to osm2lanes for https://github.com/a-b-street/osm2lanes/issues/71
There's further reorganization in raw_map and map_model that'll follow,
but the main work is done here.
crate, in preparation for future focus on travel demand models that
incorporate more per-person info.
Note: I'm also a bit tempted to try to further split sim into a
"high-level" layer that orchestrates spawning and different legs of a
trip, from the "low-level" layer that moves pedestrians and vehicles.
That could _possibly_ pave the way for someday using a different traffic
simulation backend with more realistic movement mechanics.
Step 1: just get the synthpop crate to build
* Update dependencies
* Use github for polylabel, to make all dependencies use geo 0.18, not a mix of 0.18 and 0.17
* Downgrade lyon to avoid a crash
Co-authored-by: Dustin Carlino <dabreegster@gmail.com>
It was failing because the version of flatgeobuf we were using was not
compatible with the recent tokio update. Now we point to the unreleased
flatgeobuf which is compatible.
widgetry, geom, and abstutil may wind up on crates.io in some form to
let other projects use widgetry. abstio has A/B Street-specific tricks
for reading data on native/web. Note widgetry still depends on abstio,
will figure out how to clean that up next.
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.
depends on.
The goal is to be able to split things like the OSM viewer, parking
mapper, and 15 min tool into separate crates from the game, while still
sharing lots of code.
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.
85ad194d introduced a patched winit.
In the glium build, we were pulling in a second version of winit (the
unpatched version, via glutin). This caused conflicts between the data
types, breaking the build.
Apparently the proper way to specify a patch like this, usable by
transitive dependencies, is via cargo's "patch" specifiers
