Table of Contents
Feature elements are descriptions of aeronautical objects such as airports or runways. Their designations have exactly three letters, the first of which is uppercase. Features come in two flavors, core and nested features:
- – Airport core feature (Aerodrome heliport)
Rwy– Runway nested feature (Runway)
Features contain a
*Uid element as their first child. The asterisk stands for the corresponding three letter feature element. The
*Uid element identifies the feature and is therefore also known as it's identifier. It's purpose is best illustrated with an example:
<Vor source="LF|ENR|4.1|6|3749"> <VorUid region="LF"> <codeId>AGN</codeId> <geoLat>435316.90N</geoLat> <geoLong>0005222.30E</geoLong> </VorUid> <txtName>AGEN-GAUDONVILLE</txtName> <codeType>VOR</codeType> (...) </Vor>
VorUid uniquely identifies this feature by it's key properties (
geoLong in this example). Think of it as the fingerprint of the feature: All identifying parts of the feature are wrapped by the
Modifications on the key properties constitute a new and different feature whereas modifications on other properties (
codeType in this example) merely edit an existing .
*Uid elements are used to associate two related features.
Core features describe primary aeronautical objects such as an airport. (In this documentation, designations of core features are .)
<Ahp source="EB|AD|1.3|2018-01-04|3857"> <AhpUid region="EB" mid="c3643227-1de6-482c-8fb7-7512fdabb297"> (...) </AhpUid> (...) </Ahp>
Core feature require some mandatory attributes:
@sourceattribute is mandatory if the data is imported to OFM databases.
@regionattribute is mandatory.
@midattribute is optional.
All other features such as a
Rwy runway are nested since they further describe the core feature associated in their
*Uid element. (In this documentation, designations for nested features are not underlinded.)
<Rwy source="EB|AD|1.3|2018-01-04|3909"> <RwyUid mid="85784432-2460-4970-b6fe-ee41959b15ab"> <AhpUid region="EB" mid="c3643227-1de6-482c-8fb7-7512fdabb297"> (...) </AhpUid> (...) </RwyUid> (...) </Rwy>
Nested features do not require any mandatory attributes:
@source attribute maps a feature to an AIP document. The presence and value is only enforced when importing data to OFM databases – for quality control and later certification by aviation authorities.
@source attribute has to be set on the feature element!
The reference string consists of five segments joined by the pipe symbol
| (Unicode character U+007C):
REGION– The region this feature is located in
VAC(visual approach chart) or
FILE-NAME– The file name without extension as uploaded and archived on OFM (e.g.
1.3 AERODROMES HELIPORTSor
2.2 Other regulated airspace). The OFM Editor displays this file name.
AIRAC-DATE– Beginning date of the AIRAC cycle this document belongs to (e.g.
POSITION– Page number for PDF documents or source line number for HTML documents
The following example from the French AIP references the file
ENR-4.1.html, more exactly line 3749 of ENR-4.1 published as a HTML page:
Another example from the French AIP which references the file
VAC-LFMV.pdf, more exactly page 3 of the VAC of LFMV airfield published as a PDF file:
@region attribute defines which area of responsibility a feature belongs to and may be assigned any valid region.
@region attribute has to be set on the
*Uid elements may contain many attributes and key properties, comparing them is challenging at times. Optional
@mid attributes facilitate this by adding a unique fingerprint to the corresponding
*Uid elements with identical
@mid values are to be considered identical without the need to compare any other attributes or key properties.
@mid attribute has to be set on the
@mid value is calculated from the attributes and properties of the
*Uid by use of this payload hash function.
- When importing data to OFM databases, existing
@midattributes are ignored and rebuilt.
- When exporting data from OFM, all
*Uidelements are enriched with
@midattributes formatted as UUID version 4.