Modelling observable properties in aerodrome weather forecasts

From iwxxm-sx created by ilkkarinne: blchoy/iwxxm-sx#5

We need to agree on how the identify (and reference?) observable properties included in the aerodrome weather forecasts. This is has previously been seen a difficult problem to solve in a general way, the in the OMS standardisation process the inner structure of the ObservableProperty class was largely left undefined.

There seem to be many models which aim at providing solutions to describing an observable property somewhere on the spectrum between just a name/URI in a catalog and a very detailed descriptions that can be used for machine processing and reasoning.

Previous existing work on this matter are at least

the OPM model included in the METCE Schema
The INSPIRE OMOP Schema
the I-ADOPT Ontology from RDA

You may want to know that OPM is no longer being used in IWXXM (may be some other WMO schemas used to be using OPM but I am not sure about the status now). We are still using complex types describing tropical cyclones and volcanoes in METCE but their use can be superseded at any time.

The following slide is extracted from a presentation by Jeremy Tandy on behalf of TT-AvXML delivered back in 2013:

For those who have not seen the UML diagram of OPM this is it:

A quick check of the OPM and OMOP schemas suggested that they may have the same origin (and may have the same author too).

I think this is good in presenting a conceptual view to adequately describe an observation. In real-life situation, we could be using only a few of them at a time (e.g. we would like to indicate the reported wind data has undergone the "2-minute running mean" aggregation process). If one is doing it through OPM, there may be nesting of metadata as well as presence of unnecessary tags simply because the comprehensive model requires them for clarity. None of these add value to the representation. If we want to create compatible data types (e.g. JSON) the complexity of the XML instances will make things more complicated.

To elaborate a bit more why using an external schema could be an overkill, we may want to look at an IWXXM instance of version 1.1. At that time, a single OM_Observation is being used to represent the whole observation:

<iwxxm:METAR>
    <iwxxm:observation>
        <om:OM_Observation>
            <om:type/>
            <om:phenomenonTime/>
            <om:resultTime/>
            <om:procedure/>
            <om:observedProperty/>
            <om:featureOfInterest/>
            <om:result>
                <iwxxm:MeteorologicalAerodromeObservationRecord>
                    <iwxxm:airTemperature/>
                    <iwxxm:dewpointTemperature/>
                    <iwxxm:qnh/>
                    <iwxxm:surfaceWind/>
                    <iwxxm:visibility/>
                    <iwxxm:rvr/>
                    <iwxxm:presentWeather/>
                    <iwxxm:cloud/>
                </iwxxm:MeteorologicalAerodromeObservationRecord>
            </om:result>
        </om:OM_Observation>
    </iwxxm:observation>
    ...
</iwxxm:METAR>

With this representation, if a MET parameter has a property different from the others (e.g. RVRs needs to indicate a different "coverage" than the rest of the parameters) they will need to define their own properties. A more appropriate way of using OM_Observation may be:

<iwxxm:METAR>
    <iwxxm:observation>
        ...    <-- Time, coverage, etc. of the observation
        <om:OM_Observation>
            ...
            <om:result>
                <iwxxm:airTemperature/>
            </om:result>
        </om:OM_Observation>
        <om:OM_Observation>
            ...
            <om:result>
                <iwxxm:dewpointTemperature/>
            </om:result>
        </om:OM_Observation>
        ...    <-- OM_Observation of other MET parameters
    </iwxxm:observation>
    ...
</iwxxm:METAR>

But of course this will make the instance much larger and complex because of the complexity of O&M.

If one makes reference to an example of WAFS SIGWX F/C one may recognize that the latter is essentially the new IWXXM approach in which each OM_Observation fragment is being replaced by its simplified/more generic form (i.e. WxObject).

Ilkka is correct with regard to the tight integration of TSML with O&M. Following the same line of thought, if we want to use TSML, we may end up with (using the second example in the previous post):

<iwxxm:METAR>
    <iwxxm:observation>
        ...    <-- Time, coverage, etc. of the observation
        <om:OM_Observation>
            ...
            <om:result>
                <tsml:Collection>
                    <tsml:samplingFeatureMember/>
                    <tsml:observationMember>
                        <om:OM_Observation>
                            ...
                            <om:result>
                                <tsml:TimeseriesTVP/>    <-- Time series of the MET parameter
                            </om:result>
                        </om:OM_Observation>
                    </tsml:observationMember>
                </tsml:Collection>
            </om:result>
        </om:OM_Observation>
        ...
    </iwxxm:observation>
</iwxxm:METAR>

So we will be having nested OM_Observation. But is this what we want?

Going back to what we have right now with the new IWXXM approach:

<iwxxm:AerodromeMeteorologicalObservation ...>    <-- An extension to iwxxm:MeteorologicalFeatureCollection
    <gml:identifier .../>
    <iwxxm:boundingPeriod .../>
    <iwxxm:boundingVolume .../>
    <iwxxm:phenomenaList .../>
    <iwxxm:issueTime .../>
    <iwxxm:originatingCentre .../>
    <iwxxm:phenomenonCategory .../>
    <iwxxm:phenomenonTime .../>
    <iwxxm:feature>
        <iwxxm:MeteorologicalFeature .../>
            <gml:identifier .../>
            <iwxxm:issueTime .../>
            <iwxxm:originatingCentre>
                <aixm:Unit .../>
            </iwxxm:originatingCentre>
            <iwxxm:phenomenonCategory .../>
            <iwxxm:phenomenonTime .../>
            <iwxxm:phenomenon .../>
            <iwxxm:phenomenonGeometry .../>
            <iwxxm:phenomenonProperty>
                ...    <-- This is where we put the MET parameter and its metadata
            </iwxxm:phenomenonProperty>
        </iwxxm:MeteorologicalFeature>
    </iwxxm:feature>
    <iwxxm:feature .../>    <-- More features as necessary
    <iwxxm:otherFeatures .../>    <-- Other features defined during extension to iwxxm:MeteorologicalFeatureCollection
</iwxxm:AerodromeMeteorologicalObservation>

Each of iwxxm:MeteorologicalFeature is a standalone data block so theoretically it can be exchanged without losing integrity on what it is representing (e.g. An automatic weather station can continuous produce data blocks on wind, temperature, etc. measurements with iwxxm:MeteorologicalFeature, just like an IoT but with more comprehensive representation). Putting these blocks together in an iwxxm:MeteorologicalFeatureCollection (in fact its extension), taking the above case as an example, can create an aerodrome meteorological observation. I have to admit that this is a kind of "product" which some of those promoting SWIM would like to eliminate. A second thought, however, reinforce that this may still be required as in some situation we would like to convey a situation (or story) by putting selected data together. IWXXM VONA is a very good example.

A couple of things that need to be added here as context:

Firstly, the OGC O&M XML Implementation Standard and it's XML Schemas should probably not be used in any new application schemas, as the O&M Abstract Specification (ISO 19156:2011 / OGC 10-004r3) which they implement, has been withdrawn and revised (ISO 19156:2023) / deprecated (OGC 20-082r4). Also the name of the standard has been amended by including sampling, from Observations & Measurements (O&M) to Observations, Measurements and Samples (OMS).

Currently no revision of the O&M XML Implementation and the XML Schemas exist, and there is no active task for accomplishing that in the OGC OMS SWG. The main focus in OMS implementation work at OGC is in JSON, XML/GML is generally used little in new OGC standardisation, although it's acknowledged, that in the aviation domain XML based workflows are still used a lot.

I completely understand the idea of trying to avoid overly complex XML structure in IWXXM, and for this reason would not suggest implementing a full OMS Observation for aerodrome forecast or observation timeseries on the implementation level. If I understand the new draft IWXXM schema correctly, the iwxxm:MeteorologicalFeature is based in soft-typing: Based on the value of thephenomenon element (on of the codelist http://codes.wmo.int/49-2/MeteorologicalFeature values), only particular data structures are allowed under the phenomenonProperty elements. Thus particular realisations of iwxxm:MeteorologicalFeature (XML document elements rather than types) would realise the new aerodrome weather forecast concept. What is not fully clear to me at this point, is whether we need to extend the iwxxm:MeteorologicalFeatureCollection type for the aerodrome weather forecast, or would the iwxxm:MeteorologicalFeatureCollection suffice as-is as a container for one or more aerodrome weather forecast iwxxm:MeteorologicalFeature instances.

Considering the mapping of the properties of the OMS Observation concept to iwxxm:MeteorologicalFeature, many things already seem to be in place:

Screenshot 2024-02-16 at 9 47 13

phenomenonTime exists as an element with the same name
resultTime maps nicely to the issueTime element
validTime I cannot find currently, so this may need a new element
featureOfInterest is probably the vicinity of the aerodrome, and its geometry is likely to be described in the phenomenonGeometry element. Some kind of explicit target aerodrome identifier is still needed I think. Together these implement the featureOfInterest nicely
observingProcedure is implicit in the both aerodrome observations and forecasts (as described by the the WMO/ICAO standards), so it may not be needed
observedProperty is a key concept needed, and indeed the main topic of this very issue. I would guess that this needs to be described inside the phenomenonProperty somehow.
observer may be used to describe the used observation systems / sensors, issuing forecaster or the used numeric weather model. Not sure currently a which level of the IWXXM schema this would best map into
host may be used to describe the mounting platform for sensors creating the data, or some other useful grouping of Observers in cases where an Observer may be deployed on different Hosts at particular times. Currently not sure if this is needed in the aerodrome weather forecast.
relatedObservation could be implemented as relatedForecast etc. inside the phenomenonProperty, and be used for linking the previous and next forecast objects together, if necessary.
result could be implemented as the time-value-pair timeseries inside the phenomenonProperty using the TSML TimeseriesTVP structure, if we can cleanly break it off the O&M XML Schemas (would likely need to propose refactoring the TSML into more modular namespaces as part of the upcoming TSML revision)

What is not fully clear to me at this point, is whether we need to extend the iwxxm:MeteorologicalFeatureCollection type for the aerodrome weather forecast, or would the iwxxm:MeteorologicalFeatureCollection suffice as-is as a container for one or more aerodrome weather forecast iwxxm:MeteorologicalFeature instances.

I have no strong views on the direct use of iwxxm:MeteorologicalFeatureCollection, but noting that most "products" like VONA has additional information to be conveyed (e.g. Colour Code) outside of the iwxxm:MeteorologicalFeature blocks, it would be best to assume that this would be required.

team-sx / iwxxm-sx

Modelling observable properties in aerodrome weather forecasts #16