Methodology

How the dataset is assembled

The site follows the stack in the brief: a Go single binary, SQLite, and server-rendered HTML. The ingest command downloads the phase 1 datasets directly, aggregates the phase 2 tables, and materializes summary tables so the live app can stay simple.

County key normalization

FEMA’s declaration and public assistance data carry county FIPS codes. Several individual-assistance tables do not, so the ingest step normalizes county names against a Census county directory and stores a stable 5-digit county key for downstream joins.

Summary tables

County pages run against materialized rollups such as county_summary, county_disaster_profiles, county_incident_type_totals, and county_decade_totals. That keeps request-time SQL predictable and page rendering fast.

Phase 2 aggregates

The validated IHP registrations table and the NFIP claims/policies tables are too large to store raw for this project. The CLI walks them in batches and stores county-by-disaster or county-by-year aggregates instead.

Cross-linking to FloodZoneMap.org

Every county page links to the matching county on FloodZoneMap.org. Disaster history and flood-zone context are complementary, not duplicates, so the sites can pass intent back and forth cleanly.

Core source datasets

PhaseDatasetUse on site
1DisasterDeclarationsSummariesCounty disaster timeline and declarations spine
1PublicAssistanceFundedProjectsDetailsCounty public assistance spending by category
1HousingAssistanceOwners / RentersDamage severity and approved amounts
1RegistrationIntakeIndividualsHouseholdProgramsRegistration totals and IHP / HA / ONA amounts
2IndividualsAndHouseholdsProgramValidRegistrationsValidated county registrations and damage totals
2FimaNfipClaims / FimaNfipPoliciesFlood insurance claims, payouts, and policy context