Building DrainGuard: Prioritizing Bengaluru’s Drain Inspections with Geospatial Data and AWS
How I built DrainGuard, a geospatial decision-support prototype that helps prioritize drainage inspections before heavy rainfall in Bengaluru. This article explores the problem, interactive mapping and risk-ranking approach, AWS serverless architecture, development challenges, and lessons learned while building an environmental technology project.
Student
Building DrainGuard: Prioritizing Bengaluru’s Drain Inspections with Geospatial Data and AWS
Introduction: A Local Problem with Real-World Impact
Urban flooding and waterlogging are difficult challenges for cities, especially during periods of heavy rainfall. When drainage infrastructure intersects with low-lying terrain and other vulnerable locations, some areas may need attention sooner than others.
One practical challenge is deciding where inspection teams should focus their limited time before rain arrives.
As a student developer, I wanted to explore how geospatial data and cloud technology could help address this problem. That led me to build DrainGuard, a drainage inspection prioritization prototype designed around Bengaluru.
The goal is straightforward: instead of showing only where drains are located, can we help users understand which locations may deserve inspection first and why?
What Is DrainGuard?
DrainGuard is an interactive geospatial decision-support application designed to help field teams explore drainage locations and prioritize inspections before heavy rainfall.
The prototype combines several geographic data layers, including:
- Drainage network features
- Flood-prone locations
- Low-lying areas
- Terrain slope information
The application brings these layers together on an interactive map. Users can explore different rainfall scenarios, view priority-ranked drainage locations, inspect geographic risk factors, record field observations, and track inspection status.
A key design decision was to make the ranking explainable. A number alone is not enough for a useful inspection workflow. Users should also be able to examine the geographic context behind a location’s score.
DrainGuard is not a flood forecasting system. Its current rankings are heuristic priorities intended to support inspection planning, not validated predictions of flood probability or water depth.
How I Built the Geospatial Experience
The first major challenge was preparing geographic data that could be used consistently in an interactive map.
The project brings together thousands of drainage features and supplementary environmental layers. I used Python geospatial tools to work with the source data, validate geometries, and prepare map-ready GeoJSON files.
For the frontend, I chose Next.js, React, TypeScript, and Tailwind CSS. Leaflet provides the interactive mapping functionality, allowing users to explore drainage features alongside supporting geographic layers.
I also implemented rainfall scenario controls and a priority list so that users can move from a city-wide view to a specific location. The field observation workflow is intended to connect geographic prioritization with information collected by people on the ground.
This matters because a map is most useful when it helps someone take a concrete next step.
Making Prioritization Explainable
DrainGuard uses a deterministic scoring approach that combines geographic indicators, drainage hierarchy, a rainfall scenario factor, and the presence of field observations.
The score is intended to help users compare locations under the same scenario. It should not be interpreted as a probability that a particular drain will flood.
This is an important limitation. A heuristic can help organize an inspection queue, but it cannot replace verified field information, reliable rainfall observations, or model validation.
A future version could distinguish more clearly between drain conditions such as clear, partially obstructed, and severely obstructed. It could also be evaluated against historical inspection findings to determine whether the rankings actually help field teams allocate their time more effectively.
Connecting the Backend to AWS
I wanted to learn how a locally developed environmental application could begin moving toward a serverless cloud architecture.
The frontend is built with Next.js and communicates with a Node.js API. For the cloud backend, I chose two AWS services:
AWS Lambda: Lambda runs the backend handler without requiring me to provision or maintain a traditional server. I created a Node.js function and successfully tested its health-check response through the Lambda console.
Amazon API Gateway: API Gateway provides the HTTP API layer intended to expose the backend endpoints. During development, I worked through route configuration, Lambda integration, and deployment settings to make the application’s API paths available.
I also developed DynamoDB integration handlers for field observations and inspection records. At the time of writing, the API Gateway proxy configuration and end-to-end DynamoDB persistence still require final verification. I consider that an important remaining engineering task, rather than assuming that writing a handler means the complete cloud workflow is working.
This experience taught me that deploying an individual cloud function is only one part of building a working cloud application. Route paths, permissions, integrations, environment configuration, and persistent storage must work together.
Challenges and Lessons Learned
One of my biggest lessons was that data preparation can be just as important as the user interface. Geographic features must have usable geometries and consistent formats before they can become reliable map layers.
Another lesson was the importance of keeping a prototype’s claims proportional to its evidence. A priority score can be useful without being a validated prediction, provided its purpose and limitations are clear.
Working with AWS also helped me understand the difference between creating a function and exposing a complete API. Testing each layer separately makes it easier to identify where a problem occurs and prevents an unverified feature from being presented as finished.
Most importantly, I learned to approach environmental technology as a decision-support problem. The aim is not simply to produce another map or dashboard, but to help someone decide what action to investigate next.
What Comes Next?
My next priorities for DrainGuard are to verify end-to-end cloud API behavior, confirm persistent storage for field observations and inspection status, and test the application as a complete workflow.
Further improvements could include richer field-condition scoring, better rainfall inputs, validation against real inspection outcomes, and feedback from people familiar with municipal drainage operations.
These improvements would help determine whether the prioritization approach is useful beyond a demonstration.
Conclusion
DrainGuard began with a simple question: when heavy rain is approaching, how can inspection teams decide where to look first?
By combining geospatial data, an interactive map, explainable heuristic rankings, and an AWS serverless backend, I have developed a prototype that explores one possible answer.
The project is still evolving, but the process has strengthened my understanding of geospatial data engineering, full-stack development, serverless architecture, and responsible technical claims.
For me, the most valuable outcome is not just the application itself. It is learning how to connect data, software, and cloud services to investigate a real-world environmental problem.
Project: DrainGuard
Track: Heat & Water
Technology: Next.js, React, TypeScript, Leaflet, GeoJSON, Node.js, AWS Lambda, Amazon API Gateway, and DynamoDB integration handlers
Source code: [Insert your public GitHub repository URL]
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article