...
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;
- Important note: According to encoding rule ER-06, the TEMPDELTA might also include RouteAvailability elements that have been copied from the BASELINE data for compliance with the AIXM Temporality rules. The current practice is to not include such static information in the NOTAM text. Therefore, all RouteAvailability that have an associated annotation with purpose=REMARK and the text="Baseline data copy. Not included in the NOTAM text generation" shall be excepted from the text NOTAM generation algorithm!
...
The following mapping shall be used for the Q code:
BL.navigationType | Corresponding Q codes |
|---|---|
RNAV or TACAN (for all RouteSegments concerned by the Event) | QANLC |
otherwise | QARLC |
...
The following pattern should be used for automatically generating the E field text from the AIXM data:
Reference | Rule |
|---|---|
(1) | If for each and everyone of the TD.RouteSegment that are concerned by the Event, during the times (considering an eventual schedule) and at the vertical levels covered by TD having TD.RouteAvailability=CLSD the BL.RouteAvailability.status=COND and BL.RouteAvailability(extension).eASM:conditionalRouteType=CDR1, then insert the text "CDR1". 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:
|
(3) | Insert here the concatenated values of the designatorPrefix, designatorSecondLetter, designatorNumber, multipleIdentifier of the Route portion identified above. |
(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 TD.RouteAvailability/AirspaceLayer has either lowerLevel different from "FLOOR" or upperLevel different from "CEILING" (the segment is not completely closed on the vertical), then insert here each pair lowerLevel - upperLevel of one TD.RouteAvailability.AirspaceLayer having status="CLSD" that exists identically on all TD.RouteAvailability with status "CLSD" of the RouteSegments of the affected route portion, decoded as indicated below:
If the value "FLOOR" is used as TD.RouteAvailability/AirspaceLayer.lowerLimit, then use the BL.lowerLimit, BL.lowerLimit@uom and BL.lowerLimitReference instead. If the value "CEILING" is used as TD.RouteAvailability/AirspaceLayer.upperLimit, then use the BL.upperLimit, BL.upperLimit@uom and BL.upperLimitReference instead. In all situations the values shall be formatted according to the decoding ruled for vertical limits. |
(7) | Annotations shall be translated into free text according to the common rules for annotations decoding. |
...