Metadata for AMOIS AMFIS and HWIS 2026 Mar 16 - wmo-im/iwxxm GitHub Wiki

Details

2026-Mar-16, 14:30-15:30 UTC, Webex

Agenda

  1. While this discussion is on the new IWXXM AMOIS, AFMIS and HWIS packages, it is hoped to also provide some insights on what we could do with existing (legacy) IWXXM messages exchanging over SWIM.
  2. Metadata needs for these packages:
    • Previous discussion suggested that a review of the metadata needs is required to better support their provision over SWIM.
    • The needs may fall into the following categories:
      1. Metadata to support message/object exchange/transaction over SWIM, especially through MQs and APIs (e.g. iwxxm:permissibleUsage, etc.).
      2. Metadata and data representation to support more effective/efficient MQ and API operations (e.g. filtering).
      3. Metadata to improve the description of data in an object (e.g. data specifications, like "measurement accuracy of 0.1 degrees Celcius" or "reporting in steps of 10 degrees angle").
    • This discussion will focus on (a) and (b), as it requires a better understanding of the concepts of operation as well as use cases involving MQs and APIs.
    • For (c), separate discussions is being made within ICAO WG-MRAD.
  3. The following consolidates some initial findings/thoughts for discussion:
    1. Permissible usage information (iwxxm:permissibleUage, etc.):
      • Introduced in IWXXM 2.1 in 2017 to indicate the operational status of an IWXXM message.
      • The idea had been back ported to TAC SIGMET, AIRMET, Volcanic Ash Advisory, Tropical Cyclone Advisory and Space Weather Advisory messages in Amendment 78 to ICAO Annex 3 in 2018.
      • Documented in Appendix D of the Manual on the ICAO IWXXM (Doc 10003). There was no documentation on how the metadata affects exchange/transaction as well as downstream processing.
    2. TAC-to-IWXXM translation outcome (iwxxm:translatedBulletinID, etc.):
      • Introduced in IWXXM 2.1 in 2017 to indicate the outcome of translation from respective TAC messages if applicable.
      • Documented in Appendix E of the Manual on the ICAO IWXXM (Doc 10003). There was no documentation on how the metadata affects exchange/transaction as well as downstream processing.
  4. The best place to include the implementation details (may be supporting use cases too), like Guidelines for MET-SWIM Implementation, CONOPS, ICD, Doc. 10003, etc.

Notes (Draft)

  1. Choy welcomed all to join the discussion.
  2. A general overview of issues discussed at MET3SG regarding implementation of MET-SWIM was given. There was a general consensus on the need to standardize relevant details on implementing AMQP and EDR or otherwise interoperability issues would emerge.
  3. Guidance materials on EUROCONTROL SWIM Wiki was mentioned. These include MET-SWIM OGC EDR Guidance and AMQP Message Structure in MET-SWIM. Relevant points discussed include:
    • For AMQP, available transport specific functionalities require appropriately structured messages to operate. The following is an example proposed on the SWIM Wiki: 
      # Message Addressing 
address: weather.aviation.metar 

# Header 
priority: 4 

# Message Properties 
subject: "weather.aviation.metar" 
content-type: "application/xml" 
content-encoding: "gzip" 
absolute-expiry-time: 1744823400 

# Application Properties 
conformsTo: "https://eur-registry.swim.aero/services/eurocontrol-iwxxm-metar-speci-subscription-and-request-service-10" 
properties.issue_datetime: "2025-04-15T12:02:00Z" 
properties.datetime: "2025-04-15T12:00:00Z" 
properties.icao_location_identifier: "EBBR" 
properties.icao_location_type: "AD" 
properties.report_status: "NORMAL" 

# Payload 
# [Gzipped IWXXM XML content]
    • Some of the information, like Application Properties, are extracted from the IWXXM message (as gzipped payload) involved:
      AMQP Property Report Types XPath Expression
      properties.issue_time ALL /iwxxm:*/iwxxm:issueTime
      properties.datetime METAR, SPECI /iwxxm:METAR/iwxxm:observationTime
      properties.start_datetime TAF, SIGMET /iwxxm:*/iwxxm:validPeriod/gml:beginPosition
      properties.end_datetime TAF, SIGMET /iwxxm:*/iwxxm:validPeriod/gml:endPosition
      properties.icao_location_identifier METAR, SPECI, TAF /iwxxm:*/iwxxm:aerodrome/aixm:AirportHeliport/aixm:locationIndicatorICAO
      properties.icao_location_identifier SIGMET /iwxxm:SIGMET/iwxxm:issuingAirTrafficServicesRegion/aixm:Airspace/aixm:designator
      properties.icao_location_type METAR, SPECI, TAF "AD"
      properties.icao_location_type SIGMET /iwxxm:SIGMET/iwxxm:issuingAirTrafficServicesRegion/aixm:Airspace/aixm:type
    • For EDR, except for geospatial properties, other transport specific functionalities will have to be implemented by the service provider.
  4. Although the set up for transport specific functionalities like filtering are different for AMQP and EDR, there is indeed a need to consolidate the location for such information in IWXXM instances, as well as their nomenclature (e.g. properties.end_datetime) which should be consistent across transports.
  5. Other existing operational metadata like iwxxm:permissibleUsage is also useful and should be promoted for use in AMQP and EDR, as well as client device. Future needs (e.g. metadata for data policy) should also be taken into account.
  6. Regarding the use of WMO AHL in exchange of bulletins over AFS, while there is no such need (bulletinizing and routing) for exchange over AMQP and EDR, the presence of CCx and RRx does show the full chain of messages involved (from original to CCA to CCB, etc.) which is a benefit in some situations. TT-AvData will see if relevant operational metadata can be included in future versions of IWXXM messages.
  7. There were also discussions on the level of details to be documented on transport implementation requirements. Those on SWIM Wiki could be regarded as the minimal set. Further discussions in WG-MIE would be required to find the best place to hold such information (e.g. The ICAO Guidance for MET-SWIM implementation).

Actions

  • Choy, Dirk and may be Joonas too to see if there is a need to bring up the need in WG-MIE/14 on documenting AMQP and EDR implementation details in ICAO documents.
  • Choy to consider introducing new operational metadata in future IWXXM messages, including indication of CCx or RRx chains.

Next Meetings

N/A

Invitees / Attendance

Name Country/Affiliation Attendance
Boon-leung CHOY Hong Kong, China X
Dirk ZINKHAN Germany X
Joonas EKLUND Finland X
Boris BURGER IBL X
Jan KOROSI IBL X
Dario DI CRESCENZO EUROCONTROL X
Michael PICHLER SESAR X