Introducing a more compact IWXXM form to transport meteorological parameters

[blchoy]

During 30 Sep 2026 meeting, Ilkka pointed out that the existing atomised container WxObject is not effective in transporting multiple meteorological parameters, no matter it is a time series of a single parameter, or a snapshot of multiple parameters, or a mixture of them, especially with additional quantifiers like probabilities, etc. to each parameter.

Making reference to Ilkka's examples (like [AerodromeWeatherForecast-probability-distribution-p90-95-mean-Example.xml](https://github.com/spatineo/iwxxm-sx/blob/amf/IWXXM/examples/AerodromeWeatherForecast-probability-distribution-p90-95-mean-Example.xml)), it is effectively an XML version of table driven encoding (like WMO GRIB and BUFR):

<tsml:defaultPointMetadata>
   <iwxxm:ValueRecord>
      <iwxxm:field>
         <iwxxm:RecordField position="1" name="windSpeedDistribution" title="Probability distribution of 10 min average wind speed">
            <iwxxm:observedProperty xlink:href="#windSpeedDistribution" />
            <iwxxm:interpolationType xlink:href="http://www.opengis.net/def/timeseries/InterpolationCode/AveragePrec"/>
         </iwxxm:RecordField>
      </iwxxm:field>
      <iwxxm:field >
         <iwxxm:RecordField position="2" name="windDirectionDistribution" title="Probability distribution of 10 min average wind direction">
            <iwxxm:observedProperty xlink:href="#windDirectionDistribution" />
            <iwxxm:interpolationType xlink:href="http://www.opengis.net/def/timeseries/InterpolationCode/AveragePrec"/>
         </iwxxm:RecordField>
      </iwxxm:field>
      <iwxxm:field>
         <iwxxm:RecordField position="3" name="windGustDistribution" title="Probability distribution of 10 minute wind gust">
            <iwxxm:observedProperty xlink:href="#windGustDistribution" />
            <iwxxm:interpolationType xlink:href="http://www.opengis.net/def/timeseries/InterpolationCode/MaxPrec"/>
         </iwxxm:RecordField>
      </iwxxm:field>
   </iwxxm:ValueRecord>
</tsml:defaultPointMetadata>

<tsml:point>
   <amfis:DistributionRecordTVP>
      <amfis:mean>1.1 105 1.5</amfis:mean>
      <amfis:predictionIntervalBoundary level="0.95" type="lower">1.0 90 1.2</amfis:predictionIntervalBoundary>
      <amfis:predictionIntervalBoundary level="0.95" type="upper">1.2 115 1.7</amfis:predictionIntervalBoundary>
      <amfis:predictionIntervalBoundary level="0.90" type="lower">0.9 87 1.0</amfis:predictionIntervalBoundary>
      <amfis:predictionIntervalBoundary level="0.90" type="upper">1.5 116 1.9</amfis:predictionIntervalBoundary>
   </amfis:DistributionRecordTVP>
</tsml:point>
...

The original intention of "atomising" the container is to make flexible retrieval of parameters by sacrificing efficiency. We believe this has higher priority than bulk transfer of data.

For time series of a single parameter, even with additional quantifiers like probabilities, it is till possible to cramp all data into a single WxObject instance.

If multiple parameters are involved, then the logical choice is to use iwxxm:MeteorologicalFeatureCollection to hold the whole data set, either with (1) multiple WxObjects each has a table of data of a single parameter, time series and quantifiers, or (2) a huge table of data of multiple parameters, their time series and quantifiers.

We have yet to see the use cases to confirm if the amount of data to be transported in one shot needs (1), (2) or both of them.

[blchoy]

The use case I can think of so far is the data used to feed a dashboard showing time series of multiple parameters and (2) above is the most efficient transport. However, unless the IWXXM data file is generated on-the-fly, it is unlikely that a pre-generated aggregation of parameters will fit all use cases (c.f. a METAR report may contain unnecessary parameters for certain applications which the WxObject design would like to fix).