Inspiration
A property manager responsible for several sites may need to decide where preparation deserves attention first during heavy rain. Rainfall readings and official flood alerts provide valuable information. We wanted to connect that information to the areas around a manager’s properties, helping them prioritise checks and preparation using their existing response plans.
What it does
Proposed flood-preparation tool that would present a short priority list for monitored areas. Each entry would show a Low, Medium or High risk band, the rainfall evidence behind it, the latest official PUB information, and the age of the data. Missing or stale information would produce an unknown state. The initial prediction target is a new recorded flood report within the next 30 minutes. The tool would support preparation decisions alongside official guidance.
How we built it
I am are currently at the research and planning stage. Reviewed 18 public dataset candidates, inspected sample rainfall and flood records, and checked the contents of the available water-sensor dataset. These findings shaped the proposed Databricks architecture: Lakeflow Jobs for ingestion, Delta tables and SQL for data checks and joins, MLflow for comparing a simple rainfall rule with a small classifier, and an AI/BI dashboard for presenting priorities. The planned prototype would begin with three monitored corridors. I will evaluate it on later, separate storms to check whether it provides useful information beyond the rainfall baseline.
Challenges we ran into
Reliable historical flood labels were the biggest challenge. One flood API sample returned empty readings during a period when PUB had publicly reported a flood. We therefore could not treat an empty response as evidence that no flooding occurred. We also discovered that the public water-sensor file contains sensor locations, rather than water-level measurements. Timing created another difficulty: a report’s publication time does not establish the exact moment flooding began. Our prediction target and evaluation need to preserve that distinction.
Accomplishments that we're proud of
We turned a broad dashboard idea into a focused proposal with a clear user, decision and evaluation plan. We also identified important data limitations early, developed a source-backed dataset shortlist, and remade the pitch into three concise slides. This gives us a concrete starting point for the build sprint.
What we learned
We learned to inspect what a dataset actually contains before designing around it. Public availability alone does not make data suitable for training. We also learned that model performance and user value need separate evaluation. FloodSense must provide useful signals while helping managers prioritise preparation with a manageable alert burden.
What's next for pickle
Our next steps are to interview property managers, curate a verified flood-event history, and confirm its overlap with rainfall records. We will then build the small Databricks prototype, compare its predictions with the rainfall baseline, and test whether the priority view helps users make correct decisions more quickly. If the event history cannot support a reliable classifier, we will present a clearly labelled rainfall indicator and keep prediction validation open.
Log in or sign up for Devpost to join the conversation.