(HRI/CRI) Product Releases & Release Files

ICEYE's Hurricane Rapid Impact / Cyclone Rapid Intelligence 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 landfall. The aim is to deliver the first release within 24 hours of landfall. 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. 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 Hurricane Rapid Impact / Cyclone Rapid Intelligence File Guide documentation.

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.

US only:

• In addition, ICEYE provides an estimate of the severity of damage (low/medium/high), based on the fraction of a building footprint that experienced change.
• This layer allows users to rapidly assess structure-level damage, directly cross-referencing building IDs with exposure files (via building ID fields such as PreciselyID).

Australia only:

• This layer allows users to rapidly assess structure-level damage, directly cross-referencing building IDs with exposure files (via PID or G-NAF ID). Please note that Geoscape IDs are only available in Australia.

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 summarise 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

• 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.

Naming Convention

< ICEYE_WIND > < #### > < STORM TYPE > < STORM NAME > < DELIVERABLE TYPE > < R# > . < FILETYPE >

US example (Hurricane Otis):

• Building Damage Classification: ICEYE_WIND-0000_hurricane_otis_building_damage_R4.gpkg
• Raster Damage Heatmap: ICEYE_WIND-0000_hurricane_otis_damage_raster_R4.tif
• Vector Hexgrid Damage Heatmap: ICEYE_WIND-0000_hurricane_otis_damage_vector_hexgrid_R4.gpkg
• Release notes: ICEYE_WIND-0000_hurricane_otis_release_notes_R4.gpkg
• Metadata: ICEYE_WIND-0000_hurricane_otis_metadata_R4.json

Australia example (Tropical Cyclone Alfred):

• Building Classification Layer: ICEYE_WIND-2812_tropical_cyclone_alfred_building_damage_R4.gpkg
• Raster Damage Heatmap: ICEYE_WIND-2812_tropical_cyclone_alfred_damage_raster_R4.tif
• Vector Hexgrid Damage Heatmap: ICEYE_WIND-2812_tropical_cyclone_alfred_damage_vector_hexgrid_R4.gpkg
• Release notes: ICEYE_WIND-2812_tropical_cyclone_alfred_release_notes_R4.gpkg
• Metadata: ICEYE_WIND-2812_tropical_cyclone_alfred_metadata_R4.json