Introduction

A basic knowledge of the AIXM key concepts, in particular of the Temporality model, is necessary in order to understand the Digital NOTAM coding examples discussed here. The XML sources are attached, together with the Visio file that contains the source of the diagrams used on the page.

A Digital NOTAM is a small data set, which provides in a coded format (AIXM 5.1 or later versions) information about operationally significant aeronautical information changes. Most of the time, these changes are of short duration and affect only a few of the properties of a feature (the operational status of a runway, the activation status of an airspace, the position of a runway threshold, etc.). It may also happen that the change is of longer duration or even permanent and it is also possible that the event in fact consists in the creation of a complete new feature (such as a temporary new obstacle).

Relation with the baseline data

Existing airspace becomes active - add TEMPDELTA TimeSliceNew obstacle (temporary or permanent) - create BASELINE TimeSlice


In most situations, the Digital NOTAM is in the form of a "temporary delta" which contains only the properties actually changed during the event. For example, if an Airspace is activated, the Digital NOTAM is encoded as a TEMPDELTA TimeSlice for the Airspace that contains an (activation.AirspaceActivation.)status='ACTIVE'.

The TEMPDELTA and the BASELINE records are closely related, they are facets of the same feature.


When there is no baseline feature, the Digital NOTAM itself is in the form of a new baseline.
It contains all the properties that are necessary to be know for that feature during its duration of validity.

The role of the Event feature

In addition to the aeronautical information features defined by the AIXM model (such as Airspace, VerticalStructure, Runway, etc.), the coding of a Digital NOTAM relies on an additional "Event" class. This is added through an Event extension of the AIXM 5.1(.1) XML schema.

The primary purpose of the Event class is:

  • to identify the kind of event, which then enables verifying the conformance with the event coding rules and also facilitates its processing;
  • where applicable, to explicitly associate all the TimeSlices of the different features that contribute to the digital encoding of one event;
  • to provide further information about the event, such as a textual description suitable for preflight briefing, advanced planning data, etc.
Airspace activation - TEMPDELTA association with the Event

New obstacle with runway declared distance changes - associated with same Event


In this case, a single Airspace TEMPDELTA is sufficient, therefore only its TEMPDELTA TimeSlice needs to be associated with the Event.


In this case, the temporary obstacle also impacts the values of the declared distances of a closely situated runway. Therefore, both the VerticalStructure BASELINE and the RunwayDirection TEMPDELTA are associated with the Event. The scenario coding rules are practically an aggregation of the coding rules of the two sub-scenarios (new obstacle and runway declared distance changes).

Basic elements of the XML coding

explain here the basic elements of the XML coding (collapsed elements), for the two threads

  • the Event
  • the TEMPDELTA timeslice with its type and its meaningful attributes.
  • the association with the event

More advanced elements of the XML encoding

For both threads

  • duration of validity
  • gml:identifier as the principal means to connect the TEMPDELTA with the BASELINE. Mention that the BASELINE is not part of the digital NOTAM encoding, but that it can be provided as a complement. More details in the next section.

Option - complementary baseline data

Except for the new obstacle, show here how additional baseline data could be provided in order to:

  • generate NOTAM text or text for pre-flight briefing
  • graphicaly represent the event
  • identify the feature affected in a system that does no use the UUID values as feature identifier