Before the Spark
An engineering deep dive into moving past reactive heatmaps by using Cloud-Optimized GeoTIFFs and serverless AWS to forecast crop fire risks 48 hours before ignition.
Building an Early Warning System for Agricultural Fires
Agricultural stubble burning across Northern India generates massive amounts of seasonal smoke, but existing environmental dashboards generally only track fires after they have already ignited. When our team entered the WeMakeDevs and AWS Environmental Hacks event, we knew that plotting active thermal anomalies on a heatmap would not be enough. By the time a satellite registers a fire, the air quality damage is already done. We built an early warning system to shift the focus from reactive detection to proactive prevention by calculating the risk of ignition 24 to 48 hours before a field is burned.
1. Current solutions implemented
Our current implementation provides a functional web interface and a backend risk evaluation engine designed to monitor crop residue. The primary user interface is built around a central map (
MapView.tsx ), which is controlled by a timeline slider ( TimelineSlider.tsx ) that allows users to view different temporal risk windows. The actionable insights are separated into a LeftPanel.tsx for regional breakdowns and a RightPanel.tsx for specific environmental metrics.Behind the interface, our risk engine (
risk_engine.py ) processes geographic data for specific districts using our punjab_pilot_districts.geojson configurations. The system evaluates this data against historical fire samples ( historical_fires_sample.json ) and calculates a priority score. If a village's risk score exceeds a critical threshold, the system triggers automated routing manifests through a dedicated WhatsApp integration ( whatsapp_service.py ). This allows municipal officers to receive a prescriptive, text-based list of high-risk farms to target with crop residue management machinery.2. What are we doing?
We are addressing the gap between passive satellite observation and active municipal intervention. In Track 01 of the hackathon, the prompt focused on air quality and stubble burning. Existing tools pull NASA FIRMS data and color the map red where fires are actively burning. A municipal officer staring at a screen in a moving jeep cannot use that information to prevent anything.
We wanted to bypass the passive dashboard entirely. By analyzing spectral data, radar imagery, and weather patterns before the stubble is lit, we aim to identify high-risk farm units. We restricted our initial scope to a pilot program in Punjab to test our assumptions on a well-documented geographic region. The intended workflow gives block development officers a prioritized list of at-risk locations, enabling them to deploy Happy Seeders and tractors precisely where they are needed most before the first spark occurs.
3. Technical approach
We separated the project into a React frontend and a serverless Python backend to allow our UI and API teams to iterate independently. Early in development, we relied heavily on a
mock_state.json file, which allowed frontend development to proceed without waiting for the backend mathematical models to stabilize.Our backend architecture relies on strict, deterministic mathematical modeling. Initially, we explored agentic AI approaches, as evidenced by our
AGENTS.md documentation and test_novelties.py suite. However, we realized that parsing environmental variables through probabilistic models was too slow and complex for a reliable early warning system. Instead, we built spectral.py , which calculates the Normalized Difference Vegetation Index to detect sudden crop harvests, and the Normalized Difference Tillage Index to quantify unmanaged straw left in the field.To ingest this data without exhausting memory limits, our
cog_service.py leverages Cloud-Optimized GeoTIFFs from the Registry of Open Data on AWS. Because COGs are internally tiled, we pass the exact bounding box of our target Punjab villages into an HTTP range request. This extracts only the 50 to 60 KB pixel slices we actually need, rather than downloading entire 500 MB satellite files.One of our most practical engineering decisions was building a failsafe for local development. We integrated a local filesystem emulator directly into our
aws_service.py class. If a team member runs the backend without active AWS credentials, the application intercepts the SDK calls and saves the JSON state snapshots to a local mock directory, preventing IAM permission bottlenecks from blocking local testing.4. Where AWS comes into play
Our backend is designed to run entirely on AWS serverless infrastructure. We manage our infrastructure as code using the AWS Serverless Application Model, which is defined in our
template.yaml file.The core API routes and scheduled evaluation tasks are handled by AWS Lambda functions. Our risk engine is designed to run on an Amazon EventBridge schedule early every morning. Lambda handles the Python routing and risk algorithms, requiring zero idle compute costs. When an intervention is required, the system triggers Amazon Simple Notification Service alongside our custom Python scripts to dispatch the alerts. We chose this strictly serverless architecture because it minimizes costs during idle periods while scaling automatically when officers poll the API for updates during peak morning hours.
5. Current limitations
Our current implementation faces several concrete constraints. Processing complex geographic polygons from
punjab_pilot_units.geojson against spectral math is computationally intensive. Because we execute this on AWS Lambda, we occasionally push the functions dangerously close to their maximum execution timeout limits during cold starts.We also rely heavily on external data sources, including the Central Pollution Control Board (
cpcb_service.py ) and NASA FIRMS. These external dependencies introduce uncontrollable latency and potential rate-limiting bottlenecks into our pipeline. On the frontend, despite moving toward unified side panels, we still rely on nested pop-ups like EvaluationModal.tsx and FarmerReportModal.tsx . This design remains cumbersome to navigate on smaller mobile screens in the field. Finally, while the WhatsApp integration functions properly in our isolated testing environment, it has not been validated for high-volume automated broadcasting.6. Future scope
The most necessary architectural improvement is permanently offloading the heavy raster and spectral processing to ephemeral AWS Fargate containers. This migration will solve our current timeout limitations, allowing us to keep AWS Lambda strictly dedicated to fast API routing and state management (
state_engine.py ).On the data integration side, we need to implement an internal caching layer for the external weather and emissions APIs. Storing this data temporarily in Amazon DynamoDB would drastically reduce our external dependency bottlenecks, protect the application from third-party rate limits, and improve the overall load times for the frontend map view.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article