Skip to content

Design Thoughts

Jump to bottom
BL Choy edited this page Sep 17, 2026 · 38 revisions

This page lists out thoughts regarding the design of IWXXM-SX. There is no guarantee that these thoughts will be implemented in the information model.

  • Enhancements to the humble WxObject with the introduction of a new "Region of Interest" element to describe (sensor) sampling or representative space: 
    <iwxxm:MeteorologicalFeature>
   <gml:identifier ... />
   <iwxxm:phenomenonCategory />
   <iwxxm:phenomenonTime />
   <iwxxm:phenomenon />
   <iwxxm:phenomenonRegionOfInterest />
   <iwxxm:phenomenonProperty />
</iwxxm:MeteorologicalFeature>
  • iwxxm:phenomenonRegionOfInterest could have the following structure: 
    <iwxxm:phenomenonRegionOfInterest>
   <iwxxm:phenomenonROICommonName>R2C</iwxxm:phenomenonROICommonName>   <-- This is optional
   <iwxxm:phenomenonROIGeometry />   <-- This is mandatory
   <iwxxm:phenomenonROIReference xlink:href="http://location-of-some-online-resources"/>   <-- This is optional
</iwxxm:phenomenonRegionOfInterest>

Some thoughts on transition from METAR and TAF to AMOIS and AMFIS

  • A METAR or TAF is a message with multiple meteorological parameters. Metadata which is applicable across these parameters is being grouped together to form part of the message envelope:
METAR/SPECI TAF

  • In the new WxObject design, to make iwxxm:MeteorologicalFeature a standalone object that can be utilised without the iwxxm:MeteorologicalFeatureCollection envelope, the former has to carry crucial metadata which may also exist in the envelope to support independent exchange and consumption.

  • Under the context of AMOIS, the concept of providing inferred meteorological conditions to certain regions (e.g. aeronautical features like TDZ) is no longer applicable. Instead, observations made by sensors and human observers will be provided and the Region Of Interest (ROI) will be the location of the observation or under certain circumstances the measuring volume.

  • While it is understood that the role of identifying which observation can be used as representative condition(s) within an aeronautical feature (e.g. TDZ) rest with the consumers, there are thoughts that the producers should have a better knowledge on this mapping. Hints may be provided by producers on this mapping and if the mapping is not one-to-one the suggested priority of assignment.

  • For AMFIS, the ROI will continue to be aeronautical features.

  • Even though without an envelope, the name of an aerodrome still serve as a handle to all observations and forecasts made for the aerodrome. This concept of a cluster of observations for a named aerodrome may be able to apply in other places like a remote location; all we need to do is to replace all aerodrome specific nomenclatures with those relevant to the remote location. While naming of aerodromes is handled by ICAO, the naming of remote locations is likely to be local and guidance on establishing a mechanism for discovering, managing and announcing may be required.

  • There are two ways to retrieve observations from an information service: Use of common names (which is then more human friendly) and machine readable handles (like UUIDs which is not supposed to be handled by human). The following is an interaction diagram of the latter:

Items under consideration

  • Keys to AIXM aeronautical objects and WMO sensor objects to be used in iwxxm:phenomenonRegionOfInterest

Older thoughts to be incorporated

  • Regarding MET parameter representation:

    • There is no known use case on user consolidation of primitive data (e.g. 120 1-second data used to calculate the 2-minute mean) (See 2024 Jan 23 discussion)
    • Data points on a time series may have variable time intervals (See 2024 Jan 23 discussion)
    • In addition to a data point, supplementary data may be provided for consumers to obtain further insights regarding the data point (e.g. A 2-minute-mean wind and the 1-second data used in the calculation. A probability on exceeding certain threshold/range of values within certain confidence level and the CDF/PDF used in the calculation) (See 2024 Feb 28 discussion)

  • Regarding information model design:

    • External schemas are likely to be self-contained, though direct use may bring in redundant features. Using their primitive features to build local features may better suit our use cases and maintain interoperability (See 2024 Jan 23 discussion)

  • Regarding information model implementation:

    • While the aviation community is still using (and continues planing to use) XML for information exchange, the Open Spatial Consortium (OGC) has not been creating XML schemas for their information models recently. Holding on to XML technologies, without considering alternatives like JSON in parallel, is risky, because the tool support and technical skills for producing and using XML is bound to decline as XML-based data exchange gradually transitions from mainstream to niche. Considerations will have to be made in developing IWXXM-SX that facilitates implementation in different formats like JSON (See 2024 Feb 16 and 2024 Feb 28 discussions)

  • Regarding information services to be supported:

Clone this wiki locally