HeatCommons

• 

  01-plan-overview

• 

  03-local-place-note

• 

  02-route-options

Inspiration

Planning a short trip on a hot day takes more than checking the temperature. The forecast, places where someone might pause, and the walking network usually sit in separate tools. I wanted to bring those clues together around one practical question: how can I make the next few hours and the trip ahead easier to plan?

What it does

HeatCommons combines an hourly apparent-temperature forecast with mapped drinking-water points, green spaces, and indoor public places. People can explore Kuala Lumpur or Dehradun, filter nearby places, compare a footpath-preferring walk with the shortest mapped walk, and add a stop to a simple day plan. A place note can also be saved in the current browser for personal reference.

How we built it

I built the interface with React, TypeScript, Vite, and React Leaflet. Open-Meteo supplies weather forecasts; OpenStreetMap tiles and place data queried through Overpass provide the map context; and Valhalla returns pedestrian routes on OpenStreetMap data. The browser caches recent map and route results, while personal place notes stay in local browser storage. If a live service is unavailable, the app labels sample weather or places clearly and explains when a route cannot be shown.

Challenges we ran into

Open map data can be incomplete, stale, or unclear about public access. A mapped park does not prove shade, an indoor listing does not prove cooling or opening hours, and a route that follows mapped footpaths does not measure shade, sidewalk quality, accessibility, or closures. I made those limits visible in the interface and kept source and freshness information close to the data. I also designed fallbacks so an API problem does not turn into a confident-looking but invented answer.

Accomplishments that we're proud of

I connected forecast context, nearby places, and route choices in one usable flow across two cities. The map filters, route comparison, plan actions, and personal place-note form work together without an account. I am especially proud that the interface explains where its data comes from and what it cannot verify, while keeping the experience calm and easy to scan.

What we learned

I learned that more data is not automatically more useful. People need to see the source and limits of a suggestion to judge whether it fits their situation. I also learned to keep different route trade-offs visible instead of presenting one route as universally best, and to design around third-party data gaps from the start.

What's next for HeatCommons

I would validate mapped places and access details with people who know each neighborhood, improve data freshness and provenance, and test the planning flow with outdoor workers and other people who travel in the heat. Any future shared place reports would need clear consent, moderation, and privacy controls; notes in this prototype are currently stored only on the user's device.

Built With

• leaflet.js
• open-meteo
• openstreetmap
• react
• typescript
• valhalla