Skip to content
English
Solution Suite
  • There are no suggestions because the search field is empty.

(ERI) File specification - Earthquake Rapid Impact

ICEYE's Earthquake Rapid Impact product is provided to users in a series of "Releases". Each release is provided on the basis of data availability, where ICEYE strives to provide as much data, as quickly as possible after the event occurrence. The aim is to deliver the first release within 24 hours of earthquake detection. Each subsequent product release is typically provided 24 hours after the previous, with each subsequent release superseding the previous. ICEYE aims to provide full coverage of the event within three releases, though this is dependent on the characteristics of the event, including whether a post-earthquake fire was detected. The user should only consider the most recent release for a given event.

Each release contains the same set of files and each file follows the same naming conventions, which indicate the event ID, release, name and release number. Below is a description of each and their intended use. For a detailed breakdown of content in each file's structure and their contents, see the accompanying Earthquake Rapid Impact File Guide documentation.

Earthquake Building Damage Classification (.gpkg)

  • A vector file that assigns damage classification to individual building footprints (delivered as centroids), translating geospatial damage to building-level intelligence.
  • Each building centroid inherits summary statistics from the raster file underneath: total number of pixels belonging to the building, the number of those pixels exceeding a damage threshold, the maximum damage intensity, and a binary "damaged/not damaged" flag.
  • To determine whether a building is considered damaged or not, ICEYE considers both the magnitude of change detected within a building's footprint (maximum damage intensity) and the total area of the footprint that has been affected. The exact threshold used to determine damage is subject to regional variation, and is specified within the output file.
  • This layer allows users to rapidly assess structure-level damage, directly cross-referencing building IDs with exposure files.

Earthquakes provide a diverse range of damage throughout the affected region. This variability stems from a combination of shaking intensity, the diverse characteristics of the structures affected, and many other environmental factors. While ICEYE's Earthquake Rapid Impact strives to deliver consistency in its assessments regardless of these variables, it's important to acknowledge that performance may exhibit regional variations due to said factors.

GSI footprints are available in Japan. In the USA, building footprints are sourced from Precisely.

Vector Hexgrid Damage Heatmap (.gpkg)

  • An aggregate view (H3 level 8, ~500m) of the Building Damage Classification designed for higher level situational awareness of the storm event impact, providing users with a total count of damaged structures in each cell.
  • Users can employ this layer to visually identify the most impacted regions across the full extent of the event and quickly summarize locations of interest that may be affected.

Raster Damage Heatmap (.tif)

  • A granular view of damage (1.5m), with each cell assigned a change detection intensity.
  • This layer allows users to examine the signal underlying the building damage classification, and enables differentiation between large vs. small changes occurring at the pixel level.
  • In this layer, higher values correspond to greater changes observed between the pre- and post-image. These changes are scaled between 1-255, with higher numbers corresponding to greater change.

Release Notes (.gpkg)

  • Defining valid data area and respective times of capture.
  • Users should keep the Release Notes files available in their system to ensure their location of interest is within the release coverage. This can help from mistaking a location as "not damaged", when in fact, the location was not included in product coverage at all.
  • Further, pre- and post-image timings are included with each polygon. This enables the user to sanity check the relevance of a given detection. For example, in certain cases archive images of a few weeks old are used. If there is a suspected false positive or false negative, the timing of the imagery could help inform this determination.

Metadata (.json)

  • Machine readable file for organization and ingestion of releases.
  • If receiving files manually (not utilizing the ISS API), users can use this file to automate ingestion of files according to the event characteristics included (id, time, location, etc.). If a user is integrating with the API directly, the metadata file is not needed as all the information is available directly from the find-deliverables endpoint.