AWS Builder Center

Builder Center

Chasing the Heat: Building HEPo With Python and AWS SAM

HEPo is an open-source Progressive Web App that identifies localized urban heat pockets using simulated temperature and humidity observations, helping visualize potential heat risks at a neighborhood scale. Built for the Environmental Hacks challenge, it combines a spatial detection engine, interactive mapping, and AWS SAM-based serverless development to explore how localized heat insights can support safer, more climate-aware cities.

 How a student developer turned a question about urban heat into an interactive geospatial prototype. 

Every quest begins with a problem. Mine began with a question: What if two streets in the same city felt very different, but the map showed them as one place?
A city-wide temperature reading can tell us something about the weather. It cannot necessarily tell us what is happening on every street, beside every concrete wall, or beneath every patch of shade. Urban heat varies with vegetation, building density, surface materials, and local airflow.
I wanted to explore those differences.
I did not have a network of calibrated temperature sensors, a research laboratory, or an army of engineers. I had a laptop, a development environment, and a problem worth investigating.
That was enough to begin.

The quest: Finding heat pockets

Urban heat is not distributed evenly. Two locations a few hundred metres apart can experience different thermal conditions. Regional weather reports remain valuable, but they may not capture every small-scale variation within a city.
These differences matter to outdoor workers, delivery couriers, pedestrians, event organizers, and urban planners. Better localized information could help people identify areas that deserve closer investigation.
The challenge was to turn this broad idea into something people could explore.
I called the project HEPo, or Heat Encroachment Pockets, pronounced “hippo.”
HEPo is an experimental Progressive Web App (PWA) that explores how geotagged temperature observations could help identify and visualize potential urban heat anomalies.
The goal was not to claim that I could map a city's real heat conditions with a few lines of code. It was to build a prototype that demonstrated the workflow, exposed its assumptions, and provided a foundation for further testing.

The first dragon: Data without sensors

A map full of colorful markers is easy to build. A map that communicates trustworthy environmental information is much harder.
Without physical sensors or a validated environmental dataset, I needed a way to test the detection pipeline without confusing invented observations with real measurements.
I built a synthetic observation generator that creates 26 observations across four demonstration zones. Each observation includes fields such as temperature, humidity, timestamp, and geographic coordinates.
The generated dataset lets me exercise the application without claiming access to live environmental measurements.
This distinction is central to HEPo: the current observations are simulated, not collected from physical sensors. The displayed heat pockets demonstrate the prototype's detection workflow. They do not establish actual temperatures at the example coordinates.
Synthetic data gives me a controlled starting point. It does not replace field validation.

Teaching the map to notice differences

HEPo's Python detection engine looks for temperature differences between nearby groups of observations and their local surroundings.
The current prototype uses these configurable rules:
Detection parameter
Current value
Observation time window
15 minutes
Approximate clustering radius
200 metres
Minimum observations per cluster
3
Minimum temperature anomaly
+3.0°C above baseline
The engine validates observation data, groups geographically nearby points, estimates a local baseline, and evaluates the temperature difference. It can return contextual information such as cluster temperature, baseline temperature, observation count, and a heuristic confidence classification.
These rules are engineering choices for the prototype, not scientifically established thresholds. The confidence labels are not validated probabilities.
A real deployment would need calibrated sensors or trusted environmental datasets, reference measurements, and systematic evaluation before anyone could rely on its results for heat-safety decisions.
For the interface, I used JavaScript and Leaflet to create an interactive map. Users can explore the demonstration data and refresh the simulation to generate another dataset.
The PWA structure supports browser access across desktop and mobile devices. Its service worker provides application-shell caching for supported offline use, although API requests and uncached map tiles can still require a network connection.
The result is a working environment for exploring the idea, rather than a claim that the scientific problem has already been solved.

The workshop: Python, Docker, and AWS SAM

Building the interface was only part of the journey. I also wanted a serverless API structure that I could test locally before considering a cloud deployment.
HEPo includes an AWS Serverless Application Model (AWS SAM) template and a Python Lambda-compatible handler. The application defines two API routes:
  •  POST /simulate  generates a synthetic observation dataset.
  •  POST /detect  processes submitted observations and returns detection results.
AWS SAM CLI lets me define and validate the serverless application in a template. SAM Local provides a way to exercise the API routes through HTTP on my own machine.
I use Docker with  sam build --use-container  to build the application in an environment compatible with its configured Python 3.12 Lambda runtime. This is useful when the host development environment uses a different Python version.
My local workflow looks like this:
Plain text
Synthetic observations
         |
         v
   Python generator
         |
         v
     POST /simulate
         |
         v
   Browser-based PWA
         |
         v
    Interactive map

Submitted observations
         |
         v
      POST /detect
         |
         v
 Python detection engine
         |
         v
   Detection results
The frontend also contains client-side detection logic. As a result, the map's displayed results should not automatically be attributed to the server-side  /detect  route.
This architecture gives me separate pieces to inspect and test. It also provides a route toward future serverless deployment without requiring a public cloud endpoint during early development.
HEPo currently uses AWS SAM locally. It has not been presented as a deployed AWS cloud service. I do not claim a live Lambda deployment, a production API Gateway, or a cloud database.
There is a difference between preparing an application for a cloud environment and actually operating it there. Documenting that difference is part of building software responsibly.

AI-assisted development, with the developer still responsible

I used Antigravity CLI and AWS Kiro CLI as AI-assisted development tools while working on HEPo.
They helped support the implementation workflow, but tool assistance did not remove the need to inspect the code, connect the components, test the behavior, or document limitations.
An implementation suggestion is not proof that a feature works. A successful syntax check is not proof that the whole application works. A local test is not proof that a cloud deployment works.
Those distinctions shaped how I approached the project.
My focus was to build a coherent prototype, validate the parts I could test, and keep the documentation aligned with the actual implementation.

What I learned along the way

HEPo taught me that the interesting part of building an environmental application is not simply putting data on a map.
It is deciding what the data means, how to compare observations, how to communicate uncertainty, and how to prevent a demonstration from being mistaken for evidence.
I also gained practical experience connecting a browser-based application to a Python backend, defining API routes with AWS SAM, and using Docker to support a compatible local build environment.
Most importantly, I learned to distinguish between an idea, a prototype, a validated system, and a deployed service. They are different stages of engineering, and each requires its own evidence.

The next stage of the quest

HEPo is a beginning, not a finished environmental monitoring system.
The next steps are to integrate validated environmental datasets or calibrated sensors, evaluate detection accuracy against reference measurements, improve baseline estimation, and investigate historical comparisons.
Only after those steps would it make sense to assess a secure cloud deployment and persistent storage.
The longer-term question remains simple: Can localized environmental observations help reveal patterns that broad averages hide?
I do not yet have the evidence to answer that question for real-world conditions. I have built a prototype that lets me investigate it.

Build, test, and explore

HEPo was built for Environmental Hacks · Bharat Builds Tour, organized by WeMakeDevs and AWS Builder Center, in the Heat and Water track.
  • Project: HEPo — Heat Encroachment Pockets
  • Languages and frameworks: Python, JavaScript, HTML, CSS, and Leaflet
  • AWS tooling: AWS SAM CLI, a Lambda-compatible handler, and SAM Local with Docker
  • Data status: Synthetic simulation data
  • Deployment status: Local development and testing
The project also builds on open-source software and community work, including Python, Leaflet, OpenStreetMap, Git, and AWS SAM CLI. I used Antigravity CLI and AWS Kiro CLI to support AI-assisted development. Each project retains its own license and attribution requirements.
A quest does not become worthwhile because the hero declares victory. It becomes worthwhile when the journey produces something others can inspect, question, test, and improve.
HEPo is my attempt to start that journey, one simulated observation at a time.
# aws-sam# aws-lambda# kiro
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