AWS Builder Center

Smoke - Scout (TEAM TERRA)

Smoke - Scout is a web app that traces stubble smoke back to where it probably came from. Drop a pin in MAP and it checks the air, and then follows the wind upwind, looks for NASA FIRMS satellite-spotted fires, and names the likely district. Built on AWS Lambda, API Gateway, S3, DynamoDB and Amplify.

Smoke Scout: Tracing Stubble Smoke Back to Its Source

Every autumn, the air over Punjab and much of north India turns thick and grey. A big reason is stubble burning: after the rice harvest, farmers have very little time before the next crop, and setting the leftover stalks on fire is the quickest way to clear a field. The smoke doesn't stay put. It drifts for hours, sometimes across state lines.
Most of us only see the end of that story: a number on some weather app. It doesn't say where the smoke came from, and it doesn't say whether we should open the window. Smoke Scout is a small web app we built for  Environment Hacks 2026 - WeMakeDevs x AWS  to answer both. You drop a pin on a map of Punjab and it tells you how the air looks. If the air is bad, it works backwards towards the wind to show where the smoke most likely came from, and whether NASA FIIRMS satellite has spotted fires there.

What it does

Smoke Scout has two modes, and you pick one on the first screen.
The first one, “When can I open my windows?”, is for everyday use. Drop a pin where you live and it shows the fine dust (PM2.5) in the air right now, along with how it's expected to look at 6 AM and 2 PM tomorrow.
The second one, “Trace the smoke”, is for stubble fires. Drop a pin, pick how many hours back to look (1 to 6 hours) and press Investigate. Now our application draws a cone on the map showing where that smoke could have come from, mark any fires the satellite spotted inside it, and name the district it points to.

How the pin behaves

To avoid random clicks on the map that can be taken as pin drop we set up a Google Map like system where the first click drops a permanent pin. After that, a click only shows a faint temporary pin with a “Use this spot” button, and the original pin stays until you confirm. You can also drag the pin, use your device's location, tap a city shortcut or type coordinates.

The backend: the investigator

When you press Investigate, the backend starts with the air at the pin. If it's clean, it says so and stops. If PM2.5 is 30 µg/m³ or more, or it jumped by 20 in the last hour, it carries on and reads the wind: how fast, and which direction it's coming from. Multiply the speed by the hours you chose and gets the distance.
From the pin it looks at far upwind and draws a narrow cone, 15° either side, because wind is never perfectly steady. Then it pulls the last day of fire detections from NASA FIRMS and keeps the ones inside the cone. It finds the district using our district map (geoJSON file) and gives the result a score: 10 if a fire sits inside the cone, 3 if not. With no fire, the far end of the cone becomes the estimated origin. Every investigation gets saved.

The frontend: the map

The app is built with React. The map is drawn with Leaflet on CARTO tiles, light for everyday use and dark for investigations. It draws what the backend sends: an amber cone for the search area, diamonds for satellite fires, and a dashed circle for the estimated origin when no fire was found. A side panel explains each piece in plain words and reminds the reader that this is an approximation, not a confirmed sighting.

How the two halves talk

The two sides talk through one small request: the pin's latitude and longitude, the mode and the hours to look back. The backend answers with the status, score, district and the shapes for the map, and the app checks that answer before showing anything. There are no accounts, and nothing is stored in your browser.

What we used

We tried to keep the toolbox small, and almost all of it free.
  • The app: React and TypeScript, built with Vite, with Leaflet for the map on CARTO tiles (OpenStreetMap data).
  • The brain: one Python function on AWS Lambda.
  • Air and wind: Open-Meteo, a free weather and air-quality service.
  • Fire detections: NASA FIRMS, which publishes near-real-time fire detections from satellites.
  • District boundaries: a map of Punjab's 23 districts that we drew ourselves, saved as a GeoJSON file.
  • AWS: Lambda, API Gateway, S3, DynamoDB and Amplify, each covered below.
We also wrote the map maths ourselves. “Is this point inside this shape?” and “where do I end up after 72 km in this direction?” take only a few lines of geometry, so we skipped heavy mapping libraries and kept the backend a single small file.

Working smart, not hard

A tool like this can easily waste effort, or sound more certain than it is. A few choices keep Smoke Scout efficient and honest.
  • It only investigates when needed. If the air is clean, it says so and stops: no wind lookup, no satellite call, nothing saved.
  • It remembers the district map. The function keeps it in memory between requests, so only the first request pays to load it.
  • It never waits forever. Every outside call has a time limit. If a service fails and stand-in numbers appear, the app warns you instead of showing them as real.
  • It stays inside its lane. Pins outside Punjab, or outside the satellite search area, can't be investigated.
  • It chooses its words carefully. It never says “this farm caused this smoke.” A fire in the cone is a “satellite hotspot detected within the search corridor”; no fire is a “possible plume, no matching hotspot.” The estimated origin is dashed and labelled a calculation.

Reading the results

The same data has to work for a parent deciding about outdoor games with their child and an officer deciding where to send a team, so the screens are built for two readers.

For everyday people

  • A plain headline first, like “Keep windows closed for now.”
  • Four simple bands: good (under 60), moderate to poor (60 to 120), very poor (120 to 250) and severe (250 and above), in PM2.5 µg/m³.
  • Now, 6 AM and 2 PM side by side. A later time is only “comparatively better” if it is clearly lower, and even then the app reminds you the air is still polluted: “less bad,” not “clean.”
  • Practical advice: a mask, closed windows, or a walk moved to the afternoon.

For officials and field teams

  • The cone is a place to look, not a verdict.
  • Diamonds are satellite detections. Click one for its fire power, the time it was seen (UTC) and its coordinates.
  • The dashed circle is a calculation, marking where the middle of the cone ends when no fire is found.
  • The district name says where to look first.
  • Measured and estimated are kept apart. PM2.5 at the pin is measured; wind speed and drift distance are estimates, and labelled that way.
  • Every investigation has an ID, so there is a trail to come back to.
The rule we kept repeating: a fire inside the cone means “worth checking,” not “proven.” Smoke Scout helps decide where to look. It isn't evidence on its own.

AWS Lambda: the brain

We use Lambda to run the whole backend: a single Python function that checks the air, traces the wind, asks NASA about fires, finds the district and sends the answer back. Traffic for something like this is uneven, quiet for days and busy when smoke season peaks, so paying only when it runs made sense, and there is no server to look after.

Amazon API Gateway: the front door

We used the API Gateway to help the app reach Lambda. It gives the function a web address, passes each request through and returns the answer. We also set the CORS rules there, so only our Amplify site can call it from a browser. This saves us from fraudulent requests to our backend (CORS).

Amazon S3: the map shelf

A district name is something a person can act on, and it needs a map of district boundaries. That is the one piece of data that doesn't come from an outside service: we had the Punjab's 23 districts saved as a single GeoJSON file in Amazon S3.
The function reads the file once, keeps it in memory, and checks which district the likely source falls in. S3 suits the job: a plain file that rarely changes, cheap and always there. Updating a boundary means uploading a new file, with no change to the function.

Amazon DynamoDB: the notebook

Every full investigation gets saved in DynamoDB: an event ID, the time, the pin's location, the estimated source, the district, the status and score, and the PM2.5 and carbon monoxide readings. It's only coordinates and readings, nothing personal, and if saving ever fails the user still gets their answer. Over time it also gives us a record of which districts show up most, and when.

AWS Amplify: the shopfront

We host the frontend on Amplify. It's connected to one of our GitHub repository, so every push rebuilds the app and publishes it at a public HTTPS address. The only setting the app needs is the address of our API along with the CARTO map API key.

What we went through

The idea fits in a sentence. Making it behave took care, and a few problems shaped the final design.
  • Drawing Punjab's districts ourselves. We wanted a district name, not just a dot on a map, so we created the 23-district boundary file and had the backend read it. It took a while because it was not available anywhere - only a 22 district json file was available on open sources
  • Getting the wind direction right. Weather services report where the wind comes from, not where it goes. Mix them up and you search the wrong side of the pin, so the app checks the cone's direction itself.
  • Making a click mean what you meant. A stray tap on a phone shouldn't wipe out your choice, hence the temporary pin you confirm, and no accidental pins from double-click zoom or dragging.
  • Free services have off days. Open-Meteo and NASA can be slow or unavailable, so every call has a time limit and clear messages, and stand-in values are flagged.
  • Teaching the browser to trust our site. We set up the API to welcome our Amplify site specifically.
  • Saying less than we know. This was the hardest part. A trace pointing at one fire can sound like an accusation, so every label asks the same question: does this claim only what the data supports?

What's next

Smoke Scout is built for Punjab, but stubble smoke doesn't stop at a state border. Fires in Punjab and Haryana are widely cited as one of the contributors to the autumn smog over Delhi and the wider NCR, carried by north-westerly winds over hundreds of kilometres. A resident in Delhi sees a bad number without knowing where it came from, and an officer in a district sees fires without knowing who is downwind. Linking the two, across state lines, is what this idea is for.
Some directions it could grow in:
  • Beyond Punjab: Haryana, Delhi and the wider NCR, by widening the satellite search area and drawing district maps for the new states.
  • Longer wind trails, using hourly wind history and winds at different heights, for smoke that travels a day or more.
  • More satellite sources, with fires ranked by distance, power and time.
  • Ground-level checks against official monitoring stations and local sensors.
  • Alerts by SMS or WhatsApp for officers and residents.
  • A dashboard for authorities built on the saved investigations.
  • Hindi and Punjabi, and a lighter app for weak connections, so farmers can use it too.
  • Open data and a public API for researchers and other developers.
  • 

Closing thoughts

Smoke - Scout began with a simple question: if the smoke is here, where did it start? It doesn't claim to have the final answer. It offers a careful starting point and a few clues to check, in seconds, on a phone, with no server for us to maintain. A handful of small AWS services, each doing one job, made that possible.
The part we care about most is the restraint. The app is clear about what it measured, what it estimated, and where its knowledge stops. We think that is what makes a tool like this safe to use for decisions about people's health and about people's fields.
If you'd like to read the code (and more of our rant):
We'd love to hear what you think, from anyone - if you want to try out our app contact us through the comment box and we'll share the link to you personally.
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