Text NOTAM production rules

This section provides rules for the automated production of the text NOTAM message items, based on the AIXM 5.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 RSG.BL. indicates that the corresponding data item must be taken from the RouteSegment BASELINE, which is valid at the start time of the Event;
  • the abbreviation RSG.TD. indicates that the corresponding data item must be taken from the RouteSegment TEMPDELTA that was created for the Event;
    • Note: According to encoding rule ER-08, the TEMPDELTA might also include RouteAvailability elements that have been copied from the BASELINE data. For RTE.OPN scenario such static information shall be included in the text NOTAM generation algorithm to assure clarity with respect to the exact route segment status. 

Item A

The item A shall be generated according to the geographical location of the Airspace, following the ICAO DOC 8126 and the OPADD rules.

Item Q

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

Q code

The following mapping shall be used for the Q code:

RSG.BL.navigationType

Corresponding Q codes

RNAV or TACAN (for all RouteSegments concerned by the Event)

QANCA

otherwise

QARCA

Scope

Insert the value ‘E’.

Lower limit / Upper limit
  • the lowest value between all RSG.TD.RouteAvailability/AirspaceLayer.lowerLimit associated with the Event, formatted according to the common rules for {{Lower limit / Upper limit}} shall be used as Lower limit;
  • the highest value between all RSG.TD.RouteAvailability/AirspaceLayer.upperLimit associated with the Event, formatted according to the common rules for {{Lower limit / Upper limit}} shall be used as Upper limit.
Geographical reference

Calculate the centre and the radius (in NM) of a circle that encompasses all route segments concerned. Insert these values in the geographical reference item, 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 consists of 3 figures rounded up to the next higher whole Nautical Mile; e.g. 10.2NM shall be indicated as 011.

Items B, C and D

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

If at least one RSG.TD.RouteAvailability.timeInterval exists (the Event has an associated schedule), then select the RSG.TD.RouteAvailability.timeInterval(s) that have RSG.TD.RouteAvailability.status='OPEN' and represent them in item D according to the common NOTAM production rules for {{Item D, E - Schedules}}. Otherwise, item D shall be left empty.

Notes: 

  • only the opening schedules will be translated in the NOTAM Text. Eventual closure times described as schedules are considered as having been copied from the BASELINE, for completeness sake (see ER-08);
  • according to the input template, a single set of schedules is applicable to all RouteSegment openings associated with the Event. This will be ensured with a data verification rule. Therefore, it is sufficient to decode the schedules associated with one of the RSG.TD.RouteAvailability.timeInterval.


Item E

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

EBNF Code 
template = ["RSG.BL.RouteAvailability.status(1)"] "route segments open:" \n
"(2)" "/n" "RSG.BL.routeFormed(3)" "RSG.BL.start.pointChoice(4)" "-" "RSG.BL.end.pointChoice(5)" "open levels(6)" {"open levels(6)"}
{"(2)" "/n" "RSG.BL.routeFormed(3)" "RSG.BL.start.pointChoice(4)" "-" "RSG.BL.end.pointChoice(5)" "open levels(6)" {"open levels(6)"}} \n
{"(7)" "/n" "RSG.BL.routeFormed(3)" "RSG.BL.start.pointChoice(4)" "-" "RSG.BL.end.pointChoice(5)" "baseline levels(8)" {"baseline levels(8)"} "remain" "RSG.TD.RouteAvailability.status(9)"} \n
{"." "/n" "RSG.TD.RouteAvailability.annotation(10)"} "." .

Reference

Rule

(1)

If for each and everyone of the RSG.TD.RouteSegment that are concerned by the Event, during the times (considering an eventual schedule) and at the vertical levels covered by TEMPDELTA having RSG.TD.RouteAvailability=OPEN, the RSG.BL.RouteAvailability.status=COND and RSG.BL.RouteAvailability(extension).ADR:conditionalRouteType=CDR2, then insert the text "CDR2". Otherwise insert the text "ATS"

(2)

Identify the route portions concerned and repeat steps from 3 to 5 for each route portion. To identify the route portions, order the RouteSegments associated with the Event:

  • first sort by the designatorPrefix, designatorSecondLetter, designatorNumber, multipleIdentifier of the Route that is referred to by the RSG.BL.routeFormed property;
  • second order by identical values of RSG.BL.start/EnRouteSegmentPoint.pointChoice or RSG.BL.end/EnRouteSegmentPoint.pointChoice with another segment of the same Route. Attention that it is possible to have two distinct portions of the same route associated with the Event.

(3)

Insert here the concatenated values of the designatorPrefix, designatorSecondLetter, designatorNumber, multipleIdentifier of the Route portion identified.

(4)

Insert here the DesignatedPoint.designator or the Navaid.designator or the AirportHeliport.designator that was identified as start of a route portion at point (2) above. Note that this could be either the start or the end of a RouteSegment, as it is not guaranteed that the RouteSegments have been encoded in a regular P1-P2/P2-P3/P3-P4/... order. There could be situations where the segments have been encoded as P1-P2/P3-P2/P3-P4/etc.

(5)

Insert here the DesignatedPoint.designator or the Navaid.designator or the AirportHeliport.designator that was identified as end of a route portion at point (2) above. Note that this could be either the start or the end of a RouteSegment, as it is not guaranteed that the RouteSegments have been encoded in a regular P1-P2/P2-P3/P3-P4/... order. There could be situations where the segments have been encoded as P1-P2/P3-P2/P3-P4/etc.

(6)

If any RSG.TD.RouteAvailability/AirspaceLayer has either lowerLevel different from "FLOOR" or upperLevel different from "CEILING" (the segment is not completely open on the vertical), then insert here each pair lowerLevel - upperLevel of one RSG.TD.RouteAvailability.AirspaceLayer having status="OPEN" that exists identically on all RSG.TD.RouteAvailability with status "OPEN" of the RouteSegments of the affected route portion, decoded as indicated below: 


EBNF Code 
template_levels = {"RSG.TD.RouteAvailability.lowerLevel" to "RSG.TD.RouteAvailability.upperLevel" ";"}.


If the value "FLOOR" is used as RSG.TD.RouteAvailability/AirspaceLayer.lowerLimit, then use the RSG.BL.lowerLimit, RSG.BL.lowerLimit@uom and RSG.BL.lowerLimitReference instead. If the value "CEILING" is used as RSG.TD.RouteAvailability/AirspaceLayer.upperLimit, then use the RSG.BL.upperLimit, RSG.BL.upperLimit@uom and RSG.BL.upperLimitReference instead. In all situations the values shall be formatted according to the decoding ruled for vertical limits

(7)Follow this branch if there are RouteAvailability objects with a Note having purpose=REMARK and the text="Baseline data copy." for the duration of the event. Otherwise ignore this branch.
(8)

Insert here the AirspaceLayers of the RouteAvailability objects with a Note having purpose=REMARK and the text="Baseline data copy." decoded as in rule (6) regardless of the status. 

If the Event has an associated schedule, consider only the AirspaceLayers timeSheets corresponding to the opening schedule.

(9)Insert here the RouteAvailability.status for each of the levels and directions corresponding to the AirspaceLayers selected on (9).
(10)

Annotations shall be translated into free text according to the common rules for annotations decoding.

Note: The objective is to full automatic generation, without human intervention. However, the implementers of the specification might consider reducing the cost of a fully automated generation by allowing the operator to fine-tune the text in order to improve its readability (with the inherent risk for human error, when re-typing is allowed).

Items F & G

According to the OPADD rules, item F & G shall be left empty.

Event Update

The eventual update of this type of event shall be encoded following the general rules for [archived] Event update or cancellation, which provide instructions for all NOTAM fields, except for item E and the condition part of the Q code, in the case of a NOTAM C

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

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

EBNF Code 
template_cancel = "RSG.BL.RouteAvailability.status(1)" "route" ("opening cancelled." | " : New NOTAM to follow.(11)").

Reference

Rule

(11)

If the NOTAM will be followed by a new NOTAM concerning the same situation, then the operator shall have the possibility to choose the "New NOTAM to follow" 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”. 

  • No labels