Coding guidelines for ObstacleArea
- Wolfgang Scheucher
- georgiana.andrei04
- POROSNICU Eduard
Introduction
The PANS-AIM document identifies a number of areas of interest for which obstacles should be collected, such as Area 1, Area 2 a/b/c/d, etc. In the AIXM 5.1(.1) data model, the area is identified through the ObstacleArea.type attribute. Additional obstacle identification surfaces are specified in the ICAO Annexes 4 and 14, such as Obstacle Limitation Surfaces (OLS) and their sub-divisions. These are captured in the AIXM model as ObstacleArea.type.
The following diagram shows the AIXM 5.1(.1) classes that model the concept of Obstacle Areas:
The ObstacleArea class is the main element, with an attribute named type that can be used for the identification of the area: 'AREA1', 'AREA2', 'AREA3', etc.
Note
The list of values is likely to be modified in AIXM 5.2, in order to reflect the latest ICAO subdivision of the Area 2 (a, b, c, d), which is missing from the current model. Also, the attribute obstructionIdSurfaceCondition is likely to be revisited in AIXM 5.2.
Each ObstacleArea may be associated with one of the following:
- an AirportHeliport - for areas that are defined in relation with an airport, such as the Area 2
- a RunwayDirection - for areas that are defined in relation with a particular runway landing and take-off direction
- an OrganisationAuthority - for areas that are defined in relation with the whole State territory
The horizontal projection of the ObstacleArea is modelled through the association hasExtent with Surface.
Finally, the model allows to associate the ObstacleArea with zero or more VerticalStructure, which allows to directly identify the obstacles declared as being situated in each obstacle area. This means not only that the obstacle is situated within the geographical limits of the area, but also that it satisfies the data collection rules for obstacles in that area.
Type and Origin
There is a direct correlation between the area type and its origin. The following table indicates the ObstacleArea.type value that shall be used for the various obstacle area collection surfaces and their sub-areas. It also indicates the origin of the area expected to be used depending on the area type.
AIXM 5.1.1 issue
AIXM 5.1(.1) does not support the ICAO subtypes of Area 2 (i.e. Area 2a, 2b, 2c and 2d). Also, the attribute obstructionIdSurfaceCondition is not relevant for the ObstacleArea but only for the ObstacleAssessementArea (procedure design).
An issue (AIXM-203) has been raised for this purpose in the AIXM CCB and a Change Proposal is being discussed.
The coding guidelines proposed will be aligned with the AIXM 5.2 changes proposal. This means that the obstructionIdSurfaceCondition is not used in the coding.
| PANS-AIM Area type | AIXM ObstacleArea.type value | AIXM ObstacleAreaOrigin | Remarks |
|---|---|---|---|
| Area 1 | AREA1 | OrganisationAuthority with type equal-to 'STATE' | |
| Area 2a | OTHER:AREA2A | RunwayDirection that has the lowest designation number. | AIXM 5.1(.1) Limitation AIXM 5.1(.1) does not allow associating an ObstacleArea with one or more Runway. An issue (AIXM-203) has been raised for this purpose in the AIXM CCB and a Change Proposal is being discussed. |
| Area 2b | OTHER:AREA2B | RunwayDirection at the end of which it is located (departure). | Two instances of Area 2b will exist for each runway, each associated with a RunwayDirection |
| Area 2c | OTHER:AREA2C | RunwayDirection that has the lowest designation number. | AIXM 5.1(.1) Limitation AIXM 5.1(.1) does not allow associating an ObstacleArea with one or more Runway. Am issue (AIXM-203) has been raised for this purpose in the AIXM CCB and a Change Proposal is being discussed. |
| Area 2d | OTHER:AREA2D | AirportHeliport | |
| Area 3 | AREA3 | AirportHeliport | |
| Area 4 | AREA4 | RunwayDirection | |
other obstacles in or around Area 2, that are considered a hazard to air navigation. | OTHER:AREA2_HAZARD | AirportHeliport | This is based on an interpretation of the Annex 15 requirements. The obstacle definition says that an obstacle can also "c) stand outside those defined surfaces and that have been assessed as being a hazard to air navigation." Annex 15 also requires 5.3.3.4.4 "For aerodromes regularly used by international civil aviation, obstacle data shall be provided for all obstacles within Area 2 that are assessed as being a hazard to air navigation." The conclusion is that there could be obstacles outside Area 2 that are hazards to air navigation. Otherwise, they would be in the Area 2 a/b/c/d or OLS or Take-off flight path area. |
| take-off flight path area | OTHER:TAKE_OFF_FLIGTH_PATH_AREA | RunwayDirection | |
| obstacle limitation surfaces | OLS | RunwayDirection | This surface consists in fact of the surfaces listed below, that start with 'OTHER:OLS_...', Data providers might choose to associate an obstacle more precisely with the sub-surfaces of the OLS, instead of associating them with the general 'OLS' type. |
| outer horizontal surface of OLS | OTHER:OLS_OUTER_HORIZONTAL_SURFACE | RunwayDirection | |
| conical surface of OLS | OTHER:OLS_CONICAL_SURFACE | RunwayDirection that has the lowest designation number. | |
| inner horizontal surface of OLS | OTHER:OLS_INNER_HORIZONTAL_SURFACE | RunwayDirection that has the lowest designation number. | |
| approach surface of OLS | OTHER:OLS_APPROACH_SURFACE | RunwayDirection | |
| inner approach surface of the OLS | OTHER:OLS_INNER_APPROACH_SURFACE | RunwayDirection | |
| transitional surface of OLS | OTHER:OLS_TRANSITIONAL_SURFACE | RunwayDirection | |
| inner transitional surface of OLS | OTHER:OLS_INNER_TRANSITIONAL_SURFACE | RunwayDirection | |
| balked landing surface of OLS | OTHER:OLS_BALKED_LANDING_SURFACE | RunwayDirection | |
| take-off climb surface of OLS | OTHER:OLS_TAKE_OFF_CLIMB_SURFACE | RunwayDirection |
AIXM 5.2 Improvements
A change proposal (AIXM-515) for the next AIXM 5.2 version has been approved by the AIXM Change Control Board, in which new coded values are added in the CodeObstacleAreaBaseType for the Area 2 sections (A/B/C/D) and for the different areas of Obstacle Limitation Surfaces.
The coding guidelines provided here are aligned with forward/backward conversion rules contained in the AIXM-515 Change Proposal.
VerticalStructure association to ObstacleArea
If an obstacle matches the data collection criteria for a certain area, then a direct association between the ObstacleArea instance and the VerticalStructure concerned needs to be coded. For the Obstacle Data Sets, this associations needs to be always coded explicitly, even in the situation where a data set is limited to one area and it could be considered that the association is implicit. This explicit association facilitates integrating the obstacle data in user databases. It also enables the data providers to explicitly indicate which VerticalStructure constitutes an obstacle, as some VerticalStructures might not be considered obstacles in an area, even if by their horizontal position they are located within the area.
The model allows to associate a VerticalStructure with multiple areas, if necessary. This association can be provided in the form of an abstract Xlink, using the target VerticalStructure gml:identifier (UUID). An obstacle shall be coded as a single VerticalStructure, even if it penetrates the evaluation surfaces of more than one area.
It is not possible to associate an area with a part of an obstacle. For example, if only a part of a power line is in Area 2, there are two options:
- either split the obstacle in multiple VerticalStructure, so that only the relevant ones are associated with the Area concerned;
- or keep a single obstacle, but then there will be situations where some parts of that obstacle are actually not situated in the Area indicated by the association.
ObstacleArea geometry
The AIXM model enables coding the horizontal projection of an ObstacleArea through the association with Surface. This could serve for visualisation purpose, in order to show graphically the location and extent of the area. However, the inclination of the surface would be absent, where applicable. It should also be kept in mind that the coding of the horizontal projection of certain Obstacle Areas exceeds the capabilities of the current GML profile for aviation data. For example, Area 2a-c need to be excluded form 2d. This is not allowed by the current profile which does not support the coding of "interiors". Therefore, no coding guidelines are currently provided for this topic.
A question might arise with regard to merging certain airport obstacle areas due to the proximity of the runways around which they are defined. For example, if an airport has two intersecting runways, then a large part of their AREA 2 might be common to the two runways. The data originators might decide in this case to declare a single AREA 2, covering both runways. This is not a data coding decision, it is a data origination decision. No specific coding guidance is considered necessary in this case.