Airspace boundaries, in particular Air Traffic Services (ATS) Airspace, may be based on national borders or on other geographical features, such as shorelines, rivers, etc. An example of such an Airspace border is provided below:
A particularity of this situation is that official definitions of the airspace, as provided in the Aeronautical Information Publication (AIP), does not include the actual geometry of the referenced geographical border. It is left for the end users to derive the actual geometry of the airspace by using a source of geographical border data.
The UML model of AIXM shows a “dependency” association between Surface and GeoBorder to cater for such situations.
In AIXM, the GeoBorder class is used to encode a physical or political border. In general, it will be the border between two States but could also be a coastline, the description of the bank of a river, or any other geographical shape which can be named and used to describe the border of an airspace. If two States have more than one common border, each one will be an occurrence of this entity.
When an Airspace is using a GeoBorder for a portion of its horizontal projection, GML the encoding of references to this GeoBorder can be done in two ways:
- either using the annotation property of the aixm:Curve class, for applications where a simple text remark is sufficient;
- or using the xlink:href attribute of the gml.curveMember element, for applications where a true reference needs to be preserved.
Using annotations
In this case, the aixm:Curve is used as content of a gml:curveMember, which allows including an aixm:annotation. This encoding has the advantage that the geometry is self-contained (the relevant series of latitude/longitude pairs from the referenced GeoBorder are directly copied in a gml:GeodesicString/gml:posList element).
This method should be used when the information (that this part of the airspace border actually comes from a GeoBorder) is intended “for human consumption”, such as for directly displaying the Airspace on a screen or printing on paper. An example is provided below:
Note that the first point of the curveMember that contains the portion extracted from the GeoBorder (39.42916667 47.36333334) is equal with the last point of the previous curveMember. This satisfies the requirement stated in the GML Standard (ISO 19136, 10.5.11.1- Ring, RingType, curveMember) that “In the context of a ring, the curves describe the boundary of the surface. The sequence of curves shall be contiguous and connected in a cycle.” In order to match this requirement when encoding existing Airspace data an additional gml:curveMember might be necessary. This is required in order to connect the last specified point of the Airspace boundary before the GeoBorder with the first vertex of the GeoBorder. It is typically a very short segment which does not alter the geometry. However, its presence is important in order to have a contiguous Surface border.
Using xlink:href
If necessary to preserve a true dependency between the Airspace horizontal projection and the GeoBorder, then a gml:curveMember with a xlink:href attribute can be used. In this case, there shall be no child aixm:Curve or gml:Curve element for that portion of the border. The GML standard requires a local reference, using a gml:id value. For compatibility reasons with previous AIXM versions and to satisfy the operational needs of the AI domain, it is also allowed to use a remote reference. The two solutions are detailed below, the second solution being widely used in many AIXM implementations today.
Local reference to aixm:Curve
In this situation, the gml:curveMember contains a local reference (xlink:href) to the gml:id value of an aixm:Curve that contains the relevant geo border points. The referred aixm:Curve is embedded into an ad-hoc GeoBorder SNAPSHOT Timeslice. This GeoBorder Timeslice is“ad-hoc” because it contains just the sub-set of point that need to be embedded.
(It would be better if it was possible to encode an aixm:Curve made of multiple segments and then give a gml:id to one of these segments. Then, use only that segment for the reference from the Airspace Border. Unfortunately, gml:id is not present in any of the segment types in GML (LineString, Geodesic, etc…). This could be an improvement suggestion for the next GML version. An (alternative) AIXM solution could be to allow multiple aixm:Curve in the definition of a GeoBorder. Thus, the encoding could refer to the gml:id of the Curve.)
This solution is appropriate when the data is provided for direct consumption by a GML tool for display or other calculation purpose, but there is a need to also preserve a true reference (by xlink:href) to the GeoBorder. Obviously, it requires that both the Airspace and the referenced GeoBorder are included in the same file. It might be problematic to apply this solution in the case of WFS getFeature requests, because the referenced feature will not be present in the response.
Note also that the xlink:title attribute is used to provide a human readable identification of the GeoBorder that is referred, which can be used in printed documents (e.g. “along the state border with…”).
This solution does not imply the persistence of the gml:id value. It is still a temporary identifier, which enables linking the gml:curveMember with the aixm:Curve inside the file.
This direct link between gml:curveMember and aixm:Curve is a deviation from the general AIXM principle of having xlink:href associations towards the feature level only. However, this direct association is the only solution identified for really encoding geometry dependencies at the GML level. In a source database, the association can still be towards the GeoBorder itself (as detailed in the next section). Only for data export/import purpose the reference would be towards the aixm:Curve directly.
Abstract reference to remote feature
The second possibility is to use an xlink:href towards a remote feature, as in the example below. This coding solution is practically the norm in the AIS applications to date.
The xlink:href value is a remote reference to the gml:identifier of the GeoBorder that includes the series lat/long positions used in the airspace horizontal projection definition. However, that GeoBorder is likely to be much longer, including also points that are beyond the portion used for the current airspace border definition. A native GML tool might identify this as an error, because the target aixm:GeoBorder is not a gml:curveMember legal child.
However, this solution is still considered appropriate for the situations when the AIXM encoding is used for exchanging data between a local system and a reference database. In such cases the data will not be directly used for graphical visualization and other spatial calculations. The recipient system would preserve this link and would eventually recuperate the gml:pos data of the referred feature in case this is necessary for further data use. This third solution is practically equivalent (with the same advantages and disadvantages) to the use of the “FNT” elements from the previous AIXM 4.5 version, which was not based on GML.
Note
Abstract references to geo-borders fall outside the GML specification. However, for geo-border, there is really no other solution than allowing abstract references because you do not want to include the GeoBorder whenever you exchange the Airspace data. For points, it was concluded that the benefit of abstract references does not justify the overhead. If you really need to indicate that an Airspace vertex is the location of a navaid or designated point, then that feature should be included in the file. However, most of the time it will be just an annotation, not a real reference. That’s because there is also an operational difference between references to geo-borders and references for SignificantPoint. A change in the GeoBorder geometry is considered to automatically apply to the Airspace geometry. This justifies a real xlink:href. A change in the position of a designated point or navaid does not automatically cascade to the Airspace that might use it as border point or centre of a circle. The Airspace is usually modified explicitly and eventually aligned with the new position. Therefore, an xlink:href is not really justified for points. If really necessary, than the limitation is that only a local reference can be used.
Temporal aspects for abstract references
An Airspace geometry that depends on a GeoBorder is the most common case of temporal dependency between different features, as discussed here: https://ext.eurocontrol.int/aixm_confluence/display/CGWIP/%5BWIP%5D+Temporal+aspects+of+feature+associations+and+dependencies.
Summary
Coding Examples
| No. | Description | XPath Expression |
|---|---|---|
| ASE-EX-06 | Special activity airspace, Restricted Area, reference to state boundary (annotation) | //aixm:AirspaceTimeSlice[@gml:id='ID_262'] |
| ASE-EX-07 | Special activity airspace, Local type, reference to state boundary (xlink:href) | //aixm:AirspaceTimeSlice[@gml:id='ASE_EAMOA01_MOA'] |