AIXM IWXXM Coordination Teleconference 2021 Dec 9

Details

2021-December-9, 13:30-14:30 UTC, Microsoft Teams

Agenda

1. Preparation of Data Product Specifications for MET information
   • Similar works in other aviation domains, including the draft AIS Manual Part IV - Digital Data Sets
   • WG-MIE activity with similar context - Activity 2.11: Meta-data Requirements for Describing MET Information
   • (Related WG-MIE activity - Activity 3.11: Information Requirements in ICAO Annex 3)
2. IWXXM reference to AIXM
   • Issues on referencing AIXM geometric features and types (#100)
   • AIXM PropertyType issue (#94)
   • AIXM WX profile namespace issue (#199)
   • AIXM way of specifying UoM instead of adopting UCUM
   • Getting schemas via HTTPS (#216)

Presentation

AIXM-IWXXM Coordination Teleconference

Take away

1. Preparation of Data Product Specifications for MET information
   • TBI
2. IWXXM reference to AIXM
   • AIXM geometric features and types
     • AIXM folks were interested to know IWXXM is using aixm:AirspaceVolume to represent geometric shapes of weather phenomena.
     • Noted that in newer versions of IWXXM geometric shapes will no longer be represented by aixm:AirspaceVolume but geometric features defined within IWXXM
     • Changes to AIXM aeronautical features should have no significant impact to IWXXM instances as they are the official representations that should be honoured. There could be some impact if components of spatial features have changed. The greatest risk would be changes to aixm:AirspaceLayer and aixm:AirspaceVolume as they are not originally designed to represent geometric shapes of weather phenomena.
     • AIXM 5.2 is scheduled to be published in Q1 2022. Consideration of its use should be made in the next version of IWXXM.
   • AIXM PropertyType issue
     • This is to overcome the way nilReason is specified in AIXM features (which are members of an enumeration)
     • What AIXM is doing is compatible with GML but is different from IWXXM, the latter of which is using an externally controlled vocabulary in the form of an URI.
     • Both AIXM and IWXXM ensure that users cannot use whatever nilReason they like: AIXM controls this via the schema while IWXXM controls this through schematron rules. This also reflects the difference in representation approaches (hard typing Vs soft typing)
   • AIXM WX profile namespace issue
     • This is a historical mistake made by IWXXM; the imported AIXM WX profile should not be assigned with the same namespace as the full AIXM schema in IWXXM.
     • Looking at the scarcity of AIXM features used in IWXXM there is still a value of re-introduction of AIXM WX profile in future versions of IWXXM
   • AIXM way of specifying UoM instead of adopting UCUM
     • Partly historic and partly closer to downstream usage (e.g. charts, etc.) which reduces the need for translation
     • AIXM folks have checked their UoMs against UCUM and found that they are consistent with each other
     • For IWXXM as it is difficult to guess how the UoM is presented (e.g. Kt, Knot, etc.) the use of a standard representation may be more beneficial
     • Since the AIXM part may have different UoM representation than the rest in an IWXXM instance, care should be taken in data consumption but that should not be a huge problem
   • Getting schemas via HTTPS
     • All shared the same view that local copies of schemas should be used for operational systems; online use of schemas should be discouraged
     • Having said that, it is still interested to know why a HTTP to HTTPS redirection in SAXON is causing trouble for online validation and how to get around.

Attendees

• Eduard Porosnicu, AIXM CCB Secretary
• Brian Murphy, AIXM CCB Co-chair
• Scott Wilson, ATM Information Modeller
• Dirk Zinkhan
• Dmitry Moryakov
• BL Choy