ShadeMe

Inspiration

On 27 January 2026, Victoria recorded its highest temperature on record: 48.9°C in the state's northwest, with parts of Melbourne breaching 45°C. That same week, one Melbourne hospital reported a 25% jump in emergency admissions. Heatwaves kill and injure more Australians than any other natural hazard combined, and people with cardiovascular disease, kidney disease, diabetes, and neurological conditions, along with the elderly and pregnant, face disproportionately higher hospitalisation risk in extreme heat.

Yet the tools that exist to protect people are blunt. A heat warning tells you "stay home today", "today is dangerous". It doesn't tell you that the direct route to your appointment runs through an unshaded plaza radiating 65°C, while a shaded street forty metres away sits nine degrees cooler. We wanted to close that gap: not just warn people about heat, but actively route them around it.

The other half of the idea came from GIS. One of us met it in first year, semester 2, in Engineering Modelling and Design; the other had used it for an IB Geography assessment. Both times it was a tool for producing an analysis, meaning a map, a layer, a figure in a report. We'd never seen GIS sit underneath a piece of software that a person actually uses, and once we started asking what it would take to put a shadow model behind a "get directions" button, it was hard to work on anything else.

What it does

ShadeMe is a walking-route app that finds the coolest path between two points, not just the fastest one. Instead of optimising for distance, it optimises for UTCI (Universal Thermal Climate Index), the internationally standardised measure of what heat actually feels like to a human body, accounting for air temperature, radiant heat, wind, and humidity.

Under the hood, every street segment in the CBD is scored for how much thermal stress it would put on a walker at that time of day. The router then weighs that against the extra distance a detour costs. Users also get two optional preference toggles:

"Been in heat like this recently?": the body takes 1 to 2 weeks to physiologically adapt to heat (better sweat response, more stable blood pressure). Someone freshly arrived in a heatwave, whether a tourist, a new international student, or literally anyone in the season's first hot week, is working harder than someone acclimatised.
"65+, pregnant, or a heart/kidney condition?": reduced capacity to shed heat, independent of how long you've lived somewhere.

Either answer scales up how aggressively the app searches for shade, and marks a route "Best for you" instead of leaving the user to guess. No matter what's toggled, a hard safety cap ensures no route is ever routed more than 40% further than the direct walk.

App features

Physics-based cooling model: real shade simulation updated hourly, ground surface temperature, and radiant heat, rather than a guess based on air temperature and static shade alone.
Live weather-driven routing: pulls real hourly weather data rather than hardcoded days or generalised values.
Personalised heat sensitivity: two independent, opt-in toggles for heat acclimatisation and physiological vulnerability.
"Best for you" recommendation: one route highlighted based on the user's actual stated preferences, not a silently-applied default.

How we built it

The backend is a Python pipeline that layers real open data (City of Melbourne building footprints, OpenStreetMap tree canopy and road surfaces, and Open-Meteo's weather API) into a physical model of the urban environment. To do this we used GIS techniques and research-backed calculations: shadow-casting by solar position, sky view factor per street segment, a surface energy balance for ground materials, and a mean radiant temperature calculation, all feeding into the UTCI score for every individual street edge. Routing runs on A* over the walking network, using UTCI-inflated edge costs instead of raw distance, with a 40% detour cap.

Nearly all of the modelling work started life in Jupyter notebooks, one notebook per physical question, each one checked against a hand calculation or a published figure before any of it was allowed near the engine. The production package is what those notebooks turned into once we trusted them.

The frontend is a React Native / Expo mobile app, talking to the routing engine over a FastAPI service. Personalisation preferences are stored on-device rather than the server, so an untouched toggle sends no data at all and the default experience is provably unpersonalised.

Challenges we ran into

Getting the physics right, not just plausible. Early versions had real bugs hiding behind reasonable-looking output: wind units mismatched between km/h and m/s, humidity silently never being fetched, winter routes using summer shadow rasters, parks modelled hotter than asphalt, and diagonal shadow rays tunnelling through the corners of buildings instead of being blocked by them. Each one looked fine until we checked it against a ground truth.

Knowing what we could and couldn't validate. Mean radiant temperature, one of the most important numbers in the whole pipeline, can't be checked against Melbourne's public weather sensors, because none of them include a radiant heat instrument. We had to be explicit about the difference between something that's wrong, and something that simply can't be validated with the data available.

Personalising without overreaching. We wanted the app to account for the fact that heat doesn't affect everyone equally, without turning it into a clinical risk calculator we had no ability to validate. We landed on two broad, opt-in preference toggles instead of per-condition medical scoring, with the reasoning stated plainly in the app itself.

Building on a stack none of us had touched. Expo, Xcode and the iOS toolchain, and FastAPI were all new to us this weekend, on top of the modelling work.

Accomplishments that we're proud of

Getting a real physics-based radiant heat model, the same class of model used in urban heat research, running end-to-end on real Melbourne geodata, fast enough to return a route in milliseconds.

Seeing GIS become a tool rather than a deliverable. Between us we'd only ever used it to produce an analysis for a subject: a first-year Engineering Modelling and Design project, an IB Geography assessment. This was the first time we've taken the same techniques and put them underneath software that someone could actually open and use, and watching a shadow raster turn into a route on a phone was genuinely the highlight of the build.

That phone part was a first too. None of us had done mobile development before, and getting ShadeMe running in the iOS simulator, a real app with our own map and our own routes in it, was a very different feeling to seeing output in a notebook.

We're also proud of catching and fixing the shadow-tunnelling and parks-hotter-than-asphalt bugs before they made it into a demo; both would have quietly made the app give worse advice in exactly the situations it's meant to help with. And we're proud of the heat-sensitivity feature holding a genuinely honest line, being upfront that the direction of the adjustment is well-supported by physiology, while the exact magnitude is a stated judgement call, not a clinical claim.

What we learned

Most of what we learned came out of building the engine. Going from "shade is cooler" to an actual mean radiant temperature meant reading the urban climate literature properly, SOLWEIG and the papers around it, and then implementing it: solar geometry, sky view factor, a surface energy balance, the longwave terms that give hot ground its memory. Working from research-backed methods rather than tuned constants was slower and much less forgiving, and it taught us more in a weekend than we expected, including that "accurate" isn't one thing. A number can be correct-but-unprovable, correct-with-known-error-bars, or flat-out wrong.

The other half was the heat itself. Researching thermoregulation, acclimatisation, and why older, pregnant, and chronically ill people are hospitalised at such disproportionate rates put extreme heat in a genuinely different light for us. It stopped being a comfort problem and started being a health one, and that changed both the routing logic and how we chose to talk about the app's limits.

What's next for ShadeMe

A low-cost physical sensor build (a simple globe thermometer plus humidity and wind sensors) to walk a real validation transect through Melbourne and convert our radiant heat model from "structurally checked" to "locally measured"
A facade energy balance, so sunlit walls in laneways radiate realistically instead of sitting at air temperature, currently our largest known modelling bias
Expanding beyond the CBD footprint
Public deployment with live weather refresh

Disclosures

AI-assisted development. We used AI assistance throughout the build: Anthropic's Claude, via Claude Code, mostly the Opus 5 model.

The concept, the features, and the modelling approach are ours. The physics engine was designed by us: which model to implement, which terms matter, what to validate against, and what we were and weren't entitled to claim were all decisions we made and can defend. Most of it was worked out first in Jupyter notebooks, one physical question at a time, and checked by hand or against published figures before it was trusted.

Within that, Claude was used heavily as an implementation partner: turning our derivations into working code, helping with the harder numerical and geometric parts of the engine, and getting us productive fast in tools none of us had used before, since Expo, Xcode, and FastAPI were all new to us. A meaningful share of the code in this repository was written with AI assistance and then reviewed, tested, and corrected by us. Several of the bugs listed under Challenges were ones we found in that reviewing.

Pre-existing libraries, assets, and datasets.

Data: City of Melbourne Open Data (building footprints, tree canopy, surface materials), OpenStreetMap (walking network, road surfaces, opening hours), Open-Meteo (hourly weather forecast API), ARPANSA (live UV index).
Libraries: the standard open-source Python geospatial and scientific stack (Shapely, pyproj, rasterio, NumPy, SciPy, pandas, NetworkX, pvlib) served over FastAPI/Uvicorn, and React Native / Expo with MapLibre, NativeWind and Reanimated on the mobile side.
Methods: our mean radiant temperature and UTCI implementation follows published urban-climate literature (SOLWEIG and the UTCI standard). The implementation is ours, the physics is not.

No pre-existing project code was reused; the repository was started at the beginning of the hackathon.