EcoRoute AI on AWS: Connecting Route Planning, Air Quality, and Wearable Insights
Discover how our team combines real route comparisons, estimated pollution exposure, and Samsung Health records in one experience. Explore the AWS serverless architecture, engineering lessons, and future possibilities behind more informed urban travel.
Every journey involves a decision. We choose where to go, when to leave, and how to travel. Navigation applications make these decisions easier by showing travel time, distance, and traffic conditions. EcoRoute AI adds another perspective: the environmental information available for that journey.
Our project brings route planning, estimated air-pollution exposure, and wearable activity records into a connected dashboard. We want to help people understand the trade-offs between their travel options while keeping the quality and limitations of the data visible.
AWS provides the cloud foundation for this experience. Its managed services support frontend hosting, authenticated APIs, environmental processing, storage, and monitoring, allowing our team to focus on application behaviour and useful information.
Why we built EcoRoute AI
A fast route is useful, but travel time alone does not communicate the environmental conditions a person might encounter. Air-quality information often appears in a separate application, leaving users to connect that information with their journey themselves.
EcoRoute AI explores how these experiences can work together. Users can compare genuine road routes alongside available PM2.5 information, estimated concentration-time exposure, and data-coverage indicators.
The purpose is to make those comparisons understandable. We do not assume that a longer route is cleaner or that every alternative has meaningfully different pollution conditions. The application presents the available evidence and explains when it cannot support a comparison.
From destination selection to route comparison
The experience begins with an origin, destination, travel mode, and departure time. Users can explore driving, walking, or cycling where the configured providers support them.
The backend retrieves candidate routes and their estimated durations. It then matches the journey’s location and timing with eligible environmental records. The dashboard presents route geometry, distance, travel time, exposure estimates, and coverage information.
Users can select another route to update the map and inspect its metrics. Preferences allow them to consider the fastest option, the lowest estimated exposure among eligible alternatives, or a balanced score. A maximum detour setting helps keep the comparison practical.
The current provider integrations use Google Routes and Places for driving and walking, with OpenRouteService supporting cycling. These services supply route information; AWS runs the application that validates, combines, and scores the results.
Understanding the exposure calculation
EcoRoute AI divides a route into segments and estimates how long the traveller spends in each segment. It combines that duration with the matched PM2.5 concentration:
Plain text
Exposure index = Σ(segment PM2.5 concentration × segment duration)
Concentration is expressed in micrograms per cubic metre, and duration is expressed in hours. The resulting index is measured in
µg·h/m³ .This provides a consistent way to compare concentration and travel time together. It does not measure inhaled pollution or establish an individual medical risk.
Coverage is equally important. Complete coverage means the calculation has suitable data for the required segments; it does not mean the air is clean. When coverage is insufficient, the application keeps the full exposure result unavailable instead of filling the gap with invented values.
Building the cloud application with AWS
Our core architecture connects a React frontend to a Python FastAPI backend through AWS managed services:
Plain text
AWS Amplify Hosting↓React dashboard↓Amazon API Gateway↓AWS Lambda + FastAPI↓Route processing, application APIs, and data access↓Amazon S3 + Amazon DynamoDB
AWS Amplify Hosting serves the frontend and its static assets. React and TypeScript provide the application interface, while Three.js supports the interactive visual presentation. Actual route overlays use provider geometry; the animated city scene is illustrative.
Amazon API Gateway provides the entry point for backend requests. AWS Lambda runs FastAPI through Mangum, handling route comparisons and application logic without requiring our team to maintain a dedicated backend server. Lambda’s managed execution model suits the project’s request-driven and event-driven workloads.
Amazon Cognito supplies authentication for protected features. API scopes and backend ownership checks help separate personal records from the public route-preview experience.
Amazon DynamoDB stores structured application records and environmental metadata. Amazon S3 stores raw provider responses, curated datasets, and machine-learning artifacts. Keeping these responsibilities separate helps preserve original inputs while making processed information easier to retrieve.
AWS Secrets Manager holds server-side provider credentials. IAM defines the permissions available to each component, and CloudWatch supplies logs, metrics, and alarms. AWS CDK and CloudFormation make infrastructure changes repeatable and reviewable.
Processing environmental data reliably
Environmental information must be checked before it can support a route calculation. Timestamps, units, geographic coverage, and source types all affect whether a record is suitable.
Our processing pipeline follows this path:
The collector preserves source responses in S3. SQS buffers processing tasks, and the cleaner validates and normalizes records before writing curated data and metadata.
This separation allows collection and cleaning to operate independently. Temporary processing failures can be retried, while repeated failures can move to a dead-letter queue for investigation. This is a central benefit of using SQS to decouple application components.
The project has documented successful bounded runs through the cloud pipeline, including forward-forecast processing. EventBridge Scheduler definitions support potential automated collection, but continuous schedules remain disabled until deliberately activated.
Environmental adapters include Open-Meteo/CAMS for modeled conditions and forecasts, and OpenAQ for measured observations where access and coverage permit. These sources remain distinguishable throughout processing.
A detailed map needs equally clear data limitations
One of our most important lessons is that detailed road geometry does not guarantee detailed pollution information.
The documented global CAMS dataset has a coarse geographic resolution of approximately 45 kilometres. Several nearby routes can therefore share the same environmental grid cell.
In that situation, differences in the exposure calculation may come from journey duration or departure time. They do not establish that one individual street has cleaner air than another.
This limitation shapes both the algorithm and the interface. Source labels, timestamps, coverage indicators, and warnings help users understand what the comparison can reasonably support.
An engineering lesson from the Mumbai demonstration
Our team’s earlier article describes a Gateway of India–to–Marine Drive demonstration that exposed a time-matching issue. Hourly environmental data existed, but the current hour’s modeled value was excluded from near-future route segments, creating an artificial coverage gap.
The reported repair preserved freshness checks and the existing matching tolerance, with regression tests added to cover the case. A subsequent comparison returned complete modeled-data coverage for the tested journey. This demonstrated the repair for that example without implying complete coverage everywhere.
The broader lesson is that an unavailable result needs investigation across the entire path—from provider records to timestamps, processing rules, and frontend presentation.
Bringing Samsung Health into the wearable dashboard
The latest local wearable integration connects Samsung Galaxy Watch6 Classic records to EcoRoute AI through Samsung Health and Android Health Connect.
The data travels through this sequence:
Plain text
Samsung Galaxy Watch6 Classic↓Samsung Health on the phone↓Android Health Connect↓Health Connect to Webhook local server↓EcoRoute AI local backend↓Wearable dashboard
With the phone and laptop on the same trusted Wi-Fi network, the local backend can read permitted records from the phone bridge. Users enter an expiring pairing key and grant session consent before displaying their measurements.
The wearable section shows heart rate, blood oxygen saturation, steps, and calories burned. Measurement cards and an interactive Galaxy Watch6 Classic-style preview present the available readings. Users can refresh manually or enable periodic updates.
Timestamps make the distinction between a recent synchronization and an older measurement visible. This is near-real-time access to synchronized records, with freshness depending on the watch, Samsung Health, Health Connect, and the bridge.
The integration also checks record sources and calorie intervals. This matters when multiple applications contribute overlapping totals or unfinished projected values.
The local phone connection operates separately from cloud wearable ingestion. It does not establish that the Samsung watch is sending telemetry directly to AWS IoT Core, and wearable measurements are not currently used to calculate personalized medical route recommendations.
Separating forecasting from explanations
EcoRoute AI gives machine learning and generative AI different responsibilities.
A forecasting model may contribute station-level PM2.5 predictions after suitable validation. The route engine still calculates exposure and ranks returned candidates using explicit rules.
A completed local experiment used 420,768 rows from the historical UCI Beijing Multi-Site Air Quality dataset. The selected Random Forest achieved a test mean absolute error of approximately 9.75 µg/m³, compared with approximately 10.09 µg/m³ for persistence.
Those results describe a local historical experiment. They do not establish Delhi forecasting accuracy or justify deploying the model for current navigation.
The prepared cloud workflow uses S3 for datasets, ECR for training containers, SageMaker AI for bounded training jobs, and Step Functions for orchestration and validation. SageMaker provides managed infrastructure for this kind of containerized training workflow.
A completed SageMaker training job and an approved Delhi navigation model remain outside the project’s verified results.
Explanations have a different purpose: turning calculated route facts into readable language. The published team walkthrough reports grounded Gemini explanations, with Amazon Bedrock available as an optional adapter. A deterministic summary remains available when a language model cannot be used.
Privacy, permissions, and cost awareness
Location and health records require deliberate access controls. Personal APIs use authentication, scopes, and ownership checks. Wearable workflows include consent and deletion capabilities, while the local bridge uses a limited, expiring pairing key.
Private provider credentials remain on the server. Local health records should stay within the trusted network used for the phone connection.
Operational discipline matters too. IAM permissions, Cognito callback configuration, infrastructure events, and application logs all influence whether a cloud feature works as intended.
The default serverless architecture avoids requiring a continuously running application server or ML endpoint. Optional schedules, notifications, and training jobs remain separate activation decisions. Request limits, retention settings, monitoring, and budget alerts help manage usage, although budget alerts do not impose a hard spending cap. External routing-provider charges also remain separate from AWS charges.
What the project offers today
EcoRoute AI brings route alternatives, environmental context, source information, and locally synchronized wearable records into one experience.
For commuters, this makes travel trade-offs easier to examine. For people considering walking or cycling, it places journey options alongside available environmental information. For builders, it demonstrates how APIs, queues, storage, identity, and data validation fit together in a practical application.
The earlier architecture article also emphasizes a principle we continue to follow: optional services shown in a diagram should not be mistaken for active, verified features.
Where we want to take it next
Our next priorities are better measured-data coverage, validated location-specific forecasts, and stronger evaluation across different journeys.
Further development could introduce opt-in departure advisories, better accessibility information, and more robust wearable connectivity. Privacy-preserving aggregate analysis could eventually support research into travel patterns and gaps in environmental monitoring.
These are opportunities to investigate, rather than outcomes already demonstrated. The project has not established reduced illness, lower citywide emissions, or guaranteed cleaner routes.
Our ambition is to make everyday navigation more informative. AWS provides the infrastructure to expand the application, while transparent calculations and reliable data determine the value it delivers.
The team and the project
EcoRoute AI was developed by Mayank Gupta, team leader, alongside Devesh Raj and Devesh Singhal.
Explore the live application , visit the GitHub repository for the project’s code and documentation.
EcoRoute AI — Know Your Route. Understand Your Exposure.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article