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


The temporary closure of a runway. The closure can be total (any traffic is forbidden) or partial (with the exception of particular operations, flights or aircraft categories).


  • this scenario covers the closure of both complete runway (all landing directions) and single landing directions; For the temporary closure of a portion of a runway, refer to runway portion closure scenario RWE.CLS

  • this scenario does not cover the temporary addition of a supplementary restriction to the runway availability, such as "closed for aircraft heavier than...". This will be dealt with in a separate scenario;

  • this scenario does not cover the temporary change of the operational hours of a runway. Such situations will be covered by a different scenario;

  • this scenario does not cover the situation when the runway is operating normally, but subject to a reason for caution (such as "grass cutting in progress", etc.). Such situations will be covered in a separate scenario.

  • this scenario covers the closure of a runway with the exception of particular conditions. Therefore, situations like “closed to VFR operations” are a limitation and cannot be expressed with this scenario.

Event data

The following diagram identifies the information items that are usually provided by a data originator for this kind of event. Note that the "excepted operations" branch is optional, but can be used more than once. A similar situation occurs for the aircraft/flight branch, where the "other combination" can be used to return and insert additional aircraft/flight conditions.

input = "airport designator" ["airport name"] ("runway" | "runway direction") ["runway surface composition"] ["closure reason"]\n
{"excepted operation" ["PPR time" ["PPR details"]] [["aircraft"] ["flight"] {"other combination" ["aircraft"] ["flight"]}]} \n
"start time" "end time" [schedule] \n

The table below provides more details about each information item contained in the diagram. It also provides the mapping of each information item within the AIXM 5.1.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

airport designator

The published designator of the airport where the runway is located, used in combination with airport name, runway or landing direction in order to identify the runway concerned.


airport name

The published name of the airport where the runway is located, used in order to identify the runway concerned.


The published designator of the runway (or FATO) concerned. This information is used in combination with the airport designator/name in order to identify the runway (or FATO), for which it is assumed that both landing directions are concerned by the closure.


runway direction

The published designator of the runway direction concerned. This information is used in combination with the airport designator/name in order to identify the concerned landing direction.


runway surface composition

In cases where there are two runways with the same designator but different surfaces (for instance RWY 07/25, one concrete and the second gravel or grass), the surface composition needs to be provided.


closure reason

The reason for the runway closure.

RunwayDirection/ManoeuvringAreaAvailability.annotation with propertyName="operationalStatus" and purpose="REMARK". Note that the property "warning" of the ManoeuvringAreaAvailability class is not used here because it represents a reason for caution when allowed to operate on the runway, not a reason for a closure.

excepted operation

The description of one or more operations (such as "taxiing") that are exceptionally permitted on the runway during its closure.

RunwayDirection.availability/ManoeuvringAreaAvailability.usage/ManoeuvringAreaUsage.operation with the list of values CodeOperationManoeuvringAreaType

PPR time

The value (minutes, hours, days) of the prior permission request associated with the permitted operation.

RunwayDirection.availability/ManoeuvringAreaAvailability.usage/ManoeuvringAreaUsage.priorPermission with attribute uom specified.

PPR details

Additional information concerning the prior permission requirement.

RunwayDirection.availability/ManoeuvringAreaAvailability.usage/ManoeuvringAreaUsage.annotation with propertyName="priorPermission" and purpose="REMARK"


The description of one or more aircraft (such as "helicopter") types that are exceptionally permitted on the runway during it's closure.

RunwayDirection/ManoeuvringAreaAvailability/..Usage/..ConditionCombination/..AircraftCharacteristics. Note that only certain properties can be used in this scenario. See data validation rules for details.


The description of one or more type of flight categories (such as "emergency") that are exceptionally permitted on the runway during its closure.


other combination

Another combination of aircraft/flight characteristics that are excepted from the closure.

RunwayDirection/ManoeuvringAreaAvailability/..Usage/..ConditionCombination.logicalOperator with its value set to "OR".

start time

The effective date & time when the runway closure starts. This might be further detailed in a "schedule".

RunwayDirection/RunwayDirectionTimeSlice/TimePeriod.beginPosition, Event/EventTimeSlice.validTime/timePosition and Event/EventTimeSlice.featureLifetime/beginPosition

end time

The end date & time when the runway closure ends.

RunwayDirection/RunwayDirectionTimeSlice/TimePeriod.endPosition and Event/EventTimeSlice.featureLifetime/endPosition also applying the rules for {{Events with estimated end time}}


A schedule might be provided, in case the runway is effectively closed according to a regular timetable, within the overall closure period.

RunwayDirection/ManoeuvringAreaAvailability/Timesheet/...according to the rules for {{Schedules}}


A free text note that provides further details concerning the runway closure.

RunwayDirection/ManoeuvringAreaAvailability.annotation with purpose=”REMARK”

Assumptions for baseline data

It is assumed that following BASELINE TimeSlices covering the entire duration of the event exist and have been coded as specified in the Coding Guidelines for the (ICAO) AIP Data Set:

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. When this is the case, the number of the encoding rule is mentioned in the data validation rule.


Data encoding rule


The temporary closure of a runway shall be encoded as:

  • a new Event with a BASELINE Timeslice (encoding=”DIGITAL”, scenario=”RWY.CLS”, version=”2.0”) for which a PERMDELTA TimeSlice may also be provided and

  • a TimeSlice of type TEMPDELTA for each affected RunwayDirection feature, for which the "event:theEvent" property points to the Event instance created above. Note that in case a full runway is concerned by the closure, then a TEMPDELTA shall be encoded for each of its RunwayDirection features.


One ManoeuvringAreaAvailability element having operationalStatus=CLOSED shall be included in each RunwayDirection TEMPDELTA.


If the runway is "closed except for" specified operations, flight and/or aircraft categories, all specified excepted operations shall be encoded as RunwayDirection.availability/ManoeuvringAreaAvailability.usage/ManoeuvringAreaUsage child elements with:

  • either type=PERMIT, if there is no prior permission requirement;

  • or type=CONDITIONAL, if a prior permission requirement was specified. Note that this implies that a "closed" runway can still allow certain particular operations.


For every ManoeuvringAreaUsage encoded, the aixm:operation shall be specified.


If PPR time is specified, the uom attribute shall also be specified.


If a unique flight or aircraft are specified as being excepted, they shall be encoded as one ConditionCombination with logicalOperator="NONE".


Each pair of flight and aircraft conditions specified as being excepted shall be encoded as one ConditionCombination with logicalOperator="AND".


If the "other combination" branch is used, then a root ConditionCombination element shall be encoded having logicalOperator="OR" and each pair of flight/aircraft included as a subCondition (with logicalOperator="AND", see ER-07).


If the runway closure 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 ManoeuvringAreaAvailability of the RunwayDirection TEMPDELTA Timeslice. See the rules for Event Schedules.


In accordance with the AIXM Temporality Concept, the ManoeuvringAreaAvailability elements included in the TEMPDELTA completely replace all the BASELINE ManoeuvringAreaAvailability information, during the TEMPDELTA time of applicability. Therefore, if the closure only concerns certain times, then the other times, when the runway eventually remains subject to the availability conditions of the Baseline data, shall be explicitly included in the TEMPDELTA. The calculation of the necessary additional ManoeuvringAreaAvailability elements to be included in the TEMPDELTA shall be automatically done by the applications implementing this specification.

All ManoeuvringAreaAvailability 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" view of each runway direction closure, enabling the operator to graphically check the availability at different times, 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.


  • No labels