Bangalore Traffic Demand Prediction

Table of contents

1. Executive summary
2. The problem in everyday terms
3. The data
4. How success is measured
5. Our mental model
6. Feature engineering
7. Models we used
8. Validation strategy
9. Experiment journey
10. Final solution architecture
11. Project file map
12. Glossary
13. Limitations and outlook
14. Elevator pitch

1. Executive summary

This project predicts how busy each road cell will be at a given time — similar to forecasting ride or delivery demand across a city grid.

We are given two days of historical traffic data and must predict demand for the next day at times we have never seen labels for. The best honest solution combines:

1. Smart data preparation — location, time, and “what happened recently”
2. Two complementary machine-learning models blended together
3. Simple rules where patterns are obvious (e.g. daytime often mirrors the previous day)

We reached 91.38 out of 100 on the public leaderboard. Scores of exactly 100 from many teams are likely from overfitting the public test set; the final evaluation is expected to use hidden data and a submitted Python script.

2. The problem in everyday terms

Imagine Flipkart needs to know:

“At 10:30 AM, in this small map square, how many deliveries or rides will we need?”

Each row in the dataset answers:

At this location (geohash), on this day, at this time — how high was demand?

• Demand is a number between 0 and 1 (normalized “busyness”, not a raw count).
• Location is a geohash — a short code for a map cell.
• Time is in 15-minute steps (0:0, 0:15, 0:30, …).

The twist that makes this hard

We must predict daytime on day 49 using mostly day 48 plus a tiny slice of day 49 night. We never see day-49 labels for 10 AM, 11 AM, etc. during training.

3. The data

3.1 Columns explained

3.2 Scale

3.3 Data flow (high level)

4. How success is measured

Metric: R² (R-squared)

Think of it as: “How much of the true pattern did we capture?”

R² punishes systematic mistakes heavily. If you predict everything 60% too high, the score collapses — even if the general shape looks right.

5. Our mental model

We treated this as three different sub-problems, not one uniform rule:

Why this split matters

Changing only hour 2 moved the score from 90.96 → 79.55 (−11 points). Hour 2 is small in row count but huge in score impact because night demand is high and spiky.

6. Feature engineering

Feature engineering = creating new columns that help the model. We did not feed raw timestamps alone.

6.1 Feature categories

6.2 Lag features (memory of the past)

6.3 Key discovery — 15-minute persistence

Demand at consecutive 15-minute slots is ~95% correlated. Test starts at 2:15; training labels for day 49 end at 2:00. So “use the 2:00 value” is a powerful rule for hour 2.

6.4 Cyclical time encoding

Raw hour treats 23:45 and 0:00 as far apart. Sin/cos encoding tells the model they are neighbors:

Same idea for 15-minute slots across the day.

6.5 What did NOT help

7. Models we used

A model learns patterns from past data and predicts future values. We used gradient boosted decision trees — many small decision trees combined, ideal for spreadsheet-like data.

7.1 Model comparison (simple view)

Quadrant positions are illustrative scores relative to our experiments, not exact measurements.

7.2 CatBoost

7.3 XGBoost + target encoding

7.4 Ensemble (our best public score)

Score: 91.38 — when one model is slightly wrong, the other often compensates.

7.5 Why not neural networks / RNNs?

8. Validation strategy

Bad approach: Randomly shuffle all rows → 80% train / 20% test.

Problem: Model sees future and past mixed together. Local scores look too good and mislead you.

Good approach (what we built):

On honest temporal validation, our improved pipeline reached ~87 R² on held-out night data — a realistic signal.

9. Experiment journey

9.1 Score timeline

9.2 Full submission log

9.3 Confirmed truths

1. Daytime (hours 3–13) ≈ same demand level as day 48 at same location and time (~89% exact match).
2. Hour 2 must use day-49 night data — not plain day-48 copy.
3. Demand is smooth over 15 minutes — recent history beats yesterday’s shape at night.
4. Public 100s likely overfit; final ranking may use hidden test data.

10. Final solution architecture

Recommended scripts to run

# Main pipeline (temporal CV + lags + CatBoost + XGB + ensemble)
python scripts/train/train_temporal.py

# CV only — check honest score without submitting
python scripts/train/train_temporal.py --cv-only

# Re-blend with proven 91.38 weights
python scripts/blend/blend_ensemble.py --w-xgb 0.6 --w-cat 0.4

11. Project file map

12. Glossary

13. Limitations and outlook

1. We cannot fully validate daytime day-49 locally — no labels for those hours in training.
2. ~9 points below public “100” may be unbridgeable without overfitting public test.csv.
3. Final ranking may favor models that generalize on hidden data over public leaderboard 100s.
4. Temperature and weather appear to be noise in this synthetic dataset.

14. Elevator pitch

We predict traffic demand on a city grid by combining where (geohash), when (time and recent 15-minute history), and what happened yesterday at the same place and time. Daytime is mostly stable and matches day 48; the tricky 2 AM hour needs fresh day-49 night data. Two tree-based models (CatBoost and XGBoost) learn these patterns and are blended for a 91.38 score. We validate honestly by simulating the real test — train on the past, predict unseen future times — so the solution is built to survive a hidden final test, not just chase a public leaderboard.