Quite cool to see this space being explored! https://github.com/headwaymaps/headway is another related project.

Nice - thanks for the pointer. Headway is definitely a related "self-hosted maps stack" project.

One place Corviont is trying to differentiate is the update story for edge/fleet deployments: the goal is a signed, resumable regional dataset updater (verify manifest -> atomic swap -> reload/rollback) so boxes in the field can stay fresh without manual rebuilds or "re-download the world" updates. Headway (at least from a quick skim) looks more like "bring your own data / regenerate when needed," which is totally fine for servers, but fleets usually need something more automated.

If you've seen Headway (or similar) handle incremental/regional updates well, I'd love to learn from it - updater design is the big missing piece I'm validating demand for.

(Headway maintainer here)

Indeed there is currently no incremental update in Headway, and deployments are largely an exercise left to the reader.

For maps.earth (a Headway planet deployment), I typically rebuild the world, and then do a blue/green deployment.

I guess the one exception is for transit routing. We have individual transit zones small enough to fit into memory, which can be deployed incrementally. There’s nothing really built in about it - just another level of indirection via our “travelmux” service which redirects your routing queries to a different backend depending on mode and region.

Thanks for chiming in - super helpful context.

I am trying to learn from real deployments as I design Corviont's updater for edge boxes (bandwidth caps, maintenance windows, unreliable WAN, atomic swap + rollback).

When you say transit "zones" are small enough to deploy incrementally - what is the actual artifact per zone (roughly what format), and what sizes do you typically see?

And when a transit zone dataset changes, how do you roll that out safely - do you restart/reload the backend that serves that zone, or do you bring up a new backend/version and then flip travelmux to point at it?

Transit routing is provided by OpenTripPlanner, so the deployment artifact is their OTP serialized graph format.

So it’s not really incremental with respect to the existing transit zone deployment. I just mean I can redeploy a single transit zone with the latest GTFS without having to touch the other transit zones, tileserver, geocoder, etc.

Deployment/rollback is handled by k8s config.

Thank you, that's very helpful.

This is incredible. I remember failing to hunt some down earlier, but does anyone know of really detailed plans or 3D models?

I stayed there about a year ago, and wrote a bit about it with some photos. Just search this page for "Chungking": https://dabreegster.github.io/prose/dec2023/pt1_hk.html

Great photos, thanks. The one with the "negative space" must be what my roommate talked about when he could not see the ground from his room window during the day. Btw, back in the 90s they still had some market alleys in Akihabara/Tokyo that looked like the one in the next photo. And it was amazing.

Just want to plug Pantheon as a TV series exploring this idea with excellent storytelling. (https://en.wikipedia.org/wiki/Pantheon_(TV_series))

Really can't recommend this show enough. As soon as they brought out the dining philosophers problem I was hooked.

This is super cool, thank you for building it! Two small UX ideas:

- a scrollbar and search for the Online Library would be helpful

- switching difficulty levels in the middle of reading could be helpful. Or if you keep that on a separate page, returning automatically to the last open position. (I was floating between beginner levels to find the right amount of challenge)

Thanks for the feedback! I'll look at adding those.

Super awesome! I like how you just color roads to show time. When you calculate polygons to try and cover the whole area in some 5-10 minute bucket, you can wind up with all sorts of odd holes far away from roads. Keep it simple.

https://github.com/a-b-street/abstreet/pull/1075

Hi! https://a-b-street.github.io/docs/project/history/retrospect... has a summary of where the project went. The original scope of the traffic simulation was too grandiose, and it was hard to influence real decision-making with something so complex and buggy. A/B Street morphed into several simpler tools focused on specific problems (removing through-traffic through an area, estimating uptake of new cycle lanes). I'm focused more on web-based tools for gov use these days, but will get back to simulation someday!

thanks for the summary and link, yes it was pretty boldly scoped indeed:)

I love this series. It also reminds me a bit of https://unsongbook.com -- another beautiful work of creative writing combining technology and magic.

Market pressures from the open source world ;)

One of the authors of https://github.com/a-b-street/osm2streets here. If you're interested in improving the quality of the lane rendering, please get in touch on the repo! https://a-b-street.github.io/docs/tech/map/geometry/index.ht... is an older, but still relevant, deep-dive into how the geometry is calculated.