Monty Model

The Monty model is maintained in the GDBC repository and is used to generate the Monty model documentation. This JSON schema is the authoritative source for the Monty model and is used to build the STAC model.

eoAPI risk

The STAC extension aims to provide a way to include Montandon data in STAC items and collections. eoAPI risk is a flavor of eoAPI dedicated to risk data. The Monty model is transformed into a STAC model that is assimilable by the eoAPI data store.

Model Normalization

The first step in the process is to normalize the Monty model. This is done by converting the Monty model into a format that is easier to work with and compliant with the STAC specifications model. The normalized model must keep all the information from the Monty model and cover the applications intented that will use the eoAPI risk data.

Data Overview

The Monty model is based on Event data type that consititutes the core of the model. In STAC, they will be represented as an item. Then for each event, 3 kinds of data are collected:

• Hazard: The type of hazard, its location and the intensity
• Impact: All type of impact affecting the population, the infrastructure, the environment, etc in terms of number of people affected, financial loss, dmaage to infrastructure, etc.
• Response: Anticipatory measures and actions taken in response to the event

The original Monty model is a relational model with a lot of redundant taxonomy attributes in various forms (e.g. country code + name). In the STAC model, we try to use unambiguous and normalized attributes as much as possible but keeping the capacity to query the data with the original taxonomy. For example, the country code is used as a normalized attribute in a specific field but the country name is kept as a keyword for free text search.

The following classs diagram shows the relationships between the different classes in the Monty model and their high-level attributes.

---
title: Montandon STAC Model
---
classDiagram
    direction TD
    linkStyle default interpolate basis

    class Item["STAC Item"] {
        +id: string
        +title: string
        +geometry: GeoJson geometry
        +datetime: datetime
        +start_datetime: datetime
        +end_datetime: datetime
        +keywords: string[]
    }

    class Event {
        +country_codes: string[]
        +hazard_codes: string[]
    }

    MontyData <|-- Event

    class MontyData {
        +corr_id: string
        +collection: string
    }

    Item <|-- MontyData

    MontyData "0..*" --> "1" Event : is associated with

    class Hazard {
        +hazard_detail: HazardDetail[]
    }

    Hazard --|> MontyData

    class Impact {
        +impact_detail: ImpactDetail[]
    }

    Impact --|> MontyData
    Impact "0..*" --> "1..*" Hazard : is the effect of

    class Response {
        +response_detail: ResponseDetail
    }

    Response --|> MontyData
    Response "0..*" --> "0..*" Hazard : addresses
    Response "0..*" --> "0..*" Impact : informs

    class ResponseDetail {
        +type: string
        +source_id: string
        +status: string
        +producer: string
        +monitoring_number: integer
        +sendai_targets: string[]
    }

    ResponseDetail --* Response

    class HazardDetail {
        +severity_value: number
        +severity_unit: string
        +estimate_type: string
    }

    HazardDetail --* Hazard

    class HazardCode {
        +code: string
        +name: string
        +group: string
        +subgroup: string
        +type: string
        +subtype: string
    }

    Event "*" --> "*" HazardCode : has
    HazardDetail "*" --> "1" HazardCode : is defined by

    link HazardCode "./taxonomy#hazards" "See hazard codes in the taxonomy"

    class ac["&ZeroWidthSpace;"] ::: invisible
    Hazard "0..*" -- ac : is concurrent with
    Hazard "0..*" <-- ac

    ac .. Occurence
    class Occurence {
        +type: string
        +prob: string
        +probdef: string
    }

    class ImpactDetail {
        +category: string
        +value: number
        +type: string
        +unit: string
        +date: datetime
        +estimate_type: string
    }

    ImpactDetail --* Impact
    Impact "*" --> "*" HazardCode : has

Event

The event class is the core of the Monty model. It represents a disaster event that has occured or is forecasted to occur. The global crisis data bank records multiple instances of events that are related to a single event:

• One unique reference event that is used to "pair" all the instances of the event
• Multiple instances of the event that are recorded for different sources

The event class has the following attributes:

• id: A unique identifier for the event. Preferably, the identifier assigned by the issuer (source) of the event.
• The reference event uses a ? generated by the Monty system
• The source events use the identifier assigned by the source (issuer) of the event

Generated by the Monty system (currently this method). The event pairing page describes the algorithm used to generate the event id and the convention to follow. This identifier is used as the correlation id for all the sources events registered in the Monty system. - title: The name of the event assigned by the issuer (source) of the event. - geometry (GeoJSON geometry): The location of the event in the form of a GeoJSON geometry. It is recommanded to use a point geometry for the event so that it can be easily searched, displayed and clustered on a map. More geometries can be used for the hazard, impact and response data to represent the affected area. - datetime: The date and time when the event occurred. For forecasted events, it is the date and time when the event is forecasted to occur. - start_datetime: The date and time when the event started. For forecasted events, it is the date and time when the event is forecasted to start. OPTIONAL - end_datetime: The date and time when the event ended. For forecasted events, it is the date and time when the event is forecasted to end. OPTIONAL - country_codes: The country codes of the countries affected by the event. The country codes are based on the ISO 3166-1 alpha-3 standard. - hazard_codes: The hazard codes of the hazards affecting the event. The hazard codes are based on the 2025 UNDRR-ISC Hazard Information Profiles (reference classification system). For interoperability, codes from other classification systems are recommended to also be included. - correlation_id: The unique identifier assigned by the Monty system to the reference event. It is used to "pair" all the instances of the event.

Cross-item Link Typing

Event, hazard, and impact items may be connected with STAC links using rel="related". For these links, roles should contain exactly one target type value: event, hazard, or impact. This allows clients to resolve item relationships without custom fields.

Hazard

The hazard class represents a process, phenomenon or human activity that may cause loss of life, injury or other health impacts, property damage, social and economic disruption or environmental degradation. UNDRR - https://www.undrr.org/terminology/hazard. In the Monty model, a hazard is always linked to an event and as per event, every hazard is recorded from multiple sources. A hazard can be observed or forecasted and MUST contains details on its severity or magnitude.

The hazard class has the following attributes:

• id: A unique identifier for the hazard. Preferably, the identifier assigned by the issuer (source) of the hazard. If not available, an identifier can be generated and should be prefixed with the related event id.
• title: The name of the hazard assigned by the issuer (source) of the hazard.
• geometry (GeoJSON geometry): The location of the hazard in the form of a GeoJSON geometry.
• datetime: The date and time when the hazard occurrs or is forecasted to occur.
• start_datetime: The date and time when the hazard started or is forecasted to start. OPTIONAL
• end_datetime: The date and time when the hazard ended or is forecasted to end. OPTIONAL
• ref_event_id: The identifier of the reference event to which is associated the hazard.
• source_event_id: The identifier of the source event to which is associated the hazard. OPTIONAL
• source: Information about the organization and the database capturing, producing, processing, hosting or publishing this data.
• hazard_detail: A detailed description of the hazard including:
• severity_value: The estimated maximum hazard intensity/magnitude/severity value, as a number, without the units.
• severity_unit: The unit of the estimated maximum hazard intensity/magnitude/severity value.
• estimate_type: The type of data source that was used to create this hazard intensity/magnitude/severity estimate:
  • Primary data
  • Secondary data
  • Modelled data: estimated without any event-specific data

Hazards may be linked between each others. This linkage is called "concurrent hazard" and is linking the observed and potentially unobserved hazards together with a specific relationship:

• Triggers: as the current hazard triggers the linked hazard. For example, an earthquake triggers a landslide.
• Triggered by: as the current hazard is triggered by the linked hazard. For example, a landslide is triggered by an earthquake.
• Concurrent: For hazards that do not necessarily trigger one-another, but occur together. For example, thunderstorms can occur together with windstorms or cyclones, thus, we would use 'concurrent'.
• Complex: When the relationship between two hazards is complex.

The link has also specific occurence attributes:

• occurence_type: the linked hazard actually observed to have occurred with the main hazard, or is this link only a potential link. Montandon allows for hazards to be linked together by actual observed occurrences, or the possibility that the linked hazard occurred with the principal hazard. This is especially useful when handling hazards such as tropical cyclones, whereby more than half of all deaths from cyclones in the US were actually caused by inland flooding.
• occurence_prob of the linked hazard occurring with the main hazard. This is a subjective probability, and is not a statistical probability. It is a qualitative assessment of the likelihood of the linked hazard occurring with the main hazard.
• occurenece_probdef: definition of occurrence probability is for the hazard relationship. For example, if the probability is 'high', where is 'high' defined?

Impact

Impact data represent an estimate of the effect, including negative effects (e.g., economic losses) and positive effects (e.g., economic gains), of a hazardous event or a disaster. The term includes economic, human and environmental impacts, and may include death, injuries, disease and other negative effects on human physical, mental and social well-being'. UNDRR - https://www.undrr.org/terminology/disaster

The impact class has the following attributes:

• id: A unique identifier for the impact. Preferably, the identifier assigned by the issuer (source) of the impact estimate data. If not available, an identifier can be generated and should be prefixed with the related event id.
• title: The name of the impact assigned by the issuer (source) of the impact estimate data.
• geometry (GeoJSON geometry): The location of the impact in the form of a GeoJSON geometry.
• datetime: The date and time periods of the impact estimates.
• start_datetime: The date and time when the impact estimate started or is forecasted to start. OPTIONAL
• end_datetime: The date and time when the impact estimate ended or is forecasted to end. OPTIONAL
• ref_event_id: The identifier of the reference event to which is associated the impact.
• source_event_id: The identifier of the source event to which is associated the impact. OPTIONAL
• hazard_id: The identifier of the hazard to which is associated the impact. OPTIONAL
• source: Information about the organization and the database capturing, producing, processing, hosting or publishing this estimate impact data.
• impact_detail: A detailed description of the impact including:
• category: The category of impact, which is the specific asset or population demographic that has been impacted by the hazard.
• value: The estimated value of the impact, as a number, without the units. For example, for an estimate of 1000 people displaced, you would enter 1000.
• type: The estimated value type of the impact. For example, for an estimate of 1000 people displaced, the value type is people displaced, thus you would enter 'imptypedisp'. Refer to the taxonomy for all possible impact types.
• unit: The units of the impact estimate. For example, 10 deaths would be a count value, thus 'unitscountnum' should be used.
• date: If the impact estimate is a cost, provide the date that the estimate was made on, to adjust for currency value and inflation. If no value is provided, imp_sdate will be used. OPTIONAL
• estimate_type: The type of data source that was used to create this impact estimate:
  • Primary data
  • Secondary data
  • Modelled data: estimated without any event-specific data

Response

Response data represent an action taken or a product produced in response to a disaster — for example, a Copernicus EMS Grading map, an International Charter Value-Added Product, a UNOSAT damage assessment, an IFRC DREF operation, or a humanitarian shelter distribution. The scope boundary with Impact is strict: Response = action / product; Impact = estimated effect on people or assets. A CEMS Grading Product is a Response that informs Impact items; it is not itself an impact.

In the Monty model, a Response is ALWAYS linked to one or multiple event(s) through monty:corr_id, and SHOULD reference the hazard(s) it addresses (via monty:hazard_codes and related-hazard links) as well as any acquisition / source imagery items it derives from (via STAC derived_from links). The canonical landing page or product URL in the source system (e.g., CEMS activation page, Charter activation page, UNOSAT product page) SHOULD be expressed as a STAC rel: derived_from link rather than embedded as a property under monty:response_detail. Where the response product informs Impact items, the canonical provenance edge is carried on the Impact side: each derived Impact item SHOULD declare a STAC rel: derived_from link pointing back to the Response item. The Response item itself MAY add rel: related links (with roles: ["impact"]) to the Impact items it informs, but those are an optional back-reference — the derived_from edge on the Impact item is the authoritative provenance.

The full design rationale, framework survey, taxonomy of response type codes, and Sendai Framework crosswalk are documented in Response Taxonomy. The extension-layering rules and worked-example combinations are in Response Best Practices. The rules for deciding, per piece of data, whether something belongs on a Response item, on a paired Impact item, or on neither — the pattern catalogue, decision tree, ETL splitting algorithm, and query patterns — are in Response ↔ Impact Boundary Rules.

The Response class has the following attributes:

• id: A unique identifier for the response. Preferably, the identifier assigned by the issuer (source) of the response (e.g., CEMS activation product code). If not available, an identifier can be generated and should be prefixed with the related event id.
• title: The name of the response assigned by the issuer (source) of the response.
• geometry (GeoJSON geometry): The location / area-of-interest of the response in the form of a GeoJSON geometry.
• datetime: The publication or production date and time of the response.
• start_datetime: The date and time when the response action / product window started. OPTIONAL
• end_datetime: The date and time when the response action / product window ended. OPTIONAL
• ref_event_id: The identifier of the reference event to which the response is associated.
• source_event_id: The identifier of the source event to which the response is associated. OPTIONAL
• source: Information about the organization and the database capturing, producing, processing, hosting or publishing this response data.
• response_detail: A detailed description of the response including:
• type: REQUIRED. The response type code from the response taxonomy ({domain}-{type}, e.g., eo-del, eo-gra, hum-shelter, fin-dref). The only strictly required field. The domain (eo, hum, fin) is derivable from this prefix.
• source_id: The native identifier of the response in the source system (CEMS activation code, Charter call id, UNOSAT product code, DREF operation id). OPTIONAL
• status: Lifecycle status — one of planned, in-production, published, finished, no-impact, withdrawn. Harmonises CEMS statusCode and Charter disaster:activation_status. OPTIONAL
• monitoring_number: Iteration number for monitoring updates (mirrors the CEMS API monitoringNumber). The presence of this field marks the item as a monitoring update. The prior iteration this update monitors SHOULD be expressed via a STAC rel="prev" link to that Response item. OPTIONAL
• producer: Organisation that produced the response (e.g., JRC, UNOSAT, Airbus, IFRC). OPTIONAL
• methodology: Type of analysis — one of human_interpreted, semi_automated, automated, modelled. OPTIONAL
• sendai_targets: Subset of ["A","B","C","D","E","F","G"] indicating the Sendai Framework targets this response contributes to. See the response taxonomy for the per-type defaults. OPTIONAL
• sectors: For humanitarian (hum-*) items, the IASC clusters / IFRC EPoA sectors covered (e.g., shelter, health, wash). OPTIONAL

Statistical / damage figures contained in EO products (e.g., CEMS affected / total per thematic) are not part of response_detail — they belong to separate Monty Impact items linked via monty:corr_id. Likewise, underlying source imagery (acquisition items linked through derived_from) carries sar: / eo: / sat: / processing: fields directly; those are not copied into response_detail.

Response items SHOULD declare additional STAC extensions where applicable, rather than duplicating their fields under monty:response_detail. The Response Best Practices document specifies the recommended extension layering per response type — notably that International Charter VAP items MUST declare the Terradue disaster: extension alongside monty:.