[2.0] [RDD.CHG] Runway declared distances - change (NOTAM)
Item A
The item A shall be generated according to the general production rules for item A using the Event.concernedAirportHeliport.
Q code
The following mapping shall be used:
Declared Distance | Corresponding Q code |
---|---|
Declared Distance Change | QMDCH |
Scope
Insert the value ‘A’.
Lower limit / Upper limit
Use “000/999”
Geographical reference
Insert the coordinate of the ARP (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.
item D shall be left empty. Note: If the declared distances are associated with a schedule, this information will be provided in item E, next to the group of declared distances concerned. This is a different approach from the current NOTAM practice where the NOTAM user is left to integrate the information that remains valid from the baseline (AIP) data with the values provided by NOTAM. In this scenario, the NOTAM generated automatically from the AIXM coded data includes all declared distances, not only the changed values.
Item E
The following pattern should be used for automatically generating the E field text from the AIXM data:
The item E production template is based on a number of loops that group and order the declared distances values, taking into consideration the current NOTAM practice:
- by RunwayDirection concerned (if applicable), then
- by "runway alignment point" (if applicable, for runways directions that have more than one 'START_RUN' point), then
- by similar schedule (if applicable)
- by "runway alignment point" (if applicable, for runways directions that have more than one 'START_RUN' point), then
The objective of this algorithm is to allow simple cases (one runway direction with one set of declared distances) to be output in the single line, for example "RWY 08 TORA 2800M TODA 2800M ASDA 2400M LDA 2300M", while more complex cases are also supported, but the text will inevitably be longer and more complex, such as in the following example:
"RWY 08L
LDA 2300M
TORA 2800M TODA 2800M ASDA 2400M
(TWY B) TORA 2000M TODA 2000M ASDA 1600M
RWY 26R
TORA 2800M TODA 2800M ASDA 2400M LDA 2400M (DAILY SR+30 SS-30)
TORA 2400M TODA 2400M ASDA 2400M LDA 2400M (DAILY SS-30 SR+30)"
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).
Reference | Data item (from coding scenario) | Rule | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
(1) | airport designator | If AHP.BL.locationIndicatorICAO is not null, then ignore this branch. | ||||||||||||||||||
(2) | Insert here the type of the airport decoded as follows
| |||||||||||||||||||
(3) | airport name | a. AHP.BL.name is not NIL, then insert it here. Otherwise: b. 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) | runway direction | If more than one RCP.TD is associated with the Event, then group them ascending by associated RDN.BL.designator value. If more than one RDN.BL group is detected (more than one runway direction is concerned), then use the branch (4) for each RCP.TD group and repeat (4) until all groups are processed. | ||||||||||||||||||
runway surface composition | Insert the word “unpaved” if RWY.BL.SurfaceCharacteristics.composition has one of the values 'CLAY', 'CORAL', 'EARTH', 'GRASS', 'GRAVEL', 'ICE', 'LATERITE', 'MACADAM', 'SAND', 'SNOW', 'WATER', 'OTHER'. Otherwise do not insert anything. | |||||||||||||||||||
(6) | Insert here the type of the Runway decoded as follows
| |||||||||||||||||||
(7) | centreline point designator | If in the RCP.TD group that is being processed (following rule #4) there is at maximum one RCP.TD.RDD descendant that has the same type value, then use the "single declared distances group". This is the typical case, when a single set of LDA, TORA, TODA, ASDA values are declared for a runway landing direction. Otherwise, if two or more RCP.TD.RDD descendants have identical type values, then use the "multiple declared distances group" branch. In this case, there are additional "take-off alignment points" along the runway centreline, each with distinct values for TORA, TODA, LDA. It is unlikely that several LDA values exist for the same runway landing direction. | ||||||||||||||||||
(8) | schedule | If there exist RCP.TD.RDD.declaredValue.RunwayDeclaredDistanceValue.timInterval.Timesheet (there is a schedule applicable to certain declared distances), then group the RCP.TD.RDD.declaredValue.RunwayDeclaredDistanceValue by identical timeInterval.Timesheet. Otherwise (no schedule), create just one group. | ||||||||||||||||||
(9) | For each group of RCP.TD.RDD.declaredValue.RunwayDeclaredDistanceValue selected in rule (#8), order them by parent RCP.TD.RDD.type (in the order 'TORA', 'TODA', 'ASDA', 'LDA', 'TODAH', 'RTOAH', 'LDAH', other values...) and process each of them as indicated in the template | |||||||||||||||||||
(10) | declared distance type | Insert here the declared distance type decoded as indicated below.
| ||||||||||||||||||
(11) | declared distance value | Insert here the declared distance value followed by its unit of measurement decoded according to the text NOTAM production rules for distances | ||||||||||||||||||
(12) | schedule | Process the Timesheet of the group according to the NOTAM production rules for Item D, E - Schedules | ||||||||||||||||||
(13) | declared distance type | Group the RCP.TD as follows:
Then, process each group according to the template and repeat (loop #13) until all groups are processed. | ||||||||||||||||||
(14) | If the RCP.BL.designator has a value, insert that value | |||||||||||||||||||
(15) | centreline point location note | If the RCP.TD.RDD has an annotation.Note with propertyName equal to 'location', then translate it into free text according to the rule for annotations decoding | ||||||||||||||||||
(16) | note | Annotations shall be translated into free text according to the rule for decoding annotations. |
Items F & G
Leave empty.
Event Update
The eventual update of this type of event shall be encoded following the general rules for Event updates 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 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 be used.
The following pattern should be used for automatically generating the E field text from the AIXM data:
Reference | Rule |
---|---|
(17) | 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”. |