Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 22 Next »


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


  • the term "Published ATS Airspace" is used to encompass CTR, CTA, TMA or other airspaces of similar nature, such as TMZ and RMZ;
  • this scenario includes both the temporary activation and the temporary deactivation of pre-existing ATS Airspace;
  • this scenario includes the possibility to provide an activation schedule, but only "ACTIVE" times will be translated into NOTAM text;
  • this scenario does not include the temporary modification of the ATS Airspace classification;
  • this scenario does not include temporary modification of vertical limits of published ATS Airspace nor the activation beyond these vertical limits;
  • this scenario does not include temporary modification of horizontal limits of published ATS Airspace nor the activation beyond these horizontal limits;
  • this scenario does not include the permanent modification of activity status of published ATS Airspace;
  • this scenario does support the activation through a single NOTAM of the sectors/parts of one ATS airspace, if same conditions apply to all. Only the designator and the name can be different.

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”


  • It is recommended that data input applications allow the operator to visualise graphically the horizontal shape and the vertical extent of the ATS airspace activation, in the context of the overall airspace structure of the region. If a schedule is used, the graphical interface should also have a "time slider" that allows the operator to see when the airspace is actually active.

Assumptions for baseline data

  • It is assumed that information about the area already exists in the form of Airspace BASELINE TimeSlice(s) covering the complete period of validity of the event, coded as specified in the Coding Guidelines for the (ICAO) AIP Data Set.
  • If an area has sectors, it is assumed that each sector was encoded separately, as an airspace with its own designator, so that it can be activated individually. The collapsed area should not exist as a Baseline airspace, just the sectors. If the area becomes active, the digital data encoding should activate the individual sectors as part of one event;
  • It is assumed that Transponder Mandatory Zone(TMZ) and Radio Mandatory Zone (RMZ) have been encoded as Airspace features with: 
    • type=RAS
    • localType=OTHER:TMZ, respectively OTHER:RMZ.
  • (question) rule candidate for Coding Rules for Class of Airspace - If the Airspace concerned has BASELINE type=CLASS, then it is assumed that it contains a single AirspaceLayerClass child element. Otherwise, the algorithm for the automatic generation of the item E will not work properly. 

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):

  • No labels