AirTrace

Trace PM2.5 pollution from sensor anomalies to evidence-supported candidate source regions.

Comment

Inspiration

Air pollution is easy to observe, but much harder to investigate.

Taiwan has a dense network of PM2.5 sensors capable of revealing local pollution patterns in great detail. However, a concentration spike alone does not explain where the polluted air may have come from.

Investigating an event means connecting sensor measurements with time, location, weather conditions, wind direction, industrial facilities, emissions data, and possible fire activity. These datasets exist, but they are fragmented and difficult to examine together.

AirTrace was built to connect them into a single environmental investigation workflow.

The goal is not to automatically blame a facility or claim legal attribution. Instead, AirTrace narrows the search to evidence-supported candidate source regions while clearly showing where uncertainty remains.

What it does

AirTrace monitors PM2.5 observations and looks for abnormal pollution patterns across nearby sensors.

When a meaningful event is detected, the system:

  1. Detects abnormal PM2.5 observations.
  2. Groups related observations into an event.
  3. Reconstructs the local wind field from weather observations.
  4. Traces particles backward through that wind field.
  5. Estimates candidate source regions.
  6. Compares those regions against independent public evidence, including facilities, CEMS context, and NASA FIRMS fire hotspots.
  7. Presents the result in an interactive evidence map together with uncertainty and supporting context.

AirTrace currently focuses on a pilot area around Wugu and Xinzhuang in Taiwan rather than attempting nationwide attribution.

It supports three workflows:

LIVE uses locally recorded environmental observations and shows the latest available analysis state.

REPLAY runs the same analysis pipeline over a bounded historical time window.

Synthetic Validation provides a deterministic scenario that can reproduce the full pipeline immediately without requiring API credentials or previously collected live data.

An important part of the design is that AirTrace is allowed to return no convincing source. If the available evidence is insufficient, the system does not force an attribution.

How we built it

The backend is written in Python and exposed through FastAPI.

DuckDB is used to store locally recorded PM2.5, weather, and supporting environmental data.

The analysis pipeline combines several stages:

PM2.5 observations → anomaly detection → event clustering → validated wind field → backward particle tracing → relative source evidence → facility / FIRMS / CEMS context

Environmental data comes from several public sources:

  • Taiwan Ministry of Environment micro-sensor and environmental open data
  • Taiwan Central Weather Administration weather observations
  • NASA FIRMS VIIRS fire-hotspot observations
  • OpenStreetMap for geographic visualization

The frontend is built with React and TypeScript using MapLibre GL JS for the interactive map.

Rather than treating every dataset as equally reliable or pretending that the result is an exact probability, AirTrace keeps the distinction between observations, reconstructed conditions, candidate evidence, and attribution.

Challenges we ran into

The largest challenge was not displaying data on a map. It was combining datasets that operate at different spatial resolutions, different time intervals, and different levels of reliability.

Wind reconstruction was especially important. A backward trace is only useful if the wind field used to drive it is reasonable, so the project includes leave-one-station-out validation for the reconstructed wind field.

Another challenge was avoiding false confidence.

A facility being geographically compatible with a backward trace does not prove that it caused an event. A missing FIRMS hotspot does not prove that no fire existed. Micro-sensors themselves have placement, calibration, and quality uncertainty.

Because of this, AirTrace was designed around evidence and uncertainty rather than a single definitive answer.

Reproducibility was another challenge. A fresh clone does not contain historical live observations or private API credentials, so a deterministic synthetic validation scenario was added to make the complete pipeline immediately testable.

Accomplishments that we're proud of

AirTrace became more than a pollution visualization dashboard.

The finished system connects sensor observations, anomaly detection, event clustering, reconstructed weather, backward particle tracing, geographic evidence matching, and an interactive frontend into one working pipeline.

The project also includes multiple forms of validation:

  • Wind-field leave-one-station-out validation
  • Deterministic synthetic source recovery
  • A real known-fire blind replay
  • Post-hoc sensor and spatial diagnostics

The blind replay was performed without providing the known-fire coordinates to the analysis pipeline.

Equally important, AirTrace does not force known events into detections when the available evidence is insufficient. A negative result is still a meaningful result.

What we learned

The project changed how I think about environmental data.

At first, pollution source tracing can look like a simple problem of following the wind backward. In practice, each additional data source introduces new uncertainty: sensor reliability, missing observations, interpolation, changing weather, geographic coverage, and incomplete emissions information.

I learned that building a useful environmental investigation system is not only about making the algorithm more powerful. It is also about communicating what the algorithm does not know.

I also gained experience integrating environmental APIs, geospatial processing, time-series analysis, backward particle tracing, local data storage, backend APIs, frontend visualization, automated testing, and validation into one system.

What's next for AirTrace

AirTrace is currently a pilot rather than a nationwide attribution service.

Future work could expand geographic coverage, improve atmospheric reconstruction, incorporate additional environmental datasets, strengthen calibration and validation against independently documented events, and make long-term live monitoring easier to deploy.

A longer-term goal would be to compare multiple candidate explanations and show how the available evidence changes over time instead of treating pollution investigation as a single static result.

Most importantly, future versions would preserve the same principle as the current system:

AirTrace should help investigators know where to look next — not pretend to know more than the evidence supports.

Development note

AirTrace was developed with assistance from AI coding tools, including OpenAI ChatGPT and Codex, for design discussion, implementation, debugging, testing, and documentation.

Project direction, system design, validation choices, and the final submitted results were reviewed and directed by the author.

Built With

Share this project:

Updates

Submission history