RapidDisaster

RapidDisaster

Inspiration After hurricanes and earthquakes, responders collect thousands of drone photos but have very little time to look at them. The slow part is not taking the pictures, it’s working out which buildings need attention first. We wanted a tool that does a fast first pass so human reviewers start with the worst-looking damage. What it does RapidDisaster takes post-disaster photos or drone video and uses AI to find buildings and label each as No Damage, Minor, Major or Destroyed. It then: • shows the original and annotated images side by side, • places the findings on a color-coded map when the photos have GPS data, • exports a CSV/GeoJSON list ranked worst-first, ready for GIS tools. It prioritizes what to review. It does not decide who gets help. How we built it • App: a Python/Streamlit web app with three tabs: Assess, Map and Export. It uses Folium for maps and OpenCV to pull frames out of video. • Model: a small YOLO11 object detector, trained on the public RescueNet dataset (4,494 drone photos from Hurricane Michael). • Data pipeline: we wrote a converter that turns RescueNet’s pixel-level masks into bounding boxes for the four damage classes. • Training: done on a Mac’s GPU. Everything runs locally, so sensitive imagery never leaves the machine. • Demo mode: a synthetic mode lets anyone try the full workflow without a model. Challenges we ran into • No ready-made model: no damage-trained model was available, and generic YOLO models can’t judge damage. We had to find a dataset and train our own. • Masks to boxes: RescueNet labels every pixel, not buildings. Touching buildings of the same class merge into a single box, so counts are approximate. • Location: a photo’s GPS is the camera’s position, not the building’s. We label locations clearly instead of pretending they are precise. • Honesty: we made sure demo output, unverified model output and real findings are never confused, since people may act on the results. • Training on a laptop: a full run takes hours, so we validated the whole pipeline on a tiny run first. Accomplishments that we’re proud of • A working end-to-end pipeline, from raw public data to a trained model to a running app. • In early testing, a partly trained checkpoint (about 8 of 50 epochs) scored around 0.6 mAP50 on validation images (a 0-to-1 box-accuracy score). It also correctly flagged a destroyed building on a held-out test photo. • Tests for the core logic, and every export keeps its model, location source and review status. What we learned • Data preparation took more effort than the model itself. • In disaster response, being clear about what an AI cannot tell you matters as much as accuracy. • Location metadata is not the same as building location. • Starting with a small, fast test run saves hours of debugging. What’s next for RapidDisaster • Finish training, then measure accuracy on the held-out test set. • Train on more disasters, such as earthquakes and floods, and on satellite imagery, so it works beyond one hurricane. • Compare before and after images to separate new damage from older damage. • Avoid counting the same building twice across overlapping photos. • Let reviewers confirm or correct labels in the app, and use those corrections to improve the model. • Add login and access controls before using real incident data. • Check the licensing: the training data’s authors have conflicting license statements, and one says non-commercial.