Definition

The temporary closure of one or more route portions (could be on different routes) due to a common cause, such as the activation of a temporary restricted area.

Notes:

  • The recognised practice in many NOFs is to issue a single NOTAM containing all route segment closures for a given period of time, such as the next 24 hours. This practice does not strictly comply with the general ICAO principle that single NOTAM shall address one subject and one condition only, however per OPADD exceptions may apply if the same subject/condition and timeframes apply. From a Digital NOTAM point of view it is recommended to group in a single Event (and issue one single NOTAM) for all the route segments closures that have a common cause, such as the activation of a given restricted area. In a digital environment, this would facilitate the automatic generation and processing of the Events. This might increase the number of NOTAM messages, but the advantage would be the clarity of the information. For example, this would also enable calculating more precise centre/radius of influence for these NOTAM;
  • this scenario does not include the permanent modification of the availability of a route; such events will be dealt with as a separate scenario;

Event data

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


EBNF Code 
input = "route availability" "route designator" "start point" "end point"  {"upper limit" "lower limit"} {"route designator" "start point" "end point" {"upper limit" "lower limit"}} \n "start time" "end time" ["schedule"] {"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

Description

AIXM mapping

route availability

An explicit indication that the route portion is closed.

RouteSegment/RouteAvailability.status with the list of values CodeRouteAvailabilityType

route designator

The published designator of the route concerned. This information, in combination with the start/end point is used to identify the route segments concerned.

RouteSegment.routeFormed

start point

The designator and eventually the type (in the case of a Navaid) of the significant point from where the route availability is affected. This information, in combination with the route designator and the end point is used to identify the route segments concerned.

RouteSegment.start/EnRouteSegmentPoint.pointChoice

end point

The designator and eventually the type (in the case of a Navaid) of the significant point until where the route availability is affected. This information, in combination with the route designator and the start point is used to identify the route segments concerned.

RouteSegment.end/EnRouteSegmentPoint.pointChoice

lower limit

The vertical level above which and including that level is affected by the closure.

RouteSegment/RouteAvailability/AirspaceLayer.lowerLimit and lowerLimitReference

upper limit

The vertical level below which and including that level is affected by the closure.

RouteSegment/RouteAvailability/AirspaceLayer.upperLimit and upperLimitReference

start time

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

RouteSegment/RouteSegmentTimeSlice/TimePeriod.beginPosition, Event/EventTimeSlice.validTime/timePosition and Event/EventTimeSlice.featureLifetime/beginPosition

end time

The effective date & time when the closure ends.

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

schedule

A schedule might be provided in case of the closure only being effective according to a regular timetable, within the period between the start time and the end time.

RouteSegment/RouteAvailability/Timesheet/… according to the rules for {{Schedules}}

note

A free text note that provides further details concerning the route closure, such as reason, alternate routes, etc.

Route/RouteAvailability.annotation with purpose=”REMARK”

Notes:

  • It is recommended that data input applications allow the operator to visualise graphically the route segments that are closed, in the context of the overall airspace structure.

Assumptions for baseline data

  • It is assumed that information about the route segments concerned already exists in the form of RouteSegment 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 - Route [RTE].
    (Proposal for encoding rule - It is assumed that RouteAvailability information exists in the BASELINE data covering as a minimum the direction, status and associated AirspaceLayers.
  • It is assumed that all RouteSegment affected by the closure have a similar availability/RouteAvailability.status, e.g. 'OPEN', 'COND'.

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.

Identifier

Data encoding rule

ER-01

The temporary closure of a route portion shall be encoded as:

  • a new Event with a BASELINE TimeSlice (encoding=”DIGITAL”, scenario=”RTE.CLS”, version=”2.0”), for which a PERMDELTA TimeSlice may also be provided; and
  • a new TEMPDELTA TimeSlice for each individual RouteSegment that is located on the route portion specified in the event data. It is recommended that data provider interfaces allow the encoding of the route portion closure at once and that the application takes care of converting the information into TimeSlices for the individual RouteSegment(s) concerned.

ER-02

The "route designator" shall be used in order to identify the route concerned, in order to instantiate the value of the RouteSegment.routeFormed property. If multiple routes exist with that designator, then the "start point" and "end point" information shall also be considered in order to identify the route concerned.

ER-03

A RouteAvailability object with status='CLSD', direction and at least one associated level.AirspaceLayer object shall be included in the TEMPDELTA TimeSlice for each RouteSegment concerned.

ER-04

If no lower limit is specified in the Event data input, then the associated level.AirspaceLayer should contain the values lowerLimit='FLOOR' (uom='OTHER').

ER-05

If no upper limit is specified in the Event data input, then the associated level.AirspaceLayer should contain the values lowerLimit="CEILING' (uom='OTHER').

ER-06

Note that in accordance with the AIXM Temporality Concept, the RouteAvailability associated with the TEMPDELTA completely replaces all the BASELINE RouteAvailability information, during the TEMPDELTA time of applicability. Therefore, if the temporary closure only concerns certain times, direction and/or levels, the other times, direction and/or levels, when the route eventually remains open/conditional, shall be explicitly included in the TEMPDELTA. The calculation of the necessary additional RouteAvailability elements to be included in the TEMPDELTA shall be automatically done by the applications implementing this specification.

All RouteAvailability 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." It is recommended that the input interface provides a "calendar/level" view of the route portion availability, enabling the operator to graphically check the status of the route availability 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.

Examples

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


  • No labels

3 Comments

  1. TOMAS CAP

    How is determined which route direction is "forward" and which is "backward"? As a former ATC and an active pilot, I am not aware that such distinction is made in the real world.

    Also, there are bidirectional and unidirectional routes, shouldn't this be distinguished somehow in the data? It feels strange to have a unidirectional route encoded e.g. as open in the forward direction and closed in the backward direction, because in reality there simply exists just one direction in which the route is valid.

  2. TOMAS CAP

    Additionally, is there any practical value in being able to close just a single route segment? I have never encountered that in practice, but I may be wrong.

    1. ALEKSANDER WOJTOWICZ

      I believe this would be an example:

      A1636/18 NOTAMN Q) KZMA/QANLC/IV/NBO/W/000/600/

      A) KZMA

      B) 1811080000

      C) PERM

      E) ROUTE Y587 IS CLSD BTN SKIPS AND HARDE.

      F) SFC

      G) FL600