AMOIS and AMFIS Discussion 2026 09 02 - team-sx/iwxxm-sx GitHub Wiki

Details

2026-Sep-02, 12:00-13:00 UTC, Webex

Agenda

Review of the requirements in Internal Reference Document - AMOIS and AMFIS v1.0
- Need ordered descriptions of reference locations/coverages (e.g. Aerodrome -> RWY -> TDZ, Aerodrome -> significant point, etc.)
- Need to resolve overlapping reference locations/coverages for wind at an aerodrome (coming from METAR) and wind at TDZ of a RWY at an aerodrome (coming from LRR). Are the descriptions of reference locations/coverages good enough for filtering (need API examples for confirmation).
- Need to confirm if descriptions of reference locations/coverages are generic proxies to sensor location and measuring volume, the former are expected to be used by default while the latter by advanced users.
Technical issues to be resolved:
1. iwxxm:PhenomenonGeometry in WxObject adequately describes the boundary of a phenomenon, but it is not supposed to be used to describe a region of interest
2. In OMS (see Ilkka's excellent summary) an observation can be attributed to a "product" (e.g. an anemometer next to the runway infers wind condition at TDZ over the runway). In real life use only the wind condition at TDZ is important to end users; it is the producer's responsibility to choose the best data source.
How to make contributions (schemas, sample instances, etc.)

Notes

Review of the requirements:
- MRAD indicated that they no longer wanted to pursue with the concept on coverage representativeness:
- Instead, they would like to expose observations made with reference to the location of the sensor/human observer (or may be the sensor measuring coverage/human observation range) and let the consumer side determine which of them are providing the meteorological condition they need.
The need of a new element in place of iwxxm:PhenomenonGeometry to describe a region of interest:
- The original intention of iwxxm:PhenomenonGeometry is to describe the spatial coverage occupied by the phenomenon being mentioned in a WxObject. This works well in SIGWX and VA.
- But when we are talking about an observation or measurement we are usually referring to the sampling space instead of the spatial bound of the phenomenon. This is further complicated when the observation or measurement within the sampling space is being used to infer the conditions in a larger space (e.g. an aerodrome represented by a coverage within 8km from the ARP).
- The following is once again the humble WxObject:
```
<iwxxm:MeteorologicalFeature>
   <gml:identifier ... />
   <iwxxm:phenomenonCategory />
   <iwxxm:phenomenonTime />
   <iwxxm:phenomenon />
   <iwxxm:phenomenonGeometry />
   <iwxxm:phenomenonProperty />
</iwxxm:MeteorologicalFeature>
```
- As suggested by Ilkka, a new "Region of Interest" element could be used to describe the sensor sampling space or the representative space it inferred:
```
<iwxxm:MeteorologicalFeature>
   <gml:identifier ... />
   <iwxxm:phenomenonCategory />
   <iwxxm:phenomenonTime />
   <iwxxm:phenomenon />
   <iwxxm:phenomenonRegionOfInterest />
   <iwxxm:phenomenonProperty />
</iwxxm:MeteorologicalFeature>
```

Examples taking the above into account (conceptual, not actual representation):

Wind observed at anemometer R1E in aerodrome VHHH

<iwxxm:MeteorologicalFeature>
   <iwxxm:phenomenon>Wind</iwxxm:phenomenon>
   <iwxxm:phenomenonRegionOfInterest>
      <iwxxm:phenomenonROICommonName>Aerodrome-VHHH</iwxxm:phenomenonROICommonName>   <-- Identifier for the aerodrome
      <iwxxm:phenomenonROICommonName>Anemometer-R1E</iwxxm:phenomenonROICommonName>   <-- Identifier for the anemometer
      <iwxxm:phenomenonROIGeometry>
         <iwxxm:ElevatedPoint />   <-- Location of the anemometer
      </iwxxm:phenomenonROIGeometry>
   </iwxxm:phenomenonRegionOfInterest>
   <iwxxm:phenomenonProperty />   <-- Actual observation data goes in here
</iwxxm:MeteorologicalFeature>

While it will be the consumer to determine which sensor/human observations fits their needs, it is possible for the producer to provide hints to where a sensor/human observation is applicable.
Reporting in this way, AMOIS is essentially a cluster of sensor/human observations. Some participants indicated that they have a need to provide such a cluster at a different location and has provided a use case. Participants considered it essential to relate this cluster with an associated aerodrome.
Checking against the requirements in IRD v1.1 (Note that the use of words "mandatory" and "optional" is unclear. Better options like "mandatory for all occasions" (e.g. issue time), "mandatory for specific occasions" (e.g. location) and "supplementary" (e.g. Full name of an aerodrome)):

Other things worth considering:

Contributing to this GitHub repository
- Participants are welcomed to contribute to this GitHub repository with their views in particular on sample instances so that they can be used to confirm correctness of generated schemas and schematron rules.
- TT-AvData has set up rules and workflows for contribution on its GitHub repositories. They are borrowed for use on this GitHub repository and are summarised here.

Decision and Action

Use of iwxxm:phenomenonRegionOfInterest to indicate an enclosed space (a) for an observation (sensor or human), (b) in which the meteorological condition within is inferred by an observation, and (c) for a forecast.
The structure of common name and its support for information service operations like filtering

Next Meeting

16 Sep 2026 11:00-12:00UTC

Attendees from TT-AvData, WG-MIE and WG-MRAD

Name (Affiliation)	Attendance
Rosalind Lapsley (EUROCONTROL)	X
Dirk Zinkhan (DWD)	X
Svenja Koos (DWD)	X
Joonas Eklund (FMI)	X
Anu Lång (FMI)	X
Rauhala Mikko (FMI)	X
Ilkka Rinne (FMI)	X
Terhi Nikkanen (FMI)	X
Ashwin Naidu (BoM)	X
Patric Desgagnes (NAVCAN)	X
Tom Helms (FAA)	X
Michiko Ikeda (JMA)	X
BL Choy (HKO)	X