AMOIS and AMFIS Discussion 2026 06 29 - team-sx/iwxxm-sx GitHub Wiki

Details

2026-Jun-29, 06:30-08:30 UTC, Webex

Agenda

1. Outcomes of ICAO METP WG-MIE/14 and WG-MRAD/6 in 2026
   1. WG-MIE/14:
      • Raised the need to create namespaces for individual IWXXM packages - Examples of initial thoughts:
        • Namespace: http://icao.int/iwxxm/amois/1.0
        • Namespace abbreviation: amois
        • Schema location: http://schemas.wmo.int/iwxxm/amois/1.0.0/amois.xsd
      • Raised the need for iwxxm:MeteorologicalFeature and iwxxm:MeteorologicalFeatureCollect (as well as its extensions) to carry more metadata
        • Structural metadata:
          • nilReason="http://codes.wmo.int/iwxxm/nil/inapplicable"
        • Operational/administrative metadata:
          • reportStatus="NORMAL" permissibleUsage="OPERATIONAL“
          • Correction and backward reference (c.f. CCx)
          • To facilitate operations of the transport (e.g. AMQP)
   2. WG-MRAD/6:
      • Went deeper into the concept of dataset with individual iwxxm:MeteorologicalFeature (WxObject) as members of the set instead of a collection of them (c.f. legacy IWXXM METAR which is a collection of phenomena)
      • In AMOIS for a measured parameter (e.g. wind) it is still not clear what should coverage in a WxObject refer to (the sampling point/area/volume of the measurement or the point/area/volume it infers - this is because we seldom have sensors located exactly at the place we want to measure like runway centre line)
      • Further needs for metadata:
        • Descriptive metadata:
          • the kind of specifications the information is conforming to (e.g. averaging period of wind)
          • the conditional parameters that should come together under certain conditions (e.g. surface cross-/head-wind)
          • whether predefined in PANS-MET or locally agreed arrangements are being applied and what they are (e.g. a higher frequency time step, surface wind gust exceeding locally agreed thresholds)
2. A need to review iwxxm:MeteorologicalFeature taking into account of the above needs and the latest O, M and S, including how external schemas are being incorporated into IWXXM (import or no import)

Notes

1. The idea to have separate namespaces for each IWXXM package has its pros and cons. We will need to examine the actual implementation before we can draw conclusions.
2. In separate discussions some WG-MRAD/WG-MIE members indicated their wish to have each WxObject carry site-wise (for example a location near a runway end) information which can be observation or sensor data at the site and let the consumer pick the one most suitable for their operation (e.g. weather conditions at TDZ for landing). They have expressed the concept behind but this arrangement deviates from existing Annex 3 and PANS-MET descriptions in which the provided information should be representative to a specified coverage like TDZ, aerodrome, etc. with other documents describing how to make observations and/or measurements representative to the coverage through siting and other arrangements. While OM&S is focused on representation the observation, it has options to define a "product" with reference to the observation an OM&S instance carries. Ilkka has created a [wiki page}(https://github.com/team-sx/iwxxm-sx/wiki/Alignment-of-AMOIS-AMFIS-data-model-to-ISO-19156:2023-Observations,-measurements-and-samples-(OMS)-standard-concepts) to give context to further discussion on which OM&S concepts could be useful to IWXXM
3. There is one more reason why we prefer providing information representative to a coverage rather than a site-wise observation or sensor data to represent that coverage: Sensor data may be interrupted for many reasons and for more capable airports they usually have a backup sequence to provide the information representative to the coverage. The producer is supposed to be the one with best knowledge to provide the best information for the coverage.
4. Regarding WG-MRAD's intention not to provide METAR and TAF-like collection by extending iwxxm:MeteorologicalFeatureCollection, Joonas and Dirk pointed out this is coming from a pragmatic perspective. While TAC METAR and TAF is expected to be taken out from SARPs, IWXXM METAR and TAF will persist for some time and it could be a waste of effort to migrate from IWXXM METAR and TAF to their equivalents in AMOIS and AMFIS. They prefer to spend more time to explore the possibilities of AMOIS and AMFIS in which other forms of collection could be more useful.

Next Meeting

Tentatively 20 Jul 2026

Attendees

• BL Choy (HKO)
• Dirk Zinkhan (DWD)
• Joonas Eklund (FMI)
• Anu Lang (FMI)
• Rauhala Mikko (FMI)
• Ilkka Rinne (FMI)