Airspace Geometry by Aggregation (more than one AirspaceVolume)

The geometry of an airspace may be constructed by the composition of other airspaces.

The main concept behind these operations is the so called "Parent/Child relationship".

The figure below shows 2 examples. The geometry of the "child" airspace which dervies the geometry from the "parent" airspace(s) may be

• the same horizontal shape as another airspace but with different vertical limits ("above-below" association).
• a composition by aggregation of airspaces (e.g. union and substraction operations).

In the first case only one parent can be used (but it may be used for more than one child) and the derivation process is limited to the horizontal border.

In the second case a combination of "parent" airspaces (one to many relationship) will be used. The derivation process is extended to a total aggregation of airspace volumes (i.e. may also take vertical limits into account).

In both cases, based on already defined airspaces the geometry of a new airspace can be defined using a set of various operations.

The parent airspace(s) always determine(s) the geometry of the child airspace, i.e. the parent airspace has already a specified geometry which will be inherited by the child.

For the GML encoding of the Surface of the airspaces see document  12-028_Use_of_GML_for_aviation_data-2.pdf

Aggregation Chains (Hierarchy of Aggregation)

An airspace described as the "child" of an aggregation, may again be used as "parent" for another aggregation and so on. (so you are able to create "grandchildren" if you like to say so).

An airspace may also be the "parent" for several different "child" airspaces in different associations.

Types for Airspace Geometry Components

For airspace aggregations the AirspaceGeometryComponent class defines the role of the component in the airspace geometry.

If the geometry of an airspace is composed of single volume (see Airspace Geometry - One AirspaceVolume), then the attributes of this association class may be left empty.

The attribute operation defines 4 types of operation. The operations may be used in all kind of combinations.

BASE

The operation 'BASE' is used to define the 'Parent' airspace which is the basis for any subsequent operations.

In case of a simple "above-below" composition, 'BASE' will be the only opertion used.

UNION

The operation 'UNION' is used to define that the 'Parent' airspace is second operand in a union operation.

Airspace1 is used as aggregation component (parent) with operation equal-to 'BASE', and operationSequence equal-to '1'

Airspace2 is used as aggregation component (parent) with operation equal-to 'UNION', and operationSequence equal-to '2'

Sbsequently, the geometry of Airspace 3 is the results of the aggregation of the two components.

Substration

The operation 'SUBSTR' is used to define that the 'Parent' airspace is second operand in subtraction operation.

Airspace1 is used as aggregation component (parent) with operation equal-to 'BASE', and operationSequence equal-to '1'

Airspace2 is used as aggregation component (parent) with operation equal-to 'SUBSTR', operationSequence equal-to  '2'

Subsequently, the geometry of Airspace 3 is the results of the aggregation of the two components.

Intersection

The operation 'INTERS' is used to define that the 'Parent' airspace is second operand in intersection operation.

Airspace1 is used as aggregation component (parent) with operation equal-to 'BASE', and operationSequence equal-to 1

Airspace2 is used as aggregation component (parent) with operation equal-to  'INTERS', operationSequence equal-to 2

Subsequently, the geometry of Airspace 3 is the results of the aggregation of the two components.

Airspace Aggregation - Coping Geometry vs. Referencing

There are 2 methods to define the geometry of an airspace with more than one airspace volume, by coping the geometry or by referncing.

Combinations of both for defining one airspace geometry are possible.

Coping Geometry

The first method consists in effectively copying the geometry of the referenced Airspace as local AirspaceVolume.

This method might be appropriate for applications that need to provide fully digested geometrical data for direct consumption (e.g. graphical visualization, spatial calculations). The disadvantage of this method is that the referenced geometry might also change in time. This is not a problem when the aggregation is used for the provision of SNAPSHOT data (valid at a time instant) but it might become problematic when providing BASELINE data (which is valid for a period of time). Future changes of the geometry of referenced airspace needs to be propagated to the AirspaceVolume of the aggregated airspace. The advantage is that this method provides complete geometrical data for the aggregated Airspace and does not require further calculations by the client system.

For this method the AirspaceGeometryComponent class is used to define the aggregation and the Surface class to define the lateral limits of the child airspace (viz. the copies of the lateral limits of the parent airspaces).

The figure below illustrates a simple coping of geometry, using as an example the BRUSSELS TMA which is a Union of two parts: TMA one and TMA two

There is an additional option here. Instead of coping the geometry of the exsisting parts, the parts may be defined as integral part of the geometry of the child airspace. In this case the parent airspace does not exist as own airspace feature.

Referencing

The seond method is limited to referring to another airspace, but without effectively copying the geometry of that Airspace as own AirspaceVolume.

This method might be appropriate for data provision between synchronized databases, such as between a local and a regional database and it is equivalent to the approach of the previous AIXM 4.5 version (which is not based on GML). The disadvantage of this method is that the client needs to eventually retrieve the geometry of the referenced Airspace and do the geospatial calculations that are necessary in order to effectively get the actual geometry of the current Airspace in a GML usable form. The advantage is that it preserves a true association with the composing Airspace.

For this method the AirspaceGeometryComponent class  and the AirspaceVolumeDependency class are used to define the aggregation.The Surface class may not be used!

The AirspaceVolumeDependency class defines the relationship between the geometry of an AirspaceVolume and the geometry of another (parent) Airspace.

The dependency attribute will be used to define if only the horizontal limits of the "parent" airspace(s) shall be taken into account or also the vertical limits (i.e. the full geometry).

The figure below illustrates a simple referencing, again using as example the BRUSSELS TMA with its two parts: TMA one and TMA two.

Coding Examples

Example 1: R-4912 Sand Springs, NV

This example shows the encoding of the geometry of a Restricted area (R-4912) utilizing the AIXM airspace aggregation concept.

The airspace aggregation is made of 4 airspace components which are used in a combination of copying and referencing.

The first AirspaceGeometryComponent used in this aggregation is the 'BASE' from which 3 other airspace geometry components are substracted.

The 'BASE' is defined with theAirspaceVolume defining an upperLimit, a lowerlimit and a Surface that has the shape of rectangular (in the figure below highligted in orange).

The second AirspaceGeometryComponent is used for a 'SUBSTR' operation applied on the 'BASE' component. For this substraction operation the referencing concept is applied, i.e the AirspaceVolumeDependency class has to be defined.  The dependency is coded as HORZ_PROJECTION. That means that the substraction is limited to the horizontal projection. 

The  whereas only teh horizonal projection is tajken into account. The  which results in a corresponding shape (in the figure below highligted in orange).

Example: Twin Peaks

More examples TBD in the scope of the DONLON AIXM XML AIP data set.