G-One: Flood Awareness & Emergency Response

Inspiration

A flood warning should lead to a clear next step. People need to understand the danger around them, explore routes toward safety, and request help when they cannot evacuate. Responders need accurate locations and useful context before entering an unfamiliar situation.

Inspired by flood risk in Nepal, we built G-One to connect citizens and emergency coordinators through two dashboards. Our goal is to help people make informed decisions and give helpers a clearer picture before they act.

What it does

The citizen dashboard combines location-based weather and river forecast context, maps, voice and text guidance, hazard reporting, and emergency help.

Citizens can explore nearby facilities and screen road routes against reported hazards. They can report a blocked or flooded road using their location, a selected hazard type, and an optional photo. Reports are saved to the shared backend, appear on the map, and inform route screening. Photos support the report; the prototype does not automatically classify danger from images.

If someone needs assistance, they can submit an SOS with their location, request type, group size, and notes. The admin dashboard receives an in-app alert and displays the request in a shared queue.

Coordinators can acknowledge requests, assign responders, mark them en route, and resolve incidents. Citizens see these status updates on their tracking screen. Admins can also review maps, reported hazards, sourced emergency contacts, operational reports, and CSV exports.

For the Work & Productivity track, G-One connects requests, context, assignments, and outcomes in one traceable workflow, helping reduce manual handoffs between separate tools.

How we built it

We built the frontend with React, TypeScript, and Vite, with separate citizen and admin views. A Python FastAPI backend handles authentication, validation, emergencies, hazards, routing, dispatch assistance, and reporting. PostgreSQL stores shared operational records.

JWT authentication controls access. Citizens access their own SOS records, while admins coordinate the shared incident queue. HTTP polling keeps the dashboards updated.

Open-Meteo supplies weather and modeled river-discharge forecasts. Leaflet displays maps, OpenStreetMap/Overpass supplies nearby facility information, ArcGIS supports place lookup, and OSRM supplies road routes.

Citizen voice interaction uses browser speech capabilities alongside the application's guidance engine. An optional OpenAI integration extracts supporting evidence from incident notes when configured.

We deployed the frontend and API together through Docker on Render, with a separate managed PostgreSQL database. Our README includes the system architecture and request flow.

Challenges we ran into

The main challenge was keeping locations, incident states, and ownership consistent across two dashboards. We worked through map-coordinate issues, conflicting navigation handlers, duplicate submissions, stale data, and differences between demonstration records and saved operational data.

We also needed to communicate uncertainty clearly. Forecasts are not verified street-level flood boundaries, mapped facilities are not confirmed open shelters, and route screening cannot guarantee safety.

Accomplishments that we're proud of

We deployed a working application and demonstrated the SOS workflow across separate citizen and admin sessions: submission, acknowledgment, assignment, en route, and resolution.

We implemented shared hazard persistence, route screening, operational reports, and support for three citizen and two admin demo identities. Automated checks cover important behaviors including access control, record ownership, hazard handling, and reporting.

Most importantly, the citizen and responder interfaces share saved backend records, allowing actions in one dashboard to appear in the other.

What we learned

We learned that useful emergency software depends on clear ownership, consistent state changes, and understandable information. A map becomes more useful when people can understand the source, freshness, and limitations of what it displays.

We also learned to separate working functionality from future goals and to keep human review central to emergency coordination.

What's next for G-One

We plan to integrate verified local warnings and shelter information, complete automatic reroute and notification coordination, improve weak-network behavior, and expand account onboarding.

We also want to measure coordination time and test performance with more concurrent users. The current five-account checks demonstrate functional workflows, not capacity for hundreds of simultaneous users.

G-One is a working prototype. Broader operational use would require validated risk estimates, field testing, and partnerships with emergency organizations.

Built With

• docker
• fastapi
• leaflet.js
• open-meteo
• openstreetmap
• osrm
• postgresql
• python
• react
• render
• speech
• sqlalchemy
• typescript
• vite
• web