As a general principle, the encoding of the Digital NOTAM shall occur first and the application that supports the encoding shall be able to automatically generate the corresponding text NOTAM message, which complies with the International Civil Aviation Organisation (ICAO) requirements. The NOTAM shall also comply with eventual regional guidelines, such as contained in the European Operating Procedures for AIS Dynamic Data (OPADD). The operator should not be allowed to modify the automatically generated NOTAM text, as this would introduce a risk for discrepancies between the digital data and the content of the NOTAM. However, some event scenarios may require operator input in order to decide for which airports a NOTAM needs to be generated. NOTAM specific values, such as series, number, country codes, etc. might need to be pre-configured in the application and eventually selected by the operator from a list of allowable values. In addition, developers of Digital NOTAM encoding application shall be aware that in particular situations the operator might need to adjust the content of the Q line (code, purpose, area of influence, etc.) in order to ensure a certain processing for that NOTAM for pre-flight purpose. Therefore, it might be necessary to allow modifications in the items A and Q of an automatically generated text NOTAM. Manual intervention in the other NOTAM items is strongly discouraged.

Digitisation level to match the intended use


Digital NOTAM will be provided as AIXM 5.1 data sets. The logical data model of AIXM defines features and properties that enable the provision as separate data items of numerical values, coded values and textual elements. Therefore, many of the information items contains in a NOTAM message can also be provided as individual data elements, such as: names/identifiers of the item affected, operational status, schedules, levels, etc.

When defining the Digital NOTAM encoding rules, it shall be kept in mind that the objective of the NOTAM digitisation is to enable the direct use of the data by software applications which support the ATM processes. Digitisation comes with a cost and there might be counter-productive to split into individual components information elements that are intended only for human consumption and that have to always be merged back before being used. Over-digitisation has to be avoided. For example, it is possible using the AIXM model to encode as individual data items phone numbers used for contacting an airport authority, in case of a prior permission requirement. However, it is highly unlikely that such data would be used by a computer to automatically dial the phone number. Therefore, in the current scenarios, such phone numbers are included in the free text Notes associated with the event.

As a general principle, the encoding rules have been developed in order to support the following range of applications:

AIXM 5.1 Baseline Data


The Digital NOTAM encoding is based on the general temporality rules of AIXM 5.1, as detailed in the Temporality Concept document. Thus, most Digital NOTAM encodings will produce TEMPDELTA TimeSlices for the affected AIXM features. For example, a temporary navaid out of service event will be encoded as a new TimeSlice with interpretation=TEMPDELTA for the corresponding Navaid and including a property operationalStatus=UNSERVICEABLE.

Therefore, a pre-requisite for any Digital NOTAM application is the availability of the corresponding static data, in the form of AIXM 5.1 BASELINE TimeSlices. In the example given above, it is required that the Navaid BASELINE TimeSlice is available both to the application that will generate the Digital NOTAM encoding and to the clients who will receive the AIXM 5.1 data.

The BASELINE data can exist locally or in a remote reference database. Some {{Event Scenarios}} explicitly indicate that certain data has to be taken from the corresponding feature BASELINE. Although it is theoretically possible to manually input such information, when needed, although such an approach would significantly increase the risk of data encoding errors and reduce the quality of the Digital NOTAM data. Therefore, it is considered a critical prerequisite that all BASELINE data necessary for the encoding of the Event Scenarios described in this Specification be available in AIXM 5.1 format.

Solution Completeness


In order to balance the implementation costs with the expected benefits, an incremental approach is likely to be followed by a large majority of the Digital NOTAM adopters. This raises a potential difficulty, as data users might need to consult two data sources:

To avoid this difficulty, the Digital NOTAM Specification needs to support from the beginning a complete solution. The NOTAMs that are not yet provided as fully structured digital encodings shall be also made available through the AIXM 5.1 data source. As a minimum, all text NOTAM shall be provided as "text notes" of the AIXM 5.1 feature concerned. This is supported by the {{AIXM Event Schema}}, in structured format.

Automatic text NOTAM generation


As a general principle, the encoding of the Digital NOTAM shall occur first and the application that supports the encoding shall be able to automatically generate the corresponding text NOTAM message, which complies with the International Civil Aviation Organisation (ICAO) requirements. The NOTAM shall also comply with eventual regional guidelines, such as contained in the European Operating Procedures for AIS Dynamic Data (OPADD).

The operator should not be allowed to modify the automatically generated NOTAM text, as this would introduce a risk for discrepancies between the digital data and the content of the NOTAM. However, some event scenarios may require operator input in order to decide for which airports a NOTAM needs to be generated. NOTAM specific values, such as series, number, country codes, etc. might need to be pre-configured in the application and eventually selected by the operator from a list of allowable values.

In addition, developers of Digital NOTAM encoding application shall be aware that in particular situations the operator might need to adjust the content of the Q line (code, purpose, area of influence, etc.) in order to ensure a certain processing for that NOTAM for pre-flight purpose. Therefore, it might be necessary to allow modifications in the items A and Q of an automatically generated text NOTAM. Manual intervention in the other NOTAM items is strongly discouraged.

NOTAM content versus digital data


As the information is becoming more complex, it becomes increasingly difficult to provide all the details in the NOTAM text. For example, providing the details of a new 'polygon' obstacle through NOTAM text would require a very long and very complex E fields. The NOTAM messages were not intended to contain such detailed geometrical information. The introduction of Digital NOTAMs will offer a solution to this problem. Only the information necessary for a human to identify the event will continue to be published in the NOTAM text. The very detailed geometrical information could in provided by the AIXM encoding only.

Even more, certain information updates could be made available just as digital data, if it is decided that a NOTAM does not need to be issued. For example, the GNSS outages could be encoded as digital events. However, if it is decided that they are not needed as NOTAM messages, they could either stay just as digital data or could be published for human consumption in another format, such as a table on a Web site, a map, etc.

Graphical presentation of Digital NOTAM


One of the major advantages of Digital NOTAM (as compared with the current text NOTAM) is that it enables the automatic creation of more precise graphical representations of the event. In the case of an ad-hoc restricted area, a navigation warning, a temporary obstacle, a taxiway closure, etc. the real location and geometry of the feature shall be presented graphically (right side of the following image) and not the radius of influence (left side of the following image, as provided by the Graphical visualisation of Digital NOTAM usually requires data which goes beyond strictly the features affected by the event. For example, a taxiway closure Digital NOTAM will provide the information about the closure status, eventual exceptions and schedules of the closure. In order to graphically display this closure on an airport map, the geometry of that taxiway is necessary. This might not be available in the message that contains the Event data and might require querying a source of reference database. A system providing Digital NOTAM data to consumer application might include the provision of ‘reference data’, to support applications such as graphical visualisation. Such data might be included directly in the Digital NOTAM messages (as an option) or be provided as a separate service.


Text NOTAM  (centre/radius)                                      Digital NOTAM (real geometry)