Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Definition

...

  • the current practice in many NOTAM Offices 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 ICAO principle for NOTAM of one subject and one condition per NOTAM. 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;
  • this scenario does not include the unidirectional closure of a route; such events will be dealt with as a separate scenario;
  • the encoding of this event requires the use of the "eASM" extension in order to know the BASELINE CDR status of the route segment concerned. (question) This will probably need to be replaced with the ADR extension, which declares exactly the same elements, but in the ADR namespace. It is the follow-up of the eASM extension.


Event data

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

...

Assumptions for baseline data

  • It is assumed that information about the route the route segments concerned already exists in the form of RouteSegment Baseline, which contain as a minimum the start association with the Route and the start/end Significant Points;If the Baseline data includes a schedule associated with the RouteAvailability, then this should not leave any gaps. If any gaps exist, then the status of the RouteAvailability at the levels/times concerned is considered "undefined". See the AIXM Temporality Concept (versions 1.0) sections 3.4 and 3.5;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].
  • It is assumed that all RouteSegment affected by the closure have a similar Baseline availability/RouteAvailability.status, e.g. OPEN, CDR1COND (question).

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=BOTH and at least one associated level.AirspaceLayer object shall be included in the Tempdelta 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 (see sections 3.4 and 3.5 of the Temporality document version 1.0), 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 and/or levels, the other times 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. 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 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.

...