The UML model of AIXM shows a “dependency” association between Surface and SignificantPoint in order to cater for such situations:
The reason for using a “dependency” association and not a standard “object to feature association” is that this occurs deep inside the GML encoding of the Surface. Using a “dependency” also indicates that the actual encoding can be done differently, based on the intended use of the data.
The encoding of point references and annotations can be done using gml:pointProperty elements, which can appear as a descendant of gml:Curve, for example in the construction of a gml:GeodesicString. Note that the pointProperty allows either referring to another gml:Point (by xlink:href) or providing a gml:Point child element.
According to the GML standard
chapter 10 :
A property that has a point as its value domain may either be an appropriate geometry element encapsulated in an element of this type or an XLink reference to a remote geometry element (where remote includes geometry elements located elsewhere in the same document). Either the reference or the contained element shall be given, but neither both nor none.
Using aixm:Point annotations
In this case, a gml:pointProperty is used, including an aixm:Point with an annotation (aixm:Note). This encoding has the advantage that the geometry is self-contained (the position of the referenced object is directly copied as a gml:pos element).
This method should be used whenever the data is intended “for human consumption”, such as in the case of the NOTAM examples (e.g. “VILLAGE JAKOVO”). Even in the case when an arc center is located on a DME navaid and the distance information provided by the DME can be used to keep the aircraft inside or outside the arc, the provision of a Point annotation could be sufficient for the end user.
An example is provided below:
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
....
<gml:exterior>
<gml:Ring>
<gml:curveMember>
<gml:Curve gml:id="C001">
<gml:segments>
<gml:GeodesicString>
<gml:posList>52.1855 5.2083 52.2061 5.2875 52.1891 5.2988 52.1691 5.2988</gml:posList>
</gml:GeodesicString>
<!-- The next segment contains a point annotation encoded as a Note-->
<gml:GeodesicString>
<gml:pos>52.16917 5.29889</gml:pos>
<gml:pointProperty>
<aixm:Point gml:id="P001">
<gml:pos>52.16917 5.21972</gml:pos>
<aixm:annotation>
<aixm:Note gml:id="N001">
<aixm:translatedNote>
<aixm:LinguisticNote gml:id="N002">
<aixm:note lang="eng">VILLAGE JAKOVO</aixm:note>
</aixm:LinguisticNote>
</aixm:translatedNote>
</aixm:Note>
</aixm:annotation>
</aixm:Point>
</gml:pointProperty>
</gml:GeodesicString>
<!-- This is the final straight segment encoded as a Geodesic, which closes the surface-->
<gml:GeodesicString>
<gml:posList>52.16917 5.21972 52.18556 5.20833</gml:posList>
</gml:GeodesicString>
</gml:segments>
</gml:Curve>
</gml:curveMember>
</gml:Ring>
</gml:exterior>
... |
Using xlink:href
When necessary to preserve as a true reference the information that the current position depends on the location of another aeronautical feature, then a gml:PointProperty with a xlink:href attribute can be used. In this case, there shall be no child gml:Point/gml:pos element.
The GML standard requires a local reference, using a gml:id value.
Local reference to gml:Point (or equivalent)
In the example below, the position of the Navaid is used as centre for the circle that defines the horizontal geometry of the Airspace.
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<aixm:Navaid gml:id="urn.uuid.791fb712-6c7a-46bb-8e98-49d76942573e">
...
<aixm:type>VOR_DME</aixm:type>
<aixm:name>DONLON</aixm:name>
<aixm:location>
<aixm:ElevatedPoint gml:id="P0001" srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>52.2889 -32.0350</gml:pos>
<aixm:elevation uom="FT">365</aixm:elevation>
</aixm:ElevatedPoint>
</aixm:location>
...
</aixm:Navaid>
...
<aixm:Airspace gml:id="urn.uuid. fc5b4fb3-004e-42c4-8552-6566d25a09f7">
...
<aixm:theAirspaceVolume>
<aixm:AirspaceVolume gml:id="V001">
<aixm:horizontalProjection>
<aixm:Surface gml:id="S001" srsName="urn:ogc:def:crs:EPSG::4326">
<gml:polygonPatches>
<gml:PolygonPatch>
<gml:exterior>
<gml:Ring>
<gml:curveMember>
<gml:Curve gml:id="CUR001">
<gml:segments>
<gml:CircleByCenterPoint numArc="1">
<gml:pointProperty xlink:href="#P0001" xlink:title="VOR/DME DONLON"/>
<gml:radius uom="[nmi_i]">12</gml:radius>
</gml:CircleByCenterPoint>
</gml:segments>
</gml:Curve>
</gml:curveMember>
</gml:Ring>
</gml:exterior>
</gml:PolygonPatch>
</gml:polygonPatches>
</aixm:Surface>
</aixm:horizontalProjection>
</aixm:AirspaceVolume>
...
</aixm:Airspace> |
This solution is appropriate when the data is provided for direct consumption by a GML tool for display or other calculation purpose. Obviously, it requires that both the Airspace and the referenced feature (Navaid, DesignatedPoint, etc.) 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 Navaid that is referred, which can be used in printed documents.
This solution does not imply the persistence of the gml:id value. It is still a temporary identifier, which enables linking the gml:PointProperty with the gml:Point or one of its allowed substitutions (aixm:Point, aixm:ElevatedPoint) inside the file.
This direct link between gml:PointProperty and gml:Point is a deviation from the general AIXM principle of having xlink:href associations towards the feature level only. However, this direct association with the gml:Point property of the aixm:Navaid 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 Navaid itself (as detailed in the next section). Only for data export/import purpose the reference would be towards the gml:Point directly.
Summary
In conclusion, there are two options for encoding point references in AIXM/GML:
- as a simple annotation
- as a local concrete xlink:href reference using gml:id
The most appropriate one depends on the intended usage of the data. Therefore, AIXM applications should offer the client the possibility to specify how such references should be exported: to be preserved or be replaced with copies of gml:Point elements, eventually including the reference as an annotation.
For more details of AIXM/GML encoding see the document Guidance and Profile of GML for use with Aviation Data.
Coding Examples
