The obstacle type is usually provided with a descriptive noun, such as 'building', 'bridge', 'antenna', 'tree', etc. In AIXM 5.1(.1), the type can be coded at two levels:
- for the obstacle as a whole, using the VerticalStructure.type
- for each of its components, using the VerticalStructurePart.type
For aeronautical operations, the type is not considered a critical property when the geometry of the obstacle is coded in detail, using the possibilities offered by the AIXM model. It is mostly used for identifying the obstacle, either visually or when comparing obstacle data sources for the same area. For certain types, such as 'tree', 'vegetation', etc. the type is also an indication that the height of the obstacle evolve in time and might be a hint for verifying the date when the data was collected.
Only when the geometry is coded in a simplified way the type provides additional information for the data users. For example, when a power line that is coded as a single position, the type is important because it is the only property that indicates that the horizontal/vertical extent is larger than the single position.
AIXM 5.1(.1) provides a predefined list of values for obstacle types, which was derived from several sources:
- EUROCAE ED-98 / RTCA DO-276 / User Requirements for Terrain and Obstacle data ;
- real-world data, based on data samples provided by the United States National Geospatial Agency (NGA);
- additional types derived from standards previously developed by the Air Modelling Advisory Team (Air MAT) and based on the model for FAA’s Electronic Airport Layout Plan (eALP).
This limited list of values aims at providing some uniformity in the identification of the obstacle types in the digital data sets, while the current AIP and other obstacle data sources contain a significantly larger number of terms that are used.
AIXM 5.1.1 issue
An issue is currently open in the AIXM CCB concerning the list of obstacle types, with the proposal to either include more types in the AIXM codelist or to shorten this codelist and introduce a second attribute for a 'localType'. If the CCB decides on additional obstacle types in AIXM 5.2, these will be added as type "OTHER:" in AIXM 5.1.1.
The following table indicates the current list of obstacle types.
|AIXM coded value||Meaning|
The components of a compressed air system
The components of an electronic monitoring and control system (EMCS) including cables, devices, and so on
The components of an electrical exterior lighting system including cables, switches, devices, transformers, and so on. Does not include field, navaid, or approach lighting.
The components of an electrical distribution system including cables, switches, devices, motors, transformers, and so on.
The components of a fuel distribution system consisting of pipes, fittings, fixtures, pumps, tanks, and so on
Area of a fence which may be opened for passage through the fence or closed to prevent passage through the fence
The components of utility system which are universal in use and purpose and do not belong to a specific utility
The components of a heating and cooling distribution system consisting of pipes, fittings, fixtures, and so on
The components of an industrial waste collection system including pipes, fittings, fixtures, tanks, lagoons, and so on
The components of a natural gas distribution system consisting of pipes, fittings, fixtures, and so on
Natural high point
Navaid (navigation aid)
|RIG||Rig (oil rig)|
The components of a salt water collection system
Stack (smoke, industrial)
The components of a storm drainage collection system including pipes, fittings, fixtures, and so on)
The components of a wastewater collection system including pipes, fittings, fixtures, treatment plants, collection locations, and so forth
The components of a water system including pipes, fittings, fixtures, treatment plants, and so on
AIXM 5.2 Improvements
A change proposal (AIXM-522) for the next AIXM 5.2 version has been approved by the AIXM Change Control Board, which introduces additional values for the types of VerticalStructure to allow more precise data coding and alleviating information loss, when regularly value OTHER is used.
The coding guidelines provided here are aligned with forward/backward conversion rules contained in the AIXM-522 Change Proposal.
For single part obstacles, the type shall be coded only in the VerticalStructure.type.
For multi-part obstacles, the type shall be coded always in the VerticalStructure.type. In addition, if a part has a different type from the overall obstacle, then the specific type of the may be coded in the VerticalStructurePart.type. There are certain plausibility rules that can be verified - for example, it does not make sense for a VerticalStructure with type='VEGETATION' to have VerticalStructurePart.type with values such as 'BULDING', 'MONUMENT'. etc. However, it is not possible to provide very precise rules with regard to the overall type based on the type of the parts. The type value, both for the parts and the overall obstacle, need to be decided by the data originator.
Single Part Obstacle
In this example, the obstacle type is coded ('ANTENNA') only in the VerticalStructure.type.
Multi Part Obstacle
In this example, each VerticalStructurePart has its own type ('BUILDING' or 'CATENARY'), which is different from the overall VerticalStructure.type ('CABLE_CAR').
The following coding examples can be found in the Obstacle Data Set - Specimen (DONLON):