Hyperlocal air-quality forecasting & pollution source attribution

Regulatory air-quality stations are few and expensive, and regional models resolve only ~10 km cells, while pollution varies from street to street. Hyperlocal systems fuse sparse reference stations, dense low-cost sensors, chemistry-transport model output, satellite data, traffic and weather with ML to forecast concentrations at street or district level and to apportion them to sources. Cities, regulators and large emitters use the result for clean-air plans, low-emission-zone decisions, event/traffic management and health alerts.

Problem & value

• Who: municipal environment offices, state environment agencies, port/airport/industrial operators, mobility planners, health services, and consumers (asthma, outdoor sport, route choice).
• Today: a handful of stations per city plus occasional dispersion-model studies. Source apportionment relies on campaign measurements and static emission inventories, updated rarely.
• Why now: the revised EU Ambient Air Quality Directive (EU) 2024/2881 sets tighter 2030 limit values (annual PM2.5 10 µg/m³, NO2 20 µg/m³ per the EEA [1]) and provides for modelling, air-quality roadmaps and short-term action plans, which raises demand for forecasting and attribution [2].
• Health burden (EEA, EU-27, 2022): about 239,000 premature deaths attributable to PM2.5 above the WHO guideline, 70,000 to ozone and 48,000 to NO2; exposure above the revised EU limit values alone accounts for ~84,000 PM2.5 deaths [1].
• Benefit: finer spatial resolution than regional models and earlier warning than station-only alerts; scenario testing before costly traffic measures. No vendor-independent, audited ROI figures are available — measure locally (see KPIs).

Variants

• Municipal clean-air management: sensor network + forecast + scenario tool for low-emission zones, school streets, construction logistics.
• Industrial/port/airport fence-line monitoring: attribute neighbourhood exceedances to site vs. background; early-warning to operators.
• Health alerts & public apps: personalised exposure/route guidance (private users) via APIs such as Google Air Quality (500 m grid, hourly forecast up to 96 h, EEA-billing users may use tiles on any map) [3].
• Indoor/outdoor linkage: ventilation control in schools/offices using outdoor forecasts (see building use cases).
• Wildfire/smoke and dust episodes: event detection from satellites and sensor clusters.
• Research/citizen science: open networks (Sensor.Community, Luftdaten) as additional data layers.

How it works

1. data ingest (stations, low-cost sensors, CAMS, weather, satellite, traffic, inventories)
2. QA & sensor calibration (drift, humidity correction, co-location with reference stations)
3. spatial/temporal fusion (data assimilation or ML downscaling to street/grid level)
4. forecast model (1–96 h) with uncertainty
5. source apportionment (receptor models, ML with feature attribution, or tagged-tracer dispersion runs)
6. scenario engine ("what if traffic -20 % / zone introduced")
7. alerts, maps, API, reports (human review for public warnings & policy)

• Calibration: low-cost optical PM and electrochemical NO2 sensors need ML correction (humidity, temperature, cross-sensitivity) against co-located reference instruments; this is usually the largest data-quality lever.
• Forecast core: gradient boosting or deep spatio-temporal models (graph/transformer) taking CAMS and weather forecasts as inputs; CAMS provides daily analyses and four-day forecasts from an ensemble of European chemistry-transport models (e.g. CHIMERE, EMEP, EURAD-IM, LOTOS-EUROS, MOCAGE, SILAM) [4].
• Attribution: statistical (PMF, regression with traffic/heating proxies), ML with SHAP-style explanations (correlational, not causal), or dispersion model runs with source tags. Causal claims need scenario/natural-experiment evidence.
• LLM role: explain results, draft bulletins and answer citizen questions; never compute concentrations.
• Human-in-the-loop: agency experts validate model skill, approve public warnings and any measure derived from attribution results.

Data preparation

• Which data: reference-station feeds, low-cost sensor streams, CAMS and weather forecasts, satellite products, traffic counts and emission inventories.
• Where it lives: state environment agency portals and EEA downloads, the sensor vendor's cloud, traffic-management systems, Excel emission inventories, PDFs of earlier dispersion studies.
• Typical gaps: sensor drift and humidity bias, missing timestamps and gaps, inconsistent station IDs and units, emission inventories that are years old, no co-located reference data for calibration.
• Steps: (1) inventory sources and owners (PREP-001), (2) pull data via APIs and connectors (PREP-005), (3) harmonise units, coordinates and time zones into tidy tables (PREP-011), (4) co-locate 3-5 sensors with a reference station and fit calibration models, (5) flag outliers and gaps, (6) build a validation set against reference instruments (PREP-018). Tools: Python, pandas, TimescaleDB, Copernicus APIs, Grafana for QA views.
• Effort share: roughly 50-60 %, calibration being the largest lever; DATA-007 style pipeline work for continuous feeds is needed in production.

Implementation paths

Which path for whom

• public (B): agencies should combine free CAMS/EEA data with a managed stack in a sovereign EU/German cloud, which satisfies procurement and sovereignty rules and keeps sensor data under their control; certified products only for the sensor layer.
• enterprise (B): port, airport and industrial operators need fence-line attribution fed with their own emission and process data, which no off-the-shelf product covers.
• developer (C): open CTM codes, PyTorch/XGBoost and TimescaleDB on HW2 give full control over calibration and attribution.
• private (A): consumers just need ready-made apps or APIs for exposure and route guidance.

Path A — Buy (off-the-shelf)

Sensor + platform vendors: Breeze Technologies (Hamburg, EU) with modular sensors, an "Environmental Intelligence Cloud", recommendations and a citizen portal piloted in Hamburg-Rothenburgsort [5]; further vendors exist but were not verified for this file. Forecast data services: Google Air Quality API (global, 500 m) [3]. Public CAMS data is free. Right for a quick pilot, for the sensor layer and for private users; for public bodies the longer-term fit is Path B on a sovereign EU cloud. Verify data residency and sensor certification (CEN/TS indicative-measurement classes).

Path B — Build on cloud APIs

Combine CAMS (Copernicus Atmosphere Data Store, free), Sentinel-5P via the Copernicus Data Space Ecosystem, EEA air-quality data and national station feeds with a managed time-series/ML stack in an EU cloud region (e.g. StackIT, OVHcloud, IONOS, or hyperscaler EU regions). Add the Google Air Quality API as a baseline or benchmark. LLM (EU-hosted, e.g. Mistral) only for reporting. Suited to engineering firms and municipal utilities (Stadtwerke).

Path C — Self-host (open source)

Open data and models: CAMS ensemble members and open dispersion/CTM codes (CHIMERE, EMEP, LOTOS-EUROS, SILAM, OpenFOAM-based microscale), PyTorch/XGBoost, MLflow, TimescaleDB/InfluxDB, Apache Kafka or MQTT for sensor streams, Grafana for maps. Foundation weather models (Aurora, open weights) can be fine-tuned for air quality [6]. One GPU workstation (HW2) is enough for inference and downscaling; CTM runs need CPU clusters. Ops effort: a part-time data engineer plus an atmospheric scientist.

Path D — Custom training

Worth it when you own a dense local sensor network and long histories (>1–2 years, several seasons). Train city-specific downscaling/forecast models, calibration models per sensor type and attribution models. Needs reference-station co-location, traffic and emission data, and a validation protocol against reference instruments.

State of the art (2026)

• Foundation models: Microsoft's Aurora, a large Earth-system foundation model, is reported to beat operational forecasts on air quality among other tasks at orders-of-magnitude lower compute than dedicated numerical systems, and can be fine-tuned at modest cost [6]. Operational CAMS remains the authoritative European baseline [4].
• Satellites: Sentinel-5P TROPOMI delivers NO2, O3, CO, SO2, HCHO and aerosol-index products [7], useful for emission hot-spots and as model constraints, but column data does not equal surface concentration.
• Global hyperlocal APIs: Google Air Quality API offers 500 m resolution and hourly forecasts up to 4 days in 100+ countries [3].
• Limits and failure modes: low-cost sensor drift and humidity bias; sparse reference data for validation; street-canyon effects that ML trained on few sites does not generalise to; inventory errors dominate attribution; extreme episodes (smoke, dust, inversions) are under-predicted; ML attribution shows association, not causation; forecast skill falls with horizon. Always publish uncertainty and validation statistics.

Shared resources & combinations

• Shared building blocks: time-series forecasting, sensor ingestion/streaming, QA and calibration pipelines, geospatial stack, weather inputs; HW2 GPU or CPU server.
• PRED-017 (AI weather forecasting) supplies meteorology and shares models such as Aurora; PRED-019 (traffic & mobility demand) supplies traffic emission drivers and consumes scenario results; PRED-007 (energy load & generation) shares heating/power-plant drivers; ANOM-005 (sensor anomaly detection) supports sensor QA; PRED-027 (flood forecasting) reuses geospatial/hydromet data pipelines and alerting; PRED-031 (smart-meter analytics) links heating behaviour to emissions.

Effort, cost & KPIs

• Effort: A: weeks to deploy sensors plus platform onboarding; B: 2–4 months; C: 3–6 months; D: 6–12+ months including measurement campaign. Cost drivers: sensor hardware and maintenance (recalibration), reference co-location, data engineering, domain experts.
• KPIs: forecast RMSE/MAE and bias vs. reference stations per pollutant and horizon; exceedance-day detection (recall/precision, false-alarm rate); sensor uptime and calibration error; attribution stability across seasons; time from alert to action; public-information reach.

People & change

• Involve early: management and the department lead of the environment or operations office, IT and IT security for the sensor network, data owners at the agency, and legal/compliance for the clean-air law. The affected public (customers) should be informed through the communication office before warnings are published.
• Works council: no for the forecasting itself, as no staff behaviour is analysed. In public bodies the staff council (Personalrat) must be informed if work processes change (state law, BPersVG).
• Data protection: environmental data is non-personal. Citizen-hosted sensors and location-based exposure apps are personal data; involve the DPO and sign an AVV with hosting providers.
• AI literacy (Art. 4): support the analysts with training on uncertainty, sensor bias and the difference between correlation and causation in attribution (GUIDE-006).
• Communication and pilot: start with one district and one question, and publish validation statistics openly (GUIDE-009).
• Typical concerns: fear of wrongly attributed blame - mitigate by expert sign-off before any public warning or measure; the LLM only drafts bulletins (GUIDE-008).

Risks, regulation & compliance

• EU AI Act: typically minimal risk; air quality forecasting is not an Annex III use. Could move to high-risk only if embedded as a safety component in critical infrastructure management (check Annex III, point 2). Art. 50 applies to AI-generated public text/images that mimic real events. AI literacy (Art. 4) applies.
• Air-quality law: Directive (EU) 2024/2881 and national transposition (Germany: BImSchG, 39. BImSchV); regulatory compliance still requires reference-method measurements, with models as supplement [2].
• GDPR: environmental data is non-personal; personalised exposure apps using location, and citizen-hosted sensors with addresses, are personal data and need a legal basis and minimisation.
• Risks: wrongly attributed blame (litigation, bans), public alarm or complacency from poor forecasts, vendor lock-in on proprietary indices. Mitigate with documented validation, uncertainty communication, and open data/format use.

Getting started

1. Define the decision (alerts, zone planning, compliance support) and the required spatial resolution and horizon.
2. Inventory data: station feeds, existing sensors, traffic counts; pull CAMS forecasts and EEA data as free baselines.
3. Co-locate 3–5 low-cost sensors next to a reference station for 2–3 months and build the calibration model.
4. Benchmark a simple model (CAMS + local bias correction, gradient boosting) against the Google Air Quality API before investing in deep models.
5. Pilot one attribution question (e.g. traffic share on one street) and validate it against a measurement campaign before publishing.

Sources

1. EEA, Harm to human health from air pollution in Europe 2024 — https://www.eea.europa.eu/en/analysis/publications/harm-to-human-health-from-air-pollution-2024 (accessed 2026-10)
2. EUR-Lex, Directive (EU) 2024/2881 on ambient air quality and cleaner air for Europe — https://eur-lex.europa.eu/eli/dir/2024/2881/oj/eng (accessed 2026-10; only topic summary retrieved: limit values, modelling, roadmaps, action plans, index)
3. Google Maps Platform, Air Quality API overview — https://developers.google.com/maps/documentation/air-quality/overview (accessed 2026-10)
4. Copernicus Atmosphere Monitoring Service, regional air quality production systems — https://atmosphere.copernicus.eu/regional-air-quality-production-systems (accessed 2026-10)
5. Breeze Technologies — https://www.breeze-technologies.de/ (accessed 2026-10)
6. Aurora: A Foundation Model of the Atmosphere (arXiv) — https://arxiv.org/abs/2405.13063 (accessed 2026-10)
7. Copernicus Data Space Ecosystem, Sentinel-5P — https://dataspace.copernicus.eu/data-collections/copernicus-sentinel-missions/sentinel-5p (accessed 2026-10)