From Satellite Signals to Smarter Forecasts: Building an AI-Powered Air Quality Dashboard on AWS

From Satellite Signals to Smarter Forecasts: Building an AI-Powered Air Quality Dashboard on AWS

Introduction

Air pollution is a serious environmental challenge, particularly across Delhi, Punjab, and Haryana, where seasonal agricultural stubble burning can contribute to elevated particulate matter levels. Understanding air quality requires more than looking at current pollution readings. It also involves studying weather conditions, identifying nearby fire activity, and estimating how pollution levels may change over the next 24 to 48 hours.

That was the motivation behind Stubble Smoke Forecaster — an AI-powered air quality forecasting dashboard that combines satellite fire detections, weather information, and PM2.5 data to explore short-term pollution forecasting.

The project brings together machine learning, geospatial visualization, public environmental datasets, and AWS cloud architecture to create a system for exploring the relationship between fire activity and air quality.

The Problem: Connecting Fires, Weather, and Air Quality

PM2.5 refers to fine particulate matter with a diameter of 2.5 micrometers or less. These particles are small enough to penetrate deep into the respiratory system, making their concentration an important indicator of air quality.

However, predicting PM2.5 is challenging because pollution levels depend on several interacting factors:

- Fire activity: Agricultural fires can release smoke and particulate matter into the atmosphere.
- Weather conditions: Wind speed and direction influence how smoke travels.
- Atmospheric mixing: Boundary layer height affects how pollutants disperse.
- Humidity and precipitation: These conditions can influence particulate concentrations and atmospheric processes.
- Historical pollution: Recent PM2.5 measurements provide useful information about short-term trends.

A dashboard that combines these different signals can help users explore environmental patterns instead of relying exclusively on a single air quality measurement.

The objective was to build a system that brings these data sources together and generates forecasts for the next 24 and 48 hours.

The Project at a Glance

Stubble Smoke Forecaster combines a machine learning pipeline with an interactive web dashboard.

Its core components include:

- Machine learning: LightGBM quantile regression models for PM2.5 forecasting.
- Weather data: Open-Meteo weather variables.
- Air quality data: CAMS PM2.5 data.
- Satellite fire detections: NASA FIRMS VIIRS observations.
- Frontend: React and Vite.
- Visualizations: Recharts and Leaflet.
- Cloud architecture: AWS services for API delivery, computation, storage, notifications, monitoring, and deployment infrastructure.

The system is designed to make environmental data easier to explore through forecasts, maps, and visual comparisons.

1. Building the Environmental Data Pipeline

The first major challenge was bringing together environmental datasets that describe different aspects of the same problem.

NASA FIRMS: Satellite Fire Detections

NASA's Fire Information for Resource Management System (FIRMS) provides satellite-based fire and thermal anomaly detections.

For this project, FIRMS data helps represent fire activity across the region. These detections can be explored alongside air quality and weather information to investigate potential relationships between fire activity and pollution.

Satellite detections should not be interpreted as direct measurements of smoke concentration. They indicate detected fire activity, and their relationship to PM2.5 depends on factors such as distance, wind, atmospheric conditions, and observation timing.

CAMS: PM2.5 Data

The Copernicus Atmosphere Monitoring Service (CAMS) provides atmospheric composition information, including PM2.5-related data.

The project uses CAMS PM2.5 data as part of the air quality forecasting pipeline. Historical observations and related environmental variables help the model learn patterns associated with changes in particulate matter.

The data's spatial and temporal coverage must be considered when preparing training examples and evaluating forecasts.

Open-Meteo: Weather Features

Weather conditions influence how pollutants move and accumulate. The project uses Open-Meteo to retrieve weather-related variables, including:

- Wind speed and direction
- Boundary layer height
- Relative humidity
- Precipitation

These variables provide additional context for understanding air quality changes.

Data Alignment and Feature Engineering

Combining these sources is not simply a matter of joining files. They may have different timestamps, spatial resolutions, update frequencies, and missing-data patterns.

The pipeline therefore needs to align the data consistently before model training and inference. This includes preparing timestamps, matching relevant observations, handling missing values, and constructing model features.

Historical data coverage also matters. For example, the available FIRMS observations may not cover every location and date equally. These limitations affect the reliability of derived features and the conclusions that can be drawn from the model.

2. Forecasting PM2.5 with LightGBM Quantile Regression

Instead of relying on a single prediction model for each forecast horizon, the project uses six LightGBM quantile regression models.

LightGBM is a gradient-boosting framework based on decision trees. It can model nonlinear relationships between input features and a target variable, making it useful for structured datasets containing weather, historical pollution, and fire-related features.

Why Quantile Regression?

A conventional regression model typically predicts one central estimate. Quantile regression allows a model to estimate different points of a target distribution.

For this project, three quantiles are used:

- q10: A lower forecast quantile.
- q50: The median forecast.
- q90: An upper forecast quantile.

The lower and upper quantiles provide additional context around the median prediction. They can help communicate uncertainty, although they should not automatically be interpreted as calibrated prediction intervals without appropriate validation.

Forecast Horizons

The project produces forecasts for two time horizons:

Forecast horizon| Models
24 hours| q10, q50, q90
48 hours| q10, q50, q90

This results in six models in total.

The 24-hour forecast focuses on nearer-term changes, while the 48-hour forecast explores a longer horizon. As the forecast horizon increases, uncertainty can also increase because future weather and emissions-related conditions become harder to predict.

Evaluating the Forecasts

Forecast quality is evaluated using Mean Absolute Error (MAE), which measures the average absolute difference between predicted and observed values.

The project also examines severe-pollution classification performance using precision and recall. These metrics provide a different perspective from regression error: they measure how well the system identifies cases classified as severe under the chosen threshold.

It is important to evaluate these results against a simple persistence baseline — a forecast that assumes the latest available pollution value remains unchanged. A machine learning model is more useful when it demonstrates meaningful improvements over such a baseline.

The results should also be interpreted in the context of data coverage, forecast horizon, and the definition of a severe-pollution event.

3. Creating an Interactive Dashboard

A forecasting model becomes more useful when its output can be explored without requiring users to inspect raw data files or run Python scripts.

The frontend is built using React and Vite, with Recharts and Leaflet supporting visual analysis.

React and Vite

React provides the component-based structure for the dashboard, while Vite supports the frontend development and build workflow.

The interface brings the different parts of the project together so users can explore forecasts and environmental information in one place.

Recharts: Forecast Visualization

Recharts is used for chart-based visualization.

The forecast views can present predicted PM2.5 values across different horizons and compare lower, median, and upper quantile estimates. Such visualizations make it easier to inspect forecast trends and understand how different estimates relate to one another.

Leaflet: Geospatial Exploration

Leaflet supports interactive maps that help users explore the geographical distribution of fire detections and relevant environmental information.

Mapping is particularly valuable for this project because pollution and fire activity are spatial phenomena. A map can provide context that is difficult to communicate through a table of numbers alone.

Together, these tools form the visualization layer of Stubble Smoke Forecaster.

4. Designing the AWS Cloud Architecture

The project also explores how the forecasting application can be organized using AWS services.

The cloud architecture separates API access, computation, storage, notifications, monitoring, and infrastructure configuration into distinct responsibilities.

Amazon API Gateway

API Gateway provides an API entry point for clients. It can expose application endpoints without requiring the frontend to communicate directly with internal compute components.

AWS Lambda

Lambda provides serverless compute for supported backend operations. It can be used to handle API requests, execute lightweight processing tasks, and connect application logic to other AWS services.

A deployed implementation must ensure that the model's runtime dependencies, memory requirements, execution duration, and package size are compatible with the selected Lambda configuration.

Amazon DynamoDB

DynamoDB provides a managed NoSQL database for application data. Depending on the implementation, it can store forecast records, metadata, or other structured information needed by the application.

Amazon SNS

Amazon Simple Notification Service (SNS) can distribute notifications to subscribed endpoints. It provides a potential mechanism for notifying users when configured conditions or application events occur.

Amazon EventBridge Scheduler

EventBridge Scheduler is an optional component for running scheduled tasks. It could trigger periodic data processing or forecast-generation workflows, depending on how the pipeline is deployed.

Amazon Bedrock

Amazon Bedrock is an optional extension for generating natural-language summaries of forecast outputs.

For example, a language model could explain a forecast trend in accessible language. Such summaries should remain grounded in the model's actual outputs and must not be treated as a replacement for validated numerical forecasts.

AWS SAM and CloudFormation

AWS Serverless Application Model (SAM) and AWS CloudFormation support infrastructure-as-code workflows.

Rather than configuring every resource manually, infrastructure definitions can describe the resources and their relationships. This improves repeatability and makes changes easier to track and reproduce.

Amazon CloudWatch

CloudWatch provides monitoring and logging capabilities for AWS resources and application components. Logs and metrics are essential for identifying failures, investigating unexpected behavior, and understanding operational performance.

Amazon S3

Amazon S3 provides object storage and can be used for suitable artifacts, datasets, model files, or static assets, depending on the deployment design.

These services form a proposed set of architectural building blocks; optional components are not necessarily part of every deployed version of the application.

5. Local Development and Testing

Before relying on cloud resources, the project also considers local development and testing workflows.

Docker can help package application components into reproducible environments. DynamoDB Local can support development against a local DynamoDB-compatible endpoint, while SAM Local can help test supported serverless functions and API workflows.

One practical issue encountered during local testing was a mismatch in the database endpoint configuration. Local and deployed environments use different endpoints, so the application must be configured to connect to the intended database instance.

This illustrates an important lesson in cloud development: an application may have correct business logic and still fail because its environment configuration does not match the environment in which it is running.

Keeping local and production configuration separate helps reduce these issues.

6. Challenges and Lessons Learned

Developing Stubble Smoke Forecaster involves challenges beyond training a machine learning model.

Integrating Multiple Data Sources

Environmental datasets rarely share identical timestamps, geographic resolutions, or coverage. Careful alignment is necessary to prevent invalid comparisons and misleading model inputs.

Avoiding Data Leakage

Forecasting requires a strict distinction between information available at prediction time and information observed afterward.

Features must be constructed so that the model does not inadvertently use future information. Chronological validation is particularly important when evaluating time-dependent predictions.

Establishing a Meaningful Baseline

A sophisticated model is not automatically better than a simple forecasting method. Comparing LightGBM against a persistence baseline helps establish whether the additional complexity is justified.

Interpreting Severe-Pollution Metrics

MAE measures numerical error, while precision and recall measure event-detection performance. Both are useful, but neither alone provides a complete picture of model quality.

The definition of a severe event, class imbalance, and the consequences of false positives and false negatives all affect how these metrics should be interpreted.

Managing Cloud Configuration

Local emulators and deployed AWS resources may differ in their endpoints, permissions, environment variables, and runtime constraints. Infrastructure-as-code, clear configuration boundaries, and useful logging can make these differences easier to manage.

Understanding the Limits of Satellite Data

Satellite fire detections provide valuable context but do not directly quantify the amount of smoke reaching a specific location. Weather, transport, atmospheric mixing, and observation limitations all influence the relationship between detected fires and PM2.5.

These limitations should remain visible when presenting forecasts or drawing conclusions.

7. Potential Future Improvements

Several extensions could make the system more useful over time:

1. More rigorous time-series validation: Evaluate the models across multiple chronological test periods and different pollution conditions.
2. Better uncertainty evaluation: Check whether the q10 and q90 predictions provide appropriately calibrated forecast ranges.
3. Improved spatial features: Investigate how fire detections at different distances and directions relate to observed PM2.5.
4. Forecast monitoring: Track errors as new observations become available and identify changes in model performance.
5. Automated data refresh: Use scheduled workflows where appropriate to refresh input data and generate updated forecasts.
6. User notifications: Explore threshold-based notifications through SNS, with careful handling of false alarms.
7. Natural-language summaries: Add an optional Bedrock-powered explanation layer that describes forecasts without inventing facts or overstating certainty.
8. Operational evaluation: Measure API latency, compute costs, reliability, and the effort required to maintain the application.

These are potential directions for further development, rather than claims that every capability is already implemented.

Conclusion

Stubble Smoke Forecaster explores how machine learning, satellite observations, weather data, and cloud services can be combined to study a complex environmental problem.

The project uses NASA FIRMS fire detections, CAMS PM2.5 data, and Open-Meteo weather variables to build a forecasting pipeline based on LightGBM quantile regression. React, Recharts, and Leaflet provide an interactive way to explore the resulting forecasts and geographical context.

The AWS architecture introduces a path toward separating API access, compute, storage, notifications, scheduling, and monitoring into manageable components.

The broader lesson is that an environmental forecasting system is not just a model. Its usefulness also depends on data quality, time-aware evaluation, uncertainty communication, visualization, deployment design, and operational monitoring.

By connecting these elements, Stubble Smoke Forecaster provides a practical exploration of how AI and cloud infrastructure can support the analysis of air quality and seasonal fire activity.