Use NOAA Storm Events episode ID to group the larger storm system and event ID to identify each reported flood, flash-flood, or related event. Preserve event type, county/zone, beginning and ending times, location points, source, narrative, injuries, deaths, and broad damage estimates; the database is not a complete property-loss inventory.
Last checked: August 7, 2026.
One episode can contain many event types and many event rows. Flooding tied to a tropical cyclone may appear under Flood, Flash Flood, Storm Surge/Tide, or other event categories rather than only under the named cyclone. Reporting practices and periods of record vary over time, and NOAA describes property and crop damage as broad estimates not adjusted for inflation.
Define the row before joining and totaling
NOAA's Storm Events Database separates episodes, events, and event locations. An episode can contain several county or zone events, while location rows can describe individual points or paths. The event narrative, begin and end times, type, geography, source, injuries, deaths, and property or crop damage estimates have different meanings. Counting every joined row as a separate flood can multiply one reported event.
Before calculating, define the grain. A county-event count might deduplicate by event ID after filtering the event type and period, while a location analysis may intentionally retain several location rows per event. Damage fields can contain broad estimates and encoded magnitudes; the export format and FAQ should control parsing. A total should disclose whether unknown values were excluded, treated as zero, or retained separately.
Reporting practices and event definitions change over time and by hazard. A blank narrative is not proof that nothing happened, and the absence of a database row is not proof that a property never flooded. The data support documented-event research at the published scale. They do not replace local incident reports, insurance records, a parcel history search, or an engineering reconstruction of water depth.
NOAA's export format separates episodes, events, and locations
NOAA Storm Events Database supplies official event search, period of record, event types, narratives, injuries, deaths, and damage estimates; this guide cites it for episode_id / event_id/event_type / begin/end and time zone / county/zone and locations / damage/injuries/deaths / event narrative/source. NOAA Storm Events FAQ supplies episode/event distinctions, reporting changes, and broad-estimate limitations for damage fields; this guide cites it for episode_id / event_id/event_type / damage/injuries/deaths. NOAA Storm Data export format supplies episode, event, location, date, narrative, and damage column definitions; this guide cites it for episode_id / event_id/event_type / begin/end and time zone / county/zone and locations / damage/injuries/deaths / event narrative/source.
The NOAA Storm Events flood data crosswalk keeps these assignments explicit: NOAA Storm Events Database → episode_id / event_id/event_type / begin/end and time zone / county/zone and locations / damage/injuries/deaths / event narrative/source; NOAA Storm Events FAQ → episode_id / event_id/event_type / damage/injuries/deaths; NOAA Storm Data export format → episode_id / event_id/event_type / begin/end and time zone / county/zone and locations / damage/injuries/deaths / event narrative/source. If episode_id or another named field is absent from its cited record, leave that fact unresolved and obtain it from the responsible official source instead of expanding a different citation beyond scope.
| Official record | What it actually supplies | Field used here |
|---|---|---|
| NOAA Storm Events Database | official event search, period of record, event types, narratives, injuries, deaths, and damage estimates | episode_id / event_id/event_type / begin/end and time zone / county/zone and locations / damage/injuries/deaths / event narrative/source |
| NOAA Storm Events FAQ | episode/event distinctions, reporting changes, and broad-estimate limitations for damage fields | episode_id / event_id/event_type / damage/injuries/deaths |
| NOAA Storm Data export format | episode, event, location, date, narrative, and damage column definitions | episode_id / event_id/event_type / begin/end and time zone / county/zone and locations / damage/injuries/deaths / event narrative/source |
Do not extend a citation beyond its mapped fields. Evidence for episode_id cannot automatically establish event narrative/source; keep either unanswered item visible before taking the action to deduplicate and cite event records with their narrative and uncertainty.
How episode_id connects to event narrative/source
| Field | Meaning in this check | Error it exposes | Response |
|---|---|---|---|
| episode_id | Groups events in a storm system | Not one hazard or location | Use for context/grouping |
| event_id/event_type | Identifies the reported event and hazard | Different rows may share episode | Keep unique ID/type |
| begin/end and time zone | Temporal extent | Publication/update dates differ | Preserve exact timestamps |
| county/zone and locations | Reported spatial context | Not a property footprint | Keep geometry precision caveat |
| damage/injuries/deaths | Reported impacts | Damage is a broad estimate | Do not treat as audited loss |
| event narrative/source | Evidence and description | Completeness varies | Quote sparingly and cite row |
episode_id is the starting identifier, but it is usable only when event_id/event_type and begin/end and time zone agree. Two conflicts can break that agreement: “Not one hazard or location” and “Publication/update dates differ”. A polished screenshot cannot repair either one.
For interpretation, event_id/event_type answers “Identifies the reported event and hazard”, while damage/injuries/deaths answers “Reported impacts”. They are not interchangeable. A failure in the first calls for “Keep unique ID/type”; a failure in the second calls for “Do not treat as audited loss”.
The final safeguard is event narrative/source, which answers “Evidence and description”. Its warning condition is “Completeness varies”. At that point in the NOAA Storm Events flood data check, document the limited result or take the unresolved issue to the official decision owner.
Preserve IDs, period, geography, type, and parsing rules
The order matters most around begin/end and time zone. First, “Read the narrative and source rather than filtering on the title alone”. Next, “Group related events by episode while retaining individual event rows”. Reversing those actions can attach a sound interpretation to the wrong date, place, product, or case for begin/end and time zone.
- Define the geography, date range, and flood-related event types before searching.
- Export or record episode ID, event ID, event type, dates, county/zone, and locations.
- Read the narrative and source rather than filtering on the title alone.
- Group related events by episode while retaining individual event rows.
- Treat property/crop damage as broad nominal estimates and document missing values.
- Compare with USGS high-water marks, gauges, declarations, or local reports only as separate evidence sets.
- Save the database period, retrieval date, query, and known reporting changes with the output.
End with “Save the database period, retrieval date, query, and known reporting changes with the output”. That preserves event narrative/source beside the source and date instead of leaving a detached number, color, category, or status that another reader could overinterpret.
One episode that becomes several joined rows
To build a chronology, filter the state, county or zone, date range, and relevant event types. Group events by episode but retain each event ID and narrative. Two rows in one episode are not duplicates when they document different hazards or locations; conversely, summing every segment without reading the episode can double-count one story.
In this example, episode_id identifies the relevant record, while begin/end and time zone is the fact most likely to change the interpretation. Conclude “Reported event evidence” only when the evidence shows “IDs, dates, type, location, narrative”.
For NOAA Storm Events flood data, if the facts instead fit “Property history”, the result changes to “Unsupported use”. Respond by following “Use local and property records”. Do not substitute the more favorable conclusion from the earlier example.
Event match, duplicate locations, blank damage, and reporting change
| Observed state | Evidence test | Limited conclusion | Next response |
|---|---|---|---|
| Event chronology | IDs, dates, type, location, narrative | Reported event evidence | Cite each row |
| Episode summary | Several related event IDs | Storm-system context | Avoid double counting |
| Damage trend | Broad nominal estimates | Methods/reporting vary | Disclose and avoid false precision |
| Property history | No parcel-complete loss inventory | Unsupported use | Use local and property records |
The first decision turns on “IDs, dates, type, location, narrative”, while the next turns on “Several related event IDs”. Those tests lead to different conclusions—“Reported event evidence” and “Storm-system context”—so they should remain separate in the saved record.
“Damage trend” calls for “Disclose and avoid false precision”, but “Property history” calls for “Use local and property records”. Reporting the Damage trend and Property history differences is more accurate than forcing both conditions into one generalized warning.
Duplicate joins, blank damage, and changing reporting practice
- Avoid counting episodes as events. Recheck episode_id. The mapped warning is “Not one hazard or location”; the corresponding response is “Use for context/grouping”.
- Avoid double-counting segments. Recheck event_id/event_type. The mapped warning is “Different rows may share episode”; the corresponding response is “Keep unique ID/type”.
- Avoid treating damage as audited. Recheck damage/injuries/deaths. The mapped warning is “Damage is a broad estimate”; the corresponding response is “Do not treat as audited loss”.
- Avoid calling the database a parcel loss history. Recheck county/zone and locations. The mapped warning is “Not a property footprint”; the corresponding response is “Keep geometry precision caveat”.
Two field-specific corrections are required. For “counting episodes as events”, follow “Use for context/grouping”. For “double-counting segments”, follow “Keep unique ID/type”. Keeping episode_id separate from event_id/event_type prevents one repaired field from hiding the other error.
“treating damage as audited” can trigger Damage is a broad estimate; correct the mapped damage/injuries/deaths field or fields by following “Do not treat as audited loss”. “calling the database a parcel loss history” affects county/zone and locations, so use “Keep geometry precision caveat” before relying on the result.
What this storm episode-to-event record hierarchy cannot decide
Scope: United States public historical flood datasets. Limitation: Storm Events is based on reports and estimates and is not a complete property-level loss inventory.
The value of the storm episode-to-event record hierarchy is traceability: it places episode_id, begin/end and time zone, and event narrative/source beside their sources. Authority to decide the underlying episode_id remains with the organization named in the official record.
Link the cleaned event set to separate property evidence
- Consult OpenFEMA NFIP Claims Data By County after episode_id has been matched to the correct subject and date.
- Consult OpenFEMA Disaster Declarations Flood Filter for the distinct issue revealed by begin/end and time zone.
- Consult USGS Flood Event Viewer High Water Marks when event narrative/source changes the next official step beyond the action to deduplicate and cite event records with their narrative and uncertainty.
Use this guide to deduplicate and cite event records with their narrative and uncertainty. The linked guides address separate questions raised by episode_id, begin/end and time zone, or event narrative/source.
Before counting NOAA Storm Events rows
Does episode_id settle the question by itself?
No. episode_id answers “Groups events in a storm system”, but it can fail when “Not one hazard or location”. Pair it with event_id/event_type, begin/end and time zone, and the checked date.
What if the evidence shows Property history?
Confirm the stated evidence test: “No parcel-complete loss inventory”. The limited conclusion is “Unsupported use”. The documented response is “Use local and property records”; a more favorable branch should not be substituted.
When should event narrative/source be checked again?
Repeat the export when NOAA corrects an event narrative, adds a location row, changes a damage estimate, or refreshes the database. Preserve episode_id and event_id in the old and new extracts so a reporting revision is not mistaken for an additional flood.
NOAA Storm Events Flood Records: Episode, Event, Location, and Damage Fields is independent public-record guidance for the limited action to deduplicate and cite event records with their narrative and uncertainty. The cited government records retain authority over episode_id and event narrative/source. Last checked: August 7, 2026.