Project Overview & Goals

Owner(s): CrowdPM team | Last updated: 2026-03-08 | Status: Production

Project Overview & Goals

One-page summary

Problem

PM2.5, or particulate matter smaller than 2.5 micrometers, is a significant public-health concern. Traditional monitoring stations are valuable but often sparse, which means they do not always answer the most local question a user actually has: what is the air like here, right now, along this route, or at this event?

CrowdPM Platform addresses that gap by collecting hyper-local PM2.5 measurements from distributed low-cost nodes, processing those readings through a secure ingest pipeline, and presenting them in a map-centric interface that supports both current conditions and recent-history exploration.

Who benefits

• Schools, advocates, and outdoor workers who need more local awareness of elevated particulate levels.
• Local governments and civic organizations that want denser coverage than fixed stations alone can provide.
• Researchers and technical teams who need timestamped, spatially organized readings with retained raw ingest artifacts.
• Cyclists, runners, and the broader public who want to explore routes and areas with lower exposure.

What success looks like

A successful CrowdPM release demonstrates all of the following:

• devices can complete onboarding and pairing securely;
• measurements can be ingested, retained, processed, and queried repeatably;
• approved public data can be exposed without exposing private or quarantined data;
• operators can moderate submissions and manage higher-trust workflows;
• users can inspect the resulting data on an interactive WebGL map;
• developers can reproduce the core experience locally without requiring physical hardware.

Project goals

Primary goals

1. Build a secure ingestion path for node-generated PM2.5 data.
2. Preserve raw payloads before processing so ingest is auditable and replay-friendly.
3. Normalize processed data into a queryable structure for map rendering and future analytics.
4. Provide a usable frontend for map exploration and dashboard-driven testing.
5. Support a demonstrable workflow using emulators and seeded smoke-test data.
6. Provide role-aware moderation and administration capabilities.

Non-goals for the current documented release

The wiki should avoid presenting the following as already shipped unless the implementation is later added and verified:

• advanced research export pipelines not represented in the current API/docs surface;
• automated video/export-to-file map playback workflows;
• hardware-dependent demo requirements for baseline grading or contributor onboarding;
• production observability and SRE maturity beyond the currently documented release runbooks.

Current repository-aligned summary

As of the current repository state, CrowdPM is best described as:

A crowd-sourced PM2.5 monitoring stack combining Firebase microservices, DPoP-based device authorization, raw ingest retention, Firestore-backed processing, moderation-aware APIs, and a React + deck.gl Google Maps client.

Demo-oriented definition of success

For grading, sponsor review, or internal handoff, the shortest credible definition of success is:

1. Start the local stack.
2. Log in with the seeded emulator user.
3. Run the smoke test from the User Dashboard.
4. Confirm a device is paired and a batch is processed.
5. Confirm the map renders the resulting path and time-based playback state.
6. Confirm public/private/moderation boundaries behave as intended.

Risks that shaped the project

The current design reflects several practical constraints:

• ingest must not depend on a tightly coupled synchronous processing chain;
• hardware should not be required for every demo or grading path;
• device authentication must be stronger than a plain shared secret;
• public visualization must be separated from privileged moderation views;
• contributors must be able to reproduce the system locally with explicit environment configuration.

Relationship to the rest of the wiki

• Requirements & Scope defines what is in scope and which roles/capabilities matter.
• System Design (with diagrams) explains how the stack is assembled.
• Developer Setup & Project Conventions explains how to run it.
• Demo Scripts explains how to present it coherently.
• Handoff, Reflection, and Future Work explains what remains incomplete or should evolve next.