Definition
The temporary displacement of a runway centreline point and the modification of its associated declared distances.
Notes:
- this scenario supports only the case when the declared distances associated with the point being displaced remain associated with the same RunwayCentrelinePoint after displacement.
- runway centreline points may be used as "landing threshold", "departure threshold" or both. How the point is used can be deduced from its role and/or from the declared distances associated with the point. The displacement of a runway centreline point that has dual role might concern only one of its roles. For example, the displacement of a threshold due to an obstacle in the approach area will typically concern only the landing operations, while the start of the take-off run might remain unchanged. This means that the runway centreline point is split into two separate points - a "displaced landing THR" with a new position and a "start of take-off run" that remains in the same place as before. This is not supported in the current scenario. When this situation occurs, it is assumed that the RunwayCentrelinePoint baseline data is first adapted as explained in the coding guidelines for Runway Declared Distances. Then, the THR displacement can be coded using this scenario.
- this scenario does not cover the situation when the runway centreline point is displaced according to a schedule as this is not supported by the current AIXM version. Only changes of declared distances according to a schedule are supported in AIXM;
- this scenario does not include the change of the declared distances from the other end of the runway. That information can be coded as a consequential RDD.CHG Event.
- including the consequential changes on the opposite runway direction would require adding another runway direction and possibly multiple runway centreline points, with their declared distances, in this scenario. The scenario rules and the NOTAM production rules risk to become very complex and error prone, both for implementation and for use. The same information can be provided with a related consequential Event.
Event data
The following diagram identifies the information items that are usually provided by a data originator for this kind of event.
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 runway is located, used in combination with other elements in order to identify the runway concerned. | AirportHeliport.designator |
airport name | The published name of the airport where the runway is located, used in combination with other elements in order to identify the runway concerned. | AirportHeliport.name |
runway direction | The published designator of the runway direction concerned. This information is used in combination with the airport designator/name in order to identify the runway landing direction and its centreline point. | RunwayDirection.designator and RunwayCentrelinePoint.onRunway |
runway surface composition | In cases where there are two runways with the same designator but different surfaces (for instance RWY 07/25, one concrete and the second gravel or grass), the surface composition needs to be provided in order to identify the runway concerned. | Runway.SurfaceCharacteristics.composition |
| centreline point designator | The designator of the RunwayCentrelinePoint, which is being displaced. The value is used in combination with the runway direction information in order to identify the RunwayCentrelinePoint concerned. | RunwayCentrelinePoint.designator |
| centreline point location note | Textual information (such as "intersection with TWY B") enabling to identify the RunwayCentrelinePoint which is being displaced. Note: The application should support the operator by allowing tp graphically display and select the runway centreline point concerned. Furthermore, the application should support the operator by displaying all baseline RunwayDeclaredDistance associated with the selected point. | RunwayCentrelinePoint.annotation |
| new position | The new lat/long position of the centreline point. | RunwayCentrelinePoint.location.ElevatedPoint.gml:pos |
displacement distance | The value of the centreline point displacement from the start towards the centre of the runway. Note: The displacement distance should always be provided from the start of the runway. If the baseline data contains a permanently displaced RunwayCentrelinePoint which needs to be temporarily moved, the displacement distance provided should be considered from the start of the runway and not from its (baseline) displaced location. | RunwayCentrelinePoint.annotation |
new elevation | The new elevation of the centreline point after displacement if applicable. | RunwayCentrelinePoint.location.ElevatedPoint.elevation |
| declared distance type | The type of declared distance. Note: the coding guidelines for the ICAO AIP Data Set - Declared Distances different declared distance types can be associated to different centerline points. The application shall support in the HMI the operator by providing the baseline values and asking the operator to indicate which and by what distance they have been modified. | RunwayCentrelinePoint/RunwayDeclaredDistance.type |
| declared distance value | The new value of the declared distance that is changed as result of the displacement. | RunwayCentrelinePoint/RunwayDeclaredDistance/RunwayDeclaredDistanceValue.distance |
| schedule | A schedule might be provided, in case the temporary declared distances are according to a regular timetable, within the overall period. | RunwayCentrelinePoint/RunwayDeclaredDistance/ RunwayDeclaredDistanceValue/Timesheet/... |
start time | The effective date & time when the runway centreline point displacement starts. | RunwayCentrelinePoint/ RunwayCentrelinePointTimeSlice/TimePeriod.beginPosition, Event/EventTimeSlice.validTime/ timePosition and Event/EventTimeSlice.featureLifetime/ beginPosition |
end time | The end date & time when the runway centreline point displacement ends. | RunwayCentrelinePoint/ RunwayCentrelinePointTimeSlice/ TimePeriod.endPosition and Event/EventTimeSlice.featureLifetime/endPosition also applying the rules for {{Events with estimated end time}} |
note | A free text note that provides further details concerning the runway displaced centreline point. | RunwayCentrelinePoint.annotation with purpose='REMARK' according to the rules for encoding annotations |
Assumptions for baseline data
It is assumed that information about the runway centreline point concerned already exists in the form of AirportHeliport, Runway, RunwayDirection and RunwayCentrelinePoint BASELINE TimeSlice(s) covering the complete period of validity of the event, for which the baseline availability may be coded as specified in the Coding Guidelines for the (ICAO) AIP Data Set.
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. To the maximum possible extent, the compliance with these encoding rules shall be verified with automatic data validation rules.
Identifier | Data encoding rule |
|---|---|
ER-01 | The temporary displacement of a runway centreline point shall be encoded as:
|
| ER-02 | If the baseline RunwayCentrelinePoint has role='THR', then the RunwayCentrelinePoint TEMPDELTA shall have role='DISTHR'. Note: If the baseline RunwayCentrelinePoint already has role='DISTHR', then no change is necessary in the TEMPDELTA. In this case, a displaced THR is displaced further. |
| ER-03 | If "centreline point location note" is provided, the operator shall have the possibility (at their own discretion) to save this information in the RunwayCentrelinePoint TEMPDELTA concerned as annotation.Note with purpose='REMARK' and propertyName='location'. Note: the textual information provided by the data originator that allows to identify the runway centreline point being displaced might also be relevant for the data users who need to understand which point is concerned by the temporary change. |
| ER-04 | If the "displacement distance" is provided, it shall be encoded in RunwayCentrelinePoint.annotation with propertyName='location', purpose='DESCRIPTION' and note="(value of the centreline point displacement) (value of the distance uom)". Note: AIXM 5.1.1 would allow the coding of the displacement distance using RunwayCentrelinePoint.associatedDeclareDistance/RunwayDeclaredDistance.type and RunwayCentrelinePoint.associatedDeclareDistance/RunwayDeclaredDistance.declaredValue/RunwayDeclaredDistanceValue.distance. For compatibility reasons with future AIXM versions, where the "DIST_THR" is being removed as a declared distance type, this option is not applied here. See [AIXM-546] Threshold displacement distance |
| ER-05 | In accordance with the AIXM Temporality Concept, the RunwayDeclaredDistance associated with the TEMPDELTA completely replaces all the BASELINE RunwayDeclaredDistance information, during the TEMPDELTA time of applicability. Therefore, if the change only concerns some declared distances for that point, then both the values that remain valid from the baseline data and the temporary values shall be encoded as associatedDeclaredDistance object(s) of the RunwayCentrelinePoint TEMPDELTA TimeSlice mentioned in ER-01. |
ER-06 | If the change of declared distances 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 RunwayDeclaredDistanceValue.timeInterval/Timesheet properties for each RunwayDeclaredDistanceValue. See the general rules for coding schedules. In accordance with the AIXM Temporality Concept, the RunwayDeclaredDistance associated with the TEMPDELTA completely replaces all the BASELINE RunwayDeclaredDistance information, during the TEMPDELTA time of applicability. Therefore, if the change only concerns certain times, the other times when the declared distances eventually remains with the same status as in the Baseline data, shall be explicitly included in the TEMPDELTA, as explained in the general rules for coding schedules. The calculation of the necessary additional RunwayDeclaredDistanceValue elements to be included in the TEMPDELTA shall be done, as much as possible, automatically by the applications implementing this specification. A graphical "calendar" view displaying the corresponding declared distance values and the applicability times should be provided in order to facilitate the correct and complete data coding. |
| ER-07 | The system shall automatically identify the FIR where the AirportHeliport is located. This shall be coded as corresponding concernedAirspace property in the Event |
| ER-08 | The AirportHeliport concerned by the closure shall also be coded as concernedAirportHeliport property in the Event. |
Examples
Following coding examples can be found on GitHub (links attached):