// the find
a-b-street/abstreet
Transportation planning and traffic simulation software for creating cities friendlier to walking, biking, and public transit
A/B Street is a Rust traffic simulator and urban planning tool built on OpenStreetMap data — you load any city, edit streets and intersections, and watch simulated pedestrians, cyclists, and cars react to your changes. As of 2025 the monorepo is effectively legacy; active development has fragmented into half a dozen separate spinoff tools deployed by UK government planning agencies.
- The OSM-to-driveable-map pipeline in convert_osm is serious work: intersection geometry, turn restrictions, GTFS transit integration, elevation, and parking all handled from raw OSM XML. Doing this correctly at city scale is genuinely hard.
- The same Rust codebase compiles to native and WASM without a separate build path, so the web demo and the desktop app share logic rather than being two different codebases with drift between them.
- The discrete-event traffic simulation models pedestrians, cyclists, buses, and cars as distinct agent types with realistic queueing and signal timing — it's not a toy flow model.
- The spinoffs (LTN tool, Active Travel England's planning tool) are in active government use, which means the core geometry and simulation libraries have been stress-tested against real-world planning decisions, not just toy scenarios.
- The main repo is in maintenance mode and the README says so upfront — active development has scattered across half a dozen other repos. Someone cloning this expecting a live project will be confused about where to contribute or file issues.
- The custom immediate-mode GUI toolkit (widgetry) is a full lock-in to a bespoke rendering stack. There's no ecosystem, no documentation outside the source, and any UI work is de facto core contributor territory.
- Generating a realistic trip demand scenario requires external tools (grid2demand, actdev) and a non-trivial data pipeline. You cannot just point it at a city and simulate rush hour — the O/D matrix problem is left largely to you.
- OSM data quality is load-bearing and there's no graceful degradation. Cities with sparse or inconsistent OSM coverage produce broken maps, and debugging why a lane connectivity is wrong requires understanding both the OSM tagging schema and the import pipeline internals.