Versions Compared

Key

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

Coding

Definition

The temporary closure of area(s) intended to accommodate aircraft for purposes of loading or unloading passengers, mail or cargo, fuelling, parking or maintenance. The closure can be total (any traffic is forbidden) or partial (with the exception of particular operations, flights or aircraft categories).

Notes:

  • this scenario includes the closure of one or more aprons (could be all the aprons at the airport);
  • this scenario includes closure of apron portions, defined by reference to intersection with other airport surfaces;
  • this scenario also includes closure of an apron except for flight and/or aircraft categories;
  • more than one apron and apron element can be included only if the closure conditions (closed, exceptions, parts) applies equally to all. Otherwise, separate NOTAM shall be issued;
  • this scenario does not cover the temporary addition of a supplementary restriction to the apron 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 an apron or apron element;
  • this scenario does not cover the situation when the apron and/or apron element is operating normally, but subject to a reason for caution (such as "grass cutting in progress", etc.). Such situations will be covered in a different 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 flight and/or aircraft categories branch is optional, but can be more than once.

Image Removed

Image Removed

Code Block
titleEBNF Code
collapsetrue
input = "airport designator" ["airport name"] ("apron name" ["closed_apron_portion_input"]) {("apron name" ["closed_apron_portion_input"])}\n
["closure reason"] {"except" ["PPR time" ["PPR details"]] [["aircraft"] ["flight"] {"other combination" ["aircraft"] ["flight"]}]} \n
"start time" "end time" [schedule] \n
{note}.

closed_apron_portion_input = ("between" ("taxiway designator" | "runway designator" | "apron designator" | "stand designator") "and" ("taxiway designator" | "runway designator" | "apron designator" | "stand designator") | "relative position to" ("taxiway designator" | "runway designator" | "apron designator" | "stand designator")) {"between" ("taxiway designator" | "runway designator" | "apron designator" | "stand designator") "and" ("taxiway designator" | "runway designator" | "apron designator" | "stand designator") | "relative position to" ("taxiway designator" | "runway designator" | "apron designator" | "stand designator")}.

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

Description

AIXM mapping

airport designator

The published designator of the airport where the apron is located, used in combination with other elements in order to identify the apron(s) and/or apron portion(s) concerned.

AirportHeliport.designator

airport name

The published name of the airport where the apron is located, used in order to identify the apron(s) and/or apron portion(s) concerned.

AirportHeliport.name

apron name

The published name of the apron concerned. This information is used in combination with the airport designator/name in order to identify the affected  apron(s) and/or apron portion(s)

Apron.name

closed apron portion input

The portion of a published apron, specified using intersection elements between that apron and other taxiways, runways, aprons or stands.

See note on closed apron portion input below.

ApronElement(s) identified as explained in the Data Encoding Rule ER-01. 

closure reason

The reason for the apron(s) and/or apron portion(s) closure.

Apron/ or ApronElement/ApronAreaAvailability.operationalStatus 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 apron, not a reason for a closure.

flight

The description of one or more type of flight categories (such as "emergency") that are exceptionally permitted on the apron(s) and/or apron portion(s) during closure.

Apron or ApronElement/ApronAreaAvailability/..Usage/../FlightCharacteristics

aircraft

The description of one or more aircraft (such as "helicopter") types that are exceptionally permitted on the apron(s) and/or apron portion(s) during its closure.

Apron/ or ApronElement/ApronAreaAvailability/..Usage/../AircraftCharacteristicsNote that only certain properties can be used in this scenario. See data validation rules for details.

other combination

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

Apron/ or ApronElement/ApronAreaAvailability/..Usage/ConditionCombination.logicalOperator with its value set to "OR".

PPR time

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

Apron/ or ApronElement/ApronAreaAvailability/..Usage.priorPermission with uom attribute

PPR details

Additional information concerning the prior permission requirement.

Apron/ or ApronElement/ApronAreaAvailability/..Usage.annotation with propertyName="priorPermission" and purpose="REMARK"

start time

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

Apron/ or ApronElement/ApronTimeSlice/TimePeriod.beginPosition, Event/EventTimeSlice.validTime/timePosition and Event/EventTimeSlice.featureLifetime/beginPosition

end time

The end date & time when the apron closure ends.

Apron/ or ApronElement/ApronTimeSlice/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 the apron is effectively closed according to a regular timetable, within the overall closure period.

Apron/ or ApronElement/ApronAreaAvailability/Timesheet/...according to the rules for {{Schedules}}

note

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

Apron/ or ApronElement/ManoeuvringAreaAvailability.annotation according to the rules for encoding annotations

Note on closed apron portion input:

  1. The application shall allow graphical display and selection of apron(s) and/or apron portion(s) to be closed;
  2. The HMI application should support the operator in identifying all relevant portions that are affected by the closure and have an impact on operations. Generally, the application shall support the operator in avoiding cul-de-sac/dead-end situations and warn on situations leading to nowhere. E.q. if a taxiway leads to a closed apron, the appropriate taxiway portion leading to the closed apron shall be closed as well. 

  3. If the operator selects a closure which extends over multiple ApronElements (e.g. t.b.a.), the application shall split the selection in individual TaxiwayElements and request operator confirmation for the selection. 

Assumptions for baseline data

It is assumed that Airport/Heliport BASELINE Timeslice covering the entire duration of the event exist and have been coded as specified in the Coding Guidelines for the (ICAO) AIP Data Set. In addition:

  • the information about the Apron already exists in the form of a Taxiway BASELINE TimeSlice, which contains as a minimum:
    1. a nameand
    2. an association with the AirportHeliport;

  • If taxiway portions are concerned, it is assumed that they are encoded in BASELINE TaxiwayElements as suggested in the following diagram:
    t.b.a. 
    Fig.1 - Encoding of TaxiwayElements
    It is assumed that each Taxiway and TaxiwayElements BASELINE have an annotation with purpose=“DESCRIPTION” and note describing their location as depicted below:defined by reference to intersection with other airport surfaces:
     
    Image Removed
    Fig. 2 - Encoding of TaxiwayElement description 
    E.g.  "between acft stand 1 and acft stand 5".
  • defined by a relative position to other airport surfaces,  e.g. “north of TWY F”, or
  • a combination between a and b above. 
  • It is assumed that the following principles have been followed for the encoding of BASELINE Apron.availability and ApronElement.availability data (as available in the BASELINE data):
    1. the operationalStatus has the value "NORMAL" (meaning that the facility operates with nominal parameters) for all Apron.availability and/or ApronElement.availability that are part of the BASELINE data;
    2. operations that are explicitly permitted have been encoded as availability.ApronAreaAvailability.usage.ApronAreaUsage with type=PERMIT or type=CONDITIONAL (in case a PPR is necessary);
    3. operations that are explicitly forbidden have been encoded as availability.ApronAreaAvailability.usage.ApronAreaUsage with type=FORBID;
    4. if the taxiway is exclusively reserved for certain operations, then the ApronAreaAvailability that describes this condition contains only ApronAreaUsage elements with type=RESERV;
    5. in case of conflicts:
      1. the usages of type FORBID take precedence over usages of type PERMIT or RESERVE;
      2. the usages of type PERMIT take precedence over the usages of type RESERVE;
  • 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.

    Identifier

    Data encoding rule

    ER-01

    The temporary closure of an apron or portion thereof shall be encoded as:

    • a new Event with a BASELINE TimeSlice (encoding=DIGITAL, scenario=APN.CLS, version=2.0), for which a PERMDELTA TimeSlice may also be provided; and
    • in case of complete apron closure:
      • a TEMPDELTA TimeSlice for each affected Apron feature, for which the "event:theEvent" property points to the Event instance created above;
    • in case of partial apron closure:
      • a TEMPDELTA TimeSlice for each affected ApronElement feature, for which the "event:theEvent" property points to the Event instance created above;
      • a TEMPDELTA TimeSlice for each affected Apron feature for which the above ApronElement describesPartOf (associatedApron), for which the "event:theEvent" property points to the Event instance created above;

    Identification of the ApronElements to be closed shall be done as follows:

    • The application shall support the operator in order to automatically select the ApronElements that are concerned, as much as possible with a graphical view. When no graphical view is available, the application would need to analyze the closed apron portion input provided by the operator in comparison with the baseline data descriptions.
    • If the operator specifies that the portion concerned is spread across multiple ApronElements, then the application shall automatically select the portions highlighted. 
    ER-02In case of complete apron closure, one ApronAreaAvailability element having operationalStatus=CLOSED shall be included in each Apron TEMPDELTA.ER-03In case of apron portion closure, one ApronAreaAvailability element having operationalStatus=CLOSED shall be included in each ApronElement TEMPDELTA selected to be closed.ER-04

    In case of apron portion closure, a TEMPDELTA TimeSlice for the affected Apron feature for which the ApronElement describesPartOf (associatedApron) shall be created and shall have Apron.availability/ApronAreaAvailability.operationalStatus=LIMITED.

    ER-05

    If the closure is "except for" flight and/or aircraft categories, all specified exceptions shall be encoded as ApronAreaUsage 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" apron can still allow certain particular operations.

    ER-06

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

    ER-07

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

    ER-08

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

    ER-09

    If the 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 ApronAreaAvailability of all affected Apron and/or ApronElement TEMPDELTA Timeslice(s). See the rules for Event Schedules. (e.g. If a ApronElement is closed based on a schedule, its associatedApron TEMPDELTA shall have the same associated schedule (question))

    ER-10

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

    All ApronAreaAvailability 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 apron element closure, enabling the operator to graphically check the availability at different times, such as in the example below:  

    Image Removed

    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.

    ER-11

    If there exists aircraft stands on the closed Apron and/or ApronElement and if the apron closure makes the aircraft stand unavailable, then a consequence STAND.CLS scenario shall also be encoded for the relevant AircraftStand feature and shall include a reference to the current event with role 'causeEvent'. (STAND.CLS under development)

    Decoding

    Text NOTAM production rules

    This section provides rules for the automated production of the text NOTAM message items, based on the AIXM 5.1.1 data encoding of the Event. Therefore, AIXM specific terms are used, such as names of features and properties, types of TimeSlices, etc:

    • the abbreviation APN.BL

    .
    •  indicates that the corresponding data item must be taken from the Apron

    BASELINE;
  • the abbreviation APE.BL. indicates that the corresponding data item must be taken from the ApronElement BASELINE;

  • the abbreviation AHP.BL. indicates that the corresponding data item must be taken from the AirportHeliport
    • BASELINE

     associated with the Apron that is associated with the ApronElement concerned
    • ;

    • the abbreviation APN.TD

    .
    •  indicates that the corresponding data item must be taken from the Apron TEMPDELTA that was created for the Event.

    • the abbreviation 

    APE
    • AHP.

    TD.
    • BL indicates that the corresponding data item must be taken from the 

    ApronElement TEMPDELTA that was created for the Event;
    • AirportHeliport BASELINE associated with the Apron concerned.

    In general, the ICAO DOC 8126 and the OPADD rules shall be followed. These have not been copied in this document in order to avoid duplication with those documents. Only instructions that are specific to the AIXM encoding of this event are stated here.


    Panel
    bgColor#f0f0f0
    titleOn this page

    Table of Contents
    printablefalse


    Item A

    The item A shall

    contain the AHP.BL.designator if AHP.BL.locationIndicatorICAO='YES'. Otherwise, the nationality letter(s) as defined in ICAO Doc 7910 followed by “XX” or “XXX”.

    Q code

    The following mapping shall be used:

    Availability.usage

    Corresponding Q codes

    none specified

    QMNLC

    there exist associated ApronAreaUsage.type PERMIT or CONDITIONAL

    QMNLT

    be generated according to the general production rules for item A using the Event.concernedAirportHeliport.

    Item Q

    Apply the common NOTAM production rules for item Q, complemented by the following specific rules for this particular scenario:

    Q code

    Insert QMNLC

    Scope

    Insert the value ‘A’.

    Lower limit / Upper limit

    Use “000/999”

    Geographical reference

    Insert the coordinate of the ARP (AHP.BL.ARP.ElevatedPoint) of the airport, formatted as follows:

    • the set of coordinates comprises 11 characters rounded up or down to the nearest minute; i.e. Latitude (N/S) in 5 characters; Longitude (E/W) in 6 characters;

    • the radius value is “005”.

    Items B, C and D

    Items B and C shall be decoded following the common production rules.

    If at least one APN.TD.availability.ApronAreaAvailability.timeInterval

    or APE.TD.availability.ApronAreaAvailability.timeInterval exists

    exists (i.e. the Event has an associated schedule), then all such Timesheet(s) shall be represented in item D according to the common NOTAM production rules for

    {{

    (Item D, E - Schedules

    }}

    ). Otherwise, item D shall be left empty.

    Item E

    If apron elements are used, the automatic generation of an easy human-readeable NOTAM text is practically impossible using just the AIXM encoding. Some pre-defined groups of ApronElements could be pre-defined in the application, which would then generate directly the desired text, such as "between A and C", "between A and D", etc. This is considered a limitation of this scenario - although the Digital NOTAM is accurate, the NOTAM text but cannot be automatically re-generated by the end user based on just the AIXM code.

    The following pattern should be used as a base for generating the E field text from the AIXM data:

    Image Removed

    Reference

    Image Added

    Code Block
    titleEBNF Code
    collapsetrue
    template = ["(1)" "AHP.BL.type (2)" ("AHP.BL.name (3a)" | "AHP.BL.ARP (3b)")] \n "Apron (4)" "APN.BL.name" ["(5)" ("," | "and")] {"APN.BL.name"  ["(5)" ("," | "and")]}
    \n "closed" [ "due to" "APN.TD.availability.annotation (6)"]\n
    {"\n" "APN.TD.availability.annotation(7)" "."} ["."].


    Reference

    Data item (from coding scenario)

    Rule

    (1)


    If AHP.BL.locationIndicatorICAO

    =YES

     is not null, then ignore this branch.

    (2)


    Insert here the type of the airport decoded as follows

    AHP.BL.type

    Text to be inserted in Item E

    AD or AH

    "AD"

    HP

    "Heliport"

    LS or OTHER

    "Landing site"


    (3)


    (a

    .

    ) If AHP.BL.name is not

    NIL

    null, then insert it here.

    Otherwise b.

    (b) Otherwise, insert here the text "located at" followed by the AHP.BL.ARP.ElevatedPoint decoded according to the text NOTAM production rules for aixm:Point

    .

    (4)
    Insert here the APN.annotation and/or APE.annotation note with purpose="DESCRIPTION" stored in the BASELINE data

    For the potential applications/implementations - the word "Apron" may appear twice depending on the coded APN.BL.name (e.g.
     “between Acft stand 1 and Acft stand 5”).

    If more than one ApronElement has a TEMPDELTA associated with the Event, then the application shall identify the connected elements and generate the text in a logical order (e.g. "between Acft stand 1 and Acft stand 10" could be generated from two ApronElements - one from Acft stand 1-5 and one from 5-10)

    (5)
    Apron MILITARY APRON or Apron APRON A1). Caution shall be exercised for NOTAM production to avoid possible duplications.

    (5)

    apron name

    If more than one

    apron and/or apron element

    Apron has a TEMPDELTA associated with the Event, then insert the designator of each additional

    apron and/or

    apron

    element,

    designator preceded by ",". Insert "and" before the last entry.

    (6)

    closure reason

    If there exists a APN.TD.availability.

    annotation or APE.TD.availability.annotation having

    ApronAreaAvailability.annotation having propertyName=

    "

    'operationalStatus

    "

    ' and purpose=

    "

    'REMARK

    "

    *Note: value is unlikely to be used in a NOTAM, its decoding is provided for completeness sake.

    AircraftCharacteristics.weight - insert the value followed by the value of the uom attribute. Prefix with the value of AircraftCharacteristics.weightInterpretation, decoded as indicated in the following table:

    AircraftCharacteristics.weightInterpretation

    Text to be inserted in Item E

    ABOVE

    "acft mass heavier than"

    AT_OR_ABOVE

    "acft mass equal to or heavier than"

    AT_OR_BELOW

    "acft mass equal to or lighter than"

    BELOW

    "acft mass lighter than"

    OTHER:MY_TEXT*

    "my text" (replace "_" with blanks)

    *Note: value is unlikely to be used in a NOTAM, its decoding is provided for completeness sake.

    (11)

    If TD.usage.selection.logicalOperator=OR (there are more than one flight/aircraft combinations that are excepted), then select and decode each FlightCharacteristics/AircraftCharacteristics consecutively.

    (12)

    Annotations of

    ', then translate it into free text according to the decoding rules for annotations.

    (7)

    If there exist one or more TD.availability.usage then decode them following this branch, in the following order of priorities:

    • TD.availability.usage that have operation="ALL"

    • TD.availability.usage that have type="PERMIT"

    • ... other situations ...

    • TD.availability.usage that have priorPermission which is not NIL shall be decoded last.

    (8)

    If TD.usage.priorPermission is not NIL, then insert here the decoding of the PPR information as detailed in the following diagram:

    Image Removed

    Reference

    Rule

    (8.1)

    Insert here the value of the priorPermission attribute followed by its unit of measurement decoded according to the {{text NOTAM production rules for duration}}

    (8.2)

    Decode here the annotation with propertyName="priorPermission" and purpose="REMARK", according to the decoding rules for annotations.

    (9)

    Decode here each FlightCharacteristics property that was specified, as detailed below. If more than one FlightCharacteristics property was used, insert blanks between consecutive properties.

    FlightCharacteristics.type*

    Text to be inserted in Item E

    OAT

    "Operational Air Traffic"

    GAT

    "General Air Traffic"

    ALL

    "Operational Air Traffic/General Air Traffic"

    OTHER:MY_TEXT

    "my text" (replace "_" with blanks)

    *Note: type is unlikely to be used in a NOTAM, its decoding is provided for completeness sake.

    FlightCharacteristics.rule

    Text to be inserted in Item E

    IFR

    "IFR"

    VFR

    "VFR"

    ALL*

    "IFR/VFR"

    OTHER:MY_TEXT

    "my text" (replace "_" with blanks)

    *Note: value is unlikely to be used in a NOTAM, its decoding is provided for completeness sake.

    FlightCharacteristics.status

    Text to be inserted

    HEAD

    "Head of State"

    STATE

    "State acft"

    HUM

    "HUM"

    HOSP

    "HOSP"

    SAR

    "SAR”

    EMERGENCY

    "EMERG"

    ALL

    "State acft/HUM/HOSP/SAR/EMERG"

    OTHER:MEDEVAC

    “MEDEVAC”

    OTHER:FIRE_FIGHTING

    “fire fighting”

    OTHER:MY_TEXT

    "my text" (replace "_" with blanks and convert to lowercase)

    FlightCharacteristics.military

    Text to be inserted in Item E

    MIL

    "MIL acft"

    CIVIL

    "civil acft"

    ALL*

    "civil/MIL acft"

    OTHER:MY_TEXT*

    "my text" (replace "_" with blanks)

    *Note: value is unlikely to be used in a NOTAM, its decoding is provided for completeness sake.

    FlightCharacteristics.origin

    Text to be inserted

    NTL

    "domestic"

    INTL

    "intl"

    HOME_BASED

    "home based"

    ALL*

    "domestic/intl"

    OTHER:MY_TEXT*

    "my text" (replace "_" with blanks)

    *Note: value is unlikely to be used in a NOTAM, its decoding is provided for completeness sake.

    FlightCharacteristics.purpose

    Text to be inserted

    SCHEDULED

    "scheduled"

    NON_SCHEDULED

    "not scheduled"

    PRIVATE*

    "private"

    AIR_TRAINING

    "training"

    AIR_WORK*

    "aerial work"

    PARTICIPANT

    "participating acft"

    ALL*

    "scheduled/not scheduled/private/training/aerial work/participating acft"

    OTHER:MY_TEXT*

    "my text" (replace "_" with blanks)

    *Note: value is unlikely to be used in a NOTAM, its decoding is provided for completeness sake.

    (10)

    Decode here each AircraftCharacteristics property that was specified, as detailed below. If more than one AircraftCharacteristics property was used, insert blanks between consecutive properties.

    AircraftCharacteristics.type

    Text to be inserted in Item E

    LANDPLANE

    "landplanes"

    SEAPLANE*

    "seaplanes"

    AMPHIBIAN

    "amphibians"

    HELICOPTER

    "hel"

    GYROCOPTER

    "gyrocopters"

    TILT_WING

    "tilt wing acft"

    STOL

    "short take-off and landing acft"

    GLIDER*

    "gliders"

    HANGGLIDER*

    "hang-gliders"

    PARAGLIDER*

    "paragliders"

    ULTRA_LIGHT*

    "ultra lights"

    BALLOON*

    "balloons"

    UAV*

    "unmanned acft”

    ALL*

    "all acft types"

    OTHER:MY_TEXT

    "my text" (replace "_" with blanks)

    *Note: value is unlikely to be used in a NOTAM, its decoding is provided for completeness sake.

    AircraftCharacteristics.engine

    Text to be inserted in Item E

    JET

    "jet acft"

    PISTON

    "piston acft"

    TURBOPROP

    "turboprop acft"

    ELECTRIC**

    “electric engine acft”

    ALL

    "all engine types"

    OTHER:MY_TEXT

    "my text" (replace "_" with blanks)

    **Note: new in AIXM 5.1.1.

    AircraftCharacteristics.wingSpan - insert the value followed by the value of the uom attribute. Prefix with the value of AircraftCharacteristics.wingSpanInterpretation, decoded as indicated in the following table:

    AircraftCharacteristics.wingSpanInterpretation

    Text to be inserted in Item E

    ABOVE

    "acft with wingspan more than"

    AT_OR_ABOVE

    "acft with wingspan equal to or more than"

    AT_OR_BELOW

    “acft with wingspan equal to or less than"

    BELOW

    "acft with wingspan less than"

    OTHER:MY_TEXT*

    "my text" (replace "_" with blanks)

    note

    Annotations of APN.TD.ApronAreaAvailability shall be translated into free text according to the decoding rules for annotations.


    Items F & G

    Leave empty.

    Event Update

    The eventual update of this type of event shall be encoded following the general rules for

    {{ updates }}

    , which provide instructions for all NOTAM fields, except for item E and the condition part of the Q code, in the case of a NOTAMC

    If a NOTAMC is produced, then the 4th and 5th letters (the "condition") of the Q code shall be "AK", except for the situation of a “new NOTAM to follow, in which case

    “XX”shall

    “XX” shall be used.

    .Image Removed

    The following pattern should be used for automatically generating the E field text from the AIXM data:

    Image Added

    Code Block
    titleEBNF Code
    collapsetrue
    template_cancel = ["(1)" "AHP.BL.type (2)" ("AHP.BL.name (3a)" | "AHP.BL.ARP (3b)")  ] "\n" \n 
    "Apron" "APN.BL.name" ["(4)" ("," | "and")] {"APN.BL.name" ["(4)" ("," | "and")]} ("resumed normal operations." | " : New NOTAM to follow.(8)").


    Reference

    Rule

    (

    13

    8)

    If the NOTAM will be followed by a new NOTAM concerning the same situation, then the operator shall have the possibility to

    specify

    choose the "New NOTAM to follow"

    and this text shall be appended at the end of item E of the NOTAM C

    branch.  This branch cannot be selected automatically because this information is only known by the operator.

    Note: in this case, the 4th and 5th letters of the Q code shall also be changed into “XX”