HeatRoute: Choosing the Cooler Way Home with AWS Serverless
Meet HeatRoute, Terra Tech’s serverless project for comparing routes by travel time and estimated heat exposure in Ahmedabad. Learn how we used AWS Lambda, API Gateway, DynamoDB, S3, AWS SAM, and CloudFormation to build and deploy a working prototype.
HeatRoute: Choosing the Cooler Way Home with AWS Serverless
By Terra Tech
B.Tech CSE (AI & ML), Nirma University, Ahmedabad
Track: Heat and Water — Environmental Hacks, Bharat Builds Tour
Maps optimize your journey. HeatRoute optimizes your exposure.
The problem: The fastest route is not always the best route
In Ahmedabad at 1 PM, two routes to the same destination can take almost the same time but expose travellers to very different conditions. One may run along a wide, sun-baked highway with little shade, while another passes through tree-lined streets.
Navigation apps are good at answering, “How do I get there fastest?” But during hot weather, another question matters: “How can I get there with less heat exposure?”
This is particularly relevant for people who walk, cycle, or work outdoors. A few extra minutes on a shaded route may be worth the trade-off compared with a shorter journey in direct sunlight.
We built HeatRoute to make this trade-off visible and demonstrate how environmental exposure can be considered alongside travel time.
What HeatRoute does
HeatRoute is a heat-aware route recommendation prototype designed around an illustrative corridor from Nirma University to Ahmedabad Airport.
Users select a time of day and a travel profile: pedestrian, cyclist, or outdoor worker. The application compares three candidate routes using travel time and an estimated Heat Exposure Score. It recommends a cooler alternative only when the reduction in the score justifies the additional journey time.
In our 1 PM demonstration, a pedestrian sees this comparison:
- Fastest route — SG Highway corridor: 18 minutes, heat score of 82.
- Cooler route — Tree-lined inner roads: 21 minutes, heat score of 58.
- Trade-off: Three additional minutes for approximately 29% lower estimated heat exposure.
When the user changes the time to 5 PM, the modelled conditions change. The difference between the fastest and cooler routes falls below our recommendation threshold of 15 points, so HeatRoute recommends the fastest route instead.
Users can also select different travel profiles and view an explanation of the recommendation alongside the factors behind the calculated scores.
HeatRoute is not a medical tool. Its score is an environmental estimate, and the application makes that limitation clear.
How the Heat Exposure Score works
We wanted the score to be transparent and reproducible rather than a black box.
Our model combines seven factors on a 0–100 scale: air temperature, direct sunlight, hot surfaces, time outdoors, shade, vegetation, and wind.
The scoring weights are:
Factor | Weight | Effect |
|---|---|---|
Air temperature | 25% | Increases exposure |
Direct sunlight | 20% | Increases exposure |
Surface heat | 15% | Increases exposure |
Time outdoors | 20% | Increases exposure |
Shade | 10% | Reduces exposure |
Vegetation | 5% | Provides modelled relief |
Wind | 5% | Provides modelled relief |
The first four factors increase the score, while shade, vegetation, and wind provide relief and are counted in reverse. The final score is bounded between 0 and 100 and labelled from Very Low to Very High.
We also apply a travel-profile multiplier: 1.00 for pedestrians, 1.05 for cyclists, and 1.10 for outdoor workers. These are documented modelling assumptions, not established research findings.
The recommendation rule is intentionally simple: a cooler route is recommended only when it saves at least 15 score points while adding no more than 10 minutes. Otherwise, the fastest route remains the recommendation.
This keeps the decision logic visible and easier to inspect, explain, and improve.
Architecture on AWS
We deployed HeatRoute as a serverless web application using AWS services. Each service has a specific role in the application.
Amazon S3 hosts our frontend, built with HTML, CSS, and JavaScript. Amazon API Gateway connects the frontend to two HTTP endpoints: /route and /explain.
AWS Lambda runs two Python functions. One calculates route scores and recommendations, while the other generates explanations based on the computed results.
Amazon DynamoDB stores the simulated heat conditions and route segments used by the application. Amazon CloudWatch collects Lambda logs to help us monitor requests and troubleshoot errors.
We used the AWS Serverless Application Model (AWS SAM) CLI to build and deploy the project, while AWS CloudFormation manages the infrastructure as a stack. We also used Boto3, the AWS SDK for Python, to interact with AWS services.
Keeping explanations honest
We designed HeatRoute with a planned Amazon Bedrock integration for natural-language explanations. However, live Bedrock inference is not enabled in our current deployment.
The working application uses a deterministic, template-based explanation generated from the route scores and factors. The interface identifies the source of the explanation.
Our approach separates the scoring decision from its explanation. The scoring function determines the recommended route, while the explanation describes the calculated results and trade-offs.
When Bedrock access is available, the planned integration can use computed facts to generate natural-language explanations without treating the model as the authority for the route score.
We believe that clearly distinguishing working features from planned integrations is an important part of building trustworthy technology.
How we built and deployed it
We started with the user-facing experience and worked backwards towards the backend. The project includes a local development server that uses the same Lambda handlers as the deployed application, allowing the main workflow to be tested locally.
For deployment, we used AWS CloudShell, which provided the AWS CLI, SAM CLI, Git, and Python. We built the project using
sam build and deployed the infrastructure using sam deploy --guided .After deployment, we populated DynamoDB with a Python seeding script, configured the frontend with the API URL, and uploaded the website files to S3.
We then tested both API endpoints. The route endpoint returned three candidate routes and their scores, while the explanation endpoint returned the expected template-based explanation. Finally, we verified the complete workflow through the live website.
Challenges and lessons learned
The deployment process involved more than writing code.
We encountered account verification requirements, Bedrock model-access restrictions, regional limitations, and explicit AWS Organizations permission denials while exploring different services and regions.
These challenges taught us that valid AWS credentials do not automatically guarantee access to every service or region. We proceeded in the region available to our project and kept the template-based fallback so the core application could work without live Bedrock inference.
We also learned the importance of inspecting CloudFormation events, reviewing Lambda logs, seeding the database before testing, and separating application errors from account-level permission issues.
What we would improve next
HeatRoute is a hackathon prototype, and several improvements could move it closer to real-world use:
- Live routing: Integrate real route geometry, potentially using Amazon Location Service.
- Real environmental data: Incorporate weather observations and open vegetation and built-surface datasets, with sources and licences documented.
- Better shade estimates: Use sun position and building geometry rather than relying only on predefined values.
- Wider coverage: Extend the system to additional routes and cities, including campuses and outdoor-work planning.
- AI-generated explanations: Enable and test Amazon Bedrock integration when the required account access is available.
Honest limitations
All heat inputs are simulated demonstration values for one illustrative corridor. They are not live sensor readings. Routes are predefined candidates rather than live routing results, and the map is schematic.
Environmental conditions are modelled using three time buckets: morning, midday, and evening. The scoring weights and profile multipliers are assumptions that need further evaluation. The Heat Exposure Score is an environmental index, not a medical prediction.
These limitations define the next stage of our work and help us distinguish the current prototype from a production heat advisory.
Try HeatRoute
- Source code: GitHub — HeatRoute
- Live demo: Open HeatRoute
Conclusion
HeatRoute began with a simple idea: route planning should consider more than speed when people travel outdoors in hot conditions.
By combining a transparent environmental scoring model with AWS serverless services, Terra Tech built a working prototype that compares routes, explains recommendations, and demonstrates how environmental factors could inform travel decisions.
Our next step is to improve the quality of the data, expand the route coverage, and explore more realistic environmental inputs.
Terra Tech — building technology for smarter, more climate-aware journeys.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article