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.

Page Table of Content

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:

<aixm:Airspace gml:id="urn.uuid.1965dd58-6898-4065-8f21-b1774c959bbb">
    ...
    <aixm:horizontalProjection>
        <aixm:Surface gml:id="S001" srsName="urn:ogc:def:crs:EPSG::4326">
            <gml:patches>
                <gml:PolygonPatch>
                    <gml:exterior>
                        <gml:Ring>
                            <gml:curveMember>
                                <gml:Curve gml:id="CUR001">
                                    <gml:segments>
                                        <gml:LineStringSegment interpolation="linear">
                                            <!-- because the two consecutive points have the same latitude, the first segment is encoded as a parallel (linear interpolation in EPSG:4326) -->
                                            <gml:posList> 40.05 45.88972222 40.05
                                                46.93333333</gml:posList>
                                        </gml:LineStringSegment>
                                        <gml:GeodesicString interpolation="geodesic">
                                            <gml:posList>40.05 46.93333333 39.42916667
                                                47.36333334</gml:posList>
                                        </gml:GeodesicString>
                                    </gml:segments>
                                </gml:Curve>
                            </gml:curveMember>
                            <!-- Here starts the first portion of the Airspace border that was extracted (copied) from a GeoBorder. In this case, the reference to the GeoBorder is a simple text annotation.-->
                            <gml:curveMember>
                                <aixm:Curve gml:id="CUR002">
                                    <gml:segments>
                                        <gml:GeodesicString interpolation="geodesic">
                                            <gml:posList>39.42916667 47.36333334 39.426818 47.353277
                                                39.405269 47.340623 39.370714 47.303951 39.317977 47.213494 39.304679 47.147725 39.253854 47.075486 39.209945
                                                47.064339 39.138967 46.950699 39.160036 46.929733 39.135505 46.835985 39.113835 46.826968 39.110637 46.818902
                                                39.104488 46.811639 39.084995 46.792338 39.079520 46.774177 39.063644 46.761250 39.035348 46.762985 39.015666
                                                46.733063 39.019323 46.695507 38.991019 46.690236 38.987819 46.672322 38.930984 46.626817 38.906155 46.600158
                                                38.885792 46.560942 38.885160 46.554943 38.87277778 46.54722222</gml:posList>
                                        </gml:GeodesicString>
                                    </gml:segments>
                                    <aixm:annotation>
                                        <aixm:Note gml:id="N001">
                                            <aixm:translatedNote>
                                                <aixm:LinguisticNote gml:id="N002">
                                                    <aixm:note lang="ENG">along the state border with
                                                        Islamic Republic of Iran</aixm:note>
                                                </aixm:LinguisticNote>
                                            </aixm:translatedNote>
                                        </aixm:Note>
                                    </aixm:annotation>
                                </aixm:Curve>
                            </gml:curveMember>
                            ...
</aixm:Airspace>

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.)

...
<aixm:Airspace gml:id="urn.uuid.1965dd58-6898-4065-8f21-b1774c959bbb">
    ...
    <aixm:horizontalProjection>
        <aixm:Surface gml:id="S001" srsName="urn:ogc:def:crs:EPSG::4326">
            <gml:patches>
                <gml:PolygonPatch>
                    <gml:exterior>
                        <gml:Ring>
                            <gml:curveMember>
                                <gml:Curve gml:id="CUR001">
                                    <gml:segments>
                                        <gml:LineStringSegment interpolation="linear">
                                            <!-- because the two consecutive points have the same latitude, the first segment is encoded as a parallel (linear interpolation in EPSG:4326) -->
                                            <gml:posList> 40.05 45.88972222 40.05
                                                46.93333333</gml:posList>
                                        </gml:LineStringSegment>
                                        <gml:GeodesicString interpolation="geodesic">
                                            <gml:posList>40.05 46.93333333 39.42916667
                                                47.36333334</gml:posList>
                                        </gml:GeodesicString>
                                    </gml:segments>
                                </gml:Curve>
                            </gml:curveMember>
                            <gml:curveMember xlink:href="#CRV002" xlink:title="along the state border with
                                Islamic Republic of Iran"/>
                            <gml:curveMember xlink:href="#CRV003" xlink:title="along the state border with
                                Armenia">
                            </gml:curveMember>
                        </gml:Ring>
                    </gml:exterior>
                </gml:PolygonPatch>
            </gml:patches>
        </aixm:Surface>
    </aixm:horizontalProjection>
    ...
</aixm:Airspace>

...
<aixm:GeoBorder gml:id="urn.uuid.cee41f01-849e-44d1-9aaf-573580980c69">
    <gml:identifier codeSpace="urn:uuid:">cee41f01-849e-44d1-9aaf-573580980c69</gml:identifier>
    <aixm:timeSlice>
        <aixm:GeoBorderTimeSlice gml:id="NID2168343">
            <gml:validTime>
                <gml:TimeInstant gml:id="NID00056">
                    <gml:timePosition>2011-09-15T00:00:00</gml:timePosition>
                </gml:TimeInstant>
            </gml:validTime>
            <aixm:interpretation>SNAPSHOT</aixm:interpretation>
            <aixm:name>AZERBAIJAN_IRAN_EXTRACT</aixm:name>
            <aixm:type>STATE</aixm:type>
            <aixm:border>
                <aixm:Curve gml:id="CRV002">
                    <gml:segments>
                        <gml:GeodesicString interpolation="geodesic">
                            <gml:posList>39.42916667 47.36333334 39.426818 47.353277 39.405269
                                47.340623 39.370714 47.303951 39.317977 47.213494 39.304679 47.147725 39.253854 47.075486 39.209945 47.064339
                                39.138967 46.950699 39.160036 46.929733 39.135505 46.835985 39.113835 46.826968 39.110637 46.818902 39.104488
                                46.811639 39.084995 46.792338 39.079520 46.774177 39.063644 46.761250 39.035348 46.762985 39.015666 46.733063
                                39.019323 46.695507 38.991019 46.690236 38.987819 46.672322 38.930984 46.626817 38.906155 46.600158 38.885792
                                46.560942 38.885160 46.554943 38.87277778 46.54722222</gml:posList>
                        </gml:GeodesicString>
                    </gml:segments>
                </aixm:Curve>
            </aixm:border>
        </aixm:GeoBorderTimeSlice>
    </aixm:timeSlice>
</aixm:GeoBorder>...
...

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.

...
<aixm:Airspace gml:id="urn.uuid.1965dd58-6898-4065-8f21-b1774c959bbb">
    ...
    <aixm:horizontalProjection>
        <aixm:Surface gml:id="S001" srsName="urn:ogc:def:crs:EPSG::4326">
            <gml:patches>
                <gml:PolygonPatch>
                    <gml:exterior>
                        <gml:Ring>
                            <gml:curveMember>
                                <gml:Curve gml:id="CRV001">
                                    <gml:segments>
                                        <gml:LineStringSegment interpolation="linear">
                                            <!-- because the two consecutive points have the same latitude, the first segment is encoded as a parallel (linear interpolation in EPSG:4326) -->
                                            <gml:posList> 40.05 45.88972222 40.05 46.93333333</gml:posList>
                                        </gml:LineStringSegment>
                                        <gml:GeodesicString interpolation="geodesic">
                                            <gml:posList>40.05 46.93333333 39.42916667 47.36333334</gml:posList>
                                        </gml:GeodesicString>
                                    </gml:segments>
                                </gml:Curve>
                            </gml:curveMember>
                            <!-- Here is the first reference to a GeoBorder.-->
                            <gml:curveMember xlink:href="urn:uuid:cee41f01-849e-44d1-9aaf-573580980c69"
                                xlink:title="along the state border with Islamic Republic of Iran"/>
                            <!-- Here is the second reference to a GeoBorder.-->
                            <gml:curveMember xlink:href="urn:uuid:2bc135fa-0a1a-451c-ad99-61ed3e194e1c"
                                xlink:title="along the state border with Armenia">
                            </gml:curveMember>
                        </gml:Ring>
                    </gml:exterior>
                </gml:PolygonPatch>
            </gml:patches>
        </aixm:Surface>
    </aixm:horizontalProjection>
    ...
</aixm:Airspace>
...

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

The figure below shows the encoding of an airspace referencing a geoborder as part of one of its geometry components.

More coding examples can be found in the AIP Data Set - Specimen (DONLON).

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']

References

Browser not supported