Alignment of AMOIS AMFIS data model to ISO 19156:2023 Observations, measurements and samples (OMS) standard concepts - team-sx/iwxxm-sx GitHub Wiki

Alignment of IWXXM AMOIS/AMFIS data models with Observations, measurements and samples standard (OMS, ISO 19156:2023)

The MeteorologicalFeature class of IWXXM was originated as a simplified version the Observation concept of the Observations and measurements (O&M, ISO 19156:2011) standard. The ISO 19165 Observation and Sample data models have been considerably revised in 19156:2023 version. This page discusses if and how to apply the OMS standard concepts into the future version of IWXXM MeteorologicalFeature class and XML Schemas to best support the aerodrome meteorological observations and forecasts (AMOIS/AMFIS) data models.

Terminology: Observations and forecasts

The OMS standard uses the term Observation for any kinds of event (act) in which values are assigned to one or more of the Observed Properties of a particular feature-of-interest:

3.13 observation

act carried out by an observer to determine the value of an observable property of an object (feature-of-interest) by using a procedure, with the value provided as the result

In the context of meteorology this covers both observations and forecasts: For forecasts (predictions) the resultTime is in the future while for observations it's in the past. For weather forecasting the OMS Observer concept may be a human forecaster, a weather model or a combination, and the ObservingProcedure describes the method or procedure used for creating the weather forecast described by the Observation and particularly, it's result. The OMS standard does not include data models for describing the data stucture of the Observation result contents, as they vary greatly depending on the use case. The core concept classes of the OMS Concepuial Observation model are described in Figure 9.

The Conceptual Observation Schema of OMS

As the observation and forecast terms have a very specific semantic meanings in meteorology, it makes sense to distinguish them as separate classes in IWXXM even if both can be modeled using the same OMS Observation concept.

OMS adoption strategies

In the case of adopting the OMS in IWXXM it's not a priority to adhere to the exact terminology or stucture of the OMS model, as the primary intention is not to harmonize data exchange between aviation weather domain and other domains using the OMS concepts. The key is to leverage OMS concepts as appropriate to prevent re-inventing the wheel.

In the IWXXM use cases (related to exchanging weather information to allow estimation of occurred or predicted weather conditions relevant to aviation) some of the OMS concepts may not be relevant: typically the flight pilots trust the official aviation weather observations and forecasts to contain the best available weather information available implicitly, and thus do not need the consider the details on how particular weather observations or forecasts were made, which sensors or procedures were used. Thus it's not necessary to implement all the OMS concepts in IWXXM. On the other hand some of the OMS concepts, such as ObservableProperty (a weather parameter/property) is crucial to the IWXXM users.

Some OMS concepts can be simplified, or combined for IWXXM: For observations describing the wind conditions near a specific runway landing zone, the details of the sensor type used may not be relevant, and the location of the sensor in relation to the runway may not need to be modelled using a separate Deployment and Host (multi-sensor plaftorm etc.) concepts, but as a direct property of the Observer itself, as the deployment of the particular sensor device on a host at the time the Observation was made, is not likely to be interesting to the IWXXM users.

Distinction of description of the observing procedure from its implementation

In the revised OMS Observation model, the how (description of the method/procedure used) and the what (a particual device/instument/system implementing the procedure) are clearly separated: The implementation-agnostic procedure description, such as the temporal averaging used in a wind observation, is described by the ObservingProcedure while the identity and the implementation-specific properties of the particular device/system/authority used for creating the particular Observation is described by the Observer.

Modelling observations with more that one observed property

A notable restriction in the OMS model is the cardinality of the relation between the Observation and the ObservableProperty: Each Observation instance describes the value assignment act of exactly one of the ObservableProperties of the feature-of-interest. This means that a single Observation cannot contain results on more than one ObservableProperty. As practical example the capture of both wind speed and temperature results could not be described as a single OMS Observation, if these properties are modelled as distict ObservableProperties.

For practical and encoding efficiency reasons it shouls be possible to pack the many of the observation or forecast results for a place and time together. Despite the single-property-per-observation model of OMS this is still possible in two alternative ways:

  • define the ObservableProperty as the combination of more than one weather parameter/property, or
  • leverage the ObservationCollection concept (Figure 16).

The ObservationCollection of OMS

The ObservationCharacteristics can describe any the properties and/or associations of Observation, and in the context of ObservationCollections, it can be used to describe the common or aggregated aspects (memberCharacteristics) of Observation members contained in an ObservationCollection (Figure 10).

The ObservationCharacteristics of OMS

Note that the cardinality of the association from AbstractObservationCharacterics to ObservableProperty is 0..*, even if for the AbstractObservation class this is constrained to 1 by /req/obs-cpt/Observation/observedProperty-card. This means that in the member characteristics of an ObservationCollection may contain more that one ObservableProperty.

Related and derived Observations

The the OMS model the relations between individual Observation instances are modelled in a very generic way using the relatedObservation association with an optional context qualifier used for describing the relation semantics. In the context if IWXXM this association could be used for linking the weather conditions representing the entire aerodrome to the runway-specific observed or predicted conditions from which the aerodrome-specific conditions have been derived from using an aggragating/averaging ObservingProcedure. As before, the OMS model concept and assocition names can be adjusted to fit the weather information context better than the generic ones used in the OMS conceptual model if needed.

Relevance of OMS Sample schema for AMFIS/AMOIS

The OMS Conceptual Sample schema defines consepts for describing samples and sampling acts. In some use cases it's important to describe which kind of intermediate objects were used to sample the ultimate feature-of-interest for creating Observations, how and when those samples were taken and how those samples were prepared (processsed) between the sampling and observing (Figure 25).

The OMS Sample core concepts

A Sample can be used as the target of the proximateFeatureOfInterest association of Observation, while the ultimateFeatureOfInterest association is used for pointing to the object representing the real-world observed object. An example of this in the ground water domain is given in Figure 8, where the salinity of the fluid body of an aquifer is observed using the salinity on a particular well as a Sample.

Example: Use of Sample as proximate feature-of-interest

The intention in the example case is to describe which well was used for approximating the salinity of the entire aquifier. In case there were several Observations available for the user with the same aquifer as the ultimateFeatureOfInterest, but created using water from different wells as samples, the user could distinguish and choose the best observations for his/her use case based on the samples used. Note that the example used in the standard could have been made clearer by using "WellWaterSample" as the the class name instead of just "Well".

In the aerodrome weather observation context one could use the OMS Sample schema concepts to model how the weather condictions of small surroundings of individual sensors (Samples) at various locations within or in proximity of the aerodrome are being used to sample the aerodrome-specific, collective weather conditions (Observation), and how these samples were taken (SamplingProcedure). However, the viewpoint would in this case be the act of sampling, for example to determine the suitablility of the Observations based on the properties of the Samples used, rather than exposing the observed properties and created observation results. The linking Observation instances using the relatedObservation association as descrive above is likely to be more useful for IWXXM than the OMS Sample concepts.

IWXXM Meteorological Feature

To map the IWXXM Meteorological Feature concept with OMS some of the terms used in the Meteorological Feature UML model need to be clarified.

Meteorological Feature and Collection (IWXXM v2025-2 release)

The following class and attribute descriptions (notes, in cursive) have been copied from the IWXXM UML model:

  • MeteorologicalFeatureCollection: A collective for meteorological features
  • MeteorologicalFeature: Basic feature for describing a meteorological and related phenomenon
  • MeteorologicalFeature/phenomenon:MeteorologicalPhenomenon (codelist MeteorologicalFeature): The meteorological phenomenon mentioned in the report. Based on the codelist values (jetstream, cloud, duststorm, cold front, atmospherics, airframe icing, radiation etc.) This seems more like the feature type classification than the description of the observable phenomenon. Or perhaps we should have additional codelist values in here like AERODROME_RUNWAY_CONDITION, WIND_CONDITION, VISIBILITY, WEATHER_CONDITIONS etc. or just a single AERODROME_AVIATION_WEATHER_CONDITIONS?
  • MeteorologicalFeature/phenomenonCategory:WMOCategoryCode (codelist): The category of the meteorological phenomenon which is either weatherObservations or weatherForecasts
  • MeteorologicalFeature/phenomenonProperty:Any: Properties of the meteorological phenomenon. The actual featureType to be used in describing the properties shall be constraint by iwxxm:phenomenonCategory and iwxxm:phenomenon.

For the OMS AMFIS/AMOIS concept mapping the the following questions should be answered: Which IWXXM concept represents the following:

  • The aerodrome weather observation or forecast product or "report": a distict, identifiable information package containing a single aerodrome weather conditions observation or forecast for aviation? Is this the MeteorologicalFeature or the MeteorologicalFeatureCollection?
  • Description of the observable property (wind, temperature, runway state etc.)? Is this the "phenomenon" or described within the "phenomenon property"?
  • The feature-of-interest being observed or predicted (the vicinity of the aerodrome or the runway (or the runway surface) in the AMFIS/AMOIS case)? The phenomenonGeometry describes the location, but the identity information (aerodrome or runway name/identifier) is not clearly defined.
  • The result(s) of the observation(s) (observed values for the observable properties of the feature-of-interest)?

Suggestions for selecting OMS concepts to include

Introducing a selected set of OMS properties and terminology into IWXXM would have clear benefits in describing aerodrome weather information:

  • The Observed property is the particular aspect of the object (the Feature-of-interest) that is being captured or estimated by the Observation event. In the case of AMFIS/AMOIS these as aviation meteorological parameters such as wind speed and direction, temperature, visibility, the type of cloud cover etc.

  • The airport vicinity, runway approach air volume or touch-down zone can be modelled as Feature-of-interest: the spatial object that has one or more of the Observed properties

  • The actual numeric or category values of the observation or forecast are modelled as the Result of the Observation

The following OMS concepts already exist in IWXXM MeteorologicalFeatureCollection and MeteorologicalFeature:

  • The Phenomenon time. (OMS definition: The time for which the result applies to the characteristic of the FeatureOfInterest being observed.) In the AMFIS/AMOIS context this is the validity time of the forecast or the observation time of the observation.
  • The Result time (the issueTime in MeteorologicalFeatureCollection and MeteorologicalFeature). OMS definition: The instant of time when the result of the Observation became available.

The following OMS concepts may not be very important for the IWXXM aerodrome weather information users, as the trust in the authoritative data is implicit. The users do not need to make choices in selecting appropriate forecast or observation data based on how they were measured or predicted: they rely in the information systems used to convey the information as the authoritative, professional forecasters or realiable sensor systems have created it.

  • Observing producedure. OMS definition: The ObservingProcedure is used by the Observation to determine the value of the ObservableProperty provided by the result.
  • Observer. OMS definition: Identifiable entity that can generate observations pertaining to an observable property by implementing a procedure. Note 1 to entry: An observer is an instance of a sensor, instrument, implementation of an algorithm or a being such as a person.
  • Host. In OMS, a Host is temporal a grouping of related Observers. Examples include multi-sensor platform/system, or a survey campaign.

Introducing OMS concepts in the MeteorologicalFeature structure

There are two basic options where in the stucture of the MeteorologicalFeature the new OMS concepts can be introduced:

  1. As attributes or associations of the MeteorologicalFeature class itself, or
  2. within the object provided as the value of the phenomenonProperty attribute of the MeteorologicalFeature.

As the MeteorologicalFeature is intended to be very generic class in IWXXM, applicable to many kinds of meteorological or related phenomena, it may be risky to add new members there, if it's not clear that they would be widely useful outside AMFIS/AMOIS use cases. On the other hand having some of the OMS concepts described by the MeteorologicalFeature and others by the AMFIS/AMOIS specific phenomenonProperty objects adds to the semantic complexity of the model from the OMS perspective. The initial idea to balance between these two leans on the former point, and keeps the structure of the MeteorologicalFeature as-is, adding the featureOfInterest, observedProperty and result attributes to the AMFIS & AMOIS specific objects. To keep the verbosity the XML messsages in control, the OMS cardinalities have been relaxed so that there can be more than one featureOfInterest, observedProperty and result in a single IWXXM aerodrome forecast or observation object. Additionally, the definitions of the WMO/ICAO harmonized aviation weather observed properties have been collected into a separate (out-of-band) catalog file which of only referenced from most of the AMFIS/AMOIS report files.

Realistic examples of forecasts including the suggested OMS concepts have been prepared to illustrate the draft XML schemas: