Web

DYNAcity Web Simulator

I built a browser-based environment for exploring Beirut and comparing changes to its streets. It brings building data, traffic simulation, pedestrian flows, and urban forecasts into one map while keeping assumptions visible.

Technologies used

Python
FastAPI
MapLibre GL
deck.gl
SUMO

Making Beirut’s data explorable

A planning experiment needs more than a map. Building surveys describe one part of the city, a road network describes another, and a simulation introduces assumptions about how people move. I brought these layers into a browser interface so a planner can inspect the city and compare street changes without treating every layer as an equally certain observation.

DYNAcity’s layered 3D city view looking east across the Beirut River toward Bourj Hammoud — Beirut 001, surveyed BBED buildings, Overture context, and mapped roads form one city view. From the 3 November simulator report.

From source data to a working city view

The application uses a Python FastAPI server and a MapLibre GL map, with deck.gl drawing the 3D layers. Building data comes from the Beirut Built Environment Database, with the Beirut 001 model and surrounding building context providing geometry. OpenStreetMap supplies road and street information.

SUMO runs the traffic simulation through its TraCI interface. Street closures and pedestrianisation experiments change how simulated trips move through the network. Pedestrian-flow modelling adds another perspective on the same street interventions.

Simulated cars queue at a Hamra junction beside zebra crossings, traffic signals, and pavement walkers — Hamra at 17:00: SUMO vehicles queue at a signal while modelled pedestrians walk along the pavements. These are simulated movements.

The browser interpolates SUMO’s one-second vehicle positions, drawing cars, signals, and pavement walkers in the same city scene. Sending only vehicles near the camera keeps the display focused while the server continues to count the simulated fleet.

Keeping observation separate from simulation

Historical road speeds and traffic counts help construct the experiment, but they do not make the display a live traffic feed. Demand, routing choices, and unmeasured signal timings remain modelling assumptions. I keep this distinction visible because a convincing 3D scene can otherwise make an uncertain result look measured.

Redesigned DYNAcity interface with a Charles Helou Highway section closed to cars and street intervention controls open — Closing a Charles Helou Highway section in the redesigned viewer. The traffic panel exposes the street intervention controls.

Just before the first intervention, the simulator forks the vehicles, signals, and random-number state into a baseline and a scenario. Both receive identical demand. Closing a road changes the scenario’s lane permissions, and affected cars seek a legal route to their original destination. Cars without a detour stay queued and counted.

Comparing the two runs exposes rerouted cars, blocked trips, and completed-trip delay. Unfinished trips need separate attention because a delay average over completed trips can hide the vehicles still stuck. The comparison supports investigation within the model, with local calibration still needed before making planning predictions.

Planning space for people on foot

The walking layer uses MIT City Form Lab’s Urban Network Analysis tool and the Beirut pedestrian-flow model described by Sevtsuk et al. (2024). OSM walking links and destinations combine with building-based population estimates. The resulting flows are modelled demand, not live pedestrian counts.

Green pedestrian-flow lines follow the walking network between Hamra’s 3D buildings — Modelled weekday PM pedestrian flows around Hamra. Wider green lines represent busier walking links, using the UNA model described in the report.

A planner can pedestrianise a street section, lower its speed limit, give a curb-side lane to the pavement, or close a pavement. SUMO responds to the vehicle permissions while the interface updates walking space and modelled occupancy. The report’s Bliss Street example increases pavement space from 535 to 892 square metres within the scenario.

Forecasting without borrowing information from the future

The separate urban-form engine builds building-status transitions from BBED observations. Earlier intervals supply training data, and later observations provide a time-forward evaluation. Point-cloud features acquired after the port blast cannot be inserted into earlier training rows.

Forecasts report uncertainty across repeated simulated rollouts. Learned transition models are compared with simple baselines before selection. The practical decision is to retain a stronger baseline when a more complicated model does not earn its place.

What the prototype can establish

The system demonstrates the data integration, map interaction, and simulation workflow. The next research step is better calibration and sensitivity analysis against local observations. Historical inputs, incomplete mapping, and assumed demand limit how confidently the results can be used for planning decisions.

City geometry: Beirut 001 by Salim al-Kadi and team, with Overture Maps context. BBED: Beirut Urban Lab at AUB, ODbL. Map and roads: CARTO and © OpenStreetMap contributors. The traffic layer uses Tari’ak historical speeds and CDR traffic-count context. Simulation tools: Eclipse SUMO and MIT City Form Lab UNA.