Smart Disaster Resource Management System

Dashboard
About
Registration Page
Map
AI- Chat bot

Inspiration

Every major disaster — floods, fires, earthquakes — plays out the same broken way on the ground: victims don't know where help is, responders don't know where victims are, and relief resources (food, water, medical kits) get stuck in the wrong place while another area runs out. We wanted to close that information gap in real time, so we built a single platform where affected people, volunteers, and disaster-response admins all see the same live picture.

What it does

Smart Disaster Resource Management System is a full-stack emergency coordination dashboard with two sides:

For the public / victims:

Submit an emergency request in plain language through a chatbot-style form. It's auto-classified by disaster type, priority, and needed resources (using Google's Gemini API, with a rule-based fallback if the AI is unavailable) and dispatched instantly.
View a live map (Leaflet/OpenStreetMap) showing nearby relief centers, hospitals, police stations, and responders, with routing to the nearest one.
Track available relief resources (food, water, medical supplies) with real-time available/distributed/remaining counts and estimated delivery times.
Get real-time notifications and alerts.

For admins / responders:

A dashboard to manage and update the status of incoming emergency requests (waiting → in progress → resolved).
Add, edit, and track relief resources and their distribution history.
Assign and manage volunteers by task and area.
See live locations of users and responders on the map via Socket.IO, for faster coordination.

Both sides run on role-based JWT authentication (separate User and Admin accounts).

How we built it

Frontend: React 19 + Vite, styled with Tailwind CSS and animated with Framer Motion. React Leaflet + Leaflet Routing Machine power the live map and navigation; Socket.IO-client keeps location and alert data updating in real time; React Router handles the multi-page app (Home, Map, Resources, Chatbot, Admin, Profile, Notifications, Login/Register).
Backend: Flask REST API with Flask-SQLAlchemy models for users, admins, emergency requests, resources, volunteers, notifications, relief centers, hospitals, and police stations. Flask-SocketIO broadcasts live location updates. Flask-JWT-Extended and bcrypt handle secure authentication for both user and admin roles.
Database: MySQL in production, with an automatic SQLite fallback for local demos when MySQL isn't available.
AI layer: The /chatbot endpoint calls the Gemini API to classify free-text emergency messages into structured data (disaster type, priority, people affected, need, safety tips) that immediately becomes an emergency request — with a keyword-based fallback classifier so the system still works without an API key.

Challenges we ran into

Keeping the map, resource counts, and admin dashboard in sync in real time without hammering the backend — solved with Socket.IO for location/alert events instead of polling.
Making the AI classification robust: Gemini doesn't always return clean JSON, so we built a normalization layer that parses and validates its output and gracefully falls back to a rule-based classifier if the API call fails or returns something unexpected.
Designing a data model flexible enough to cover very different entities (users, resources, volunteers, relief centers, hospitals, police stations) under one consistent admin workflow.
Getting an accurate, low-latency location pipeline working across many simultaneous connections during simulated "disaster" testing.

Accomplishments that we're proud of

A working end-to-end pipeline: a person types "I'm trapped, water is rising" and within seconds it becomes a prioritized, geolocated emergency request visible to admins.
Real-time, two-way location sharing between the public map and the admin dashboard.
A resilient AI integration that degrades gracefully instead of breaking when the AI provider is unreachable.
A genuinely usable admin console for managing resources and volunteers, not just a data viewer.

What we learned

How to design real-time systems (Socket.IO + REST) that stay consistent under concurrent updates.
Practical prompt design for getting structured, reliable JSON out of an LLM, and why a fallback path is essential for anything safety-critical.
The importance of role-based access control and clean data modeling when a system serves very different user types (victims, volunteers, admins) with the same backend.

What's next for Smart Disaster Resource Management System

True offline request submission (not just alerts) — FEMA's SMS system only helps people locate shelters by texting a ZIP code; it doesn't let someone submit an actual help request. We want SMS/USSD-based emergency requests that get AI-triaged the same way as the app, so people without data access can still be found and prioritized — something none of the citizen-facing tools currently do.
Peer-to-peer auto-dispatch — most platforms (WebEOC, Everbridge, Noggin) rely on a human dispatcher manually assigning responders. We want to auto-match each incoming request to the nearest available volunteer or resource in real time, closing the loop without a person in the middle.
Crowd-verified reporting — enterprise tools assume requests are trustworthy because they come through an official agency. An open citizen-facing system needs a lightweight trust layer: nearby users can confirm ("this is real, I see it too") or flag a report, cutting down false/duplicate requests without needing paid verification staff.
Predictive resource pre-positioning — combine live citizen-reported request density with weather/historical disaster data to suggest where to move relief supplies before a shortage hits, rather than the after-the-fact tracking that tools like OpenGov offer.
Public donation/resource transparency ledger — most fund-tracking tools (OpenGov, ArcGIS) are internal, agency-only dashboards. We want a public view where donors and affected communities can see exactly where resources went, in real time — building the kind of trust closed enterprise systems don't offer.
Multi-language, voice-enabled AI intake — enterprise platforms are typically built around a single agency's working language. Letting people speak or type their emergency in their own language, with the chatbot handling classification, removes a real barrier during high-stress, high-diversity disaster zones.
Open API for small NGOs and community orgs — unlike closed enterprise ecosystems (Everbridge, Coram), we want any local relief group to be able to plug into the live request/resource feed with a simple API key, instead of being locked into one organization's paid platform.