Bengaluru AQI Forecaster: Next-Day Air Quality Prediction from CPCB Station Data (Python, scikit-learn, Power BI)

Bengaluru AQI Forecaster is a machine-learning project that predicts the next day's Air Quality Index (AQI) for each air-monitoring station in Bengaluru and converts every forecast into the matching health-advisory band of the CPCB's National AQI scale — Good, Satisfactory, Moderate, Poor, Very Poor or Severe.

India's National Air Quality Index, launched in 2014, compresses readings of eight pollutants into one 0–500 number and six colour-coded bands. Bengaluru, a city of over eleven million people, is covered by only about a dozen continuous monitoring stations operated by the CPCB and the Karnataka State Pollution Control Board, and what citizens see today is a bulletin of current values — never a warning about tomorrow. Morning walkers, schools, outdoor workers and asthma patients learn that the air turned Poor only after it has already turned Poor. This project closes that gap with open data: it pulls station-level readings from the Government of India's data.gov.in platform, learns each station's seasonal and weekly behaviour, and predicts tomorrow's AQI per station.

The stack follows the BCA syllabus closely: Python for the pipeline, scikit-learn for the models, MySQL for storage and Power BI for analytics, with Flask added as an industry-standard extra to serve the dashboard. It demonstrates the complete data-science workflow — ingestion, cleaning, feature engineering, model comparison, evaluation against a persistence baseline and deployment — which makes it a solid, viva-defensible choice for a BCA project in the AI/ML stream.

Bengaluru residents currently get air-quality information only as current readings from CPCB/KSPCB bulletins and apps. There is no public, station-wise forecast for tomorrow, so sensitive groups — asthma patients, children, outdoor workers, morning exercisers — cannot plan around the Poor-band episodes that repeatedly occur in winter and after festivals. Behind this sit concrete data problems: a sparse network of roughly a dozen continuous stations covering a large city, frequent missing values in the raw feed, sharp spatial variation between traffic junctions and residential areas, and strong seasonality that simple averages ignore.

There is a need for a reproducible machine-learning system that ingests the official open data, models each station's history with proper time-series discipline (no data leakage, rolling-origin validation), predicts next-day AQI, translates it into the CPCB's six health-advisory bands, and presents the result in a dashboard that a non-expert can read in five seconds — all on zero-budget, open-source tooling.

Abstract

This project builds and evaluates a next-day air-quality forecasting service for Bengaluru using exclusively open government data. An automated pipeline ingests station-level AQI readings from the data.gov.in "Real time Air Quality Index from Various Locations" resource, cleans and stores them in MySQL, engineers time-lagged and rolling-average features, and trains regression models (linear regression, random forest, gradient boosting) plus a companion classifier that maps each forecast to the CPCB's six official health bands. Every model is compared against a persistence baseline ("tomorrow equals today") using MAE, RMSE, R² and macro-F1 under time-series cross-validation. Results are served through a Flask dashboard and analysed in Power BI.

Introduction

Bengaluru's air is usually rated Satisfactory to Moderate, but December–February brings stagnant winds, construction dust and traffic emissions that push several stations into the Poor band, and Deepavali adds short, severe spikes. The city's official network of continuous monitoring stations is small relative to its population, and readings differ sharply between a junction like Silk Board and a green area like Hebbal. Because pollution drives asthma, bronchitis and cardio-vascular stress, a reliable one-day warning lets people move workouts indoors, schools reschedule play periods and hospitals expect more OPD cases.

Existing System

• CPCB and KSPCB publish bulletins and portals showing current AQI per station, refreshed hourly.
• Consumer apps relay the same current readings, often with maps and push alerts for today's levels.
• Meteorological agencies issue city-level pollution advisories only during major episodes.
• Limitations: no station-wise next-day forecast in the public domain; no plain-language advisory mapping for ordinary users; no historical analytics a college or researcher can re-run; citizen action is always reactive.

Proposed System

• An ETL pipeline that calls the data.gov.in AQI API daily, handles missing readings and stores a two-year history of all Bengaluru stations in MySQL.
• A feature builder producing lag values (AQI at t−1, t−24), 3-hour and 24-hour rolling means, calendar features (month, day-of-week, festival flag) and meteorological variables.
• Model training and backtesting with scikit-learn under rolling-origin (time-series) cross-validation, benchmarked against the persistence baseline.
• A band classifier that converts predicted concentrations into the six CPCB advisory bands with class-imbalance handling.
• A Flask dashboard (per-station forecast, dominant pollutant, advisory text) and a Power BI analytics page (trends, station comparison, band distribution).

Feasibility Study

• Technical: the data source is a documented public API; scikit-learn, pandas and MySQL are free and well documented; every experiment is reproducible from a laptop.
• Economic: ₹0 — no paid APIs, no cloud bill; the pipeline runs on a machine with 8 GB RAM.
• Operational: dashboards need no training to read; re-training is a single scheduled command, so a college can keep the system running after the project ends.

In scope

• All Bengaluru CAAQMS stations reporting on the data.gov.in AQI feed (CPCB/KSPCB network).
• Up to two years of historical readings; daily scheduled ingestion going forward.
• Forecast horizon: next-day (24 h) AQI and dominant pollutant per station.
• Output mapped to the six official CPCB bands with advisory text.
• Three regressors + one band classifier + persistence baseline; experiments logged in MySQL.
• Flask web dashboard and Power BI analytics dashboard.

Out of scope (v1)

• Sub-hourly or multi-day (3/7-day) forecasting.
• Emission-source modelling (traffic counts, industry inventories) or chemical transport simulation.
• Calibrating low-cost community sensors against CAAQMS references.
• Push notifications, mobile apps and multi-city production deployment.
• Weather forecasting itself — meteorological variables are consumed as input features, not produced.

The project follows the Incremental SDLC model: a thin end-to-end pipeline (pull → store → predict → display) is built in the first increment and then improved in controlled iterations, so there is always a demonstrable system for the guide and the three internal reviews.

Team division: Member 1 owns the ETL and database layers, Member 2 owns features, models and evaluation, Member 3 owns both dashboards and the documentation of results.

Testing approach: unit tests for the AQI band function (CPCB breakpoints) and feature builder; integration tests for the ETL against recorded API fixtures; walk-forward backtests on unseen months; error analysis split by season and station to check that winter Poor-band episodes are not systematically missed.

The system is organised in four layers with clear contracts between them:

1. Ingestion layer — a scheduled Python job calls the data.gov.in AQI API with an API key, normalises field names and units, flags missing pollutants and appends new readings to MySQL.
2. Data layer — MySQL keeps stations, raw readings, derived features, trained model metadata, forecasts and evaluation metrics; all dashboards read from this single source of truth.
3. Modelling layer — a scikit-learn pipeline builds features from MySQL, trains the three regressors and the band classifier, persists them as joblib artefacts and writes every backtest metric to the database for comparison.
4. Presentation layer — a Flask app renders station-wise forecast cards and advisory banners, while Power BI connects directly to MySQL for trend analytics.

flowchart TD
  D["data.gov.in AQI API"] -->|"daily scheduled pull"| E["ETL job — Python, pandas"]
  E -->|"clean readings"| DB[(MySQL)]
  F["Feature builder — lags, rolling means, calendar"] -->|"feature rows"| M["scikit-learn models"]
  DB --> F
  M -->|"joblib artefacts"| A["Model store"]
  M -->|"backtest metrics"| DB
  M -->|"next-day AQI + band"| DB
  DB --> W["Flask dashboard"]
  DB --> P["Power BI analytics"]
  W --> U(["Citizen / student / researcher"])
  P --> V(["Analyst / guide / review panel"])

ER diagram

erDiagram
  STATION ||--o{ READING : produces
  READING ||--o{ READING_FEATURE : "is expanded into"
  STATION ||--o{ FORECAST : receives
  MODEL ||--o{ FORECAST : generates
  MODEL ||--o{ EVALUATION : "is scored by"

  STATION {
    int station_id PK
    string station_code UK
    string station_name
    string city
    float latitude
    float longitude
  }
  READING {
    int reading_id PK
    int station_id FK
    datetime observed_at
    decimal pm25
    decimal pm10
    decimal no2
    decimal so2
    decimal co
    decimal o3
    int aqi
    string dominant_pollutant
  }
  READING_FEATURE {
    int feature_id PK
    int reading_id FK
    decimal aqi_lag1
    decimal aqi_lag24
    decimal aqi_roll3
    decimal aqi_roll24
    float temperature
    float humidity
    float wind_speed
    int is_festival
  }
  MODEL {
    int model_id PK
    string model_name
    string algorithm
    string hyperparameters
  }
  FORECAST {
    int forecast_id PK
    int station_id FK
    int model_id FK
    date target_date
    decimal predicted_aqi
    string predicted_band
    datetime created_at
  }
  EVALUATION {
    int eval_id PK
    int model_id FK
    decimal mae
    decimal rmse
    decimal r2
    decimal f1_macro
  }

Data flow (level 0)

flowchart LR
  G(["data.gov.in AQI feed"]) -- "station readings" --> S(("Bengaluru AQI\nForecaster"))
  S -- "ETL status, gaps report" --> G
  S -- "forecast + advisory" --> C(["Citizen"])
  S -- "metrics, trends" --> R(["Guide / reviewer"])

Key design decisions: readings and derived features are kept in separate tables so features can be rebuilt without touching source data; every forecast records which model produced it, enabling honest A/B comparison; and the persistence baseline lives beside the ML models in the same metrics table, so improvement over the naive forecast is always visible.

• Multi-day horizons (3-day and 7-day) with uncertainty intervals via quantile regression.
• Deeper sequence models — a GRU/LSTM comparison against the gradient boosting baseline.
• Weather-forecast features from public meteorological services so the model uses tomorrow's predicted wind and humidity, not just yesterday's.
• Low-cost sensor fusion — calibrating community sensor networks against CAAQMS references to densify coverage.
• Alerts — WhatsApp/SMS advisories to schools and hospitals when a Poor band is predicted.
• Spatial interpolation (kriging or IDW) to estimate AQI between stations, plus a public API endpoint for other student projects.