Obstacles with variable geometry are vertical structures that have a fixed position, while one or more parts have variable shape or elevation. They may penetrate the obstacle collection surfaces only at certain times, depending on their actual shape or elevation. The total perimeter of penetration should be captured for those obstacles.
Since such obstacles have a fixed location, they are not considered to be mobile obstacles. The VerticalStructurePart.mobile = 'NO' shall be used for these obstacles.
The geometry could be a point, line or a polygon, depending on the footprint penetrating the obstacle collection surface. The threshold definition as specified in Eurocae ED98C App G can be used to determine the exact geometry of the footprint. If the variable character of an obstacle is not relevant for aviation (e.g. the rotating blades of a windmill), it should be considered as a 'static' obstacle with a horizontal extent. This case is explained in the coding guidelines for Horizontal extent.
The movement of the variable parts may be according to a schedule. In this case, the VerticalStructurePart(s) concerned may have associated Timesheet(s), inherited from the PropertiesWithSchedule.
Typical cases for obstacles with variable geometry are
- Cranes and other static obstacles with moving parts
- Arresting barriers that can be raised on demand
- Obstacles that change their shape based on a schedule, e.g. cranes that can be lowered during the night
An arresting barrier is an elastic barrier (usually a net) that can be raised to prevent a landing aircraft from overshooting the runway. It will usually be raised on demand or for a longer time period that is announced by NOTAM. In its raised position arresting barriers should be considered as an obstacle affecting OEI (one engine inoperative) performance.
Arresting barrier in UP (left) and DOWN (right) position
Example from AIP
Please see Minimizing the impact of runway arresting systems (external link) and Commercial operations on runways with arresting systems (external link) for further details.
Arresting barriers should be coded as line obstacles with a vertical extent / an elevation. The times when the barrier is up, if according to a schedule, should be coded as Timesheet(s) associated with the VerticalStructurePart.
Crane with variable elevation with schedule
Some obstacles are able to change their shape and/or elevation according to a schedule. Typical examples are cranes that are collapsed and lowered during night time or any schedule.
Those cranes shall be coded as multi part obstacles with a fixed base part and a variable part that is bound to a schedule.
Crane fully extended (left) and lowered/collapsed (right)
A crane that is up/down according to a schedule will be coded with verticalExtent=0 and elevation (nilReason=innapplicable) at the times when it is "down", because "0" for elevation might be interpreted as 'deep below the surface' in mountain area
When the crane is down, it is possible that it also has a smaller horizontal footprint. If the crane is coded as a point with radius, then it is not possible to modify the radius according to a schedule. The radius is a property of the VerticalStructure as a whole, not of each part. If the radius change is operationally significant, then the solution is to code each part with an ElevatedSurface geometry (circle), which may then be associated with a schedule. In practice, the change in radius is unlikely to have an operational impact, unless the radius is very large and the crane is at the edge of the obstacle evaluation surfaces.