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 VST.BL indicates that the corresponding data item must be taken from the VerticalStructure BASELINE;
  • the abbreviation VST.TD indicates that the corresponding data item must be taken from the VerticalStructure TEMPDELTA that was created for the Event.
    • Important note: According to encoding rules for OBL.UNS, the TEMPDELTA might also include VerticalStructureLightingStatus 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 VerticalStructureLightingStatus 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!

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.

Several NOTAMs possible

Note that if an obstacle is located in the vicinity of one or more airports or affects more than one FIR, explicit associations between the Event and one or more AirportHeliport or Airspace may be coded. Then, there exist dedicated provision in the OPADD (v4.1, section 2.3.9.3) with regard to the NOTAM that need to be issued in order to ensure that the NOTAM appear correctly in the relevant en-route and airport Pre-Flight Information Bulletins (PIB). Further details are provided in the “several NOTAM possible” section.

The NOTAM production rules provided on this page, unless specified otherwise, are applicable to the “first NOTAM” and the NOTAM containing one or more FIR in Item A. 

Event.concernedAirspaceEvent.concernedAirportHeliportNOTAM to be generated
1..*None

produce a single NOTAM with scope E for all the FIR(s) identified

1..*1..*Produce a "first" NOTAM with scope E for all FIR and additional (scope A) NOTAM for each airport concerned. 
11..*Produce a "first" NOTAM with scope AE for the FIR and one of the aerodromes associated with the Event and additional (scope A) NOTAM for each additional airport.

Item A

The item A shall be generated according to the general production rules for item A using the concernedAirspace(s) or the concernedAirportHeliport, according to the rules specified in table above.

Item Q

Q code

Always use: QOLAS

Scope

Identify as described in Several NOTAM possible section above. 

Items B, C and D

Items B and C shall be decoded from the values of VST.TD.validTime following the common production rules.

If at least one VST.TD.VerticalStructureLightingStatus.timeInterval exists (the Event has an associated schedule), then the associated Timesheets(s) shall be decoded in item D according to the common NOTAM production rules for Item D, E - Schedules. Otherwise, item D shall be left empty.

Item E

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

EBNF code
template = "Obstacle lights" "VST.TD.VerticalStructureLightingStatus.status(1)" "on" ["VST.BL.group(2)"] ["VST.BL.part.mobile(3)"] "VST.BL.type(4)" \n
["(" "VST.BL.annotation(5)" ")"] ["located at" "VST.BL.annotation(6)"] ["identified as" "VST.BL.name(7)"] "VST.BL.part.horizontalProjection(8)" "." \n
 "elevation" "VST.BL.part.horizontalProjection.elevation(9)" ["(" "height" "VST.BL.verticalExtent(10)" ")"] "." \n
{"VST.TD.VerticalStructureLightingStatus.annotation(11)" "."}. 

Reference

Data item (from coding scenario)

Rule

(1)

lighting status

Insert here the operational status (VST.TD.VerticalStructureLightingStatus.status) of the obstacle/obstruction light decoded as follows

TD.statusText to be inserted
UNSERVICEABLE"unserviceable"

(2)

group

If BL.group='YES', then insert the words "group of". Otherwise leave empty.

(3)

mobile

If BL.VerticalStructurePart.mobile='YES', then insert the word "mobile". Otherwise leave empty.

(4)

obstacle type

Insert here the obstacle type in lower case and, if needed, taking into account the rules described in Appendix A (new) - Abbreviations and acronyms

If BL.type='OTHER', then insert the word "Obstacle".

If the BL.type='OTHER:...', then insert the text that follows after 'OTHER:'.

In all situations decode the BL.type by replacing the "_" characters with blank.

(5)

descriptionIf there exists a BL.VerticalStructure.annotation with propertyName='type' and purpose='DESCRIPTION', then insert the text of that note according to the decoding rules for Notes. Otherwise leave empty.

(6)

location remarks

If there exists a relevant  BL.VerticalStructure.annotation with propertyName='horizontalProjection_location' and purpose='REMARK', then insert the text of that note according to the decoding rules for Notes. Otherwise leave empty the whole branch (including "located at").

(7)

obstacle identification

Insert the content of BL.name, if available. Otherwise leave empty the whole branch.

(8)

position

The GML encoding of the horizontalProjection (gml:Point, gml:Curve or gml:Surface) shall be translated into human readable text, following the rules for encoding and decoding GML geometries.

Depending on the geometry type. the following text element shall be inserted before decoding the geometry:

  • for gml:Point insert "position:
  • for gml:Surface insert "within area:"
  • for gml:Curve insert "along a line:"

(9)

elevation

Insert the value of the aixm:ElevatedPoint.elevation or aixm:ElevatedCurve.elevation or aixm:ElevatedSurface.elevation that is associated with the BL.VerticalStructurePart, followed by the value of the respective uom attribute.

(10)

heightInsert the content of BL.VerticalStructurePart.verticalExtent and of its uom attribute, if available. Otherwise leave empty the whole branch.

(11)

note

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

Note: The objective is to fully automate 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

Leave 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 "AL", 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 = "Obstacle lights" "on" ["VST.BL.group(2)"] ["VST.BL.part.mobile(3)"] "VST.BL.type(4)" ["(" "VST.BL.annotation(5)" ")"] \n
["located at" "VST.BL.annotation(6)"] ["identified as" "VST.BL.name(7)"] "VST.BL.part.horizontalProjection(8)" ("returned to service" | " : New NOTAM to follow(12)").    

Reference

Rule

(12)

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