EM-DAT Schema Mapping

EM-DAT is the Emergency Events Database maintained by the Centre for Research on the Epidemiology of Disasters (CRED) at the Universite catholique de Louvain in Brussels. It has tracked global disasters since 1988, with records going back to 1900. The database contains over 26,000 mass disaster events and is cited by the WHO, UNDRR (United Nations Office for Disaster Risk Reduction), World Bank, IPCC, and thousands of academic papers.

An event enters EM-DAT if it meets at least one threshold: 10 or more people killed, 100 or more people affected, a declaration of a state of emergency, or a call for international assistance.

Key difference: EM-DAT operates at the disasterlevel. One EM-DAT record represents an entire event like "2020 Black Summer Bushfires, Australia." EmergencyAPI operates at the incident level. That same event corresponds to thousands of individual incidents reported by state fire services over several months.

EM-DAT has no public API. Data is available via batch download at emdat.be after registration.

The archive_records table has a three-tier structure. The first 18 columns are the standard EmergencyAPI incident schema (shared with the live API). Seven provenance columns track data lineage. Eight EM-DAT columns align with international disaster data standards.

Tier 1: EmergencyAPI Core (18 columns)

Tier 2: Provenance Fields (7 columns)

Tier 3: EM-DAT International Fields (8 columns)

These fields are documented in detail in the next section.

Each EM-DAT field below shows its EmergencyAPI column name, data type, the corresponding EM-DAT field, and how much of the archive is actually populated. Population percentages are approximate and vary by data source.

Not all fields are fully populated. Impact fields (deaths, affected, economic) are sparse because most incidents are routine operational events that do not meet EM-DAT's inclusion threshold (10 dead, 100 affected, state of emergency, or international appeal). This is by design: EmergencyAPI captures every incident reported by Australian emergency services, not just major disasters.

EmergencyAPI uses operational event types from Australian emergency services. EM-DAT uses a hierarchical classification (Group, Subgroup, Type, Subtype). This table maps between the two systems and includes the GLIDE type code used by the UN for cross-database linkage.

Many EmergencyAPI event types (rescue, medical, structure fire, burn-off) fall below EM-DAT's inclusion threshold and have no direct equivalent. This is a feature: EmergencyAPI captures operational-level events that EM-DAT deliberately excludes, giving researchers access to the full spectrum of emergency service activity.

GLIDE (GLobal unique disaster IDEntifier) is managed by the Asian Disaster Reduction Center (ADRC) in collaboration with CRED, UNDP, IFRC, and OCHA. It is the primary mechanism for linking the same disaster across different international databases.

Format: TYPE-YEAR-SERIAL-ISO
Example: WF-2020-000012-AUS (a 2020 wildfire in Australia)

Type codes include WF (wildfire), FL (flood), EQ (earthquake), TC (tropical cyclone), ST (storm), TS (tsunami), DR (drought), VO (volcano), HT (heat wave), and LS (landslide). ADRC typically issues GLIDE numbers within 24 to 48 hours of a significant event.

Status in EmergencyAPI: The glide_number column exists in archive_records but is currently unpopulated (0%). This field is reserved for future enhancement. Plans include retroactive population for major historical events and potential automated assignment via event fingerprinting against the GLIDE database.

If your research requires GLIDE cross-referencing today, use the temporal + geographic + event type join approach described in the next section.

The granularity difference between EM-DAT and EmergencyAPI is the key to understanding how they complement each other. One EM-DAT record for "2020 Black Summer Bushfires, Australia" corresponds to thousands of individual EmergencyAPI incidents across multiple states and months.

Recommended join approach:

1. Match by temporal window + state + event type. Map EmergencyAPI source_state to ISO 3166-2 codes (nsw = AU-NSW, vic = AU-VIC, etc.). Match event_type to EM-DAT Disaster Type using the crosswalk table above. Filter by event_start_date or reported_at falling within the EM-DAT event window.
2. Aggregate EmergencyAPI incidents to disaster level. Group matched incidents and calculate: total incident count, geographic spread (unique LGAs, bounding box), temporal profile (first report to last), and peak activity date.
3. Enrich the EM-DAT record. The result: EM-DAT provides the impact summary (deaths, affected, economic loss). EmergencyAPI provides the operational detail (how many incidents, which agencies responded, where the activity was concentrated, how the event evolved over time).

EM-DAT tells you what happened and how bad it was. EmergencyAPI tells you what it looked like operationally, in real time, at incident level. The combination is more valuable than either dataset alone.

EM-DAT is not the only international disaster database. These related systems use overlapping schemas and can be cross-referenced with EmergencyAPI data.

The GLIDE number is the primary linkage mechanism between these databases. EM-DAT, GDACS, ReliefWeb, DesInventar, and IFRC GO all reference GLIDE numbers, though coverage is inconsistent across systems.

The Sendai Framework for Disaster Risk Reduction 2015-2030 defines seven global targets that countries report on through the Sendai Framework Monitor. EmergencyAPI's schema covers the raw data requirements for three of those targets at incident level.

This alignment matters for government customers who need to report on Sendai indicators, and for researchers studying disaster risk reduction outcomes. EmergencyAPI provides the incident-level data that gets aggregated into national Sendai reports. Combined with source_state and event_type, this data supports sub-national analysis that the Sendai Framework requires but country-level databases like EM-DAT cannot provide.

Researchers should understand what is reliable, what is sparse, and what is absent before building analyses on this data.

Important: Live poller data (collected since April 2026) has NULL for all EM-DAT fields. Historical imports have varying coverage depending on the source dataset. Always check field nullability before analysis. Use WHERE is_historical = TRUE to limit queries to historical imports with populated EM-DAT fields.

Data completeness will improve over time as additional historical datasets are imported and as major events are retroactively enriched with impact data.