Heatroute

HeatRoute — Compare real walking routes using current weather, estimated shade potential, and travel time to find the coolest reasonable way to your destination.

Comment

Inspiration

Most navigation apps optimize for the shortest or fastest route. However, during hot weather, the fastest walking route may pass through exposed roads with very little greenery, while a slightly longer route may offer more trees, parks, or covered paths. HeatRoute was inspired by a simple question:

What if a walking route could be recommended not only by time and distance, but also by estimated heat exposure?

The goal was not to build another mapping platform. Instead, HeatRoute adds an environmental analysis layer to existing walking routes and helps users find the coolest reasonable way to reach their destination.

What it does

Users enter an origin and destination—or select their current location—and HeatRoute: Suggests matching places using real map data. Generates multiple pedestrian routes when the street network allows them. Fetches current weather conditions near the trip midpoint. Estimates route-specific shade potential using nearby OpenStreetMap features. Calculates an Estimated Heat Exposure Score. Recommends the coolest reasonable route while still considering walking time. Displays every route on an interactive map for comparison. Each result includes information such as walking time, distance, heat-exposure score, estimated shade potential, and extra time compared with the fastest route.

How we built it

HeatRoute uses a small frontend-and-serverless-backend architecture.

Frontend

The interface was built with: React 19 TypeScript Tailwind CSS and custom CSS A Next-compatible App Router through vinext Leaflet for the interactive map OpenStreetMap raster tiles The map displays all available routes with separate colors and line patterns. Selecting a route card brings its polyline to the foreground. Browser geolocation allows users to select their current location as an endpoint. A separate live-location mode uses navigator.geolocation.watchPosition() to move the location marker as the user moves.

Places and routing

Place suggestions come from Photon, with an OpenStreetMap Nominatim fallback for typed locations. Coordinates from selected suggestions are preserved to avoid resolving a business or landmark to the wrong city. Walking geometry is generated by Valhalla using OpenStreetMap pedestrian data. HeatRoute requests the default route and available alternatives, removes near-duplicates, and may request additional routes through controlled waypoints. HeatRoute never draws or invents road geometry itself. Valhalla remains responsible for every generated path.

Weather and shade data

Current weather is requested around the midpoint of the trip using Open-Meteo, with MET Norway as a secondary provider. The weather inputs include: Temperature Apparent temperature Relative humidity UV index Cloud cover Route-specific shade potential is estimated using the OpenStreetMap Overpass API. HeatRoute searches for mapped features near each route, including: Trees Parks and gardens Forest and recreation areas Covered paths The result is labelled estimated shade potential because it is a geographic proxy, not a physical shadow simulation.

Heat-exposure scoring

HeatRoute uses deterministic calculations instead of asking an AI model to invent environmental measurements. Heat risk is estimated from apparent temperature and humidity: Heat Risk = clamp(round((Apparent Temperature − 20) × 4.5 + Humidity × 0.18), 8, 100) UV Risk = clamp(round((UV Index ÷ 11) × 100), 0, 100) Shade Potential = clamp(round(16 + min(36, Trees × 2.2) + min(26, Green Areas × 5) + min(18, Covered Paths × 6)), 12, 92) Environmental Intensity = 0.45 × Heat Risk + 0.25 × UV Risk + 0.30 × (100 − Shade Potential) Duration Factor = clamp(Route Minutes ÷ 20, 0.45, 1.4) Estimated Heat Exposure Score = clamp(round(Environmental Intensity × Duration Factor), 0, 100) Route Ranking Score = 0.72 × Heat Exposure Score + 0.28 × (Extra Minutes × 12) Heat Reduction Percentage = ((Fastest Route Heat Score − Selected Route Heat Score) ÷ Fastest Route Heat Score) × 100

Challenges we ran into

Generating useful alternative routes

Pedestrian networks do not always contain three genuinely different paths. Some alternatives returned by routing services overlap heavily or differ only near an endpoint. We added geometric comparison and controlled detour requests to find additional real routes without fabricating streets.

Resolving Indian places correctly

Business names and apartment complexes can be ambiguous. A search may resolve to a similarly named place in another city, producing an incorrect distance. We addressed this by biasing suggestions toward Bengaluru, preserving coordinates from selected suggestions, restricting fallback geocoding to India, and validating endpoint distance.

Keeping map state synchronized

The map initially retained old polylines or labels after new searches and map movements. We separated route, endpoint, and live-location layers so each could be updated independently. Location labels are now attached directly to Leaflet markers, allowing them to move correctly during pan and zoom.

Working with public APIs

Photon, Nominatim, Valhalla, Open-Meteo, MET Norway, Overpass, and OpenStreetMap tiles are independent public services. They may become slow, unavailable, or rate-limited. The application therefore uses fallbacks and clearly communicates when weather or shade information is unavailable instead of silently displaying invented data.

Accomplishments that we're proud of

We built a working end-to-end prototype that uses live external data instead of static or randomly generated results. HeatRoute can accept user-selected places or a current location, generate multiple real pedestrian routes, retrieve current weather, estimate route-specific shade potential, calculate heat-exposure scores, and display the results on an interactive map. We are especially proud that: Every route is generated by Valhalla using real OpenStreetMap pedestrian data. Place suggestions work with Indian locations and preserve exact coordinates to reduce incorrect distance calculations. The scoring system is deterministic, transparent, and easy to explain. Shade is clearly labelled as “estimated shade potential” instead of being presented as actual shadow data. The application distinguishes unavailable environmental data from a genuine zero value. Live-location tracking updates the user’s marker without storing location history. Route labels, markers, and polylines remain synchronized while the map is moved or updated. The complete MVP works without paid API keys or a Google Maps billing account. Non-functional features, including unreliable water-point information, were removed instead of being shown as if they worked.

What we learned

We learned that building a trustworthy environmental-routing product is mainly a data quality and systems-design problem. The most important lessons were: Preserve exact coordinates whenever possible. Treat route alternatives as optional rather than guaranteed. Separate route generation from route analysis. Never present a shade proxy as an actual shadow measurement. Show unavailable data honestly instead of replacing it with a fake value. Keep scoring deterministic and explainable. Use AI, if added later, to explain calculated facts—not to fabricate routes or environmental measurements. HeatRoute demonstrates that an existing routing engine can become more useful when transparent environmental signals are added on top of it. The project does not attempt to replace navigation platforms; it helps users make a better-informed walking decision during hot weather.

What's next for Heatroute

The next step is to improve the accuracy of HeatRoute’s environmental analysis while keeping the recommendation transparent. Future improvements could include: Adding sun position, time of day, building height, tree-canopy coverage, and seasonal information to create a more accurate shadow model. Sampling weather and environmental conditions at multiple points along longer routes. Adding verified drinking-water points and rest areas while clearly distinguishing unavailable data from zero available locations. Introducing a Fastest-to-Coolest preference control so users can choose how much extra walking time they are willing to accept. Using Gemini only to explain calculated route facts, trade-offs, warnings, and walking tips—not to generate routes or environmental measurements. Improving place search coverage for Indian businesses, apartment complexes, campuses, and local landmarks. Adding accessibility information, elevation, pavement quality, and pedestrian-safety signals. Supporting additional cities after testing the quality of routing and OpenStreetMap environmental data. Adding saved routes and preferences with explicit user consent. Building a mobile-friendly navigation experience with optional route-following and off-route alerts. The long-term vision is for HeatRoute to become an environmental layer for pedestrian navigation—helping people choose routes based not only on how quickly they arrive, but also on how comfortable and heat-aware the journey can be.

Built With

Share this project:

Updates

Submission history