The activation or deactivation of published (pre-existing) CTR, CTA, TMA or similar airspaces.


Event data

The following diagram identifies the information items that are usually provided by a data originator for this kind of event.

input = "type" "name" ["designator"]  {"name" ["designator"]} "activation status" {"concerned airport/heliport"} \n 
"start time" "end time" ["schedule"] \n
{"note"} .

The table below provides more details about each information item contained in the diagram. It also provided the mapping of each information item within the AIXM 5.1 structure. The name of the variable (first column) is recommended for use as label of the data field in human-machine interfaces (HMI).

Data item


AIXM mapping


The type of airspace concerned. Typical examples are CTR and TMA.

Airspace.type with this list of values CodeAirspaceType. Not to be encoded, just used to identify the airspace concerned.


The published name of the area. Not to be encoded, just used to identify the airspace concerned.


The published designator of the airspace concerned. If not provided, then the airspace is identified by its name.

Airspace.designator. Not to be encoded, just used to identify the airspace concerned.

activation status

The activation/de-activation status.

Airspace/AirspaceActivation.status with the list of values CodeStatusAirspaceType

concerned airport/heliport

The indication of AirportHeliport feature(s) impacted by the airspace activation. 

Note: It may be the case that the FIR(s) and eventually the airport(s) for which a NOTAM is required to be issued have already been predefined in the application. Therefore the Digital NOTAM data provider interface might offer suggestions with respect to the list of airports for which a NOTAM is required, but the operator is responsible to take a final decision.

Event.concernedAirportHeliport href

start time

The effective date & time when the activation/de-activation starts. This might be further detailed in a "schedule".

Airspace/AirspaceTimeSlice/TimePeriod.beginPosition, Event/EventTimeSlice.validTime/timePosition and Event/EventTimeSlice.featureLifetime/beginPosition

end time

The end date & time when the activation/de-activation ends. It might be an estimated value, if the exact end of activation is unknown.

Airspace/AirspaceTimeSlice/TimePeriod.endPosition and Event/EventTimeSlice.featureLifetime/endPosition also applying the rules for {{Events with estimated termination}}


A schedule might be provided, in case the area is only active according to a regular timetable, within the period between the start time and the end time.

Airspace/AirspaceActivation/Timesheet/... according to the rules for {{Schedules}}


A free text note that provides further instructions concerning the area activation, such as the authority to be contacted for further information, the possibility of crossing at ATC discretion, etc.

Airspace/AirspaceActivation.annotation with purpose=”REMARK”


Assumptions for baseline data

Data encoding rules

The data encoding rules provided in this section shall be followed in order to ensure the harmonisation of the digital encodings provided by different sources. The compliance with some of these encoding rules can be checked with automatic data validation rules.


Data encoding rule


The activation of an airspace shall be encoded as:

  • a new Event with a BASELINE TimeSlice (encoding=”DIGITAL”, scenario=”ATSA.ACT”, version=”2.0”), for which a PERMDELTA TimeSlice may also be provided; and
  • a TimeSlice of type TEMPDELTA for the corresponding Airspace feature(s), for which the "event:theEvent" property points to the Event instance created above;


The Airspace TEMPDELTA should use the values "FLOOR, uom=OTHER" for lowerLimit and "CEILING, uom=OTHER" for the upperLimit of the AirspaceLayer property associated with the AirspaceActivation. 


If the area activation/de-activation is limited to a discrete schedule within the overall time period between the "start time" and the "end time", then this shall be encoded using as many as necessary timeInterval/Timesheet properties for the AirspaceActivation of the Airspace TEMPDELTA Timeslice. See the rules for {{Schedules}}. It is recommended that the HMI of a data provider application allows to provide a schedule only in relation with active times, because only these will be translated into NOTAM text.


In accordance with the AIXM Temporality Concept, the AirspaceActivation associated with the TEMPDELTA completely replaces all the BASELINE AirspaceActivation information, during the TEMPDELTA time of applicability. Therefore, if the activation/deactivation only concerns certain times, then the other times (when the airspace eventually remains with the same status as in the Baseline data) shall be explicitly included in the TEMPDELTA. The calculation of the necessary additional AirspaceActivation elements to be included in the TEMPDELTA shall be automatically done by the applications implementing this specification. All AirspaceActivation elements that are copied from the BASELINE data for completeness sake shall get an associated Note with purpose=REMARK and the text="Baseline data copy. Not included in the NOTAM text generation". This is based on the current NOTAM practice which consists of including in the NOTAM only the changed information and not explicitly including the static data that remains valid during the NOTAM applicability. It is recommended that the input interface provides a "calendar/level" view of the airspace activity, enabling the operator to graphically check the status of the airspace at different times and levels, such as in the example below:

In the calendar view, the Baseline information that remains valid during the Event validity time shall be visibly identified from the information that is specific to the Event, for example by using a different colour fill pattern.


The Event BASELINE shall contain an association concernedAirportHeliport with reference (href) to each of the identified AirportHeliport feature.


Following coding examples can be found on GitHub (links attached):