Traffic Lab — Delhi NCR traffic scenario simulation

1) Product objective

Traffic Lab was created to make transport scenario planning easier to explore in public-facing web software. The product is not a government traffic model; it is a planning simulator that helps compare interventions quickly before deeper engineering, survey, DPR, and statutory review.

• Primary workflow: choose a time profile, edit the network, run the scenario, then compare before/after metrics.
• Target geography: Delhi NCR, with room to add more cities as separate modules later.
• Primary users: planners, civic-tech teams, researchers, journalists, and transport stakeholders who need a fast exploratory tool.

2) Map and data foundation

The simulator uses OpenStreetMap-derived road geometry as its public map foundation. Processed Delhi NCR road links are exposed to the web app as compact static data files, then visualized on top of map tiles with custom layers for base roads, proposed assets, heat intensity, and traffic direction.

• Road graph: normalized links include geometry, length, road class, lane assumptions, endpoint relations, and derived capacity hints.
• Demand profiles: time-of-day demand presets represent morning peak, school rush, evening peak, and quieter periods.
• Map rendering: MapLibre handles tile display, zoom/pan behavior, vector-style road overlays, and search-result highlighting.
• Traffic animation: directional arrows and heat movement are generated on real road paths rather than floating abstract effects.

3) Scenario editing model

Traffic Lab treats every map edit as a scenario operation. Users can add or remove roads, flyovers, underpasses, roundabouts, single-way roads, and lane capacity changes. For line-based additions, the interaction uses click-to-start and click-to-end drawing so the action matches how planners think about corridor interventions.

• New corridors: proposed roads and flyovers become additional capacity between their endpoints.
• Lane edits: added or removed lanes update capacity on existing road links instead of creating unrelated parallel demand.
• Traffic diversion: when a new usable connector is added, nearby matching demand can split across the old and new paths based on endpoint fit and capacity.
• Persistence: user edits are saved in browser storage so refreshes and return visits keep the working scenario intact.

4) Simulation and scoring mechanics

The scenario engine compares a baseline network against the edited network at the selected time profile. It estimates effective capacity, congestion pressure, average speed, waiting time, jammed segments, accident risk, and an improvement score. The score is designed to avoid false positives: negative movement or waiting-time outcomes pull the score down even if one isolated metric improves.

• Average speed: derived from demand pressure, road class, capacity, and scenario changes.
• Waiting time: computed from congestion overflow, not just raw added road length, so useful bypasses should reduce pressure while poorly connected additions may not.
• Jammed segments: counted from links whose demand-to-capacity ratio crosses congestion thresholds.
• Risk estimate: adjusts for speed changes, conflict points, new junctions, lane changes, and grade-separated alternatives.
• Improvement score: combines speed gain, waiting-time reduction, jam reduction, and risk movement with penalties when core congestion metrics worsen.

5) Cost and land-impact estimates

Costing is shown as a planning estimate. The simulator separates construction cost from land impact so users can see why a seemingly simple road can become expensive when it crosses private land, dense built-up areas, or larger footprint zones.

• Construction cost: based on asset type, corridor length, estimated width, lane count, and structure type.
• Area footprint: line edits are converted into approximate affected area using corridor width and length.
• Circle-rate component: private-land displacement can add land-cost estimates based on circle-rate categories where available.
• Disclosure: values remain rough placeholders until replaced with official DPR, agency, survey, utility-shifting, acquisition, and statutory data.

6) Frontend interaction and mobile UX

The interface is built as a dense planning tool on desktop and a map-first simulator on mobile. On smaller screens, panels move into bottom drawers with icon navigation so the map stays usable.

• Desktop: metrics, scenario details, road editor, layers, and timeline remain visible beside the map.
• Mobile: search, scenario, editor, layers, and timeline open as drawers with close controls and a top play/pause action.
• Search: place search pans the map, closes results after selection, and pulses the selected point briefly.
• Animation: arrows and heat movement are tuned for visibility over map tiles and zoom levels.

7) Deployment, SEO, analytics, and persistence

Traffic Lab is prepared for deployment at trafficlab.azonova.com with Cloudflare-backed hosting. The app includes structured metadata, JSON-LD, Open Graph assets, compressed WebP/AVIF imagery, PWA icons, Google Analytics events, and local scenario persistence.

• Framework: Next.js and TypeScript, with static data publishing for processed map files.
• Hosting path: Cloudflare deployment flow from a connected GitHub repository.
• Analytics: events track major simulator actions such as play/pause, scenario runs, road edits, drawer usage, search, and layer toggles.
• Branding: transparent browser favicon plus solid Apple/PWA icons and optimized cover/social images.

8) Limitations and responsible use

Traffic Lab intentionally labels itself as a simulation. It does not replace traffic counts, microsimulation, signal-timing studies, land acquisition records, environmental review, utility mapping, safety audits, or public consultation. Its value is rapid comparison and explanation, not final statutory approval.

Explore the live product at trafficlab.azonova.com or contact Azonova for civic simulation, geospatial tooling, and product engineering work.