AWS Builder Center
Beyond the Fastest Route: Building AeroShift, an Air-Aware Mobility Platform with AWS

Beyond the Fastest Route: Building AeroShift, an Air-Aware Mobility Platform with AWS

What if navigation considered the air we breathe, not just the time it takes to reach a destination? Explore how I built AeroShift using air-quality data, route optimization, and AWS serverless services to compare travel time with estimated pollution exposure.

Beyond the Fastest Route: Building AeroShift, an Air-Aware Mobility Platform with AWS

When air quality becomes a concern across entire cities, it changes how we think about everyday activities—including something as routine as travelling to college, work, or home.
I kept coming back to one thought: reaching a destination a few minutes earlier is not always worth overlooking the air we breathe along the way.
I wanted to explore whether navigation could help people consider environmental exposure alongside travel time. That idea became AeroShift, an air-aware urban mobility and facility exposure intelligence platform.
Rather than treating the fastest route as the only meaningful option, AeroShift compares travel time with estimated particulate exposure and helps users understand the trade-offs between different routes.

1. Rethinking What Makes a Route Better

Traditional navigation focuses heavily on distance and estimated travel time. AeroShift explores another dimension: estimated exposure to fine particulate matter, particularly PM2.5.
The platform offers three route strategies:
  • Fastest: Prioritizes the shortest estimated travel duration.
  • Cleanest: Prioritizes the lowest modeled inhaled particulate mass.
  • Balanced: Explores the trade-off between travel time and estimated exposure.
AeroShift Move presents these alternatives on an interactive map, along with route details and pollution heatmaps. Users can compare the options rather than being presented with a single route as the obvious choice.
The goal is not to promise a pollution-free journey. It is to make environmental information more useful when people make everyday mobility decisions.

2. From Road Routes to Air-Quality Estimates

One of the main engineering challenges was connecting road-network routes with air-quality observations. Monitoring stations provide measurements at particular locations, but a route passes through many places between those stations.
AeroShift combines road routing with spatial estimation to approximate pollution levels along a journey.

Road-network routing with OSRM

AeroShift uses the public Open Source Routing Machine (OSRM) endpoint to obtain road-network routes. These routes provide the geometry and segment information needed for further analysis.
An important limitation is that this routing setup does not provide reliable live-traffic estimates. Its travel times should be treated as network-based estimates, not predictions of actual traffic conditions. For real navigation, AeroShift also provides a handoff to Google Maps.

Air-quality observations with OpenAQ

AeroShift uses the OpenAQ v3 API to retrieve air-quality observations. The backend caches station data in Amazon DynamoDB to reduce repeated external requests and support the application’s data workflow.
However, monitoring coverage is not uniform. Measurements may be sparse or unavailable in some areas, so the platform must distinguish between observed data and estimated values.

Estimating pollution between stations

AeroShift applies inverse distance weighting (IDW) to estimate concentration at a location using nearby station observations. Closer observations have greater influence than farther observations.
The estimate is calculated as:
[ \hat{C}(x)= \frac{\sum_{i=1}^{n} C_i/d_i^p} {\sum_{i=1}^{n}1/d_i^p} ]
Here, (C_i) represents a station's observed concentration, (d_i) is its distance from the location being estimated, and (p) controls how quickly the influence decreases with distance. AeroShift uses (p=2) by default.
IDW is an interpolation technique, not a direct measurement of air quality at every point along a road. Its output depends on the available observations and their spatial distribution.

Estimating exposure by travel mode

Concentration alone does not tell the whole story. The amount of air inhaled during a journey also depends on how long the journey takes and the assumed ventilation rate associated with the travel mode.
AeroShift estimates inhaled particulate mass across route segments using concentration, travel duration, and mode-specific ventilation assumptions.
The model uses a baseline ventilation rate of 8 L/min, with multipliers of 0.70 for car travel, 1.30 for two-wheeler travel, and 2.20 for active travel.
These are modeling assumptions, not measurements of an individual's breathing rate or personal exposure. The resulting values are comparative estimates intended to support route analysis—not medical advice or a guarantee of actual exposure.

3. Why We Used Pareto Optimization

Optimizing only for time would ignore the environmental dimension. Optimizing only for estimated exposure could produce routes that take substantially longer.
AeroShift therefore uses Pareto-based route comparison.
A route is Pareto-dominated when another route is at least as good in both travel time and estimated exposure, and strictly better in at least one of them.
The routes that remain on the Pareto frontier represent different trade-offs. The Fastest strategy prioritizes duration, Cleanest prioritizes modeled inhaled particulate mass, and Balanced selects a compromise based on marginal exposure reduction relative to additional travel time.
This approach makes the decision more transparent: instead of hiding the trade-off behind one score, AeroShift gives users alternatives and the information needed to compare them.

4. The AWS Serverless Architecture Behind AeroShift

AWS provides the backend foundation for AeroShift's routing and advisory workflows. I used AWS Serverless Application Model (AWS SAM) to define and manage the serverless infrastructure.
The main components are:
  • Amazon API Gateway: Exposes backend endpoints to the application.
  • AWS Lambda: Runs the route engine, route explanations, facility advisories, and station-ingestion logic.
  • Amazon DynamoDB: Stores cached station observations in a table with time-to-live (TTL) expiration.
  • Amazon Bedrock: Supports generated route explanations and facility advisory content.
  • AWS SAM: Defines and deploys the serverless resources.
The station-ingestion workflow retrieves OpenAQ data and stores it in DynamoDB with TTL settings so cached observations can expire. The route engine combines road-network information with cached air-quality observations, applies spatial estimation, and compares route alternatives.
For language-model features, the application uses Amazon Bedrock models configured as  amazon.nova-lite-v1:0  and  amazon.titan-text-lite-v1 . These features provide explanations and advisory text around the application's calculated results.
Keeping numerical route calculations separate from generated explanations is important. The model can help communicate a result, but it should not replace the underlying route and exposure calculations.

5. AeroShift Shield: Extending Beyond Individual Journeys

AeroShift also includes AeroShift Shield, a facility-level air-quality advisory module.
Instead of analyzing a route, Shield focuses on locations such as schools, universities, and commercial campuses. It presents PM2.5 trends, assigns a risk category—Low, Medium, High, or Critical—and provides action-oriented bulletins related to ventilation and outdoor activity.
Users can export an advisory as a text report.
The idea is to make air-quality information easier to interpret in the context of a facility. These advisories are decision-support information, not official public-health warnings, and should not replace guidance from relevant authorities.

6. What Building AeroShift Taught Me

The most challenging part was not simply displaying a map or connecting an API. It was bringing together multiple systems whose data and assumptions do not naturally align.
A road route is a geometric path. Air-quality observations are measurements taken at particular places and times. Estimated exposure introduces further assumptions about interpolation, journey duration, and travel mode. Each layer adds uncertainty.
Building AeroShift reinforced a few important lessons:
  • Data quality matters as much as the algorithm. An interpolation method cannot compensate for missing or poorly distributed observations.
  • Cloud architecture should have a clear purpose. Lambda, API Gateway, DynamoDB, and Bedrock each serve a distinct role in the application.
  • Explanations should remain grounded in calculations. Generated text is most useful when it communicates computed results rather than inventing facts.
  • Limitations should be visible. In particular, network-based route times must not be presented as live-traffic predictions.
I also learned that building a useful prototype involves more than making the happy path work. Data availability, service integration, deployment configuration, and the clarity of the final user experience all matter.

7. What Comes Next

AeroShift is a prototype, and there is meaningful work ahead.
The next improvements I would prioritize are traffic-aware routing, broader and more reliable air-quality coverage, validation of exposure estimates against suitable reference data, and clearer communication of uncertainty when station observations are sparse.
I would also like to evaluate route recommendations across more locations and travel scenarios to understand when a lower modeled exposure meaningfully changes the journey—and when the available data is not strong enough to support a confident comparison.
The long-term goal is to make environmental information a practical part of everyday decisions without overstating what the data can tell us.

Conclusion

AeroShift started with a simple question: can navigation help us consider more than how quickly we arrive?
By combining road-network routing, air-quality observations, exposure estimation, Pareto optimization, and AWS serverless services, the project explores one way to approach that question.
It is not a replacement for established navigation systems or official air-quality guidance. It is an experiment in making another dimension of a journey visible.
Because reaching a destination matters—but so does the journey we take to get there.
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article