The UML model of AIXM shows a “dependency” association between Surface and GeoBorder to cater for such situations.
The GeoBorder class is used to encode a physical or political border. In general, it will be the border between two countries or states but could also be a coastline, the description of the bank of an important river, or any other geographical shape which can be named and used to describe the border of an airspace. If two countries/states have more than one common border, each one will be an occurrence of this entity.
In GML the encoding of GeoBorder references 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
When necessary to preserve as a true reference the (that a part of the airspace border actually comes from a 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. 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 here.
Local reference to aixm:Curve
In this example, 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
Note: The encoding described in this section is strongly discouraged on long term. However, for now, it is the only practical solution for keeping abstract references to GeoBorder curves. We strive to find a better alternative in the future.
The second possibility is to use an xlink:href towards a remote feature, as in the example below:
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.
Temporal aspects for abstract references
When using abstract references, an important issue arises that must be dealt with regard to the temporal synchronisation of the data. Since an abstract reference always points to a complete feature rather than a single time slice, it is very important that there is no ambiguity in which time slice is meant. The referenced object should not change its geometrical shape and geographical locations during the valid time of the reference.
For example, assume that the following GeoBorder feature is defined (only relevant parts are shown):
Then, the following reference is used (abstract to remote feature):
In the above example, the Airspace and the referred GeoBorder Timeslices have identical validity period. This is an unambiguous encoding.
This following one is also straight-forward since the validity of the Airspace Timeslice is inside the validity period of the GeoBorder that it references:
However, the following example is ambiguous and it should be avoided:
This is problematic because the reference is no longer unique. It points to the curve of the GeoBorder’s first time slice as well as the curve of its second timeslice. Moreover, since the remaining airspace curve must fit with the GeoBorder curve, it may be that one interpretation of this reference is valid, while the other forms an invalid airspace geometry, e.g. by slightly moving the first curve point of the GeoBorder from one time slice to the next.
In that situation, it is recommended to split the referencing Airspace timeslice as needed in order to have a reference to a single geometry at any time.
Abstract reference
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.
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'] |