International Charter on Space and Major Disasters

The International Charter coordinates satellite data delivery for disaster response worldwide. An Activation groups the areas of interest (AoIs) and the Value-Added Products (VAPs); the underlying satellite Acquisitions are grouped under the Call that triggered them. This document maps the Charter object model — as exposed by the Charter Mapper on S3 (our ingestion entry point) — to Monty STAC items.

Collections

• Source organisation: International Charter on Space and Major Disasters (CHARTER)
• Source URL: https://disasterscharter.org
• Ingestion entry point (S3): s3://cpe-operations-catalog/ (Charter Mapper catalog, JSON-only partner access)
• Discovery API: https://supervisor.disasterscharter.org/api/ (browsing only)
• License: partner access (Terradue-granted, IP-allowlisted)
• Temporal coverage: 2000-11-05 onwards (Charter formation)

Conversion principle — copy-as-is + Montandon specifics

The Charter Mapper already publishes valid STAC, so the conversion is a pass-through: each source item is carried over as-is — geometry, bbox, assets, the imagery extensions (eo: / sar: / sat: / view: / proj: / processing:), providers, and the Charter-native disaster: fields are all preserved. The ETL only does two things on top:

1. Fix STAC-level consistency issues — normalise the legacy Terradue disaster: v1.0.0 declaration to v1.1.0 (lowercase disaster:class, plural disaster:types / disaster:regions), set stac_version, drop null/internal bookkeeping fields, and repair anything that fails STAC validation.
2. Add the Montandon specifics — the monty extension plus monty:corr_id, monty:country_codes, monty:hazard_codes, monty:response_detail, the event / hazard / response roles, the Monty id and collection, and the typed related / derived_from links.

Everything else in the source item is left untouched. The mapping tables below describe only these two deltas — assume every other field rides along unchanged.

Object model

The process flow (Call → Activation → Areas/VAPs, Call → Acquisitions)

The Charter data model is easier to read once the activation process is understood. The Call is emitted first, and the Activation is the confusing pivot — acquisitions never attach to it directly.

1. An Authorized User submits a request → a Call is created (call_id, e.g. 1166). This is the first object to exist.
2. The on-call Project Manager reviews and approves the call, which then creates a new Activation (activation_id, e.g. 1019) or — more rarely — is linked to an existing activation. A Call therefore belongs to exactly one Activation, but an Activation can aggregate several Calls (its disaster:call_ids is an array).
3. Attached to the Activation: the Areas (AoIs) and the Value-Added Products (VAPs) — the human-interpreted map products.
4. Attached to the Call: the Acquisitions (satellite tasking) and all downstream production, including the progressively processed calibrated datasets.

flowchart TD
    AU([Authorized User]) -->|"1. submits request"| CALL["<b>Call</b><br/>call_id — e.g. 1166"]
    CALL -->|"2. reviews & approves"| PM{On-call<br/>Project Manager}
    PM -->|"creates new (usual)"| ACT["<b>Activation</b><br/>activation_id — e.g. 1019<br/>disaster:call_ids = (1166, …)"]
    PM -.->|"links to existing (rare)"| ACT
    ACT -->|"3. scopes"| AREAS["<b>Areas</b> / AoIs<br/>→ Hazard items"]
    ACT -->|"3. publishes"| VAPS["<b>Value-Added Products</b><br/>→ Response items"]
    CALL -->|"4. tasks"| ACQ["<b>Acquisitions</b><br/>satellite passes"]
    ACQ -->|"ETL: raw → calibrated"| CAL["<b>Calibrated Datasets</b><br/>→ eo-dat Response items"]
    CAL -.->|"analysed into"| VAPS

The most confusing association: a calibrated dataset carries only its disaster:call_ids — it has no activation_id. To reach the Event, resolve call → activation (the Activation lists the call in disaster:call_ids, and also links each calibrated dataset via rel: related). Never expect the activation id on the dataset itself.

Entities and how they are keyed

erDiagram
    ACTIVATION ||--|{ CALL : "aggregates 1..N calls (reuse rare)"
    ACTIVATION ||--o{ AREA : "scopes"
    ACTIVATION ||--o{ VAP : "publishes"
    CALL ||--o{ ACQUISITION : "tasks"
    ACQUISITION ||--|| CALIBRATED_DATASET : "final calibrated stage"
    CALIBRATED_DATASET }o..o{ VAP : "analysed into"

    CALL { string call_id }
    ACTIVATION { int activation_id "has disaster-call_ids array" }
    AREA { string area_id "carries activationid and callid" }
    VAP { string id "act-A-vap-CALL-N" }
    CALIBRATED_DATASET { string id "call_ids only, NO activation_id" }

Monty mapping

Charter exposes five object types. Four are emitted as Monty items via the Terradue disaster: extension (disaster:class); the fifth — Call — is a process pivot Monty does not emit but references through its call_id.

Both VAPs and calibrated acquisition datasets become Monty Response items in charter-response. VAPs map to derived EO product codes (eo-del, eo-gra, eo-vap, …) and are keyed by activation. Calibrated datasets map to eo-dat and are keyed by call (they are call-native), matching the source: their Monty id omits the activation, which is surfaced only via monty:corr_id and the related links. Keep only the last, calibrated stage as the Response item; earlier ETL-stage records are intermediate artifacts. All entries of the call's calibratedDatasets collection are sourced — including the global reference layers published as {...}_Auxiliary_Dataset_* (DEM, land cover, surface water, HAND, population, settlement).

A VAP links to the calibrated dataset it was analysed from as a sibling Response (rel: related, roles: ["response"]), not via derived_from — both are Response items.

{area_id} is the upstream Area id, lowercased (e.g. AOI_1_Epi_0-iNglWjcFF0v3rBHi3s1_fQ__ → aoi_1_epi_0-inglwjcff0v3rbhi3s1_fq__). {call_id}-{vap_number} is the VAP identifier from the upstream <identifier> (e.g. 1166-19). {dataset_id} is a short URL-safe slug for the calibrated dataset used inside the Monty item id; the full upstream dataset identifier is preserved separately in monty:response_detail.source_id.

The Call object is never emitted as its own item. Its call_id is carried on Response items (via disaster:call_ids and the {call_id} segment of the item id) and surfaced on the Event through the activation title (e.g. [Act-1019/Call-1166]) and the linked Response items — Events are Monty-only and do not declare disaster:call_ids directly.

Data access

Montandon ingests the Charter Mapper catalog from the OTC OBS/S3 bucket cpe-operations-catalog (see Remote Server & Object Storage). (IP-allowlisted). The S3 layout mirrors the object model — activation-scoped items under activations/…, call-scoped items under calls/…:

s3://cpe-operations-catalog/
├── catalog.json
├── activations/act-{activation_id}/
│   ├── act-{activation_id}.json                                     # Activation → Event
│   ├── {hazard}.png                                                 # thumbnail asset
│   ├── primary-{call_id}.kml                                        # AoI KML asset
│   ├── areas/{area_id}.json                                         # Area → Hazard
│   └── vaps/act-{activation_id}-vap-{call_id}-{n}/
│       └── act-{activation_id}-vap-{call_id}-{n}.json               # VAP → Response ✅
└── calls/call-{call_id}/
    └── calibratedDatasets/{dataset_id}-calibrated/
        └── {dataset_id}-calibrated.json                            # calibrated Acquisition → eo-dat Response ✅

Note the split: acquisitions live under calls/call-{call_id}/…, never under the activation — the Activation only links to them (rel: related) and lists the call in disaster:call_ids. VAPs and Areas live under activations/act-{activation_id}/….

HTTP API — discovery only

The public Supervisor API (https://supervisor.disasterscharter.org/api/) mirrors the same STAC but with a slightly different layout (calls/{call_id}/acquisitions/calibratedDatasets.json, no call- prefix) and is only used for browsing/discovery — the sample api-files/ fixtures were pulled from it. It is slow (catalog endpoints are dynamically generated) and some self links carry a .json suffix that returns HTTP 500. Alternative browsing: STAC Index.

Update & polling strategy (ETL)

Charter objects are revised independently — there is no "the activation changes first" rule at update time. The only ordering constraint is at creation (Call → Activation → Areas/VAPs, and Call → Acquisitions; see the process flow). So all of the following happen and the ETL must poll each entity on its own:

• a VAP is added (or, rarely, revised) while its Activation is untouched;
• an Area is added/refined while the Activation is untouched;
• a calibrated dataset changes (recalibration / new pass) with nothing else moving;
• any combination of the above.

Where each entity is polled

Because Areas and VAPs are activation-scoped but Acquisitions/datasets are call-scoped, a single crawl of the activation prefix does not surface dataset changes. Poll two prefixes per event:

The call list comes from the Activation's disaster:call_ids. Resolve call → activation once, then poll each calls/call-{call_id}/… prefix on its own cadence — never assume a dataset change is reflected in the Activation's own object (it is not: acquisitions never attach to the activation).

Detecting a real change

Use, in order of reliability:

1. S3 object ETag / LastModified (from ListObjectsV2 on the prefix) — the authoritative "did this JSON change" signal, immune to the republish caveat. Store the last-seen ETag per object key and re-ingest only when it changes; the listing is metadata-only and cheap. (Note S3 ETag is a content hash only for non-multipart objects — these small JSONs qualify; otherwise hash the normalised body yourself.)
2. properties.created — the true production timestamp, stable across republishes and the best signal for "is this object new since the last poll".
3. cpe:status.stage (acquisitions only) — lifecycle marker. The calibratedDatasets collection already holds only the calibratedDataset stage, but a dataset can be re-emitted at that stage after re-processing, so combine it with the ETag.

Cadence

Drive polling frequency from the activation lifecycle (cpe:activation_status):

Re-emission (idempotency)

The Monty id and monty:corr_id are stable across updates: on a detected change, recompute the item and overwrite the existing Monty item at the same id. A dataset re-processed under the same {dataset_id} is a content update on the same Response id (not a new item); a new sensor pass is a new id. Withdrawal or deletion of an upstream object is rare and is handled by removing the corresponding Monty item.

The Terradue disaster: extension

Charter is the live data model for the Terradue disaster: extension. Upstream Charter STAC declares the legacy URL https://terradue.github.io/disaster/v1.0.0/schema.json; Monty Response items declare the current URL https://terradue.github.io/stac-extensions-disaster/v1.1.0/schema.json. Field semantics are identical, but field names and value casing changed. Apply this normalization when mapping:

Events and Hazards are modelled as Monty-only items (they carry the mapped values in monty: fields and do not declare disaster:). Response items (VAPs and calibrated acquisitions) layer the disaster: extension — see VAP → Response and Calibrated acquisition → Response.

Activation → Event

Maps to a Monty Event item (charter-events). Declares the Monty extension only.

Multi-hazard: include every hazard code on the Event. For disaster:type: ["flood", "landslide"] carry both MH0600/FL/nat-hyd-flo-flo and GH0300/LS/nat-geo-mmd-lan.

Correlation ID (monty:corr_id): generated by the standard Monty algorithm from event date, ISO3 country, spatial block, primary hazard, and episode — format {YYYYMMDD}-{ISO3}-{spatial_block}-{UNDRR-ISC}-{episode}-GCDB, e.g. 20251103-AFG-1138838-GH0101-1-GCDB. The numeric block is a spatial identifier, not the Charter activation_id. All items for the same event share it.

Full example: charter-event-1000.json.

Area → Hazard

Maps to a Monty Hazard item (charter-hazards). Declares the Monty extension only.

Severity — the Area description is a flat key/value string, e.g. Call-1166 AoI ID: 1, Priority: 1, Radius (km): 8.0, Lat: -21.759126, Long: -43.360292, SurfaceArea: 201, Comment:. monty:hazard_detail requires severity_value + severity_unit; derive them as:

Priority is operational AoI ordering, not a hazard severity, and is not carried in the Monty schema. Lat/Long describe the AoI centre and are already represented by geometry.

Estimate type — map cpe:status.stage to monty:hazard_detail.estimate_type (enum primary / secondary / modelled). Observed stages (notificationNew, notificationImported) and any unrecognized stage map to primary. This is an interim mapping pending full CPE stage documentation.

Value-Added Product → Response (v1.3.0)

Charter VAPs map to Monty Response items via the v1.3.0 monty:response_detail object and the response role. This is the Charter-specific application of the cross-source guidance in response-best-practices.md (§3.2) and the response-type codes in response-taxonomy.md (§2.1).

Extension layering (do not duplicate)

VAP Response items declare two extensions:

The governing rule is extension layering over duplication: any concept already expressed by a disaster: field is canonical there and MUST NOT be copied into monty:response_detail.

Field carriage

Most disaster: fields are not present on the source VAP JSON (which only carries disaster:class and disaster:activation_id); they are enriched from the parent Activation/Area or inferred, then normalized per the disaster: extension table.

Do not set monty:response_detail.status — activation lifecycle is carried on disaster:activation_status. Do not put damage/exposure statistics in monty:response_detail; those become separate Monty Impact items (roles: ["impact"]) linked via monty:corr_id.

Product type classification — the disaster: extension does not distinguish delineation from grading, so classify best-effort from the VAP title/description: damage assessment → eo-gra, affected-area extent → eo-del, population exposure → eo-pop. Fall back to eo-vap when the type cannot be determined. Do not encode the source into the code (eo-gra, never eo-charter-gra).

Resolution / producer inference — when disaster:resolution_class is absent upstream, infer it from the acquisition metadata or VAP copyright. Example: copyright "Includes Pleiades material © CNES (2025), Distribution Airbus DS." → disaster:resolution_class: "VHR", producer: "Airbus".

Linkage

Typed related links use a single role from event / hazard / impact / response (per the Monty schema). The main spec also defines the equivalent shorthand rel values related-hazard / related-impact / related-response; Charter items use the rel: related + roles form throughout.

Correlation back to the Event/Hazard uses the shared monty:corr_id.

Example

charter-response-1000-1144-1.json is the canonical worked example (Act-1000 VAP 1144-1, an eo-gra damage assessment). Its monty:response_detail:

{
  "type": "eo-gra",
  "source_id": "1144-1",
  "producer": "Airbus",
  "methodology": "human_interpreted",
  "sendai_targets": ["C", "D"]
}

Note the absence of status, resolution_class, and activation_id — those are carried by the disaster: extension on the same item.

Calibrated acquisition → Response (eo-dat)

Calibrated acquisition datasets map to Monty Response items (charter-response-{call_id}-{dataset_id} — call-keyed, since the source is call-native) with monty:response_detail.type = eo-dat. Because the deliverable is the dataset, the Response item and the acquisition item coincide: declare disaster:class = acquisition plus the imagery-layer extensions already present upstream (eo: / sar: / sat: / view: / proj: / processing:) directly on the Response item. See Response Best Practices §4.4.

Source (S3):

s3://cpe-operations-catalog/calls/call-{call_id}/calibratedDatasets/{dataset_id}-calibrated/{dataset_id}-calibrated.json

The collection is disaster:class = "Acquisition", cpe:status.stage = "calibratedDataset". Every item in it is sourced as an eo-dat Response — both the sensor acquisitions (Pléiades, Sentinel, Landsat, TerraSAR-X, …) and the global reference layers published as {...}_Auxiliary_Dataset_* (Copernicus DEM, ESA WorldCover, JRC Global Surface Water, MERIT HAND, WorldPop, DLR WSF). An acquisition may appear at several ETL stages upstream; the calibratedDatasets collection already holds only the last, calibrated stage, so no stage filtering is needed.

VAP Response items link to the calibrated datasets they were analysed from as a sibling Response (rel: related, roles: ["response"]), since the calibrated dataset is itself an eo-dat Response item. Reserve derived_from for the upstream Charter source page.

Hazard codes

disaster:type values map to Monty hazard codes. UNDRR-ISC 2025 is required (exactly one per Hazard item); GLIDE and EM-DAT are optional but recommended.

Corrected 2026-07-16: this table previously used MH0403 (Blizzard, not Tropical Cyclone) for cyclone, MH1301 for fire and MH0901 for landslide (neither exists in the UNDRR-ISC 2025 list), GH0301 (Falls, not Tsunami) for tsunami, MH0801 (Avalanche, not ice/cold) for ice, MH1202 and a fabricated GLIDE code SW for snow_hazard, and the wrong prefix TH0300/TH0600 for oil_spill/explosive_event. All values above are verified against docs/model/taxonomy.md and its Cross-Classification Mapping table. See IFRCGo/monty-stac-extension#61.

get_canonical_hazard_codes() does not validate this table. That function preserves any code that is already a syntactically valid UNDRR-ISC 2025 code — it does not check that the code is the correct one for the mapped disaster:type (see IFRCGo/pystac-monty#168, where USGS shipped the valid-but-wrong GH0311 for years undetected). The mapping above must be correct at the source; canonicalisation is formatting, not verification.

Examples

Reference files

Actual upstream Charter responses, used as mapping fixtures:

• act-1000-activation.json — single-hazard activation (earthquake)
• act-1000-area-epi.json — polygon AoI (no radius)
• act-1000-vap-1144-1.json — VAP STAC item (damage assessment)
• act-1019-activation.json — multi-hazard activation (flood + landslide)
• act-1019-area-juiz-de-fora.json — circular AoI (with radius)

The api-files/ folder holds the S3-model fixtures backing this analysis (Act-1019 / Call-1166, Flood in Brazil):

• act-1019.json — Activation, with related links to Areas and to the call's calibrated datasets
• activation-1019-areas.json — the four Areas (each carries both callid and activationid)
• act-1019-vaps.json — per-activation VAP catalog; act-1019-vap-1166-19.json, act-1019-vap-1166-22.json — VAP items (disaster:activation_id only; call in the id)
• call-1166-calibratedDatasets.json — the call's calibrated-datasets collection (disaster:call_ids: [1166], no activation id)
• Calibrated dataset items — one per sensor family: Pléiades (optical VHR), Landsat-8 (optical MR), Sentinel-2 (optical HR), TerraSAR-X (SAR)

Resources

• International Charter
• STAC Index — Charter Catalog
• Terradue disaster: extension
• Monty STAC Extension specification