OpenSoS

Why I built it

I am interested in how open-source software could help communities organize useful public-interest information while keeping trust, privacy, and accessibility central.

What exists today

What exists today: public disaster-feed aggregation, an interactive map, clustering, search and filters, provider status, responsive incident details, automated frontend and backend tests, and optional grounded incident briefs. Community reporting and verification remain planned.

What I wanted to learn

• Normalize several public-data providers behind one API.
• Design a useful map while preserving provenance and provider freshness.
• Keep implemented public-data aggregation separate from planned community reporting.

How it works

1. Normalize USGS, NASA EONET, and GDACS records behind a FastAPI service.
2. Render searchable, filterable incidents with React and MapLibre GL JS.
3. Preserve source links, provider health, and last-known-good data when an upstream provider fails.

Technical structure

Implemented today: a React, TypeScript, Vite, and MapLibre frontend; a FastAPI backend with isolated USGS, NASA EONET, and GDACS adapters; provider-specific synchronization, in-memory caching, filters, tests, and optional manually requested incident briefs. Community submissions and verification are not implemented.

Testing

• Backend pytest files cover APIs, providers, services, and optional incident intelligence using fixtures or mocked HTTP. Frontend tests cover the application and incident visuals. Automated provider tests do not call the official services.

Technical decisions

• Keep the first milestone read-only and use an in-memory repository instead of adding a database before durable reports exist.
• Preserve source provenance and show provider freshness rather than blending feeds into an unexplained result.
• Make optional incident briefs fail independently so the public-data map remains usable without AI configuration.

Challenges

Combine public hazard feeds without hiding their different meanings, update schedules, or failure modes—and without presenting the project as an emergency authority.

What I learned

The project is teaching me how to normalize inconsistent public data, expose uncertainty and provenance in the interface, and keep an ambitious civic-tech roadmap grounded in what works today.

Planned direction

Design the first community-reporting workflow and trust model before adding submissions, verification, durable history, or public write APIs.