FloodLens Jakarta

• 

• 

• 

• 

Inspiration

Jakarta's floods are usually described at city scale, but their consequences begin much closer to the ground. A sewer rises, a drain loses flow, a street becomes impassable, and a neighborhood has only minutes to react. Weather forecasts can indicate regional rainfall, but they do not always explain what is happening inside local drainage infrastructure or what a community should do next.

FloodLens grew from my earlier work on this problem. In 2023, I worked on the award-winning Smart Sewer concept for the I²Tech Olympiad's IoT & Data Analytics challenge. It proposed ultrasonic sewer sensing, Arduino-to-cloud telemetry, municipal monitoring, pump actuation, SMS alerts, and yellow, orange, and red response levels. In 2025, I helped turn related ideas into a physical embedded-system prototype using water-level sensing, LEDs, a buzzer, an LCD, servo response, time-series logging, smoothing, peak detection, and anomaly analysis.

FloodLens is the next step: a public, interactive decision layer that connects environmental and infrastructure signals to explainable neighborhood risk and an accountable response chain.

What it does

FloodLens provides an interactive Jakarta flood-risk command center. A user can select a neighborhood and adjust four scenario inputs:

• Rainfall over the previous 24 hours
• Sewer water level
• Drainage flow
• Estimated drainage blockage

The system combines these signals into a neighborhood risk score from 0 to 100. It calculates confidence from signal agreement, assigns a yellow, orange, or red protocol, estimates the available action window, and identifies the strongest risk drivers.

FloodLens then recommends an ordered response chain:

1. Warn residents
2. Clear constrained drainage
3. Prepare evacuation
4. Trigger physical infrastructure only after human approval

The demo also includes a clickable Jakarta digital twin, water-level visualizations, danger thresholds, edge-node status, and a complete sensor-to-action architecture.

How I built it

I built FloodLens as a responsive Next.js and React application and deployed it on Vercel.

The current public inference engine is a deterministic and interpretable sensor-fusion model. Each normalized signal contributes to risk through a transparent weighting system. Drainage flow is treated inversely because lower flow during heavy rain and high water can indicate drainage stress. Confidence increases when independent signals agree and decreases when they conflict.

I designed the architecture around four stages:

1. Sense: Ultrasonic and analog nodes measure local water conditions.
2. Filter: Smoothing and anomaly checks reduce noisy readings.
3. Infer: Sensor fusion estimates risk, confidence, and primary drivers.
4. Act: Explicit protocols convert the result into alerts and human-approved interventions.

The prototype intentionally separates inference from action. It exposes uncertainty and does not automatically activate consequential infrastructure based on a single reading.

AI usage

FloodLens demonstrates an explainable expert decision system. It combines environmental signals, evaluates their agreement, identifies dominant risk drivers, estimates confidence, and selects an appropriate response state.

The current public prototype uses deterministic logic instead of claiming to have a trained predictive model without sufficient field data. Standard code handles the interface, charts, score presentation, and fixed response workflow. The intelligent decision layer handles multi-signal interpretation, confidence estimation, driver attribution, and protocol selection.

A future version will replace the calibrated fusion weights with a supervised temporal model trained on labeled local flood events while preserving the same explanation and safety interface. Until enough verified field data exists, the deterministic model is the more accountable choice for this disaster-response prototype.

FloodLens does not claim to replace BMKG, BPBD, or field measurements. Real-world deployment will require calibrated sensors, labeled events, local validation, and agency oversight.

Challenges I ran into

The hardest problem was not producing another flood map. It was designing a system that could explain why a neighborhood was at risk and what should happen next.

Environmental signals can conflict. Rainfall may be intense while a drain is still flowing, or a high water reading may be a temporary sensor spike. A single opaque score would not be responsible enough for a high-stakes context.

I addressed this by keeping the inference trace visible. FloodLens shows confidence, signal-level drivers, thresholds, and the ordered response protocol.

Another challenge was connecting a polished citywide interface to realistic low-cost sensing. The system architecture therefore begins with the same types of ultrasonic and analog hardware that I explored in earlier prototypes.

Accomplishments that I am proud of

• I built and publicly deployed a complete interactive prototype.
• I turned four environmental and infrastructure signals into one explainable decision state.
• I made uncertainty and driver attribution visible instead of presenting a black-box prediction.
• I connected flood-risk prediction to an actionable, human-in-the-loop response chain.
• I extended the project through three stages: an award-winning concept, a physical embedded prototype, and a public decision platform.
• I designed the system so that a future learned model can replace the fusion layer without changing the safety and explanation workflow.

What I learned

I learned that early warning is valuable only when it creates earlier action. A technically accurate risk score can still fail if residents do not understand it or responders do not know what to do.

I also learned that explainability is not just a presentation feature in climate resilience. It is part of system safety. When data is incomplete, the interface should expose uncertainty instead of hiding it.

Finally, hardware, modeling, and user experience cannot be designed independently. Sensor placement affects model reliability, model outputs affect response protocols, and those protocols determine what information the interface must communicate.

What's next for FloodLens

My next steps are to:

1. Deploy calibrated, low-cost sensor nodes in selected Jakarta drainage locations.
2. Collect timestamped water-level, flow, rainfall, blockage, and verified flood-event labels.
3. Train and compare temporal models against the deterministic baseline.
4. Add anomaly detection for sensor drift, obstruction, and disconnected nodes.
5. Validate alert thresholds with residents and emergency-management stakeholders.
6. Add Bahasa Indonesia alerts, accessible evacuation routing, and offline-first delivery.
7. Run a limited pilot with explicit human approval for every operational intervention.

Built With

• ai
• civic
• climate
• disaster
• environmental
• explainable
• iot
• monitoring
• next.js
• resilience
• tech