| Panel | ||
|---|---|---|
| ||
|
Positions of navaids or designated points may be used in the aeronautical information domain to define the shape of an airspace. They can be used as arc centers or even as boundary points. In the case of NOTAM messages, the latitude/longitude coordinates may be followed by geographical references, such as in the example below.
E) AIR DISPLAY WILL TAKE PLACE WI LATERAL LIMITS: 443838N 0200818E (NDB OBR) - 444508N
0201455E (VILLAGE JAKOVO) - 443445N 0202447E - 443838N 0200818E (NDB OBR).
F) GND G) 3000FT AMSL)
This is not always a reference to a significant point, it can be simply an annotation of a position (e.g. “Village Jakovo”). However, the encoding solution being quite similar, this case also is discussed here.
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:patches>
<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:patches>
</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.
Abstract reference
| Note | ||
|---|---|---|
| ||
Abstract references to both points and 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 SiginificantPoint. 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
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 page Geometry and its sub-pages or document OGC 12-028r1
, (you can access the document via http://www.aixm.aero/page/data-coding-guidelines)
More details about the use of pointProperty are provided in a dedicated section of the general coding rules for geometry.
Coding Examples
| No. | Description | XPath Expression |
|---|---|---|
| ASE-EX-17 | ATS airspace, CTR (Point reference using aixm:Point annotations) | //aixm:AirspaceTimeSlice[@gml:id='ASE_DONLON_CTR'] |
ASE-EX-18 DPN-EX-06 | ATS airspace, ATZ (Point reference, Using xlink:href) | //aixm:AirspaceTimeSlice[@gml:id='ASE_DONLON_ATZ'] | //aixm:DesignatedPointTimeSlice[@gml:id='DPN_EADH'] | |