Definition
The establishment of a new temporary or permanent obstacle.
Notes:
This scenario includes the possibility to provide obstacle type point, line or polygon, but it does not support obstacles composed of multiple parts;
This scenario includes encoding of new mobile obstacles. However, the scenario does not cover the temporarily modification of the elevation of an obstacle, such as an arresting device that is up.
This scenario includes groups of obstacles with similar height located in close proximity to one another;
This scenario includes both aerodrome (TOD Area 2, 3 and 4) and territory of State (TOD Area 1) obstacles, although the latter is rarely occurring in NOTAM messages;
This scenario does not support encoding of obstacle with variable elevation; only a single elevation value can be provided.
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 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 |
|---|---|---|
group | An indication whether Digital NOTAM refers to a group of obstacles with similar height located in close proximity to one another. | VerticalStructure.group with this list of values CodeYesNoType |
mobile | An indication whether the obstacle has no fixed position. | VerticalStructure/VerticalStructurePart.mobile with this list of values CodeYesNoType |
obstacle type | A type of vertical structure | VerticalStructure.type and VerticalStructure/VerticalStructurePart.type with this list of values CodeVerticalStructureType |
description | A textual description of the obstacle, such as the number of similar items for a group, etc. | VerticalStructure.annotation with propertyName="type" and purpose="DESCRIPTION" |
location remarks | A named geographical location where or close to which the obstacle is located (especially for Area 1 obstacles). Note: the information on relative position of an obstacle may serve as supplementary information for obstacles located closer to the airport. For such purposes a free text description of the obstacle position (distance, direction) in relation to relevant airport elements, such as a runway threshold or the control tower should be provided. | VerticalStructure/VerticalStructurePart.annotation with propertyName='horizontalProjection_location' and purpose="REMARK" AIXM 5.1 workaround In AIXM 5.1, the _ character is not allowed in the pattern for propertyName, therefore, when using AIXM 5.1, the propertyName should be left empty. |
obstacle identification | An alphanumerical designator by which the obstacle is identified in the national obstacle database | VerticalStructure.name |
point | A tuple of latitude, longitude values and horizontal reference datum associated with the obstacle position. | VerticalStructure/VerticalStructurePart/ElevatedPoint according to the rules for encoding Geometrical and geographical data |
line | Tuples of latitude/longitude values along a line, including the horizontal reference datum associated with the obstacle extent and location | VerticalStructure/VerticalStructurePart/ElevatedCurve according to the rules for encoding Geometrical and geographical data |
polygon | Tuples of latitude/longitude values defining a polygon, including the horizontal reference datum associated with the obstacle extent and location or circle type of polygon in which all the points are located at constant geodesic distance from the centre of the circle | VerticalStructure/VerticalStructurePart/ElevatedSurface according to the rules for encoding Geometrical and geographical data |
elevation | The elevation (distance from Mean See Level) at the top of the obstacle. | VerticalStructure/VerticalStructurePart/ElevatedPoint or ElevatedSurface or ElevatedCurve.elevation including its unit of measure |
height | The distance between the uppermost and the lowermost parts of the obstacle. | VerticalStructure/VerticalStructurePart.verticalExtent |
lighting | An indication if the obstacle is lighted. | VerticalStructure.lighted with the following list of values CodeYesNoType |
marking description | Includes the description of visual markers (other than lights) that are installed on the obstacle, such as painting, flags, signs, etc. | VerticalStructure.annotation with propertyName='markingICAOStandard' and purpose='REMARK' |
start time | The effective date & time when the obstacle starts to exist. This might be further detailed in a "schedule". | VerticalStructure/VerticalStructureTimeSlice.featureLifetime/beginPosition, VerticalStructure/VerticalStructureTimeSlice/validTime/beginPosition, Event/EventTimeSlice.validTime/beginPosition and Event/EventTimeSlice.featureLifetime/beginPosition |
end time | The end date & time when the obstacle ceases to exist. It may also be indeterminate for a permanent obstacle. | VerticalStructure/VerticalStructureTimeSlice.featureLifetime/endPosition, VerticalStructure/VerticalStructureTimeSlice/ validTime/endPosition, Event/EventTimeSlice.validTime/endPosition and Event/EventTimeSlice.featureLifetime/endPosition also applying the rules for Events with estimated end time |
schedule | A schedule might be provided, in case the obstacle is only active according to a regular timetable, within the period between the start of life and the end of life. | VerticalStructure/VerticalStructurePart/Timesheet/... according to the rules for {{Schedules}} |
note | A free text note that provides further details about the obstacle, such as the reason for which it exists, reduced height at certain times, etc. | VerticalStructure.annotation with purpose='”REMARK' |
| affected aerodrome | A reference (name, designator) to one or more airports/heliports for which the establishment of the obstacle has an operational relevance and needs to be notified to the users thereof. Note: Attention: the data provider interface shall warn the operator to check if the information received from the originator is consistent with the airport(s) for which the obstacle is situated in the area of interest for obstacles, as automatically calculated by the application using the obstacle positional data (lat/long). | Event.concernedAirportHeliport |
| affected FIR | A reference (type, designator) to one or more airspace of type FIR, for which the establishment of the obstacle has an operational relevance and needs to be notified. Note: the FIR(s) within which the obstacle is physically situated do not need to be provided by the data originator. They will be automatically identified by the application that enables the coding of the Event. If an additional FIR is specified by the originator, the application should check the plausibility of this data based on the FIR boundary. | Event.concernedAirspace |
Notes:
It is recommended that data input applications allow the operator to visualise graphically the position and extent of the obstacle, overlaid on an airport map and/or on an FIR map, as appropriate. If a schedule is used, the graphical interface should also have a "time slider" that allows the operator to see when the obstacle is actually effective.
Assumptions for baseline data
No specific baseline data assumptions are made.
Remark (to be deleted later): Initially it has been assumed that an “area of interest for obstacles” exists in the form of ObstacleArea BASELINE TimeSlice(s) covering the complete period of validity of the event, coded as specified in the Coding Guidelines for the (ICAO) Obstacle Data Sets. This approach has been changed because not all AirportHeliports have ObstacleAreas coded and the new Event schema brings the possibility to code an "associationEvent". The NOTAM operator will have to explicitly select the AirportHeliport that need to be considered in the vicinity and they can be coded in relation with the Event. This would allow to explicitly code the 'vicinity' situation and can be used as 'decoding' criteria for deciding when several NOTAM are necessary - Ref. FG Decision on Webex 19 June, comment on Several NOTAM possible
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. The compliance with some of these encoding rules can be checked with automatic data validation rules.
Identifier | Data encoding rule |
|---|---|
ER-01 | The new obstacle shall be encoded as:
|
ER-02 | If the obstacle can change position or has mobile parts (such as a crane arm), then the overall area in which the obstacle or any part of it can be located shall be provided as a polygonal extent and the "mobile" property of the VerticalStructure shall get the value "YES". |
ER-03 | The type of the obstacle shall be encoded (same value) both in the VerticalStructure.type and in the VerticalStructurePart.type |
| ER-04 | The system shall automatically identify the FIR(s) intersected by the obstacle location/extent. They shall be coded as corresponding concernedAirspace property(ies) in the Event If any different "affected FIR" from the one(s) determined above is(are) provided by the data originator, then corresponding concernedAirspace property(ies) shall be coded in the Event. |
| ER-05 | If an "affected aerodrome" is provided by the data originator, then a corresponding concernedAirportHeliport property shall be coded in the Event. |