Decision support for event-driven traffic congestion, planned and unplanned.
FLOWITS is a decision-support system for traffic control rooms. When a planned event (an IPL match, a rally, a festival) or an unplanned incident (an accident, a breakdown, waterlogging) is about to choke a corridor, FLOWITS forecasts how severe it will get, how long it will last, and the real risks around it, then plans the manpower, the barricading, and the public diversion before it happens. It learns from every logged outcome, so it gets sharper with use.
An officer gives only three things: the event type, the location by name, and the time. The model works out the rest.
| Live demo | https://flowits.onrender.com/ |
| Demo video | https://youtu.be/OEUOyBrtzH0 |
An incoming event runs through the Severity Engine, the FLOWITS Engine orchestrates a Deployment Planner and a Diversion Planner, and the officer receives a complete plan. An incident database and an outcome feedback loop retrain the model, and a live news feed supplies upcoming events.
- Report incident. The officer enters event type, location, and time.
- Predict severity and duration. Two gradient-boosting models forecast how bad and how long.
- Plan deployment. Officers and barricades are placed on the corridor graph.
- Plan diversion. A reroute is drawn around the blockage on a live map.
- Congestion eased. The outcome is logged and feeds back into the model.
The problem statement asks us to handle event-driven congestion, both planned and unplanned, end to end: see it coming, judge how bad it is, and plan the response. We solved this by combining a trained machine learning core with a transparent operational playbook and a graph-based planner, all behind an officer-first interface. This section walks through how each piece works and why we chose it.
A control-room officer can tell you the event type, the location by name, and the time, but not latitude and longitude or a severity score. So the system is built around those three inputs and fills in everything else. It also leads with impact (the real consequences) rather than a raw number, because that is what an officer acts on.
The models are trained on a dataset of 8,057 real Bengaluru traffic incidents. From each incident we build 12 leakage-controlled features, including:
- Historical closure rates by cause, junction, corridor, zone, and spatial cluster (how often that kind of incident or that place needed a road closure in the past).
- Time signals: hour of day, day of week, weekend flag, peak-hour flag.
- The
is_plannedflag (planned event vs unplanned incident) and the reported priority.
K-Means clustering groups all incident locations into 15 spatial risk zones, so a brand-new location inherits the behaviour of its neighbourhood. To avoid data leakage, all historical rates are computed on the training split only, never on the test data.
- Severity classifier (
scikit-learnGradientBoostingClassifier): predicts one of four response classes (Monitor, Single officer, Standard response, Maximum response). We chose gradient boosting because it is the strongest general approach for small-to-medium tabular data with mixed signals and non-linear interactions, it is robust without heavy tuning, and it returns both class probabilities and feature importances, which makes every prediction explainable rather than a black box. The high-severity classes are rare, so we use balanced class weights and tuned decision thresholds for classes 2 and 3 to recover them without wrecking the common classes. - Duration regressor (GradientBoostingRegressor): predicts how many minutes the incident will take to clear, shown as an approximate range.
Severity classifier (four classes), validated with 5-fold cross-validation:
| Metric | Value |
|---|---|
| Cross-validated F1 (weighted) | 0.859 (plus or minus 0.009) |
| ROC AUC (one vs rest) | 0.974 |
| Accuracy | 0.83 |
| Training / test incidents | 6,445 / 1,612 |
Per-class F1. The two high-severity classes are rare in the data, and we show that weakness rather than hide it. The app asks an officer to confirm those on the ground.
| Class | Response | F1 |
|---|---|---|
| 0 | Monitor only | 0.87 |
| 1 | Single officer | 0.92 |
| 2 | Standard response | 0.38 |
| 3 | Maximum response | 0.26 |
Duration regressor:
| Metric | Value |
|---|---|
| Mean absolute error (MAE) | about 52 minutes |
| Root mean squared error (RMSE) | about 80 minutes |
Top feature importances (what drives the severity forecast):
| Feature | Importance |
|---|---|
| Reported priority | 48% |
| Cause closure rate | 16% |
| Junction closure rate | 12% |
| Corridor closure rate | 6% |
| Hour of day | 5% |
The full confusion matrix is published on the About page for transparency.
Statistics cannot know that an IPL match or a political rally is inherently high impact, or that a night-time gathering carries a higher theft and altercation risk, because those signals are not in the data. The playbook is a transparent, stated rule layer that sits on top of the model: it applies severity floors for marquee events, adds secondary-risk watch-fors (crowd surge, pickpocketing, scuffles), and amplifies risk at peak hours and at night. It is clearly labelled as operational rules, not model output, so the system stays honest.
Each supported corridor is modelled as a NetworkX directed graph of junctions. An impact score spreads from the incident to nearby and downstream junctions. A greedy allocator then places officers on the highest-impact junctions first, and barricades on the bottleneck junctions (in-degree of 2 or more, where traffic streams merge). The size of the resource pool scales with the model's severity class:
| Severity class | Officers | Barricades |
|---|---|---|
| Monitor only | 0 | 0 |
| Single officer | 1 | 0 |
| Standard response | 3 | 2 |
| Maximum response | 6 | 4 |
Finally we compute a before-and-after risk reduction so the officer can see the value of the plan (a stated 35 percent mitigation per resourced junction, pending calibration against real deployment data).
To reroute the public around the blockage, we take the corridor graph, remove the blocked junction, and add parallel bypass edges weighted with a 1.6 times detour cost. We then run Dijkstra's shortest-path algorithm (via NetworkX, using edge travel-time weights) from the intercept point to the rejoin point on the far side, which gives the lowest-time reroute and the extra minutes the detour adds. This is the part of the problem statement (diversion planning) that most prototypes skip.
Upcoming events come from a Google News RSS feed (no API key needed), keyword-matched to known junctions and event types, with a curated watchlist so the board is never empty. Any event that maps to a supported corridor becomes a one-click pre-plan.
Officers think in maps and minutes, not in JSON, so the output is visual:
- Leaflet with OpenStreetMap tiles: a real Bengaluru map that shows the incident, the placed officers and barricades, and the diversion route, with an SVG schematic fallback if tiles fail to load.
- Recharts: an incidents-by-hour bar chart (to spot peak windows), a planned-vs-unplanned event-mix donut, a running-accuracy "learning loop" figure, and, on the About page, the per-class F1 bars and feature-importance bars.
- Confusion matrix image: published for model transparency.
- Printable briefing report (PDF): a one-click document with a peak-risk-by-hour chart that the control room can hand out.
Every logged outcome is stored and feeds back into the system, so the models retrain as real data accrues and accuracy improves with use rather than going stale.
End to end: the officer enters three fields, the models forecast severity and duration, the playbook adds the real-world impact, the corridor graph plans the manpower, the barricading, and a public diversion, a briefing is generated, and the outcome is logged to sharpen the next forecast. The result turns a reactive control room into a planning one, for both planned and unplanned events.
- Forecasts the severity and duration of event-driven congestion for both planned and unplanned events.
- Leads with impact: crowd surge, theft, scuffles, and queue build-up, in plain language.
- Recommends manpower and barricades per junction, scaled to the forecast severity.
- Lays out a public diversion on a real Bengaluru map (shortest path around the blockage).
- Generates a one-click briefing report (printable PDF) with a peak-risk-by-hour chart.
- Monitors a live event feed for upcoming rallies, matches, and incidents.
- Learns from every logged outcome to sharpen future forecasts.
| Layer | Technology |
|---|---|
| Frontend | React, Vite, TypeScript, Tailwind CSS |
| Visualisation | Leaflet (OpenStreetMap), Recharts |
| Backend / API | FastAPI, Pydantic, Uvicorn (Python 3.11) |
| Machine learning | scikit-learn (Gradient Boosting, K-Means) |
| Planning / routing | NetworkX corridor graph, Dijkstra shortest path |
| Live data | Google News RSS (stdlib urllib + ElementTree) |
| Deployment | Railway (the backend serves the built frontend) |
FLIPKART_PROTOTYPE/
├─ backend/
│ ├─ main.py # FastAPI app and API endpoints
│ ├─ train.py # trains the models, writes model_artifacts
│ ├─ requirements.txt
│ ├─ src/
│ │ ├─ model.py # gradient-boosting classifier + regressor
│ │ ├─ feature_engineering.py
│ │ ├─ graph_builder.py # corridor graph + Dijkstra diversion
│ │ ├─ allocation.py # officer / barricade allocation
│ │ ├─ playbook.py # transparent domain rule layer
│ │ ├─ events_feed.py # live Google News RSS + curated watchlist
│ │ ├─ feedback.py # outcome logging and learning loop
│ │ └─ schemas.py # Pydantic request / response models
│ ├─ model_artifacts/ # trained models (.pkl) + metrics.json
│ ├─ data/ # incident dataset
│ └─ static/ # built frontend served in production
├─ frontend/
│ ├─ src/
│ │ ├─ components/ # AppShell, dashboard, map, cards, forms
│ │ ├─ api/ # API client
│ │ └─ ...
│ └─ public/
├─ images/ # architecture and flow diagrams
└─ README.md
Prerequisites: Python 3.11+ and Node.js 18+.
The trained models are committed in backend/model_artifacts/, so the app runs without retraining.
cd backend
python -m venv .venv
# Windows:
.venv\Scripts\activate
# macOS / Linux:
source .venv/bin/activate
pip install -r requirements.txt
uvicorn main:app --port 8001To retrain the models from the dataset (optional):
python train.pycd frontend
npm install
npm run devOpen http://localhost:5173. The dev server expects the API on http://127.0.0.1:8001.
The backend serves the built frontend, so the whole app runs on one URL:
cd frontend
npm run build # outputs to frontend/dist
# copy the build into backend/static, then:
cd ../backend
uvicorn main:app --port 8001Open http://localhost:8001.
- Open-source libraries: FastAPI, Uvicorn, Pydantic, scikit-learn, NetworkX, pandas, NumPy, React, Vite, Tailwind CSS, Recharts, Leaflet, axios.
- Map tiles: OpenStreetMap (free, open data).
- Live event signal: Google News RSS (free, no API key).
- Fonts: Geist Pixel Grid (branding) and Inter (interface).
- Dataset: a Bengaluru traffic-incident dataset of 8,057 records, used to train and validate the models.
All other logic (the models, the corridor graphs, the playbook, the allocation and diversion, the UI) was built for this project.
- Extend from a few corridors to a full city, and onward to other cities, using the same framework.
- Connect to official event listings, CCTV and sensor feeds, and live GPS traffic data.
- Calibrate the manpower and barricade guidance against real deployment records.
- Deploy a Telegram bot as a field-facing front door, so an officer can get a full plan by messaging the event, location, and time, without opening the dashboard. It will reuse the existing API, so no separate model is needed.
- Add a mobile-friendly view and multi-language support.