Building EcoRoute AI: Pollution-Aware Route Navigation on AWS
EcoRoute AI helps commuters compare real travel routes by journey time and estimated air-pollution exposure in Delhi. Discover how we built an AWS-native platform that combines environmental forecasts, transparent route scoring and AI explanations to support more informed travel choices.
Why we built EcoRoute AI
When planning a journey, we usually compare time and distance. But what about the pollution we might encounter along the way?
We built EcoRoute AI to bring estimated air-pollution exposure into that decision. Our goal is to help commuters understand the trade-off between travel time and environmental exposure without presenting uncertain data as a precise health prediction.
What the application does
Users choose a starting point, destination and travel mode, then compare genuine road routes.
For each supported comparison, EcoRoute shows:
- Travel time and distance.
- Estimated PM2.5 concentration along the route.
- Concentration-time exposure.
- Pollution-data coverage.
- An explanation grounded in the calculated metrics.
The application includes a map-based journey planner, an air-quality view, an Insights section and a consent-based wearable integration foundation.
A walkthrough: Gateway of India to Marine Drive
For our Mumbai demonstration, we enter Gateway of India as the origin and Marine Drive as the destination.
We select Drive, choose a future departure time and click Compare routes. The backend retrieves actual road routes and matches their estimated traversal times with available pollution forecasts.
Selecting an alternative updates the sidebar with that route’s concentration, exposure and coverage. The Air Quality section presents environmental information, while Insights explains the comparison in plain language.
The explanation supports the calculation; it does not invent measurements or change the route scores.
How we calculate exposure
We divide route geometry into segments and estimate the time spent traveling through each segment.
The concentration-time exposure index is:
Exposure = Σ(PM2.5 concentration × segment duration)
Concentration is measured in µg/m³, and duration is measured in hours, giving an exposure index in µg·h/m³.
This is not a medical dose calculation. It is a way to compare estimated environmental exposure under consistent assumptions.
Our route objectives include fastest, lowest estimated exposure and balanced, with a configurable maximum detour.
Our AWS architecture
We chose a serverless architecture to avoid maintaining an always-running backend server.
Frontend and authentication
AWS Amplify hosts our React application.
Amazon Cognito supports authentication for protected features. Public route preview is separate from private wearable, journey and alert APIs.
Backend runtime
Amazon API Gateway receives API requests and forwards them to AWS Lambda, where our Python FastAPI application runs.
The backend coordinates routing providers, environmental data, deterministic exposure calculations and explanation generation.
Environmental data pipeline
Our ingestion workflow follows this structure:
Collector Lambda → raw S3 data → SQS → cleaning Lambda → curated S3 datasets and DynamoDB metadata
Amazon S3 stores raw provider responses and processed datasets. Amazon SQS separates collection from cleaning and supports retries and dead-letter handling.
Amazon DynamoDB stores environmental metadata and application state.
We prepared EventBridge Scheduler definitions for automated collection, but continuous schedules remain disabled until intentionally activated.
Security and operations
AWS Secrets Manager stores server-side provider credentials.
AWS IAM controls service permissions, and Amazon CloudWatch provides logs and alarms.
We used AWS CDK for Python to define infrastructure, Boto3 to access AWS services and the AWS CLI for deployment checks and troubleshooting.
Data providers and explanations
Our configured routing integrations include Google Routes and Places, with OpenRouteService support for cycling. Provider coverage determines which modes and locations are available.
Environmental adapters support:
- Open-Meteo/CAMS for modeled air-quality forecasts.
- OpenAQ v3 for observations where credentials and station coverage permit access.
Records retain their source, units, timestamps and quality information. Observations and modeled forecasts are kept distinct.
Our verified explanation path uses Gemini, with an optional Amazon Bedrock adapter. The explanation service operates on approved calculated facts, and a deterministic summary remains available when the LLM cannot be used.
An important limitation: route detail is not pollution detail
A detailed road map does not mean we have equally detailed pollution measurements.
Open-Meteo’s global atmospheric model has coarse geographic resolution. Nearby routes may therefore share the same pollution grid cell.
In that situation, a difference in exposure can come from travel duration or timing—not evidence that one individual street is cleaner.
Missing data stays unavailable. We do not insert invented pollution readings to make the dashboard look complete.
A bug that taught us to inspect time matching
During a Mumbai test, route exposure appeared unavailable even though hourly model data existed.
We traced this to our time-matching logic. The current hour’s value had been classified as modeled, and the backend was excluding it from near-future route seg
ments. The following hourly forecast was not yet close enough to match, creating an artificial coverage gap.
We corrected the logic while preserving our existing 30-minute matching tolerance, freshness checks and source labels. We also added regression tests.
A subsequent live Mumbai comparison returned full modeled PM2.5 coverage for both candidates. That verified the repair for the tested journey; it does not guarantee complete coverage everywhere.
What we learned while building on AWS
Permissions were one of our biggest challenges. Troubleshooting sometimes required reviewing IAM policies, CloudFormation events and application logs together.
Cognito also required careful alignment between client settings, callback URLs, scopes and frontend configuration.
On the positive side, Lambda and API Gateway let us run the backend without managing a server. Amplify simplified frontend hosting, and CDK made our infrastructure repeatable.
We also configured AWS budget alerts to improve spending visibility. These alerts are useful, but they do not hard-cap costs.
What is working, and what remains conditional
We have verified deployed route comparisons, real Open-Meteo processing and grounded Gemini explanations.
Our local forecasting experiment used historical Beijing station data. It is not an approved Delhi navigation model, and we do not claim successful SageMaker training.
We also prepared wearable APIs, optional IoT integration and automated workflow definitions. Direct live access to the Noise smartwatch, continuous schedules and SMS delivery are not claimed as completed features.
Keeping these distinctions visible is part of making the application trustworthy.
Meet the team
EcoRoute AI was built collaboratively by:
- Mayank Gupta — Team leader.
- Devesh Raj — Team member.
- Devesh Singhal — Team member.
Explore the project
Our next priority is improving measured-data coverage and validating location-specific forecasts before making stronger route-level recommendations.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article