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.

EBNF Code
input = [group] [mobile] "obstacle type" [description] \n
[("location remarks")] ["obstacle identification"] \n
(point |line|polygon) elevation [height] \n
lighting ["marking description"] \n
"start time" "end time" [schedule] \n
{note} {"affected aerodrome"} {"affected FIR"}.

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 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

VerticalStructure/VerticalStructureTimeSlice.featureLifetime/endPositionVerticalStructure/VerticalStructureTimeSlice/

validTime/endPositionEvent/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:

  • a new Event with a BASELINE TimeSlice (scenario=”OBS.NEW”, version=”2.0”), for which a PERMDELTA TimeSlice may also be provided; and

  • a new VerticalStructure with BASELINE TimeSlice for which a PERMDELTA TimeSlice may also be provided; the property "event:theEvent" of the VerticalStructure TimeSlice shall refer to the Event mentioned above.

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-05If an "affected aerodrome" is provided by the data originator, then a corresponding concernedAirportHeliport property shall be coded in the Event.

Examples (to be updated)


  • No labels