ASTraM is an operational decision-support system for Bengaluru Traffic Police (BTP) that turns a planned event — an IPL match, a political rally, a festival, a flooding alert — into a concrete, field-ready traffic plan: which junctions will choke, when, how many constables to post where, which diversions to open, and what inaction would cost the city.
The repository holds two connected pieces:
| Part | What it does | Entry point |
|---|---|---|
| Command Center | Flask API + browser dashboard that predicts event impact and generates bandobast orders | app.py, engine/ |
| Demand Forecasting Pipeline | Gradient-boosted ensemble that forecasts geohash-level traffic demand from the hackathon dataset | solution.py |
| gridlock-traffic-demand.vercel.app | Landing page — the problem, the model, the results |
| /console | The command console — run a prediction |
The build is declared in the repository rather than left to auto-detection:
vercel.json selects the Python runtime and routes every request to the
Flask app, and .vercelignore keeps the dataset and test suite out of
the serverless bundle. Dependency versions are floors rather than pins, and the Python
version is the platform default, so the build is declared but not byte-reproducible.
- 2D Spatial Demand Engine — Leaflet map rendering junction impact radiuses, congestion severity, and venue locations across 10 BTP traffic zones.
- 3D WebGL Tactical Mode (Beta) — Three.js model of M. Chinnaswamy Stadium with floating venue signboards, gate entrances (Gates 1, 2, 12, 18), pedestrian crowd swarms, animated vehicles, and on-duty constable positions.
- Generates deployment orders specifying constable staffing, barricade engineering guidelines (Type-A / Type-B), and signal override timings.
- Recommends diversion routes to cut commuter delay, broken down by zone and shift window.
- Formats low-bandwidth, copy-paste-ready alert messages for broadcast to division traffic officers.
- Interactive dispatch simulator with delivery status indicators.
- Quantifies last-mile delivery SLA disruption and the financial risk attached to it.
- Helps logistics hubs pre-position fleets ahead of peak congestion windows.
- Prices commuter time, fuel wastage, and emergency-response delay with and without deployment.
- Models excess CO₂ emissions from idling vehicles.
The engine/ package is the domain core. It is deterministic and dependency-light — no
model artifacts to ship, no external API calls at request time.
| Module | Responsibility |
|---|---|
bengaluru_kb.py |
Knowledge base: 28 junctions, 10 venues, 8 event types, 10 BTP zones, plus economic constants |
impact_predictor.py |
Spatial-temporal congestion propagation — distance decay, hourly load profile, BPR delay function against junction capacity, seasonality (IPL off-season scaling, monsoon delay factors) |
deployment_generator.py |
Bandobast order: shift windows, constable assignments, barricades, signal overrides, diversions, WhatsApp alert |
cost_analyzer.py |
With/without-deployment cost comparison, savings, and deployment ROI |
Each junction carries real coordinates, base capacity (vehicles/hr), normal-day constable strength, road type, and zone, so impact is scored against actual road capacity rather than a generic index.
Modelled event types: IPL match · political rally · religious festival · concert · exhibition · rain flooding · construction · VIP movement.
solution.py is the Gridlock 2.0 competition pipeline. It trains directly on the
demand target (no scaling noise) and blends three gradient-boosting engines.
Data — dataset/: 77,299 training rows and 41,778 test rows keyed by
geohash, day, and timestamp, with RoadType, NumberofLanes, LargeVehicles, Landmarks,
Temperature, and Weather as covariates. Target demand is normalised to [0, 1]; scoring is R².
Feature engineering (run_feature_engineering):
geohash_hour_mean— historical demand at the same geohash and hour on the previous dayearly_morning_mean— location-specific morning baseline for the current day, separating weekday from weekend profilesgeohash_target_enc— out-of-fold target encoding over geohashes- Geohash prefix groupings (2/3/4-char) so tree models can pool nearby locations
- Proximity to Bengaluru hotspots — Majestic, Whitefield, Electronic City, Manyata
- Inline base32 geohash decoding to lat/lon — no geospatial dependency required
Modelling (train_and_predict): LightGBM, XGBoost, and CatBoost trained under K-fold CV, then
blended with SciPy SLSQP-optimised linear weights (5-fold, random_state=42). Each booster is imported lazily and skipped if
unavailable, so the pipeline degrades gracefully to whichever engines are installed.
post_process.py is a small submission utility that rescales baseline
predictions.csv demand by fixed multipliers (1.12 / 1.16 / 1.20), clipped to [0, 1].
.
├── app.py # Flask server — page + API routes
├── engine/
│ ├── bengaluru_kb.py # Junctions, venues, event types, zones, economic constants
│ ├── impact_predictor.py # Spatial-temporal impact model
│ ├── deployment_generator.py# Bandobast order + WhatsApp alert generation
│ └── cost_analyzer.py # Economic disruption & ROI model
├── templates/
│ ├── landing.html # Landing page (/)
│ └── index.html # Command console (/console)
├── static/
│ ├── css/
│ │ ├── tokens.css # Design tokens — the only file with colour literals
│ │ ├── landing.css
│ │ └── styles.css
│ ├── js/landing.js
│ └── js/app.js # Leaflet 2D map + Three.js 3D tactical mode
├── solution.py # Demand forecasting pipeline (LGBM + XGB + CatBoost blend)
├── post_process.py # Submission rescaling utility
├── dataset/ # train.csv, test.csv, sample_submission.csv
├── tests/ # pytest suite for the engine and API
├── .github/workflows/ # CI — runs the suite on push and PR
├── requirements.txt # Web app dependencies
├── requirements-ml.txt # Forecasting pipeline dependencies
├── requirements-dev.txt # Web app + pytest
├── ARCHITECTURE.md # System design reference
└── UPGRADES_AND_ROADMAP.md # Backlog and planned work
git clone https://github.com/rajdeepchatale/gridlock-traffic-demand.git
cd gridlock-traffic-demand
pip install -r requirements.txt
python3 app.pyThe server starts on http://127.0.0.1:5000 — the landing page at /, the command
console at /console. Configure it with environment variables:
| Variable | Default | Purpose |
|---|---|---|
PORT |
5000 |
Port to listen on |
HOST |
127.0.0.1 |
Interface to bind |
FLASK_DEBUG |
off | Enables the Werkzeug debugger — local use only, never on a public host |
pip install -r requirements-dev.txt
pytest # 342 tests — engine, API, tokens, stylesheet disciplineBrowser tests run separately, since they need a real browser:
playwright install chromium
pytest -m browser # 19 tests — both pages, both themes, responsiveThe default run covers the knowledge base, the impact model's invariants, order
generation, the economic model, the API contract, WCAG contrast for every token
pair in both themes, and the rule that no stylesheet outside tokens.css
contains a colour literal.
requirements.txt covers the web app only — the pipeline needs the ML stack:
pip install -r requirements-ml.txt
python3 solution.py # writes predictions.csv
python3 post_process.py # writes predictions_x1.12/1.16/1.20.csvRuns the full pipeline: impact prediction → deployment order → economic analysis.
Response:
{
"success": true,
"impact": { "event", "seasonality", "impact_summary", "junction_impacts", "timeline" },
"deployment": { "order_reference", "generated_at", "event", "shift", "resources",
"assignments", "barricade_locations", "signal_overrides",
"diversions", "zone_breakdown", "whatsapp_alert" },
"economics": { "without_deployment", "with_deployment", "savings", "deployment_investment" }
}Inputs are validated before the pipeline runs. An unknown event type or venue,
a malformed date or time, a non-positive or implausible crowd, or coordinates outside the
Bengaluru region return 400 with { "success": false, "error": "..." } naming the offending
field. Unexpected server faults return 500 with a generic message and log the traceback
server-side.
Returns the event types, venues, junctions, and zones the UI populates its controls from.
ARCHITECTURE.md documents the system design — request lifecycle, layer boundaries, the eight-stage computation model with its BPR delay function and calibration constants, data contracts, the decoupled ML pipeline, and known gaps.
Planned work is tracked in UPGRADES_AND_ROADMAP.md — dynamic 3D team buses and monsoon shaders, IPL fixture and live weather integration, Flipkart hub-level delivery risk mapping, Kannada/English dual-language dispatch alerts, PDF bandobast export, and spatial heatmap smoothing.
This is a hackathon prototype built for Gridlock Hackathon 2.0. It is not an official Bengaluru Traffic Police system and is not affiliated with or endorsed by BTP, Flipkart, or any event organiser. Deployment orders, alerts, and cost figures it generates are illustrative model output, not operational instructions.
{ "event_type": "ipl_match", // key from EVENT_TYPES "venue_id": "chinnaswamy", // key from VENUES, or "custom" "event_date": "2026-04-15", "event_time": "19:30", "expected_crowd": 34000, // optional — defaults to venue capacity x event factor x season "custom_lat": 12.9788, // optional — overrides coordinates when venue_id is "custom" "custom_lon": 77.5996 }