AWS Builder Center

Builder Center

CoolRoute Delhi: Helping Pedestrians Choose a Cooler Walking Route

CoolRoute Delhi: Helping Pedestrians Choose a Cooler Walking Route

Built for Environmental Hacks — WeMakeDevs × AWS Builder Center Track: Heat and Water - Live prototype: https://d213cehqsofz1g.cloudfront.net/index.html - GitHub repository: https://github.com/dasshiva/CoolRoute - Demo video: https://youtu.be/N981CxT7Rbc?si=Ed_EeuDMFs8KBUYp

Arnab Acharya

build<->break<->rebuild

The problem

On a hot day in Delhi, the fastest walking route is not always the most comfortable one. Navigation apps usually optimise for distance and travel time, but a pedestrian may also care about sun exposure, shade, and heat.
CoolRoute Delhi is a prototype that takes two points a user selects and returns a walking route chosen with an estimated shade proxy in mind. It does not claim to measure body temperature or guarantee a route is safe. Instead, it makes a simple trade-off visible:
"This route favours mapped shade and greenery. Here is what that costs in walking time."
We chose this problem because heat is not experienced evenly across a city. Delhi's built environment, vegetation, and street design affect local heat conditions. Our prototype focuses on one practical decision: would a pedestrian prefer a slightly longer route if it is likely to be shadier?

What we built

CoolRoute Delhi is a web-based walking-route tool for a bounded Delhi demo area.
A user selects an origin and destination, then clicks Find coolest route. The app displays:
  • A Cooler route with an estimated shade score.
  • Distance and estimated walking time for that route.
  • The estimated shade proxy (how much of the route overlaps mapped shade features).
  • The shade-data label, showing the grid build timestamp and the source-data date.
  • A clear disclaimer explaining that the shade value is an estimate, not a live measurement or guaranteed shade.
Internally the backend computes both a fastest route and a cooler candidate, and returns both metrics. The interface deliberately surfaces the Cooler route so the user isn't asked to read a raw comparison — the point is a decision, not a chart.
We did not want to build another dashboard that shows data without helping someone act. The central question is: would a pedestrian prefer a slightly longer route if it is likely to be shadier?

How the shade estimate works

For this hackathon prototype, the shade value is an estimated shade proxy, not a measured temperature or complete shade model.
  1. The user chooses an origin and destination inside a fixed Delhi demo box.
  1. The backend receives the two points.
  1. It obtains candidate walking routes and calculates distance and duration.
  1. It compares each route against an environmental layer built from mapped OpenStreetMap tree points and green areas on a roughly 50 m grid.
  1. It samples route geometry at roughly 10 m intervals and averages available grid values to produce the route score.
  1. It returns the cooler candidate alongside the metrics.
We deliberately label the result as an estimated shade proxy. Real shade depends on time of day, season, sun angle, building height, tree canopy, footpath position, and weather. A mapped tree does not always mean a footpath is shaded at the moment someone walks past it. The checked-in grid does not model building shadows or sun position.
Our aim was not to claim scientific certainty. It was to build a transparent prototype that shows how environmental information could become part of a route-choice decision.

Where AWS fits

AWS is part of the working application, not just an architecture diagram.

Amazon Location Service

The frontend uses Amazon Location Service to render the Delhi map and to calculate walking routes. The browser loads a map style through a restricted Amazon Location API key, allowing us to display the demo area and draw the route geometry on a real map. The backend calls the Location route calculator ( TravelMode=Walking ) to get candidate geometries.

AWS Lambda

When the user clicks Find coolest route, the frontend sends the selected origin and destination to an AWS Lambda function. Lambda validates that both points are inside the demo area, runs the route-scoring workflow, and returns the Cooler route with its metrics.
This is the core AWS component. Without it, the route scoring does not happen.

Amazon DynamoDB

Lambda enforces a daily quota on Amazon Location calls using an atomic conditional update in DynamoDB (default 500 calls/day), so the demo has a hard cost ceiling and cannot run away with usage.

Amazon S3 and Amazon CloudFront

The frontend is deployed as static files to Amazon S3 and served through Amazon CloudFront over HTTPS. The S3 bucket remains private; CloudFront accesses the content through Origin Access Control.
That means the demo can be opened from a public CloudFront URL while the underlying S3 bucket is not publicly exposed.

Architecture

text
User browser
   |
   |  1. Loads frontend
   v
Amazon CloudFront
   |
   |  2. Serves static frontend from private S3
   v
Amazon S3
   |
User clicks "Find coolest route"
   |
   |  3. POST origin + destination
   v
AWS Lambda Function URL
   |
   |  4. Validates points, calls Amazon Location, scores against the shade grid
   v
Cooler route response (with fastest + cooler metrics)
   |
   |  5. Browser draws the route on the Amazon Location map
   v
User sees the cooler route and its estimate

How we showed AWS working

In the demo video, we show AWS during the actual user journey:
  1. The user selects an origin and destination.
  1. The user clicks Find coolest route.
  1. The browser sends a request to the Lambda Function URL.
  1. The browser Network tab shows the request returning successfully.
  1. The Lambda response contains the Cooler route and its metrics.
  1. The frontend draws the route and displays the estimate.
  1. The CloudFront URL is visible in the browser address bar.
This demonstrates that AWS is not decorative: the Lambda call produces the route score, and CloudFront serves the deployed application.

What fought back

Deciding what we could honestly claim. The hardest part was not drawing routes. It was deciding what we could say. We cannot call a route "safe" or "cooler" in an absolute sense from a simple proxy. We therefore use "estimated shade proxy" and show the data date and limitations.
Keeping the scope small. It was tempting to build a citywide heat map or a full navigation product. Narrowing the project to walking routes in a bounded Delhi area let us focus on one clear user decision and finish a working demo.
Making AWS meaningful. Adding AWS only for the hackathon would have felt artificial. Once Lambda handled the route-scoring request and CloudFront served the deployed app, AWS became part of the product flow.

Limitations

  • This is a hackathon prototype, not a production navigation product.
  • The shade estimate is based on mapped environmental features, not real-time street-level shade measurement.
  • The checked-in grid-generation code uses mapped trees and green areas; it does not model building shadows or sun position.
  • It does not model every factor affecting thermal comfort, such as exact sun angle, canopy geometry, wind, humidity, or individual exertion.
  • OpenStreetMap coverage can be incomplete or uneven.
  • The route score does not assess pedestrian safety, footpaths, crossings, lighting, or accessibility.
  • Tested origin/destination pairs have sometimes returned the same path as the direct route; the app shows the backend result and does not guarantee a distinct or demonstrably shadier detour.
  • The demo is limited to a bounded Delhi area and walking only.
  • It does not provide medical advice or emergency heat guidance.
  • A longer route may not be preferable for every user; the goal is to make the trade-off visible, not decide for them.

What we would build next

  • Improve the environmental layer with better tree-canopy and footpath data.
  • Add time-of-day shade modelling, clearly labelled as an estimate.
  • Let users report missing shade, blocked footpaths, or inaccurate route results.
  • Test the prototype with pedestrians in Delhi and refine the interface from their feedback.
  • Explore whether heat-aware routing can be combined with air-quality information without confusing the interface.

Tech stack

  • Frontend: HTML, CSS, JavaScript, MapLibre GL JS
  • Map: Amazon Location Service
  • Backend: AWS Lambda
  • Quota: Amazon DynamoDB
  • Hosting: Amazon S3 and Amazon CloudFront
  • Route scoring: Custom route-scoring workflow (Python, boto3)
  • Data: OpenStreetMap (trees + green areas)
  • AI coding tools: Claude, Opencode

Acknowledgements

We used public documentation, open-source libraries, and public APIs where applicable. All third-party code, datasets, and tools are credited in the repository.
Shade inputs are derived from OpenStreetMap data distributed through Geofabrik, available under the Open Database License (ODbL).
We also drew inspiration from existing research on heat-aware route planning, including the CoolPath Tool, which explores thermal-comfort-based route planning using UTCI. Our project is a smaller, Delhi-focused hackathon prototype and does not claim to reproduce or replace that research.

Try it

Tags

#AWS #AmazonLocation #Lambda #S3 #CloudFront #MapLibre #Heatwaves #UrbanHeat #EnvironmentalHacks #WeMakeDevs #Delhi
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