|Existing airspace becomes active - add TEMPDELTA TimeSlice||New obstacle (temporary or permanent) - create new feature and its first 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 existing 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.
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:
|Airspace activation - TEMPDELTA association with the Event|
New obstacle with runway declared distance changes - associated with same Event
In this example a single Airspace TEMPDELTA is sufficient, therefore only its TEMPDELTA TimeSlice needs to be associated with the Event.
In this example 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).
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
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.
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
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
The Event itself is also encoded as an AIXM feature, using the Event extension schema. it has all the characteristics of an AIXM feature such as a TimeSlice, a unique identifier, etc.
The value of the Event.gml:identifier was used in the Airspace shown above in order to associate the TEMPDELTA TimeSlice with the Event. See Legend item 3 above.
The duration of validity of the Event is equal to the duration of validity of the TEMPDELTA TimeSlice of the Airspace, because the Event exists only for as long as the temporary situation exists.
These properties allow identifying the type of event (SAA.ACT in this case) and the version of the Digital NOTAM specification that provides the coding rules applied (2.0 in this case). In addition, it allows giving a name to the event, which is interesting especially for events that are planned in advance and that are known to the operational people under that name.
This element contains an equivalent "NOTAM message" for the temporary Airspace activation event. This is expected to be generated automatically, applying the SAA.ACT "decoding" rules, as defined in the Digital NOTAM Specification. It can serve two main purpose:
The example discussed above is a minimal Digital NOTAM encoding in the sense that it provides strictly the data that belongs to the event - the Airspace TEMPDELTA and the Event BASELINE. The Airspace affected is identified by its gml:identifier (UUID value). An application that represents graphically the Airspace activation would have to be also provided with baseline data for the Airspace, including its geometry, name and other relevant characteristics. If necessary, the Digital NOTAM message may be enriched with some baseline information so that the graphical representation (for example) can be done using only the Digital NOTAM message, without the need for accessing a reference static data source. This can be done with a complete BASELINE TimeSlice for the Airspace or with a partial SNAPSHOT TimeSlice containing only the properties that are of interest (such as name, designator, horizontal and vertical limits). A SNAPSHOT could also be used in order to provide feature identifying properties, which can be used to identify the Airspace concerned by the activation when the UUID cannot be used.