WIP

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 TimeSlice

New 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).

XML code - basic elements

The airspace activation will be used further in order to detail the AIXM XML coding of the Digital NOTAM.

The Airspace TEMPELTA and the new Event BASELINE

Legend

The overall container of the Digital NOTAM can be an AIXMBasicMessage, whcih is simply a collection of AIXM features.

This is the Airspace TEMPDELTA TimeSlice that contains the data about the activation. Note the following elements:

<gml:validTime> indicates the period when the TimeSlice is valid, which corresponds to the period when the Digital NOTAM is active

<aixm:interpretation> indicates the type of TimeSlice (TEMPDELTA in this case)

<aixm:activation> contains the actual data about the activation. In this view, this element is collapsed, note that there are in fact 22 hidden lines. This will be discussed in more detail further down.

Note

Note that the TEMPDELTA contains strictly the Airspace feature properties that have a different value during the event, as compared to the baseline situation. For example, the name, designator, etc. properties are not modified and thus not included in the TEMPDELTA.

This <event:theEvent> element associates the Airspace TEMPDELTA TimeSlice with the Event. The association is encoded as an "abstract reference" in this example (see the AIXM Feature Identification and Reference, chapter 3.4 for further details about this topic).

The Event element is also present in the Digital NOTAM encoding. Note that in this view this element also is collapsed, there are 49 hidden lines. The details are will be discussed further down.

The airspace activation data

Legend

The data about the airspace activation is provided with an <aixm:AirspaceActivation> element. The complete list of properties of this element is described in the AIXM UML model.

The type of activity (coded value "UAV" according to the AIXM predefined list of values for this property) and the "ACTIVE" status are explicitly provided in the Digital NOTAM coding.

The <aixm:levels> complex element is mandatory and indicates the vertical extent of the activation. The special coded values "FLOOR" and "CEILING" indicate that the airspace is active between its predefined lower and upper limits, as contained in the baseline data. The explicit values are not copied here.

A Digital NOTAM may still contain free text annotations, for information that is intended for human operators and for which there is no predefined AIXM property. This this case, the annotation provides details about the activity and who to contact for further information. Note that it is possible to further qualify a free text annotation, using purpose ('REMARK' in this case) and indicating that it concerns a specific property of the feature, In this example, the first sentence ("In between firing periods...") would better be encoded as a separate annotation, associated with the <aixm:activity> property.

The Event details	Legend

XML code - complementary 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

WIP