Heat Shadow: Mapping Delhi's Invisible Heat Risk with Gemini and Earth Engine

Harjot Singh — Wed, 15 Jul 2026 04:40:24 +0000

Every summer, Delhi's heatwaves make headlines — record highs, IMD red alerts, hospitals filling up. But the citywide temperature number everyone quotes hides something important: heat risk isn't evenly distributed. A settlement with tree cover and a settlement with none can sit two kilometres apart, register the same official temperature, and face completely different realities on the ground.

I wanted to build something that made that difference visible — and actionable — for the people actually responding to it: NGOs and field teams deciding, every morning, where to send limited cooling resources.

That's Heat Shadow.

## The problem with "it's 47°C today"

Delhi's informal settlements — jhuggis, resettlement colonies — are consistently the hardest hit in heatwaves, for reasons a single temperature reading doesn't capture:

Tin roofs re-radiate heat, so indoor temperatures can run 3–5°C above the outdoor reading
Narrow, dense lanes trap heat overnight, so residents get little relief before the next day's peak
Tree canopy is unevenly distributed — some clusters have partial shade during peak sun hours, others have almost none

Existing heat-response tools report one number for the whole city. They don't tell a field team which specific settlement has zero shade from 11am to 4pm today, or why — is it tin-roof density, is it proximity to a landfill, is it floodplain humidity pushing the heat index up. That's the gap Heat Shadow tries to close.

## The core idea: hours of exposure, not just temperature

The insight the whole project is built around: two settlements at the same peak temperature can face very different real risk depending on how many hours of the day they get zero shade. So instead of ranking clusters by temperature alone, Heat Shadow computes an "unshaded hours" figure per settlement — how many hours of the 9am–6pm peak-sun window have no canopy cover at all — and weights that heavily into the risk score.

That number becomes the visual center of the dashboard: a 24-hour radial "shadow dial" per settlement, where the filled arc shows exactly which hours are exposed.

## How it works

1. Satellite thermal + canopy analysis — Google Earth Engine
Each night, a script pulls Landsat 8/9 land surface temperature data and Dynamic World land-cover classification for every registered settlement cluster, computing peak temperature and tree-canopy fraction.

2. Risk scoring
A transparent, tunable formula converts peak temperature, unshaded hours, and population density into a single 0–100 risk score — weighted toward exposure duration, since that's the factor generic heat maps miss.

3. Hyperlocal advisories — Gemini API
This is where it stops being just a map. gemini-2.5-flash takes each cluster's raw numbers and its specific local risk factors (landfill proximity, tin-roof density, floodplain humidity) and writes a short, concrete advisory — in English and Hindi — for the field team responding that day. The prompt is deliberately built to avoid generic "stay hydrated" output: it asks for one specific, actionable priority per cluster, grounded in that cluster's actual conditions.

4. The dashboard
A ranked daily priority queue, so an NGO can see at a glance which settlements need attention first — and click into any one for the full risk breakdown and advisory.

## Google tech stack

Component	Technology
Thermal + shade analysis	Google Earth Engine (Landsat 8/9, Sentinel-2, Dynamic World V1)
Advisory generation	Gemini API (`gemini-2.5-flash`)
Data storage	Firebase / Firestore
Geolocation	Google Maps Platform
Scheduling	Cloud Run + Cloud Scheduler

## What I'd build next

This is a prototype, not a pilot — the honest next steps are:

Partner with an NGO to register real cluster boundaries and validate population data against ward surveys
Replace the shade heuristic with a proper solar-position + building-height shadow model
Push advisories directly to residents via WhatsApp Business API, not just field teams
Add a feedback loop where field teams mark whether a cooling point was actually needed, to correct the model over a season

## Try it

Code, architecture writeup, and the real Earth Engine + Gemini integration scripts are on GitHub: **https://github.com/Harjotsingh00/heat-shadow

Video link: https://drive.google.com/file/d/1RhS5stfwkwe2YSbZHnXdqMbTkQyvka0S/view?usp=sharing

If you're working on something similar for heat resilience or civic tech in India, I'd love to hear from you.

Built for [Google AI APAC Builder submission]. Google technologies used: Gemini API, Google Earth Engine, Firebase/Firestore, Google Maps Platform.

DEV Community: Harjot Singh

Heat Shadow: Mapping Delhi's Invisible Heat Risk with Gemini and Earth Engine