Revision History
20 Dec 2023 Minor addtion of options and values added by 11.30 through 12.00
7 Nov 2022 Minor corrections for X-Plane 12 early access.
1 May 2022 Add row codes 1402, 1501 for custom service trucks & jetways
16 Nov 2021 Spec created, based upon most recent apt.dat 11.30 spec.
Add new surface types for runways, taxiways, helipads.
Add property extensions for runway markings and lights.
New row code 1500 for moving jetways.
16 Nov 2021 Updated new lines styles added in 11.30, correct wording in row code 21 name field
11 Apr 2019 Updated with new COM frequency capabilities added in 11.30.
14 Feb 2018 Minor corrections to Definition of Data fields
25 Jan 2017 Spec created, based upon prior apt.dat 1050 spec.
Applicability
This specification (APT.DAT 1200) is supported in X-Plane 12.00 and later and by WorldEditor 2.5 and later. The prior specification for airport data was APT.DAT 1130, which is recommended for X-Plane 11.30+.
This spec is an extension to 1130 – all features in 1130 are fully supported.
The deprecated file specifications (APT.DAT 1050, 1000) are still supported. A dwindling quantity of custom airport data exists only in this format. So airports defined according to these specifications can be included in a file otherwise complying with the most recent specification.
Overview & Scope
This specification defines core airport data for X-Plane. This includes the locations of runways, taxiway and apron pavement, basic airport ‘furniture’ (VASI/PAPIs, windsocks, light beacons and taxiway signage) and communications frequencies. It also includes attributes for each of these features to fully describe them (eg. it includes runway surface type, runway markings, taxiway lighting and markings, approach lighting, taxiway sign text, etc).
This specification (1200) introduces new surface types, extensions for runway markings & lights, and new row codes.
This specification does not include scenery objects (such as buildings, static aeroplanes or underlying terrain textures).
Basic concepts
- Latitudes and longitudes are described in a decimal notation (eg. 20.12345678) up to 8 decimal places.
- A latitude of 50 degrees 30 minutes south would be defined as -50.50000000
- North latitudes and east longitudes are positive. South latitudes and west longitudes are negative.
- All headings are referenced to true north (not magnetic north).
File Characteristics
The apt.dat files are plain text files:
- Fields in the data can be separated by one or more white space characters (space, tab).
- By default, the files are generated so that columns of data are consistently aligned, but this is not required.
- Blank rows are permitted and are helpful to differentiate between airports.
- Comments are permitted and are indicated by “#” as the first two characters of a row.
File Structure
It is recommended that all airports be created in WorldEditor (“WED”). This will ensure that all structural requirements listed here for airport data are met. WED version 2.5 is required to support all the features in this spec.
In common with most other X-Plane data file specification, header rows of data define the origin of a particular copy of a file, and define the file specification version. The file specification may be followed by a reference to a sequential release data cycle and build number for the data, and a version information message:
I
1000 Version – written by WorldEditor 2.5.0r2
Each row of data has a numeric ‘row code’ as its first field, to define its content.
- The top level of this hierarchy defines an individual airport, defined by an airport header row (a row code of ‘1’, ‘16’ or ‘17’).
- Subsequent rows define elements of an airport:
- Runways (including helipads) follow the airport header row (one row per runway).
- Pavement (taxiway/apron) definitions have a header row followed by an ordered list of nodes that define its boundaries:
- Each pavement definition must each have a single boundary with no overlaps with itself.
- Nodes on this outer boundary must be defined in a counter-clockwise direction.
- Boundaries must be terminated with a node with a row code ‘113’ or ‘114’.
- Pavement definitions may overlap with another pavement chunk. But this is not recommended – instead consider precise alignment of adjacent features by ‘snapping’ nodes to identical locations in World Editor (WED).
- A pavement definition can never overlap with itself.
- The sequencing of the pavement definitions is the layering in which they will be rendered in X-Plane, top-down. So the last piece of pavement in the file will be rendered underneath any others with which it overlaps.
- Holes can be defined for pavement (through which the underlying terrain texture will show):
- Hole boundaries should follow the termination of the pavement definition in which the hole occurs (starting with a row type ‘111’ or ‘112’).
- Hole boundaries are defined in a clockwise direction (ie, opposite direction to the boundary nodes).
- Hole boundaries must form a closed loop (ie. must terminate with a row code ‘113’ or ‘114’).
- Each pavement definition can have zero, one or multiple hole boundaries.
- Hole boundaries must be contained within the outer boundary of the pavement definition.
- Holes cannot overlap each other.
- After creating a hole boundary, it can be ‘filled’ with a new pavement chunk (probably using a different surface type).
- Linear features also have a header row followed by an ordered list of nodes that define the line:
- Linear features can be closed loops (terminating in a node of type ‘113’ or ‘114’) or just strings (terminating with ‘115’ or ‘116’).
- An airport boundary is defined with nodes in a counter-clockwise direction. A boundary can contain holes (see above) and must form a closed loop (terminating in a node of type ‘113’ or ‘114’).
- Airport traffic flows have a header row (row code ‘1000’) followed by multiple rows that define rules of multiple classes (time, wind direction, ceiling, visibility, runway in use, VFR traffic pattern) that indicated that a flow should be used (wind rules, minimum ceiling rules, visibility rules, time rules, and operations rules).
- A flow is acceptable if any rule of a class is acceptable, or if there are no rules of a given class. So to permit a flow with no time restrictions, simply exclude any traffic time rules (row code ‘1004’).
- Rules use ‘or’ logic. For example, a flow may have two wind rules (row code ‘1001’) – one for slight winds very generally aligned with a runway, and one with strong winds only if they are almost exactly with the runway.
- A flow will be used only if all its rule classes are ‘passed’.
- The flows are evaluated in sequence. The first flow to ‘pass’ will be used. So, the most specific-but-useful rule should be listed first (eg. parallel VFR approaches on a clear, calm day) and the most general (but least useful) rules should be listed last (eg. a single ILS cat III approach to a single runway).
- If the rules prevent any defined flow from being ‘passed’ then X-Plane’s AI engine will create a flow.
- ‘Runway in use’ rules (row code 1100) are also evaluated in sequence. The first ‘runway in use’ rule to ‘pass’ will be used for the parent flow. So rules should be listed in preferential sequence.
- Airport taxi routes & networks begin with a row code ‘1200’ and are defined by a set of nodes (row code ‘1201’) and ‘edges’ (the taxi routing) that connect two nodes (row code ‘1202’):
- Nodes can be defined as ‘init’ (a point at which X-Plane will try to start a taxi route), ‘end’ (where X-Plane will try to end a taxi route), or ‘both’. ‘junc’ can also be used for junctions between taxi routes.
- Edges must specify an allowed width, sizes A-E, and may be followed by multiple rows (row code ‘1204) defining an ‘active zone’ ‘for that parent edge (eg. if the edge conflicts with arrival or departure runways, or an ILS-critical area).
- Taxi routings begin or end at ramp locations (row code ‘1300’), which are also available as startup-locations in X-Plane. These locations may not be directly connected to the taxi route network – X-Plane’s ATC engine will calculate how to direct an airplane between the taxi route network and each location.
- Ground truck route edges (row code ‘1206’), parking locations (row code ‘1400’), and destinations (row code ‘1401’) are included under row code header ‘1200’ for taxi networks.
- Other airport features are defined with one row for each feature.
The file is terminated by a ‘99’:
99
Row Codes
Each row of data begins with an integer code that defines the type of data:
Row Code |
Meaning |
Comment |
|
|
|
1 |
Land airport header |
|
16 |
Seaplane base header |
|
17 |
Heliport header |
|
|
|
|
100 |
Runway |
|
101 |
Water runway |
|
102 |
Helipad |
|
|
|
|
110 |
Pavement (taxiway or ramp) header |
Must form a closed loop |
120 |
Linear feature (painted line or light string) header |
Can form closed loop or simple string |
130 |
Airport boundary header |
Must form a closed loop |
|
|
|
111 |
Node |
All nodes can also include a “style” (line or lights) |
112 |
Node with Bezier control point |
Bezier control points define smooth curves |
113 |
Node with implicit close of loop |
Implied join to first node in chain |
114 |
Node with Bezier control point, with implicit close of loop |
Implied join to first node in chain |
115 |
Node terminating a string (no close loop) |
No “styles” used |
116 |
Node with Bezier control point, terminating a string (no close loop) |
No “styles” used |
|
|
|
14 |
Airport viewpoint |
One or none for each airport |
15 |
Aeroplane startup location |
*** Convert these to new row code 1300 *** |
18 |
Airport light beacon |
One or none for each airport |
19 |
Windsock |
Zero, one or many for each airport |
20 |
Taxiway sign (inc. runway distance-remaining signs) |
Zero, one or many for each airport |
21 |
Lighting object (VASI, PAPI, Wig-Wag, etc.) |
Zero, one or many for each airport |
|
|
|
1000 |
Airport traffic flow |
Zero, one or many for an airport. Used if following rules met (rules of same type use ‘or’ logic, rules of a different type use ‘and’ logic). First flow to pass all rules is used. |
1001 |
Traffic flow wind rule |
Zero, one or many for a flow. Multiple rules use ‘or’ logic. |
1002 |
Traffic flow minimum ceiling rule |
Zero or one rule for each flow |
1003 |
Traffic flow minimum visibility rule |
Zero or one rule for each flow |
1004 |
Traffic flow time rule |
Zero, one or many for a flow. Multiple rules use ‘or’ logic. |
1100 |
Runway-in-use arrival/departure constraints, 10kHz frequency resolution |
First constraint met is used. Sequence matters! |
1110 |
Runway-in-use arrival/departure constraints, 1kHz frequency resolution |
Alternate option to row code 1100. |
1101 |
VFR traffic pattern |
Zero or one pattern for each traffic flow |
|
|
|
1200 |
Header indicating that taxi route network data follows |
|
1201 |
Taxi route network node |
Sequencing must be 0 based, ascending by ID. Must be part of one or more edges. |
1202 |
Taxi route network edge |
Must connect two nodes |
1204 |
Taxi route edge active zone |
Can refer to up to 4 runway ends |
1205 |
Taxi route edge control |
Replaces 1203 |
1206 |
Taxi route edge |
Ground vehicles only |
|
|
|
1300 |
Start up location (deprecates code 15) |
Not explicitly connected to taxi route network |
1301 |
Start up location metadata |
Consists of an ICAO width code, an operations type code and zero or more space separated 3-letter airline codes |
1302 |
Airport identification metadata |
Zero, one or many for each airport |
|
|
|
1400 |
Truck Parking Location |
Not explicitly connected to taxi route network |
1401 |
Truck Destination Location |
Must not allow car pile ups due to bad one way designs |
1402 |
Custom Truck Objects |
Overrides objects used in last preceeding 1500 rowcode |
|
|
|
1050 –1056 |
8.33kHz communication frequencies (11.30+) |
Zero, one or many for each airport |
50 – 56 |
Legacy 25kHz communication frequencies |
Zero, one or many for each airport. Ignored if row codes 1050-1056 exist. |
|
|
|
1500 |
Active jetway |
|
1502 |
Custom Jetway Objects |
Overrides objects used in last preceeding 1500 rowcode |
Example Data
Here is some example data for KBFI. It is not real and is very incomplete, but it illustrates examples of most types of data found in an apt.dat file. This data includes an airport header, runway, water runway, helipad, PAPI, taxiway definition, painted line, viewpoint, startup location, light beacon, windsock, taxiway sign and an ATC communications frequency:
1 21 1 0 KBFI Boeing Field King Co Intl
100 29.87 1 0 0.15 0 2 1 13L 47.53801700 -122.30746100 73.15 0.00 2 0 0 1 31R 47.52919200 -122.30000000 110.95 0.00 2 0 0 1
101 49 1 08 35.04420900 -106.59855700 26 35.04420911 -106.59855711
102 H1 47.53918248 -122.30722302 2.00 10.06 10.06 1 0 0 0.25 0
21 47.53666659 -122.30585255 2 150.28 3.30 13L PAPI-2L
110 1 0.25 150.29 A2 Exit
111 47.53770968 -122.30849802
111 47.53742819 -122.30825844 3
112 47.53752190 -122.30826710 47.53757385 -122.30824831 3 102
114 47.53768630 -122.30834929 47.53768690 -122.30838150 3 102
120 Line B1
111 47.53969864 -122.31276189 51
111 47.53977825 -122.31255145 1
115 47.54002296 -122.31189878
14 47.52917900 -122.30434900 100 0 ATC Tower
15 47.52926674 -122.29919589 304.16 A8 Run Up
18 47.52920400 -122.30412800 1 BCN
19 47.53900921 -122.30868700 1 WS
20 47.54099177 -122.31031317 235.71 0 2 {@L}A1{@R}31R-13L
50 12775 ATIS
Here is some example data for KSEA showing the 1000 version traffic flow and taxi route data:
1000 Calm and South flow
1001 KSEA 000 359 5
1001 KSEA 070 250 999
1002 KSEA 0
1003 KSEA 0
1004 0000 2400
1100 16C 11920 arrivals jets|turboprops|props 160340 161161 Arrival 16C
1100 16R 11920 arrivals jets|turboprops|props 341159 161161 Arrival 16R
1100 16L 11920 arrivals heavy 000359 161161 Arrival Heavy Jets
1101 16R right
1200
1201 47.46360812 -122.30613338 both 5416 A_stop
1202 5258 5266 twoway taxiway B
1204 ils 34R
1300 47.43931757 -122.29806851 88.78 gate jets|turboprops A10
Here is some example data for KSEA showing the 1050 metadata and 1100 ground truck additions:
1302 city Seattle
1302 country United States
1302 datum_lat 47.449888889
1302 datum_lon -122.311777778
1302 faa_code SEA
1302 iata_code SEA
1302 icao_code KSEA
1206 107 11 twoway C
1300 47.44158755 -122.30116873 44.78 gate jets A3
1301 D airline dal
1400 47.44374472 -122.30463464 88.1 baggage_train 3 Svc Baggage
1401 47.44103438 -122.30382493 0.0 baggage_train Luggage Train Destination South 2
Definition of Data Fields
Each column in each row code is defined below, using the example data from KBFI & KSEA shown above. Note that:
- Some row codes store data in an identical specification, and these have been grouped together in the table below.
- The specification aims to be consistent. For example, the format or latitudes and longitudes is always the same, and all headings/orientations are defined as true (not magnetic) degrees.
Row |
Meaning |
Comment |
|
|
|
Explanation |
Valid values |
|
|
|
|
1 |
Land airport header |
Row codes 1, 16 and 17 share a common format (see below) |
|
16 |
Seaplane base header |
Row codes 1, 16 and 17 share a common format (see below) |
|
17 |
Heliport header |
Row codes 1, 16 and 17 share a common format (see below) |
|
|
1 |
Row code for an airport, seaplane base or heliport |
1, 16 or 17 |
|
21 |
Elevation of airport in feet above mean sea level (AMSL) |
|
|
1 |
Deprecated. Use default value (“0”) |
Use 0 |
|
0 |
Deprecated. Use default value (“0”) |
Use 0 |
|
KBFI |
Airport Identifier. X-Plane internal use only, not used for user-facing functions, NOT used to determine the “ICAO code” by X-Plane >10.45.. See rowcode 1302. Use X + local identifier to create fictional on not Sceney gateway coordinates ID’s. |
Maximum seven characters. Must be unique and all upper case. |
|
Boeing Field King Co … |
Airport name. May contain spaces. |
Text string (up to 40 characters) |
|
|
|
|
100 |
Land Runway |
|
|
|
100 |
Row code for a land runway (the most common) |
100 |
|
29.87 |
Width of runway in metres |
Two decimal places recommended. Must be >= 1.00 |
|
1 |
Code defining the surface type (concrete, asphalt, etc) |
Integer value for a Surface Type Code (see below) |
|
206 |
|
|
(= 2x 100 + 6) |
Code defining a runway shoulder surface type + 100x width of each shoulder in whole meters. |
See Surface Type Code below – all asphalt and concrete styles supported. |
|
If the number is >100, the 100-digit (and optionally 1000-digit) define the width of the shoulder in meters. |
|
|
|
If the number is <100 (i.e. only the surface code), width is same as X-Plane 11, scaling with runway tpe and width, some 3-5 meters. |
|
|
|
|
0.15 |
Runway smoothness (not used by X-Plane yet) |
0.00 (smooth) to 1.00 (very rough). Default is 0.25 |
|
0 |
Runway centre-line lights |
0=no centerline lights, 1=centre line lights |
|
2 |
Runway edge lighting (also implies threshold lights) |
0=no edge lights, 2=medium intensity edge lights |
|
1 |
Auto-generate distance-remaining signs (turn off if created manually) |
0=no auto signs, 1=auto-generate signs |
|
The following fields are repeated for each end of the runway |
|
|
|
13L |
Runway number (eg. “31R”, “02”). Leading zeros are required. |
Two to three characters. Leading zero’s are printed, if present. |
Valid suffixes: “L”, “R”, “C” (visible in markings on paved surfaces) |
|
|
|
Suffixes “W”, “S” and “T” are valid, but never printed. |
|
|
|
|
47.53801700 |
Latitude of runway end (on runway centerline) in decimal degrees |
Eight decimal places supported |
|
-122.30746100 |
Longitude of runway end (on runway centerline) in decimal degrees |
Eight decimal places supported |
|
73.15 |
Length of displaced threshold in metres (this is included in implied runway length)A displaced threshold will always be inside (between) the two runway ends |
Two decimal places (metres). Default is 0.00 |
|
0.00 |
Length of overrun/blast-pad in metres (not included in implied runway length) |
Two decimal places (metres). Default is 0.00 |
|
2 |
Code for runway markings (Visual, non-precision, precision) |
Integer value for Runway Marking Code (see below) |
|
0 |
Code for approach lighting for this runway end |
Integer value for Approach Lighting Code (see below) |
|
0 |
Flag for runway touchdown zone (TDZ) lighting |
0=no TDZ lighting, 1=TDZ lighting |
|
1 |
Code for Runway End Identifier Lights (REIL) |
0=no REIL, 1=omni-directional REIL, 2=unidirectional REIL, |
|
|
|
|
101 |
Water runway |
|
|
|
101 |
Row code for a water runway |
101 |
|
49 |
Width of runway in metres |
Two decimal places recommended. Must be >= 1.00 |
|
1 |
Flag for perimeter buoys |
0=no buoys, 1=render buoys |
|
The following fields are repeated for each end of the water runway |
|
|
|
08v |
Runway number. Not rendered in X-Plane (it’s on water!) |
Valid suffixes “W” (or blank) |
|
35.04420911 |
Latitude of runway end (on runway centerline) in decimal degrees |
Eight decimal places supported |
|
-106.59855711 |
Longitude of runway end (on runway centerline) in decimal degrees |
Eight decimal places supported |
|
|
|
|
102 |
Helipad |
|
|
|
102 |
Row code for a helipad |
101 |
|
H1 |
Designator for a helipad. Must be unique at an airport. |
Usually “H” suffixed by an integer (eg. “H1”, “H3”) |
|
47.53918248 |
Latitude of helipad centre in decimal degrees |
Eight decimal places supported |
|
-122.30722302 |
Longitude of helipad centre in decimal degrees |
Eight decimal places supported |
|
2.00 |
Orientation (true heading) of helipad in degrees |
Two decimal places recommended |
|
10.06 |
Helipad length in metres |
Two decimal places recommended (metres), must be >=1.00 |
|
10.06 |
Helipad width in metres |
Two decimal places recommended (metres), must be >= 1.00 |
|
1 |
Helipad surface code |
Integer value for a Surface Type Code (see below) |
|
0 |
Helipad markings |
0 (other values not yet supported) |
|
0 |
Code defining a helipad shoulder surface type |
0=no shoulder, 1=asphalt shoulder, 2=concrete shoulder |
|
0.25 |
Helipad smoothness (not used by X-Plane yet) |
0.00 (smooth) to 1.00 (very rough). Default is 0.25 |
|
0 |
Helipad edge lighting |
0=no edge lights, 1=yellow edge lights |
|
|
|
|
110 |
Pavement (taxiways) |
Defines an arbitrary pavement shape |
|
|
110 |
Row code for a pavement chunk header (must be followed by a set of nodes) |
110 |
|
1 |
Code defining the surface type (concrete, asphalt, etc) |
Integer value for a Surface Type Code (see below) |
|
0.25 |
Runway smoothness (not used by X-Plane yet) |
0.00 (smooth) to 1.00 (very rough). Default is 0.25 |
|
150.29 |
Orientation (true degrees) of pavement texture ‘grain’ |
Two decimal places recommended |
|
A2 Exit |
Description of pavement chunk (not used by X-Plane) |
Text string |
|
|
|
|
120 |
Linear feature |
Painted surface markings & light strings |
|
130 |
Airport boundary |
Boundary for future terrain ‘flattening’ |
|
|
120 |
Row code for a linear feature or airport boundary |
120 or 130 |
|
Line B1 |
Description of feature or boundary (not used by X-Plane) |
Text string |
|
|
|
|
111 |
Node |
Node (plain) |
|
112 |
Node |
Node with Bezier control point |
|
113 |
Node |
Node (close loop), to close boundary |
|
114 |
Node |
Node (close loop) with Bezier control point |
|
115 |
Node |
Node (end) to terminate a line |
|
116 |
Node |
Node (end) with Bezier control point |
|
|
112 |
Row code for a node. First node must follow an appropriate header row |
111 thru 116 |
|
47.53752190 |
[All nodes] Latitude of node in decimal degrees |
Eight decimal places supported |
|
-122.30826710 |
[All nodes] Longitude of node in decimal degrees |
Eight decimal places supported |
|
47.53757385 |
[112, 114, 116 only] Latitude of Bezier control point in decimal degrees |
Eight decimal places supported. Ignore for 111, 113, 115 |
|
-122.30824831 |
[112, 114, 116 only] Latitude of Bezier control point in decimal degrees |
Eight decimal places supported. Ignore for 111, 113, 115 |
|
3 |
[Not for 115 or 116] Code for painted line type on line segment starting at this node |
Integer Line Type Code (see below). Not for 115 or 116 |
|
102 |
[Not for 115 or 116] Code for lighting on line segment starting at this node |
Integer Line Type Code (see below). Not for 115 or 116 |
|
|
|
|
14 |
Viewpoint |
Maximum of one viewpoint for each airport |
|
|
14 |
Row code for a viewpoint |
14 |
|
47.52917900 |
Latitude of viewpoint in decimal degrees |
Eight decimal places supported |
|
-122.30434900 |
Longitude of viewpoint in decimal degrees |
Eight decimal places supported |
|
100 |
Height (in feet) of viewpoint above ground level |
Integer |
|
0 |
Code deprecated. Use ‘0’ |
0 |
|
ATC Tower |
Name of viewpoint (not used by X-Plane) |
Descriptive text string (optional) |
|
|
|
|
15 |
Startup location |
Startup locations for airplanes at an airport |
Should be converted to new row code 1300 |
|
15 |
Row code for a startup location |
15 |
|
47.52926674 |
Latitude of startup location in decimal degrees |
Eight decimal places supported |
|
-122.29919589 |
Longitude of startup location in decimal degrees |
Eight decimal places supported |
|
304.16 |
Heading (true) of an aeroplane when positioned at startup location |
Two decimal places recommended |
|
A6 Run Up |
Name of startup location (list will be displayed in X-Plane for each airport) |
Short descriptive text string – ten characters or less |
|
|
|
|
18 |
Light beacon |
Maximum of one beacon for each airport |
|
|
18 |
Row code for an airport light beacon |
18 |
|
47.52920400 |
Latitude of beacon in decimal degrees |
Eight decimal places supported |
|
-122.30412800 |
Longitude of beacon in decimal degrees |
Eight decimal places supported |
|
1 |
Code for type of light beacon. Determines colors of beacon. |
Integer Beacon Type Code (see below) |
|
BCN |
Name of viewpoint (not used by X-Plane) |
Descriptive text string (optional) |
|
|
|
|
19 |
Windsock |
Multiple windsocks permitted for each airport |
|
|
19 |
Row code for a windsock |
19 |
|
47.53900921 |
Latitude of windsock in decimal degrees |
Eight decimal places supported |
|
-122.30868700 |
Longitude of windsock in decimal degrees |
Eight decimal places supported |
|
1 |
Flag for windsock lighting |
0=unlit, 1=illuminated |
|
WS |
Name of viewpoint (not used by X-Plane) |
Descriptive text string (optional) |
|
|
|
|
20 |
Signs |
Taxiway signs or runway distance-remaining signs |
|
|
20 |
Row code for a sign |
20 |
|
47.54099177 |
Latitude of sign in decimal degrees |
Eight decimal places supported |
|
-122.31031317 |
Longitude of sign in decimal degrees |
Eight decimal places supported |
|
235.71 |
Orientation of sign in true degrees (heading of someone looking at sign’s front) |
Two decimal places recommended |
|
0 |
Reserved for future use. Ignore. |
0 |
|
2 |
Code for sign size |
Integer Sign Size Code (see below) |
|
{@L}A1{@R}31R-13L |
Text to be rendered on sign front and/or back |
Text string formatted by Sign Text Definition (see below) |
|
|
|
|
21 |
Lighting objects |
VASI, PAPI, wig-wags, etc. |
|
|
21 |
Row code for a lighting object |
21 |
|
47.53666659 |
Latitude of lighting object in decimal degrees |
Eight decimal places supported |
|
-122.30585255 |
Longitude of lighting object in decimal degrees |
Eight decimal places supported |
|
2 |
Code for type of lighting object |
Integer Lighting Object Code (see below) |
|
150.28 |
Orientation of lighting object in true degrees (looking toward object) |
Two decimal places recommended |
|
3.30 |
Visual glideslope angle in degrees |
Two decimal places. 0.00 if not required. Default is 3.00 |
|
PAPI-2L |
Name of lighting object (not used by X-Plane] |
Short text string (optional) |
|
|
|
|
1000 |
Traffic flow |
Arrival and departure traffic flows |
|
|
1000 |
Row code for an arrival/departure traffic flow |
1000 |
|
Calm and south flows |
Traffic flow name |
Descriptive name (max 50 characters) |
|
|
|
|
1001 |
Traffic flow wind rule |
Zero or multiple wind rules permitted per flow |
|
|
1001 |
Row code for a traffic flow wind rule |
1001 |
|
KSEA |
METAR reporting station (may be a remote airport, eg KSEA for KBFI) |
ICAO code, up to 7 characters |
|
000 |
Wind direction minimum (magnetic) |
000 – 359 |
|
359 |
Wind direction maximum (magnetic) |
000 – 359 |
|
5 |
Maximum wind speed. Use 999 for ‘all’ wind speeds. |
0 – 999 |
|
|
|
|
1002 |
Traffic flow ceiling rule |
Zero or one ceiling rule permitted per flow |
|
|
1002 |
Row code for a traffic flow ceiling rule |
1002 |
|
KSEA |
METAR reporting station (may be a remote airport, eg KSEA for KBFI) |
ICAO code, up to 7 characters |
|
0 |
Minimum reported ceiling in feet AGL at reporting station |
Positive integer |
|
|
|
|
1003 |
Traffic flow visibility rule |
Zero or one visibility rule permitted per flow |
|
|
1003 |
Row code for a traffic flow visibility rule |
1003 |
|
KSEA |
METAR reporting station (may be a remote airport, eg KSEA for KBFI) |
ICAO code, up to 7 characters |
|
0 |
Minimum reported visibility in statute miles |
Float (eg. “1.5”) |
|
|
|
|
1004 |
Traffic time rule |
Zero or multiple time rules permitted per flow |
|
|
1004 |
Row code for a traffic flow time rule |
1004 |
|
0000 |
UTC time from which rule is valid |
0000 – 2400 |
|
2400 |
UTC time at which rule ends |
0000 – 2400 |
|
|
|
|
1100 |
Runway-in-use rule |
Multiple rules for each flow. First to ‘pass’ is used |
|
|
1100 |
Row code for a runway-in-use rule |
1100 |
|
34C |
Runway end identifier |
Two to three characters. Valid suffixes: “L”, “R” or “C” (or blank) |
|
11920 |
Arrival or departure frequency |
Five digit integer, rounded DOWN where necessary. 10kHz resolution only. |
|
arrivals |
Rule type (arrivals, departures) |
Pipe separated list (“ |
|
jets |
turboprops |
Airplane types to which rule applies |
|
181359 |
On course heading range ((ie. first leg of flight plan for departures, last leg for arrivals) |
000000 – 359359 |
|
341341 |
Initial ATC assigned departure heading range. Not used for arrivals. |
000000 – 359359 |
|
Arrival 34C |
Rule name |
Descriptive name (max 50 characters) |
|
|
|
|
1110 |
Runway-in-use rule |
Replaces 1100 row code, supports 8.33kHz radio frequencies. Multiple rules for each flow. First to ‘pass’ is used. |
|
|
1110 |
Row code for a runway-in-use rule |
1110 |
|
34C |
Runway end identifier |
Two to three characters. Valid suffixes: “L”, “R” or “C” (or blank) |
|
118325 |
Arrival or departure frequency |
Six digit integer, rounded DOWN where necessary, 1kHz resolution |
|
arrivals |
Rule type (arrivals, departures) |
Pipe separated list (“ |
|
jets |
turboprops |
Airplane types to which rule applies |
|
181359 |
On course heading range ((ie. first leg of flight plan for departures, last leg for arrivals) |
000000 – 359359 |
|
341341 |
Initial ATC assigned departure heading range. Not used for arrivals. |
000000 – 359359 |
|
Arrival 34C |
Rule name |
Descriptive name (max 50 characters) |
|
|
|
|
1101 |
VFR pattern rule |
Zero or one VFR pattern rule permitted per flow |
|
|
1101 |
Row code for a VFR traffic pattern |
1101 |
|
34L |
Runway end identifier |
Two to three characters. Valid suffixes: “L”, “R” or “C” (or blank) |
|
left |
VFR traffic pattern direction |
“left” or “right” |
|
|
|
|
1200 |
Taxi routing network |
(for readability only) |
|
|
|
|
|
1201 |
Taxi routing node |
All nodes must be used in at least one edge |
|
|
1201 |
Row code for taxi routing network node |
1201 |
|
47.53752190 |
Latitude of node in decimal degrees |
Eight decimal places supported |
|
-122.30826710 |
Longitude of node in decimal degrees |
Eight decimal places supported |
|
both |
Usage of node in network (begin or end a taxi path, or both) |
“dest”, “init”, “both” or “junc” |
|
5416 |
Node identifier (defined in 0 based sequence, ascending) |
Integer. Must be unique within scope of an airport. |
|
A_start |
Node name. Not currently used. |
String (max 16 characters) |
|
|
|
|
1202 |
Taxi routing edge |
Segment in taxi routing network |
|
|
1202 |
Row code for taxi routing network edge |
1202 |
|
5416 |
Node identifier for start of edge |
Integer. Must refer to valid node (row code ‘1201’) |
|
5417 |
Node identifier for end of edge |
Integer. Must refer to valid node (row code ‘1201’) |
|
twoway |
Edge can be used in both directions |
“twoway” or “oneway” |
|
taxiway_a |
Edge ATC restrictions. If “runway” a clearance is needed from ATC. If “taxiway_a” the trailing single letter denotes maximum wingspan for aircraft routed on that taxiway. |
“runway” or |
”taxiway_” |
|
|
|
with = a |
b |
c |
d |
|
A |
Taxiway identifier. Used to build ATC taxi clearances (eg. “.. .taxi via A, T, Q”) |
String. Taxiway or runway identifier (eg. “A” or “16L/34R”) |
|
|
|
|
1204 |
Edge active zone |
Identifies an edge as in a runway active zone. |
|
|
1204 |
Row code for an edge entering a runway active zone |
1204 |
|
arrival |
Active zone classification |
“arrival” or “departure” or “ils” |
|
16L,16C |
Runway(s) to which active zone refers |
Comma-separated list up to 4 runway identifies |
|
|
|
|
1206 |
Taxi routing edge (ground vehicles) |
Segment in taxi routing network (ground vehicles only) |
|
|
1206 |
(See 1202) |
(See 1202) |
|
107 |
(See 1202) |
(See 1202) |
|
11 |
(See 1202) |
(See 1202) |
|
twoway |
(See 1202) |
(See 1202) |
|
|
|
|
1300 |
Start up location |
Start or end point for aircraft. Not linked to taxi routing network by edges (row code 1202) |
|
|
1300 |
Row code for taxi route start/end point |
1300 |
|
47.44158755 |
Latitude of location in decimal degrees |
Eight decimal places supported |
|
-122.30116873 |
Longitude of location in decimal degrees |
Eight decimal places supported |
|
44.78 |
Heading (true) of airplane positioned at this location |
Decimal degrees, true heading |
|
gate |
Type of location |
“gate”, “hangar”, “misc” or “tie-down” |
|
jets |
Airplane types that can use this location |
Pipe-separated list (“ |
|
A3 |
Unique name of location |
Text string, must be unique within a single airport |
|
|
|
|
1301 |
Row Code |
For ramp start metadata |
|
|
1301 |
|
1301 |
|
d |
ICAO width code |
A, B, C, D, E, F |
|
airline |
Operation type |
none, general_aviation, airline, cargo, military |
|
dal |
Airline permitted to use this ramp |
3-letter airline codes (AAL, SWA, etc) |
|
|
|
|
1302 |
Row Code |
Airport metadata |
|
|
1302 |
row code |
Takes zero, any or all applicable Key_values |
|
icao_id |
key_value for ICAO code |
icao_id, faa_id, iata_id, city_id, country_id, region_id, local_id, local_authorithy, transition_alt_,_ transition_level, gui_3d, is_oilrig, allows_circuits |
|
KSEA |
ICAO for airport |
Unique identifier up to 7 characters long |
|
|
|
|
1400 |
Truck Parking |
|
|
|
1400 |
row code |
|
|
47.44374472 |
Latitude of location in decimal degrees |
Eight decimal places supported |
|
-122.30463464 |
Longitude of location in decimal degrees |
Eight decimal places supported |
|
88.1 |
Heading (true) of the OBJ positioned at this location |
Decimal degrees |
|
baggage_train |
type string |
baggage_loader, baggage_train, crew_car, crew_ferrari, crew_limo, pushback, fuel_liners, fuel_jets, fuel_props, food, gpu |
|
3 |
|
0 to 10 if type is baggage_train, 0 if not |
|
Svc Baggage |
Name of parking |
Text string |
|
|
|
|
1401 |
Truck Destination |
|
|
|
1401 |
row code |
|
|
47.44103438 |
Latitude of location in decimal degrees |
Eight decimal places supported |
|
-122.30382493 |
Longitude of location in decimal degrees |
Eight decimal places supported |
|
0.0 |
Heading (true) of the positioned at this location |
Decimal Degrees, true heading |
|
baggage_train |
Truck types allowed to end up at this destination |
Pipe separated list (“ |
|
Luggage Train Destination South 2 |
Name of Truck Destination |
Text string |
1402 |
Custom service truck |
|
|
|
myLib/myCrewCar.obj |
vpath to custom object to replace default object for vehicle in in last 1400 row code preceding this |
If vpath is not defined, this rowcode is silently ignored and the last preceeding 1400 record keeps using the default vehicle. |
|
|
|
|
1050 |
ATC – Recorded |
AWOS, ASOS or ATIS |
|
1051 |
ATC – Unicom |
Unicom (US), CTAF (US), Radio (UK) |
|
1052 |
ATC – CLD |
Clearance Delivery |
|
1053 |
ATC – GND |
Ground |
|
1054 |
ATC – TWR |
Tower |
|
1055 |
ATC – APP |
Approach |
|
1056 |
ATC – DEP |
Departure |
|
|
1052 |
Row code for ATC COM Frequency |
Supercedes row codes 50-56. |
|
128730 |
Frequency in kHz, 833kHz capable radio channels only |
118000 – 135995 |
|
ATIS |
Descriptive name (displayed on X-Plane charts) |
Short text string (10 characters or less recommended) |
|
|
|
|
50 |
ATC – Recorded |
AWOS, ASOS or ATIS |
|
51 |
ATC – Unicom |
Unicom (US), CTAF (US), Radio (UK) |
|
52 |
ATC – CLD |
Clearance Delivery |
|
53 |
ATC – GND |
Ground |
|
54 |
ATC – TWR |
Tower |
|
55 |
ATC – APP |
Approach |
|
56 |
ATC – DEP |
Departure |
|
|
51 |
Row code for an ATC COM frequency |
50 thru 56 (see above) |
|
12775 |
Frequency in MHz x 100 (eg. use “12322” for 123.225MHz) |
Five digit integer, rounded DOWN where necessary |
|
ATIS |
Descriptive name (displayed on X-Plane charts) |
Short text string (recommend less than 10 characters) |
|
|
|
|
1500 |
Active jetway |
|
|
|
46.512345 |
Latitude of location in decimal degrees |
Location of base of telescoping jetway tunnel |
|
-123.00345 |
Longitude of location in decimal degrees |
|
|
42.0 |
Heading of parked tunnel |
Decimal Degrees, true heading |
|
0 |
Jetway style code |
0 = light color, solid (metal) sidewalls |
1= light color, glass side walls |
|
|
|
2 = dark color, solid (metal) sidewalls |
|
|
|
3 = dark color, glass side walls |
|
|
|
|
2 |
Jetway size code |
0 = tunnel length 11 – 23m |
1 = tunnel length 14 – 29m |
|
|
|
2 = tunnel length 17 – 38m |
|
|
|
3 = tunnel length 20 – 47m |
|
|
|
|
0 |
Do not use or change |
not used, in X-Plane 12.00 |
|
17.5 |
Parked tunnel length |
In meters, must be within the extension capabilities according to the size code |
|
127.3 |
Parked cabin heading |
True north heading. Must be within the articulating capabilities of the jetway, which is from 0 to 90 degrees counter clockwise from the heading of the tunnel. |
1501 |
Custom jetway |
|
|
|
myLib/myJWgate8.obj |
vpath to custom cabin/tunnel object for replace LR default object in last 1500 row code preceeding this |
If vpath is not defined, this rowcode is silently ignores and the – default cabin/tunnel object is used as for the last preceding 1500 record |
|
|
|
|
Codes
Codes used to define airport data:
Codes |
Comment |
|
Code value |
Code meaning |
Code applicability |
Surface Type Code |
Surface type of runways or taxiways |
|
1 |
Asphalt |
|
2 |
Concrete |
|
3 |
Turf or grass |
|
4 |
Dirt (brown) |
|
5 |
Gravel (grey) |
|
|
|
|
12 |
Dry lakebed (eg. At KEDW) |
Example: KEDW (Edwards AFB) |
13 |
Water runways (do not use in XP10+, use rowcode for “sealane” instead) |
|
14 |
Snow or ice |
Poor friction. Runway markings cannot be added. |
15 |
Transparent |
Hard surface, but no texture/markings (use in custom scenery) |
|
|
|
20-23 |
Light colored asphalt |
Each “shade” of asphalt comes in 4 different subtypes differing in cracks, seams or dirt added to the base texture.The first subtype adds a moderate amount of seams, representing mid-aged asphalt that has not been repaired. |
The 2nd subtype adds dark, patched cracks, indicative of older, but well maintained asphalt. |
|
|
The 3rd subtype is “plain”, intended for manual additions of particular cracks & seams as a separate layer on top. |
|
|
The 4th subtype adds more cracked and discolored areas, aka “worn, fair shape or not well maintained” asphalt. |
|
|
1,24-26 |
Asphalt, comparable in brightness to XP11 asphalt |
|
27-30 |
Darker colored asphalt |
|
31-34 |
Very dark colored asphalt |
|
35-38 |
Near black, ‘new’ looking asphalt |
|
|
|
|
50-52 |
Light “new” looking concrete |
Each “shade” of concrete comes in 3 different subtypes differing in cracks or dirt added to the base texture.The first subtype looks very uniform, has no cracks, representing very good shape asphalt. |
The 2rd subtype is “dirty” looking, non-uniformly colored. |
|
|
The 3rd subtype is “worn” with cracks developing in addition to non-uniform coloring. |
|
|
2,53-54 |
Concrete, comparable in brightness to XP11 concrete |
|
55-57 |
Dark concrete |
|
Runway Marking Code |
Markings on runway |
|
0 |
No runway markings |
Disused runways appear like taxiways |
1 |
Visual markings |
|
2 |
Non-precision approach markings |
|
3 |
Precision approach markings |
|
4 |
UK-style non-precision approach markings |
UK uses distinctive touch-down zone markings |
5 |
UK-style precision approach markings |
UK uses distinctive touch-down zone markings |
6 |
EASA style non-precision approach markings |
EASA differs from FAA for location and number of distance marks on runway before/after touchdown zone bars |
7 |
EASA style precision approach markings |
|
Approach Lighting Code |
Approach lighting systems |
|
0 |
No approach lighting |
|
1 |
ALSF-I |
|
High intensity Approach Light System with sequenced flashing lights |
|
|
2 |
ALSF-II |
|
High intensity Approach Light System with sequenced Flashing lights |
|
|
Red side bar lights (barettes) the last 1000’, that align with TDZ lighting. |
|
|
3 |
Calvert |
|
British – High intensity |
|
|
4 |
Calvert ILS Cat II and Cat II |
|
British – High intensity with red side bar lights (barettes) the last 1000’ |
|
|
Barettes align with TDZ lighting |
|
|
5 |
SSALR |
|
High intensity, Simplified Short Approach Light System |
|
|
With Runway Alignment Indicator Lights (RAIL) |
|
|
6 |
SSALF |
|
High intensity, Simplified Short Approach Light System |
|
|
With sequenced flashing lights |
|
|
7 |
SALS |
|
High intensity, Short Approach Light System |
|
|
8 |
MALSR |
|
Medium-intensity Approach Light System |
|
|
With Runway Alignment Indicator Lights (RAIL) |
|
|
9 |
MALSF |
|
Medium-intensity Approach Light System with sequenced flashing lights |
|
|
10 |
MALS |
|
Medium-intensity Approach Light System |
|
|
11 |
ODALS |
|
Omni-directional approach light system |
|
|
Flashing lights, not strobes, not sequenced |
|
|
12 |
RAIL |
|
Runway Alignment Indicator Lights |
|
|
Sequenced strobes and green threshold lights, with no other approach lights |
|
|
Line Type Code |
Painted lines and light strings |
|
|
Note that for all linear features that involve runway entrance hold lines and associated lights (4, 5, 6, 103 & 104 below), the runway is assumed to be to the LEFT of the string and the taxiway to the RIGHT (looking along string from its first node) |
|
0 |
Nothing. |
|
1 |
Solid yellow line |
Taxiway centre lines |
2 |
Broken yellow line |
Miscellaneous boundaries |
3 |
Double solid yellow lines |
Taxiway edge lines |
4 |
Two broken yellow lines and two solid yellow lines. Broken line on left of string. |
Runway hold positions |
5 |
Broken yellow line with parallel solid yellow line. Broken line on left of string. |
Other (non-runway) hold locations |
6 |
Yellow cross-hatched line |
ILS hold |
7 |
Solid yellow line with broken yellow line on each side |
Taxiway centerlines in runway safety zones |
8 |
Widely separated, broken yellow line |
Mark ‘lanes’ for queuing aeroplanes |
9 |
Widely separated, broken double yellow line |
Mark ‘lanes’ for queuing aeroplanes |
51-59 |
Line types 1-9 above with a black border |
Use on concrete surfaces for higher contrast |
|
|
|
20 |
Solid white line |
Roadway markings |
21 |
White chequerboard pattern |
Roadway markings |
22 |
Broken white line |
Roadway centreline |
|
Note that lights added to the edge boundary of a piece of pavement (or hole) will be placed off the edge of the pavement (about one meter). |
|
101 |
Green embedded lights, bidirectional along string axis |
Taxiway centrelines |
102 |
Blue lights, omnidirectional |
Taxiway edge |
103 |
Closely spaced, embedded amber lights. Unidirectional to right of string |
Hold lines |
104 |
Closely spaced, pulsating embedded amber lights. Unidirectional to right of string |
Runway hold lines |
105 |
Alternating green and amber embedded lights, bidirectional along string axis |
Centrelines in runway safety zones |
106 |
Red lights, omnidirectional |
Edge lights in dangerous/critical zones (eg. on bridges) |
107 |
unidirectional steady green lights |
Runway lead-off lights |
108 |
unidirectional, alternating green and amber lights |
Runway lead-off lights inside runway safety zones |
Beacon Type Code |
Airport light beacons |
|
0 |
No beacon. Suppresses automatic creation of beacon by X-Plane. |
Use a dummy airport lat/lon for the location. |
1 |
White-green flashing |
Civilian land airport |
2 |
White-yellow flashing |
Seaplane base |
3 |
Green-yellow-white flashing |
Heliport |
4 |
White-white-green flashing |
Military airport |
Sign Size Code |
Taxiway sign sizes & types |
|
1 |
Small taxiway sign |
|
2 |
Medium taxiway sign |
|
3 |
Large taxiway sign |
|
4 |
Large distance-remaining sign on runway edge |
Alternatively, can be auto generated for a runway |
5 |
Small distance-remaining sign on runway edge |
Alternatively, can be auto generated for a runway |
Lighting Object Code |
Lighting objects |
|
1 |
VASI |
Location is centre point between the two VASI units |
2 |
PAPI-4L (four-light) on left of runway |
Left-handed: red indication appears first on right 2 lights |
3 |
PAPI-4R (four light) on right of runway |
Right-handed: red indication appears first on left 2 lights |
4 |
Space Shuttle PAPI, 20 degree glidepath |
Deprecated. Use normal PAPI with an appropriate angle. |
5 |
Tri-colour VASI |
|
6 |
Runway guard (“wig-wag”) lights |
Pulsating double amber lights alongside runway entrances |
7 |
APAPI L (two-light) on left of runway |
|
8 |
APAPI R (two-light) on right of runway |
|
Resources are available for airport designers at the X-Plane Scenery Gateway at //gateway.x-plane.com/
X-Plane Airport Data (apt.dat) File Specification Page of 1200 Version, 1-May-2022
X-Plane 12 uses an IGRF13-based grid for magnetic variation between July 2021 and June 2024. Within these dates, X-Plane’s magnetic variation will change over time based on real time.
Magnetic variation in X-Plane depends on the UTC date of the operating system’s clock, not the simulated time in X-Plane. That means, you can chose the date and time of your flight in X-Plane to be whatever you like to fly over your favourite seasonal forests, but the magnetic variation will always reflect the current real time.
Note that if your operating system’s clock is set earlier than July 2021 for any reason, the annual change in magnetic variation is capped there. It is generally required that you keep your operating system clock in sync with real time, especially if you want to use up-to-date navdata.
This information is historic and only relevant to X-Plane 10 and earlier
REVISION HISTORY
18 Jan 2017 Updated 1000 spec to final 1050 spec
APPLICABILITY
This specification (APT.DAT 1050) is supported in X-Plane 10.50 and later and by WorldEditor 1.5 and later. The prior specification for airport data was APT.DAT 1000, which is recommended for X-Plane 10.00-10.45. This spec is an extension to 1000 – all features in 1000 are fully supported.
SUPPORT FOR DEPRECATED FILE FORMATS
The deprecated file specification (APT.DAT 1000) is still supported. A dwindling quantity of custom airport data exists only in this format. So airports defined according to this specification (APT.DAT 1000) can be included in a file otherwise complying with the APT.DAT 1050 specification.
The specification for APT.DAT 1000 is available to view here.
OVERVIEW & SCOPE
This specification defines core airport data for X-Plane. This includes the locations of runways, taxiway and apron pavement, basic airport ‘furniture’ (VASI/PAPIs, windsocks, light beacons and taxiway signage), and communications frequencies. It also includes attributes for each of these features to fully describe them (eg. it includes runway surface type, runway markings, taxiway lighting and markings, approach lighting, taxiway sign text, etc).
This specification (1050) introduces new airport metadata to define additional characteristics for static spawning and for airport identifiers.
This specification does not include scenery objects (such as buildings, static aeroplanes or underlying terrain textures).
BASIC CONCEPTS
- Latitudes and longitudes are described in a decimal notation (eg. 20.12345678) up to 8 decimal places.
- A latitude of 50 degrees 30 minutes south would be defined as -50.50000000
- North latitudes and east longitudes are positive. South latitudes and west longitudes are negative.
- All headings are referenced to true north (not magnetic north).
FILE CHARACTERISTICS
The apt.dat files are plain text files:
- Fields in the data can be separated by one or more white space characters (space, tab).
- By default, the files are generated so that columns of data are consistently aligned, but this is not required.
- Blank rows are permitted and are helpful to differentiate between airports.
- Comments are permitted and are indicated by “#” as the first two characters of a row.
FILE STRUCTURE
All airports must be created in WorldEditor (“WED”). This will ensure that all structural requirements listed here for airport data are met. WED version 1.5 is required to support all features in this spec.
In common with most other X-Plane data file specification, header rows of data define the origin (“I” = PC or “A” = Mac) of a particular copy of a file, and define the file specification version. The file specification may be followed by a reference to a sequential release data cycle and build number for the data, and a copyright message:
I
1000 Version - data cycle 2012.03, build 20121054, metadata AptXP1000. Copyright © 2012, Robin A. Peel (robin@xsquawkbox.net)...
The complete copyright message must be left intact if you redistribute this data. The GNU GPL (general public License) under which this data is released is designed to encourage modifications, enhancements and redistribution, even in commercial derivative products.
Subsequent rows of data follow a hierarchical structure:
- Each row of data has a numeric ‘row code’ as its first field, to define its content.
- The top level of this hierarchy defines an individual airport, defined by an airport header row (a row code of ‘1’, ‘16’ or ‘17’).
- Subsequent rows define elements of an airport:
- Runways (including helipads) follow the airport header row (one row per runway).
- Pavement (taxiway/apron) definitions have a header row followed by an ordered list of nodes that define its boundaries:
- Each pavement definition must each have a single boundary with no overlaps with itself.
- Nodes on this outer boundary must be defined in a counter-clockwise direction.
- Boundaries must be terminated with a node with a row code ‘113’ or ‘114’.
- Pavement definitions may overlap with another pavement chunk. But this is not recommended – instead consider precise alignment of adjacent features by ‘snapping’ nodes to identical locations in World Editor (WED).
- A pavement definition can never overlap with itself.
- The sequencing of the pavement definitions is the layering in which they will be rendered in X-Plane, top-down. So the last piece of pavement in the file will be rendered underneath any others with which it overlaps.
- Holes can be defined for pavement (through which the underlying terrain texture will show):
- Hole boundaries should follow the termination of the pavement definition in which the hole occurs (starting with a row type ‘111’ or ‘112’).
- Hole boundaries are defined in a clockwise direction (ie, opposite direction to the boundary nodes).
- Hole boundaries must form a closed loop (ie. must terminate with a row code ‘113’ or ‘114’).
- Each pavement definition can have zero, one or multiple hole boundaries.
- Hole boundaries must be contained within the outer boundary of the pavement definition.
- Holes cannot overlap each other.
- After creating a hole boundary, it can be ‘filled’ with a new pavement chunk (probably using a different surface type).
- Linear features also have a header row followed by an ordered list of nodes that define the line:
- Linear features can be closed loops (terminating in a node of type ‘113’ or ‘114’) or just strings (terminating with ‘115’ or ‘116’).
- An airport boundary is defined with nodes in a counter-clockwise direction. A boundary can contain holes (see above) and must form a closed loop (terminating in a node of type ‘113’ or ‘114’).
- Airport traffic flows have a header row (row code ‘1000’) followed by multiple rows that define rules of multiple classes (time, wind direction, ceiling, visibility, runway in use, VFR traffic pattern) that indicated that a flow should be used (wind rules, minimum ceiling rules, visibility rules, time rules, and operations rules).
- A flow is acceptable is any rule of a class is acceptable, or if there are no rules of a given class. So to permit a flow with no time restrictions, simple exclude any traffic time rules (row code ‘1004’).
- Rules use ‘or’ logic. For example, a flow may have two wind rules (row code ‘1001’) – one for slight winds very generally aligned with a runway, and one with strong winds only if they are almost exactly with the runway.
- A flow will be used only if all its rule classes are ‘passed’.
- The flows are evaluated in sequence. The first flow to ‘pass’ will be used. So, the most specific-but-useful rule should be listed first (eg. parallel VFR approaches on a clear, calm day) and the most general (but least useful) rules should be listed last (eg. a single ILS cat III approach to a single runway).
- If the rules prevent any defined flow from being ‘passed’ then the X-Plane’s AI engine will create a flow.
- ‘Runway in use’ rules (row code 1100} are also evaluated in sequence. The first ‘runway in use’ rule to ‘pass’ will be used for the parent flow. So rules should be listed in preferential sequence.
- Airport taxi routes & networks begin with a row code ‘1200’ and are defined by a set of nodes (row code ‘1201’) and ‘edges’ (the taxi routing) that connect two nodes (row code ‘1202’):
- Nodes can be defined as ‘init’ (a point at which X-Plane will try to start a taxi route), ‘end’ (where X-Plane will try to end a taxi route), or ‘both’. ‘junc’ can also be used for junctions between taxi routes.
- Edges may be optionally followed by multiple rows (row code ‘1204) defining an ‘active zone’ ‘for that parent edge (eg. if the edge conflicts with arrival or departure runways, or an ILS-critical area).
- Taxi routings begin or end at airport locations (row code ‘1300’), which are also available as startup-locations in X-Plane. These locations are not directly connected to the taxi route network – X-Plane’s ATC engine will calculate how to direct an airplane between the taxi route network and each location.
- Other airport features are defined with one row for each feature.
The file is terminated by a ‘99’:
99
ROW CODES
Each row of data begins with an integer code that defines the type of data:
Row Code |
Meaning |
Comment |
1 |
Land airport header |
|
16 |
Seaplane base header |
|
17 |
Heliport header |
|
100 |
Runway |
|
101 |
Water runway |
|
102 |
Helipad |
|
110 |
Pavement (taxiway or ramp) header |
Must form a closed loop. |
120 |
Linear feature (painted line or light string) header |
Can form closed loop or simple string |
130 |
Airport boundary header |
Must form a closed loop |
111 |
Node |
All nodes can also include a “style” (line or lights) |
112 |
Node with Bezier control point |
Bezier control points define smooth curves |
113 |
Node with implicit close of loop |
Implied join to first node in chain |
114 |
Node with Bezier control point, with implicit close of loop |
Implied join to first node in chain |
115 |
Node terminating a string (no close loop) |
No “styles” used |
116 |
Node with Bezier control point, terminating a string (no close loop) |
No “styles” used |
14 |
Airport viewpoint |
One or none for each airport |
15 |
Aeroplane startup location |
*** Convert these to new row code 1300 *** |
18 |
Airport light beacon |
One or none for each airport |
19 |
Windsock |
Zero, one or many for each airport |
20 |
Taxiway sign (inc. runway distance-remaining signs) |
Zero, one or many for each airport |
21 |
Lighting object (VASI, PAPI, Wig-Wag, etc.) |
Zero, one or many for each airport |
1000 |
Airport traffic flow |
Zero, one or many for an airport. Used if following rules met (rules of same type use ‘or’ logic, rules of a different type use ‘and’ logic). First flow to pass all rules is used. |
1001 |
Traffic flow wind rule |
Zero, one or many for a flow. Multiple rules use ‘or’ logic. |
1002 |
Traffic flow minimum ceiling rule |
Zero or one rule for each flow |
1003 |
Traffic flow minimum visibility rule |
Zero or one rule for each flow |
1004 |
Traffic flow time rule |
Zero, one or many for a flow. Multiple rules use ‘or’ logic. |
1100 |
Runway-in-use arrival/departure constraints |
First constraint met is used. Sequence matters! |
1101 |
VFR traffic pattern |
Zero or one pattern for each traffic flow |
1200 |
Header indicating that taxi route network data follows |
1201 |
Taxi route network node |
Sequencing is arbitrary. Must be part of one or more edges. |
1202 |
Taxi route network edge |
Must connect two nodes. Also takes one of 6 sizes (A-F). |
1204 |
Taxi route edge active zone |
Can refer to up to 4 runway ends |
1300 |
Airport location (deprecates code 15) |
Not explicitly connected to taxi route network |
1301 |
Ramp start metadata. |
Includes width, operations type, equipment type, & airlines. |
1302 |
Metadata records |
Zero or many for each airport. |
50 – 56 |
Communication frequencies |
Zero, one or many for each airport |
EXAMPLE DATA
Here is some example data for KBFI. It is not real and is very incomplete, but it illustrates examples of most types of data found in an apt.dat file. This data includes an airport header, runway, water runway, helipad, PAPI, taxiway definition, painted line, viewpoint, startup location, light beacon, windsock, taxiway sign and an ATC communications frequency:
1 21 1 0 KBFI Boeing Field King Co Intl
100 29.87 1 0 0.15 0 2 1 13L 47.53801700 -122.30746100 73.15 0.00 2 0 0 1 31R 47.52919200 -122.30000000 110.95 0.00 2 0 0 1
101 49 1 08 35.04420900 -106.59855700 26 35.04420911 -106.59855711
102 H1 47.53918248 -122.30722302 2.00 10.06 10.06 1 0 0 0.25 0
21 47.53666659 -122.30585255 2 150.28 3.30 13L PAPI-2L
110 1 0.25 150.29 A2 Exit
111 47.53770968 -122.30849802
111 47.53742819 -122.30825844 3
112 47.53752190 -122.30826710 47.53757385 -122.30824831 3 102
114 47.53768630 -122.30834929 47.53768690 -122.30838150 3 102
120 Line B1
111 47.53969864 -122.31276189 51
111 47.53977825 -122.31255145 1
115 47.54002296 -122.31189878
14 47.52917900 -122.30434900 100 0 ATC Tower
15 47.52926674 -122.29919589 304.16 A8 Run Up
18 47.52920400 -122.30412800 1 BCN
19 47.53900921 -122.30868700 1 WS
20 47.54099177 -122.31031317 235.71 0 2 {@L}A1{@R}31R-13L
50 12775 ATIS
Here is some example data for KSEA showing the new 1000 version traffic flow and taxi route data:
1000 Calm and South flow
1001 KSEA 000 359 5
1001 KSEA 070 250 999
1002 KSEA 0
1003 KSEA 0
1004 0000 2400
1100 16C 11920 arrivals jets|turboprops|props 160340 161161 Arrival 16C
1100 16R 11920 arrivals jets|turboprops|props 341159 161161 Arrival 16R
1100 16L 11920 arrivals heavy 000359 161161 Arrival Heavy Jets
1101 16R right
1200
1201 47.46360812 -122.30613338 both 5416 A_stop
1202 5258 5266 twoway taxiway B
1204 ils 34R
1300 47.43931757 -122.29806851 88.78 gate jets|turboprops A10
DEFINITION OF DATA FIELDS
For a complete table of example definitions, download the APT1050 Spec pdf document.
This information is historic and only relevant to X-Plane 10 and earlier
Revision History
28 April 2009 Spec converted to this new format to support new web site (//data.x-plane.com).
12 July 2009 Minor typos fixed
14 July 2009 Minor errors in helipad spec fixed 6 Sept 2009 Added clearer examples of taxiway signs (submitted by Donald Good – thanks!)
1 Feb 2011 Clarified definitions of runway ends and thresholds
Applicability
This specification (APT.DAT 850) is supported in X-Plane 8.50 until X-Plane 10.52. However, the significant new feature set in this file version was not fully supported until the release of X-Plane 8.61.
The prior specification for airport data was APT.DAT 810, which is recommended for X-Plane 8.10 – 8.60.
Support for Deprecated File Formats
The deprecated file specification (APT.DAT 810) is still supported. A large quantity of custom airport data exists only in this format. So airports defined according to this specification (APT.DAT 810) can be included in a file otherwise complying with the APT.DAT 850 specification.
Full 850 apt.dat File Spec
The full 850 apt.dat file specification can be found in this pdf document.
This information is historic and only relevant to X-Plane 10 and earlier
REVISION HISTORY
12 Mar 2012 Spec created, based upon prior apt.dat 850 spec.
14 Mar 2012 Minor updates & corrections
10 Apr 2013 Updates on airport traffic flows and taxi networks based on Ben’s feedback
APPLICABILITY
This specification (APT.DAT 1000) is supported in X-Plane 10.00 and later and by WorldEditor 1.2 and later. The prior specification for airport data was APT.DAT 850, which is recommended for X-Plane 8.60 – 9.70. This spec is an extension to 850 – all features in 850 are fully supported. However it is recommended that old data for ramp start locations (row code 15) be upgraded to the new row code 1300.
SUPPORT FOR DEPRECATED FILE FORMATS
The deprecated file specification (APT.DAT 810) is still supported. A dwindling quantity of custom airport data exists only in this format. So airports defined according to this specification (APT.DAT 810) can be included in a file otherwise complying with the APT.DAT 1000 specification.
The specification for APT.DAT 810 is available to view here.
OVERVIEW & SCOPE
This specification defines core airport data for X-Plane. This includes the locations of runways, taxiway and apron pavement, basic airport ‘furniture’ (VASI/PAPIs, windsocks, light beacons and taxiway signage), and communications frequencies. It also includes attributes for each of these features to fully describe them (eg. it includes runway surface type, runway markings, taxiway lighting and markings, approach lighting, taxiway sign text, etc).
This specification (1000) introduces new airport data to define arrival and departure traffic flows to airports and taxi networks & routings for AI-controlled airplanes.
This specification does not include scenery objects (such as buildings, static aeroplanes or underlying terrain textures).
BASIC CONCEPTS
- Latitudes and longitudes are described in a decimal notation (eg. 20.12345678) up to 8 decimal places.
- A latitude of 50 degrees 30 minutes south would be defined as -50.50000000
- North latitudes and east longitudes are positive. South latitudes and west longitudes are negative.
- All headings are referenced to true north (not magnetic north).
FILE CHARACTERISTICS
The apt.dat files are plain text files:
- Fields in the data can be separated by one or more white space characters (space, tab).
- By default, the files are generated so that columns of data are consistently aligned, but this is not required.
- Blank rows are permitted and are helpful to differentiate between airports.
- Comments are permitted and are indicated by “#” as the first two characters of a row.
FILE STRUCTURE
All airports must be created in WorldEditor (“WED”). This will ensure that all structural requirements listed here for airport data are met. WED version 1.2 is required to support the features in this spec.
In common with most other X-Plane data file specification, header rows of data define the origin (“I” = PC or “A” = Mac) of a particular copy of a file, and define the file specification version. The file specification may be followed by a reference to a sequential release data cycle and build number for the data, and a copyright message:
I
1000 Version - data cycle 2012.03, build 20121054, metadata AptXP1000. Copyright © 2012, Robin A. Peel (robin@xsquawkbox.net)...
The complete copyright message must be left intact if you redistribute this data. The GNU GPL (general public License) under which this data is released is designed to encourage modifications, enhancements and redistribution, even in commercial derivative products.
Subsequent rows of data follow a hierarchical structure:
- Each row of data has a numeric ‘row code’ as its first field, to define its content.
- The top level of this hierarchy defines an individual airport, defined by an airport header row (a row code of ‘1’, ‘16’ or ‘17’).
- Subsequent rows define elements of an airport:
- Runways (including helipads) follow the airport header row (one row per runway).
- Pavement (taxiway/apron) definitions have a header row followed by an ordered list of nodes that define its boundaries:
- Each pavement definition must each have a single boundary with no overlaps with itself.
- Nodes on this outer boundary must be defined in a counter-clockwise direction.
- Boundaries must be terminated with a node with a row code ‘113’ or ‘114’.
- Pavement definitions may overlap with another pavement chunk. But this is not recommended – instead consider precise alignment of adjacent features by ‘snapping’ nodes to identical locations in World Editor (WED).
- A pavement definition can never overlap with itself.
- The sequencing of the pavement definitions is the layering in which they will be rendered in X-Plane, top-down. So the last piece of pavement in the file will be rendered underneath any others with which it overlaps.
- Holes can be defined for pavement (through which the underlying terrain texture will show):
- Hole boundaries should follow the termination of the pavement definition in which the hole occurs (starting with a row type ‘111’ or ‘112’).
- Hole boundaries are defined in a clockwise direction (ie, opposite direction to the boundary nodes).
- Hole boundaries must form a closed loop (ie. must terminate with a row code ‘113’ or ‘114’).
- Each pavement definition can have zero, one or multiple hole boundaries.
- Hole boundaries must be contained within the outer boundary of the pavement definition.
- Holes cannot overlap each other.
- After creating a hole boundary, it can be ‘filled’ with a new pavement chunk (probably using a different surface type).
- Linear features also have a header row followed by an ordered list of nodes that define the line:
- Linear features can be closed loops (terminating in a node of type ‘113’ or ‘114’) or just strings (terminating with ‘115’ or ‘116’).
- An airport boundary is defined with nodes in a counter-clockwise direction. A boundary can contain holes (see above) and must form a closed loop (terminating in a node of type ‘113’ or ‘114’).
- Airport traffic flows have a header row (row code ‘1000’) followed by multiple rows that define rules of multiple classes (time, wind direction, ceiling, visibility, runway in use, VFR traffic pattern) that indicated that a flow should be used (wind rules, minimum ceiling rules, visibility rules, time rules, and operations rules).
- A flow is acceptable is any rule of a class is acceptable, or if there are no rules of a given class. So to permit a flow with no time restrictions, simple exclude any traffic time rules (row code ‘1004’).
- Rules use ‘or’ logic. For example, a flow may have two wind rules (row code ‘1001’) – one for slight winds very generally aligned with a runway, and one with strong winds only if they are almost exactly with the runway.
- A flow will be used only if all its rule classes are ‘passed’.
- The flows are evaluated in sequence. The first flow to ‘pass’ will be used. So, the most specific-but-useful rule should be listed first (eg. parallel VFR approaches on a clear, calm day) and the most general (but least useful) rules should be listed last (eg. a single ILS cat III approach to a single runway).
- If the rules prevent any defined flow from being ‘passed’ then the X-Plane’s AI engine will create a flow.
- ‘Runway in use’ rules (row code 1100} are also evaluated in sequence. The first ‘runway in use’ rule to ‘pass’ will be used for the parent flow. So rules should be listed in preferential sequence.
- Airport taxi routes & networks begin with a row code ‘1200’ and are defined by a set of nodes (row code ‘1201’) and ‘edges’ (the taxi routing) that connect two nodes (row code ‘1202’):
- Nodes can be defined as ‘init’ (a point at which X-Plane will try to start a taxi route), ‘end’ (where X-Plane will try to end a taxi route), or ‘both’. ‘junc’ can also be used for junctions between taxi routes.
- Edges may be optionally followed by multiple rows (row code ‘1204) defining an ‘active zone’ ‘for that parent edge (eg. if the edge conflicts with arrival or departure runways, or an ILS-critical area).
- Taxi routings begin or end at airport locations (row code ‘1300’), which are also available as startup-locations in X-Plane. These locations are not directly connected to the taxi route network – X-Plane’s ATC engine will calculate how to direct an airplane between the taxi route network and each location.
- Other airport features are defined with one row for each feature.
The file is terminated by a ‘99’:
99
ROW CODES
Each row of data begins with an integer code that defines the type of data:
Row Code |
Meaning |
Comment |
1 |
Land airport header |
|
16 |
Seaplane base header |
|
17 |
Heliport header |
|
100 |
Runway |
|
101 |
Water runway |
|
102 |
Helipad |
|
110 |
Pavement (taxiway or ramp) header |
Must form a closed loop. |
120 |
Linear feature (painted line or light string) header |
Can form closed loop or simple string |
130 |
Airport boundary header |
Must form a closed loop |
111 |
Node |
All nodes can also include a “style” (line or lights) |
112 |
Node with Bezier control point |
Bezier control points define smooth curves |
113 |
Node with implicit close of loop |
Implied join to first node in chain |
114 |
Node with Bezier control point, with implicit close of loop |
Implied join to first node in chain |
115 |
Node terminating a string (no close loop) |
No “styles” used |
116 |
Node with Bezier control point, terminating a string (no close loop) |
No “styles” used |
14 |
Airport viewpoint |
One or none for each airport |
15 |
Aeroplane startup location |
*** Convert these to new row code 1300 *** |
18 |
Airport light beacon |
One or none for each airport |
19 |
Windsock |
Zero, one or many for each airport |
20 |
Taxiway sign (inc. runway distance-remaining signs) |
Zero, one or many for each airport |
21 |
Lighting object (VASI, PAPI, Wig-Wag, etc.) |
Zero, one or many for each airport |
1000 |
Airport traffic flow |
Zero, one or many for an airport. Used if following rules met (rules of same type use ‘or’ logic, rules of a different type use ‘and’ logic). First flow to pass all rules is used. |
1001 |
Traffic flow wind rule |
Zero, one or many for a flow. Multiple rules use ‘or’ logic. |
1002 |
Traffic flow minimum ceiling rule |
Zero or one rule for each flow |
1003 |
Traffic flow minimum visibility rule |
Zero or one rule for each flow |
1004 |
Traffic flow time rule |
Zero, one or many for a flow. Multiple rules use ‘or’ logic. |
1100 |
Runway-in-use arrival/departure constraints |
First constraint met is used. Sequence matters! |
1101 |
VFR traffic pattern |
Zero or one pattern for each traffic flow |
1200 |
Header indicating that taxi route network data follows |
1201 |
Taxi route network node |
Sequencing is arbitrary. Must be part of one or more edges. |
1202 |
Taxi route network edge |
Must connect two nodes |
1204 |
Taxi route edge active zone |
Can refer to up to 4 runway ends |
1300 |
Airport location (deprecates code 15) |
Not explicitly connected to taxi route network |
50 – 56 |
Communication frequencies Zero, one or many for each airport |
EXAMPLE DATA
Here is some example data for KBFI. It is not real and is very incomplete, but it illustrates examples of most types of data found in an apt.dat file. This data includes an airport header, runway, water runway, helipad, PAPI, taxiway definition, painted line, viewpoint, startup location, light beacon, windsock, taxiway sign and an ATC communications frequency:
1 21 1 0 KBFI Boeing Field King Co Intl
100 29.87 1 0 0.15 0 2 1 13L 47.53801700 -122.30746100 73.15 0.00 2 0 0 1 31R 47.52919200 -122.30000000 110.95 0.00 2 0 0 1
101 49 1 08 35.04420900 -106.59855700 26 35.04420911 -106.59855711
102 H1 47.53918248 -122.30722302 2.00 10.06 10.06 1 0 0 0.25 0
21 47.53666659 -122.30585255 2 150.28 3.30 13L PAPI-2L
110 1 0.25 150.29 A2 Exit
111 47.53770968 -122.30849802
111 47.53742819 -122.30825844 3
112 47.53752190 -122.30826710 47.53757385 -122.30824831 3 102
114 47.53768630 -122.30834929 47.53768690 -122.30838150 3 102
120 Line B1
111 47.53969864 -122.31276189 51
111 47.53977825 -122.31255145 1
115 47.54002296 -122.31189878
14 47.52917900 -122.30434900 100 0 ATC Tower
15 47.52926674 -122.29919589 304.16 A8 Run Up
18 47.52920400 -122.30412800 1 BCN
19 47.53900921 -122.30868700 1 WS
20 47.54099177 -122.31031317 235.71 0 2 {@L}A1{@R}31R-13L
50 12775 ATIS
Here is some example data for KSEA showing the new 1000 version traffic flow and taxi route data:
1000 Calm and South flow
1001 KSEA 000 359 5
1001 KSEA 070 250 999
1002 KSEA 0
1003 KSEA 0
1004 0000 2400
1100 16C 11920 arrivals jets|turboprops|props 160340 161161 Arrival 16C
1100 16R 11920 arrivals jets|turboprops|props 341159 161161 Arrival 16R
1100 16L 11920 arrivals heavy 000359 161161 Arrival Heavy Jets
1101 16R right
1200
1201 47.46360812 -122.30613338 both 5416 A_stop
1202 5258 5266 twoway taxiway B
1204 ils 34R
1300 47.43931757 -122.29806851 88.78 gate jets|turboprops A10
DEFINITION OF DATA FIELDS
For a complete table of example definitions, download the APT1000 Spec pdf document.
One dataset to rule them all
In X-Plane 11 and later, one single database is used for all purposes of navigational data in the simulator. All items defined in this common database will be used for the scenery, the map, ATC, AI and the GPS/FMS and radio navigation avionics. In X-Plane 10, it was possible to have a discrepancy between what you saw in the X-Plane world and what was available for GPS navigation. This lack of data integrity is no longer possible. X-Plane 11 has a redesigned navdata hierarchy and new formats, that strongly enforce referential integrity and correctness. Note that the format is not backwards-compatible to any of the old datasets, X-Plane 11 will only load data in the X-Plane 11 format.
X-Plane 12 loads navdata conforming to the 11.50 or later spec, for supporting all features, navdata conforming to the 12 spec is preferred.
Furthermore, all data about airports and runways is taken from the apt.dat, which has been extended so it can carry information necessary for the avionics. Previously, a separate airports.txt was used to hold information like transition level, longest runway length, etc. Now all this information is taken from apt.dat, which uses the 1302 row code for key-value pairs, which can be edited in WED. The following key-value pairs are part of the apt.dat 1050 specification and are used in X-Plane 11:
- region_code, this must specify the region according to ICAO document No 7910
- datum_lat, datum_lon, those specify the location of the airport reference point (ARP) in decimal degrees, North and East positive
- transition_alt, this must specify the transition altitude in feet
- transition_level, this must specify the transition level in feet
Note that this data is already populated for most airports in the scenery gateway. If you find an airport with these values missing or incorrect, use WED 1.5 or later to add/edit these values and upload your change to the scenery gateway.
As of X-Plane 12, the airport data is located in $X-Plane/Global Scenery/Global Airports/Earth nav data/apt.dat and is the one and only source for both scenery and GPS data, so what you see is what you get.
Correct roles and regions, please
X-Plane 11 and 12 distinguish between global and terminal fixes and navaids. Terminal fixes and navaids must specify the arpt/heli ident of their terminal area, according to the 424.20 5.6 Airport/Heliport Identifier. All fixes and navaids must specify the region ICAO code according to the 424.20 5.14 ICAO code. Note especially the seven regions defined for the continental United States. See ICAO document No 7910 for details.
By classification into terminal vs global items and assigning the correct parent terminal area or ICAO region, each item in the database is addressable by a globally unique identifier. Only then it is possible to build the layered structure. X-Plane enforces integrity of this unique index, because it is needed to build the graph of the airway network.
X-Plane 11 and 12 support two formats in which the global database can be provided:
- ARINC 424 supplements 18 up to 20, with the exceptions noted in the FAA/Aeronautical Information Services CIFP Readme
- XPNAV1100, 1150 and 1200, as explained further down
Sim-wide ARINC424 override
Professional customers with access to 424 master files can use them to override the X-Plane global database.
Upon sim start, X-Plane will examine the $X-Plane/Custom Data/ folder of its installation for a file named earth_424.dat . If this file is found, it will be interpreted according to the ARINC 424.18 standard with the FAA CIFP exceptions, and will be used to load the following information into X-Plane:
- Fixes (EA and PC records)
- Navaids (D, DB and PN records)
- Airways (ER records)
- Published Holdings (EP records)
- Minimum Sector Altitude (PS records)
- Minimum Off Route Altitudes (AS records)
- ILS (PI records)
- Markers (PM records)
- Airport data (PA records)
- Airport gate/parking locations (PB records)
- Airport terminal procedures (PD, PE, PF records)
- Airport runway information (PG records)
- Path points (PP records)
- GLS stations (PT records)
- GBAS path points (PQ records)
After this file has been read, X-Plane will not load any other information from other text files. It is assumed that when the installation is provided with a global 424 file, no data of any other format needs to be loaded. In particular, X-Plane will then NOT load any of the files described in the following as “Global data”.
Global data
If no global 424 file is present, X-Plane will instead load files of the XPNAV1150/XPFIX1101/XPAWY1100/XPHOLD1140 format. These look superficially similar to the data files of previous versions, but they are fundamentally different in that referential integrity is required, and globally uniqueness with respect to type, code, and region code is enforced at load time. Full file format specifications are available below.
The layered hierarchy of global data
It is important to understand that rather than a full replacement of data, X-Plane 11 and 12 allow the data to be organized in layers with increasing priority, where higher priority data overrides the data from all layers below.
The base – what is shipped with X-Plane:
X-Plane 11/12 ships with a global base layer of data that enables IFR navigation world-wide. The data cycle represented by those files will remain the same over the lifetime of X-Plane 12.
These files are:
- earth_fix.dat
- earth_awy.dat
- earth_nav.dat
- earth_hold.dat
- earth_mora.dat
- earth_msa.dat
- CIFP/#ICAO.dat (where #ICAO is each airport with instrument procedures)
they are located in $X-Plane/Resources/default data/ .
Starting with X-Plane 12, these files are also part of the default distribution:
- Resources/default data/airspaces/airspace.txt (starting with X-Plane 12)
- Resources/default scenery/1200 atc data/Earth nav data/atc.dat (starting with X-Plane 12)
The updated base – what is supplied by third-party providers
This layer is what advanced hobbyist users care about. They want updated data, because they want to fly online. Participation in the online networks usually requires fairly recent data. Aerosoft and Navigraph offer newest data by a monthly subscription. This data consists of the files:
- earth_fix.dat
- earth_awy.dat
- earth_nav.dat
- earth_hold.dat (starting with X-Plane 11.40)
- earth_mora.dat (starting with X-Plane 11.50)
- earth_msa.dat (starting with X-Plane 11.50)
- CIFP/#ICAO.dat (where
- is each airport with instrument procedures)
- airspaces/airspace.txt (starting with X-Plane 12)
- 1200 atc data/Earth nav data/atc.dat (starting with X-Plane 12)
they must be located in $X-Plane/Custom Data/
These files completely replace the base layer of X-Plane. If these files are present, the X-Plane base layer is ignored. Note that because of the referential integrity, it is not possible to update just the earth_fix.dat and not the earth_awy.dat. Upon load, it is checked that all files are of the same cycle number. Mix-matching different cycles is not supported.
The updated approaches – what we get from the FAA for free
The FAACIFP file is an ARINC424.18 file provided by the Federal Aviation Administration free of charge and can be downloaded from their website.
In X-Plane 11/12, this file is used to replace P* records with the latest from the FAA. The following data is read from this file, and overrides data loaded from the global layer:
- Terminal Fixes (PC records)
- Terminal Navaids (D records where the 5.6 field is not empty, PN records)
- ILS (PI records)
- Markers (PM records)
- Airport data (PA records)
- Airport gate/parking locations (PB records)
- Airport terminal procedures (PD, PE, PF records)
- Airport runway information (PG records)
- Path points (PP records)
- GLS stations (PT records)
- GBAS path points (PQ records)
The file
must be located in $X-Plane/Custom Data/
This file is not shipped with X-Plane but can be obtained from the FAA website free of charge.
Note that no enroute waypoints, VHF enroute navaids, or enroute airways are loaded from this file. These cannot be replaced safely as it would affect the referential integrity of the airway network.
Note that for integrity reasons, the cycle number of the FAA data must always match the cycle number of the underlying layer. Terminal procedures do reference waypoints out of the terminal area, therefore, the data source for global waypoints must be at the same cycle number.
Note also that when FAACIFP is in effect, terminal procedures are overridden on a per-airport basis. No attempt is made to mix-match terminal procedures from global data with those loaded from FAACIFP. As terminal procedures reference terminal waypoints, trying to build terminal procedures from global data with points loaded from FACCIFP could lead to unpredictable results. Therefore, once FAACIFP is in effect, Custom Data/CIFP/#ICAO.dat is overridden for each #ICAO with PD/PE/PF records in FAACIFP.
Hand-placed localizers – manual corrections
Starting with X-Plane 11.50, curated localizer data is only applied to a small number of airports. X-Plane is instead relying on the earth_nav.dat of the XPNAV1150 or newer variety for almost all airports. Such data is shipped with X-Plane 11.50 by default, and also available from Navigraph and Aerosoft. Please be sure to select “11.50 and later” as the data download format if you are on X-Plane 11.50 or later. Data made for X-Plane 11.41 or earlier will not assure 1000th-of-a-degree accuracy for localizers and can thus lead to ILS signals guiding the aircraft beside the runway.
With this data, we have currently identified 5 airports for which the necessary data quality is not assured. These will continue to be supplied from the X-Plane scenery gateway. The file
- Custom Scenery/Global Airports/Earth nav data/earth_nav.dat (X-Plane 11)
- Global Scenery/Global Airports/Earth nav data/earth_nav.dat (X-Plane 12)
contains these manual corrections for 5 airports. This number might increase if we find more airports with sub-par data quality.
User data – per-user overrides
The last layer is the user-defined layer.
These files are where all custom waypoints are saved. Whenever a custom waypoint is created (through the default FMS) it is saved in the user_fix.dat file, which overrides previously loaded information. The user_nav.dat can hold custom navaids, though there is no way in the X-Plane UI to create them directly.
The files
- user_nav.dat
- user_fix.dat
are located in $X-Plane/Custom Data/
and are non-existent in a default installation of X-Plane and not touched by the updater.
The user_fix.dat is first created once a pilot-defined waypoint was stored in the FMS. They are the highest layer and ensure user modifications are preserved even with updates from Aerosoft or Navigraph.
ONLY in these user_fix.dat/user_nav.dat can you add or edit the X-Plane world data without being at risk of breaking data integrity. So if you want to add custom fixes or navaids to X-Plane, this is the only safe place to do it.
Note that this does not work for deleting objects that were loaded in a lower layer. You can no longer delete a fix from the UI in a persistent way. If we’d allow for selective deletion of fixes or navaids, airways that might be referencing them would break.
From 424 to XPNAV1100
We provide a simple command line tool called convert424toxplane that is available free of charge. With this tool, data providers can convert 424.18+ files into navdata guaranteed to be compatible with X-Plane 12 and X-Plane mobile.
Do not try to create or edit XPNAV1100/XPFIX1100/XPAWY1100/XPHOLD1140 files by hand. While the format is reasonably human-readable, the data integrity assumptions that are inherent are easily overlooked. Always edit the data in a 424 file, using a tool like the ARINCDecoder v4.3, to ensure validity. Then export the data to X-Plane using the convert424toxplane command line tool.
PQ records are synthesized from the scenery
X-Plane supports tuning GBAS receivers to obtain GLS final approach course and glidepath information. If the Final Approach Segment for a GLS approach is not supplied in an ARINC424 PQ-record, the final approach segment is generated from the runway data in the scenery, with a TCH of 50 feet and a splay angle depending on runway length. This allows flying GLS approaches with ILS-like accuracy.
How do I make my own approach? No hand editing, please!
In the past, we have been asked how to edit existing procedures or create own, fictional procedures – maybe you want to prototype a future LPV approach into your own backyard airstrip?
Terminal Procedure description follows the coding rules laid out in ARINC 424.20, Attachment 5, “Path and terminator”. Correctly coding procedures obeying all those rules by hand is next to impossible, which is why industry tools have been developed to work with these files.
For X-Plane 10, no tools existed to design custom approaches, and attempts to hand-code them in text were extremely difficult and didn’t work most of the time.
With X-Plane 11/12, you have the full power of the ARINC424.18+ at your disposal. To evaluate, edit, or even design a new procedure, we strongly recommend the ARINCDecoder v4.3 program, which is an incredibly powerful tool.
The files are designed to be easily parsed, have low overhead (no XML!) and will look inherently familiar in structure if you’re familiar with the files for X-Plane 10 already. The file format changes to X-Plane 10 are clearly lined out at the beginning of each document.
Please consider the following file format specifications as a guide how to parse X-Plane 11/12 navdata, not to generate it (see warning above).
Starting with X-Plane 12:
This RFC proposes new features to the apt.dat format for X-Plane 10.50 to support the X-Plane Scenery Gateway and static aircraft spawning. It consists of two parts: one for static spawning and one for airport identifiers.
This RFC is not a general call for feature requests for the apt.dat format – it aims to solve two specific problems.
Part 1: Static Aircraft Spawning and Aircraft Metrics
In order to make ramp positions more suitable to both AI and static aircraft, the apt.dat 1050 file format includes extra meta-data on parking spots and ATC taxi routes.
Clearance Widths on Taxi Edges
Clearances for aircraft are described using the standard ICAO category codes for aircraft, A-F. Roughly speaking the coding is:
Wheel Base |
Wing Span |
Category |
4.5m |
15m |
A |
6m |
24m |
B |
9m |
36m |
C |
14m |
52m |
D |
14m |
65m |
E |
16m |
80m |
F |
Both parking spots and ATC taxi route (that are not runways) gain a new maximum ICAO category, describing the largest aircraft that can safely operate on this ATC taxi route or parking spot.
For ATC taxi route edges, this is accomplished with 6 new type tokens: where taxiway edges (record type 1202) could normally be one of “runway” or “taxiway”, new “sized” taxiways are permitted: taxiway_A, taxiway_B, taxiway_C, taxiway_D, taxiway_E, taxiway_F. Edges corresponding to runways do not need sizes because X-Plane can determine the runway width from the actual runway (type 100) record.
Ramp Starts
Additional metadata is included in a new 1301 record, which follows the 1300 (new ramp start) record.
The 1301 record consists of an ICAO width code, an operations type code and zero or more space separated 3-letter airline codes, e.g.
1301 icao_width operations_type [airlines]
1301 C airline AAL SWA UAL
The ICAO width must be one of: A, B, C, D, E, F
The operations type must be one of: none, general_aviation, airline, cargo, military
Additional Equipment Classes
A new equipment class is introduced, “fighters” – it is allowed anywhere that the original five equipment classes (heavy, jets, turboprops, props and helos) are allowed.
Clearance Widths
For ramp starts, this is accomplished by allowing a size flag (A, B, C, D, E, or F) to be included in a new extended ramp start (type 1301) record.
Ramp Operation Types
Ramps gain a new field: “operations type,” indicating what kind of AI or static aircraft appear there. Can be set to: none, general_aviation, airline, cargo, military.
Airline Sets
A ramp start may optionally tagged with a set of valid 3-letter ICAO airline codes, which must be entered as capital letters.
Part 2: Airport Identification Meta-Data
Historically, the apt.dat file provided a single identifier field, sometimes referred to as an ICAO identifier. This identifier was a mandatory primary key for the airport, and therefore if an ICAO code did not exist for an airport, some non-ICAO code had to be made up and stuffed in this field. For US airports, typically an FAA code was used, and for non-US airports, there was no clear standard. Recently the X-Plane Scenery Gateway project designed a fixed rule-set to create non-conflicting synthetic identifiers by extending the field beyond four characters.
Finding an airport by identifier can thus be challenging; if the identifier is synthetic, searching by an IATA code or a local authority code will not work.
This extension aims to solve this problem by separating the primary airport identifier key (whose goals are uniqueness and stability) from other meta-data keys aimed at airport discovery (e.g. to aid search).
Going forward, the airport identifier referred to in the type 1, 16 or 17 record is known as an airport identifier, and is required to be a globally unique identifier for a particular real-world airport. The identifier can be synthetic or match a real world authority, but it cannot be ambiguous, and it cannot be omitted.
Each airport may have zero or more meta-data records, record code 1302, which is defined as
1302 key value
For example:
1302 icao_id KBOS
1302 faa_id BOS
1302 iata_id BOS
A key may not appear more than once per airport amongst all 1302 records. Keys must not contain white space or commas but values may.
The legal semantics of a given key (e.g. global uniqueness, accepted character set) is defined on a per-key basis; the only guarantees of the file format itself are file-valid (UTF8) characters, no white space or commas in keys, no newlines in keys or values, and no repeating keys. No key is mandatory. An empty key is illegal. Only officially defined, supported, conforming, and non-empty keys are allowed.
For the purposes of the initial specification, the following keys are being officially defined:
Key Name |
Explanation |
Example |
icao_id |
ICAO airport identifier code |
EDDF |
faa_id |
FAA airport identifier (“LID”) |
MA52 |
iata_id |
IATA airport code |
FRA |
city_id |
City name |
Boston |
country_id |
Country name |
United States |
|
region_id |
State/Province/Region |
Massachusetts |
This information is historic and only relevant to X-Plane 8 and earlier
Scope
This document describes the file format and codes used in X-Plane’s apt.dat file, 715 version.
-
This data file format is usable with X-Plane version 7.15 – 8.06. It was superseded by airport file format 810 in March 2005.
-
This is the “official” definition of the X-Plane file formats. The apt.dat file defines all airport data in X-Plane, including runways, taxiways, and other airport features.
-
Navigation aids at an airport (such as ILS components) are not defined in this file, but are contained in the nav.dat file.
File structure
The file structure is similar to all other X-Plane data files, with the exception that the sequencing of the data within the apt.dat file is important. Runway, taxiway, location and ATC data for an airport must immediately follow the header data for the parent airport.
- The first line of each file indicates if the file was generated on a PC (“I” for Intel or IBM) or Macintosh (“A” for Apple). X-Plane uses this code to help deal with the different ways in which PCs and Macs manipulate carriage returns in text files, and big-endian/little-endian issues. The second line contains a version number used by X-Plane. This usually implies the first version of X-Plane that can utilise the file format (eg. “715 version” implies that this file format was first available for use in X-Plane version 7.15). The version number is followed by my own long copyright message that also includes the sequential build number of the data and my own internal code for the metadata that drives the formatting). This copyright message is very long, and includes a reference to the GNU General Public Licence under which this data is published as modifiable freeware, and also an acknowledgement and a disclaimer for the US Department of Defense NIMA for the DAFIF data. The terms of this license require that this copyright message must be left intact if this file is modified and/or redistributed.
- The very last line of each file is marked by a “99”.
Here is an example of the two header lines, one airport, one runway and the file termination line:
I
715 Version – DAFIF data cycle 200502, build 1871, metadata AptXP715, Copyright © 2004, Robin A. Peel (robin@xsquawkbox.net). This data is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program (“AptNavGNULicence.txt”); if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA. This product was developed using DAFIF (the Defense Aeronautical Flight Information File), a product of the US National Imagery and Mapping Agency (NIMA). NIMA requires the following warranty statements: (A) Under 10 U.S.C. 456, no civil action may be brought against the United States on the basis of the content of a navigational aid prepared or disseminated by either the former Defense Mapping Agency (DMA) or the National Imagery and Mapping Agency (NIMA). (B) The DAFIF product is provided “as is,” and no warranty, express or implied, including, but not limited to the implied warranties of merchantability and fitness for particular purpose or arising by statute or otherwise in law or from a course of dealing or usage in trade, is made by NIMA as to the accuracy and functioning of the product. (C): Neither NIMA nor its personnel will be liable for any claims, losses, or damages arising from or connected with the use of this product. The user agrees to hold harmless the United States National Imagery and Mapping Agency. The user’s sole and exclusive remedy is to stop using the DAFIF product.
1 1242 0 0 89TX Aero-Bee Ranch Airstrip
10 30.879343 -098.416976 17x 170.00 2800 0.0000 0.0000 50 111111 04 0 0 0.25 0
99
Each airport has a header line and one or more runway/taxiway lines, followed by lines for an airport tower viewpoint location, a startup location on the airport , airport light beacon location and windsocks, and airport ATC (Air Traffic Control) frequencies.
Line
codes used in apt.dat (715 version) |
Code (apt.dat) |
Used for |
1 |
Airport header data. |
16 |
Seaplane base header data. No
airport buildings or boundary fences will be rendered in X-Plane. |
17 |
Heliport header data. No
airport buildings or boundary fences will be rendered in X-Plane. |
10 |
Runway or taxiway at an airport. |
14 |
Tower view location. |
15 |
Ramp startup position(s) |
18 |
Airport light beacons (usually
“rotating beacons” in the USA). Different colours may be
defined. |
19 |
Airport windsocks. |
50 to 56 |
Airport ATC (Air Traffic Control)
frequencies. |
Note the following sequence of the airport data:
- The runway data for each airport must follow the airport header line.
- Taxiways should follow the runways.
- Tower viewpoints and startup locations.
- Airport light beacons and windsocks.
- ATC frequencies should be the final entries for an airport.
- A blank line can be used to separate different airports – this helps improve readability, but it is not mandatory.
Changes from previous file versions
- The previous file version for apt.dat was 703 version.
- A flag now controls if a control tower object will be drawn in X-Plane at the location of the control tower (line code 14).
Other issues
The limitations on the number of airports within a region (an X-Plane “region” is a dynamic area of 2 degrees latitude by 3 degrees longitude) changed for X-Plane 7.40. So more recent files generated in this file format (715) are only usable in X-Plane versions 7.40 – 8.06.
Example data
Here is a simplified fragment for part of an airport in apt.dat:
1 5355 1 0 KABQ Albuquerque Intl Sunport
10 35.044209 -106.598557 08x 90.44 13749 1000.0000 0.1000 150 252231 02 0 3 0.25 1
10 35.031995 -106.618838 03x 44.66 9993 0.0000 0.0000 150 352321 02 0 3 0.35 1
10 35.044021 -106.611984 17x 183.36 10014 890.0000 0.0000 150 231231 01 0 2 0.25 1
10 35.038364 -106.612950 12x 128.98 5992 0.0000 0.0000 150 121331 02 0 2 0.25 1
10 35.042778 -106.598572 xxx 90.44 13737 0.0000 0.0000 100 161161 02 0 0 0.25 0
10 35.045609 -106.595635 xxx 90.44 11220 0.0000 0.0000 110 161161 02 0 0 0.45
0
14 35.047215 -106.608162 100.00 1 Tower viewpoint
15 35.047005 -106.618576 0.000 Gate B1 (American Airlines)
15 35.047005 -106.615000 0.000 Gate A1 (United Airlines)
18 35.045031 -106.598549 1 Light beacon
19 35.045176 -106.621581 1 Windsock
19 35.043241 -106.575534 1 Windsock
53 12190 GND
54 11830 TWR
This shows one airport header line, four runways, two taxiways, a tower viewpoint, two gate starting locations, an airport beacon, two windsocks and two ATC frequencies. The meaning of the data in the above example data is:
Meaning
of example airport data (apt.dat) |
Airport
header |
Example
Usage |
1 |
Identifies this as an airport header line. Note
that a code 16 will identify this as a seaplane/floatplane
base, and a code
17 will identify it as a heliport. |
5355 |
Airport elevation (in feet above
MSL). |
1 |
Airport has a control tower (1=yes, 0=no).
Used by X-Plane’s ATC system. Not used to draw the
default ATC tower building (despite what is stated in WorldMaker!). |
0 |
Display X-Plane’s default airport buildings (1=yes, 0=no).
This is usually ‘no’ if any custom taxiways have been defined. |
KABQ |
Identifying code for the airport (the ICAO code, if one exists).
It is helpful if these are unique, but this may not be possible in all cases. |
Albuquerque Intl Sunport |
Airport name.
Usually, the city name is first followed by the airport name (eg.
“London Heathrow”). |
Runways and taxiways |
Example Usage |
10 |
Identifies this as a data line for a runway or taxiway segment. |
35.044209 |
Latitude (in decimal degrees) of runway or taxiway segment center. |
-106.598557 |
Longitude (in
decimal degrees) of runway or taxiway segment center. |
08x |
Runway number (eg “25x” or “24R”). If there is no runway suffix (eg. “L”, “R”, “C”
or “S”), then an
“x” is used. “xxx” identifies the entry as a taxiway.
Helipads at the same airport are numbered sequentially as
“H1x”, H2x”. |
90.439 |
True (not magnetic) heading of the runway in degrees.
Must be between 0.00 and 360.00. |
13749 |
Runway or taxiway segment length in feet. |
1000.0000 |
Length of displaced threshold (1,000 feet) for runway 08 and for the reciprocal runway 26 (0 feet). The length of the reciprocal runway’s displaced threshold is expressed as the fractional part of this number. Take the runway 26 displaced threshold length (in feet) and divide it by 10,000, then add it to the displaced threshold length for runway 08. For example, for displaced threshold lengths of 543 feet and 1234 feet, the code would be 543.1234.Note that the displaced threshold length is included in the overall runway length but that the stopway length is excluded from the overall runway length. This code should be 0.0000 for taxiway segments. FYI, the displaced threshold is usually marked (in the real world) with long white arrows pointing toward the threshold. The displaced threshold is not available for use by aeroplanes landing, but may be used for take-off (in practice, if you use these last few feet of the runway for take-off, you are probably in serious trouble!). |
0.1000 |
Length of stopway/blastpad/over-run at the approach end of runway 08 (0 feet) and for runway 26 (1,000 feet), using the same coding structure defined
above. FYI, in the real world the stopway/blastpad/over-run is usually marked with large yellow chevrons, and aeroplane movements are not permitted. |
150 |
Runway or taxiway segment width in feet. |
252231 |
Runway or taxiway segment lighting codes.
The first three digits (“252”) define the lighting for the runway as seen when approached from the direction implied by the runway number (08 in our example).
The final three (“231”) define the lighting for the runway as seen when approached from the opposite end (26 in our example).
In order, these codes represent:
Runway end “A” (08): Visual approach path (VASI / PAPI etc.) lighting. Here, code 2 corresponds to a VASI.
Runway end “A” (08): Runway lighting. Here, code 5 corresponds to TDZ lighting, which also implies centre-line lighting, REIL and edge lighting.
Runway end “A” (08): Approach lighting. Here, code 2 corresponds to SSALS.
Other runway end (26): Visual approach path (VASI / PAPI etc.) lighting. Here, code 2 corresponds to a VASI.
Other runway end (26): Runway lighting. Here, code 3 corresponds to REIL, which also implies edge lighting.
Other runway end (26): Approach lighting. Here, code 1 implies no approach lighting. |
02 |
Runway or taxiway surface
code for the runway or taxiway segment. The leading zero is
optional – but I always use it to keep all the columns neatly lined up. |
0 |
Runway shoulder
code. These are only available in file version
701 and later. Here, code 0 implies that there is no runway
shoulder. |
3 |
Runway markings
(the white painted markings on the surface of the runway. Here,
code 3 implies precision runway markings (ie. there is an associated
precision approach for the runway, either an ILS or MLS). |
0.25 |
Runway
smoothness. Used to cause bumps when taxying or rolling along the
runway in X-Plane. It is on a scale of 0.0 to 1.0, with 0.0 being
very smooth, and 1.0 being very, very rough. X-Plane determines a
baseline smoothness based upon the runway surface type, and then uses
this factor to determine the ‘quality’ of the runway surface. The
default value is 0.25. |
1 |
Runway has ‘distance
remaining’ signs (0=no signs, 1=show signs). These are the white
letters on a black background on little illuminated signs along a
runway, indicating the number of thousands of feet of usable runway that
remain. They are inappropriate at small airports or on most dirt,
gravel or grass runways. |
Startup locations |
Example
Usage |
15 |
Identifies this as a
data line for an airport startup
location (code 15). Multiple startup locations
are allowed as separate data lines. |
35.047215 |
Latitude
(in decimal degrees) of the viewpoint or startup location. |
-106.618576 |
Longitude (in
decimal degrees) of the viewpoint or startup location. |
0.00 |
Elevation of the viewpoint, or the heading of the aeroplane when placed at the
startup location. |
Gate B1 (American
Airlines) |
Name of
a startup location (used in X-Plane 7.10 and later). |
Tower
viewpoints |
Example
Usage |
14 |
Identifies this as a data line for a tower viewpoint (code 14).Only a single tower viewpoint is permitted. |
35.047005 |
Latitude
(in decimal degrees) of the viewpoint. |
-106.608162 |
Longitude (in
decimal degrees) of the viewpoint. |
100 |
Height (in feet)
above ground level of viewpoint. |
1 |
Flag to indicate if
a control tower object should be drawn at this location in
X-Plane. 0=no tower, 1=draw tower. |
Tower viewpoint |
Name of this
viewpoint |
Airport light beacons |
Example Usage |
18 |
Identifies this as a
data line for an airport light beacon (code 18). Note that if custom data is not defined, then appropriate data will be
generated automatically and included in apt.dat. The light beacon
types available (see list below) are in accordance with the US AM
(Aeronautical Information Manual) – other types may be added to cater
for other light beacons used in other countries. |
35.045031 |
Latitude (in decimal degrees) of the light beacon. |
-106.598549 |
Longitude (in
decimal degrees) of the light beacon. |
1 |
Identifies the
colours of the light beacon. Here code 1 implies a standard
white-green flashing light. Options are:
Code 1: white-green flashing light (land airport).
Code 2: white-yellow flashing light (seaplane base).
Code 3: green-yellow-white flashing light (heliports).
Code 4: white-white-green flashing light (military field).
Code 5: white strobe light.
Code 0: no beacon (can be used at ‘closed’ airports). I
suggest you use a dummy lat/lon based upon one of the airport’s
runways. |
Light beacon |
Name for this light beacon
(not used by X-Plane). |
Airport
windsocks |
Example
Usage |
19 |
Identifies this row
as an airport windsock (code 19). Note that:
If custom data is not defined, then appropriate data will be generated
automatically by may data export algorithms and included in apt.dat
alongside the threshold of each runway.
If at least one windsock is explicitly defined at an airport, then
no ‘automatic’ windsocks will be generated at that airport.
Multiple windsocks are
allowed.
If you do not want any windsocks at an airport, then let
me know in an e-mail and I will suppress the generation of all
automatic windsocks at that airport. |
35.045176 |
Latitude
(in decimal degrees) of the airport windsock. |
-106.621581 |
Longitude (in
decimal degrees) of the airport windsock. |
1 |
Windsock lighting
(1=illuminated, 0=not illuminated). |
Windsock |
Name for this
windsock (not used by X-Plane). |
ATC
frequencies |
Example
Usage |
53 |
Identifies this as an
airport ATC
frequency line. Codes in the 50 – 59 range are
used to identity different ATC types. |
12190 |
Airport ATC frequency, in Megahertz
multiplied by 100 (ie. 121.90 MHz in this example). |
GND |
Name of the ATC frequency.
This is often an abbreviation (such as GND for
“Ground”). |
Codes used to define data
The codes used to define the data are:
Codes used in
apt.dat (715 version) |
ATC
frequency codes |
Meaning of
code |
50 |
AWOS (Automatic Weather
Observation System), ASOS (Automatic Surface Observation System) or ATIS
(Automated Terminal Information System). |
51 |
Unicom or CTAF (USA), radio (UK)
– open channel for pilot position reporting at uncontrolled airports. |
52 |
Clearance delivery. |
53 |
Ground. |
54 |
Tower. |
55 |
Approach. |
56 |
Departure. |
Runway
surface codes |
Meaning of
code |
01 |
Asphalt. |
02 |
Concrete. |
03 |
Turf/grass. |
04 |
Dirt. |
05 |
Gravel. |
06 |
Asphalt helipad (big “H” in
the middle). |
07 |
Concrete helipad (big “H” in
the middle). |
08 |
Turf helipad (big “H” in the
middle). |
09 |
Dirt helipad (big “H” in the
middle). |
10 |
Asphalt taxiway with yellow hold
line across long axis (not available from WorldMaker). |
11 |
Concrete taxiway with yellow
hold line across long axis (not available from WorldMaker). |
12 |
Dry lakebed runway (eg. at KEDW
Edwards AFB). |
13 |
Water runways (marked with
bobbing buoys) for seaplane/floatplane bases (available in X-Plane 7.0
and later). |
Visual
approach path indicator codes |
Meaning of
code |
1 |
No visual approach path lighting. |
2 |
VASI (Visual Approach Slope Indicator). |
3 |
PAPI (Precision Approach Path Indicator). |
4 |
Space Shuttle Landing PAPI (steep 20 degree glide path) – its use is very rare! |
Runway lighting
codes |
Meaning of code
Note
that for values 1-5, the codes are cumulative – ie. code 3 also assumes code 1
and code 2
when X-Plane interprets
the data
|
1 |
No runway lighting. |
2 |
Runway edge lights
(white). |
3 |
Also has REIL (Runway End Identification Lights – the flashing strobes at
the approach end of the runway. |
4 |
Also has CLL (Center Line Lighting). |
5 |
Also has TDZ (Touch Down Zone) lighting. |
6 |
Only has blue taxiway edge lights (use on
taxiways!). |
Approach
lighting codes |
Meaning of
code |
1 |
No approach lights. |
2 |
SSALS (Simplified short approach light system). |
3 |
SALSF (Short approach light system with sequenced flashing
lights). |
4 |
ALSF-I (Approach light system with sequenced flashing lights). |
5 |
ALSF-II (Approach light system with sequenced flashing lights and red side bar
lights the last 1000’). |
6 |
ODALS (Omni-directional approach light system). |
7 |
Calvert (a British design) category 1. |
8 |
Calvert (a British design) categories 2 and 3. |
Runway
shoulder codes |
Meaning of
code |
0 |
No runway shoulder. |
1 |
Asphalt runway shoulder. |
2 |
Concrete runway shoulder. |
Runway
marking codes |
Meaning of
code |
0 |
No runway markings. Also used for helipads (X-Plane will automatically draw the
big “H” based on the runway surface code), taxiways and water
runways. The runway markings available (see list below) are in accordance with
the US AIM (Aeronautical Information Manual) – other types may be added to cater
for different types of runway markings that may be used in other countries. |
1 |
Visual markings. |
2 |
Non-precision approach markings |
3 |
Precision approach markings. |
© Robin Peel,
2005. Last updated March 29, 2005
This information is historic and only relevant to X-Plane 8 and earlier
Scope
This document describes the file format and codes used in X-Plane’s nav.dat file, 740 version.
-
This data file format is usable with X-Plane version 7.40 – 8.09. It was superseded by the nav.dat 810 version.
-
This is the “official” definition of the X-Plane file formats. The nav.dat file defines all navigation aid data in X-Plane, including global NDBs, VORs, VORTACs, VOR-DMEs, DMEs, and ILS components (localisers, glideslopes, marker beacons and any associated DMEs).
File structure
The file structure is similar to all other X-Plane data files.
- The first line of each file indicates if the file was generated on a PC (“I” for Intel or IBM) or Macintosh (“A” for Apple). X-Plane uses this code to help deal with the different ways in which PCs and Macs manipulate carriage returns in text files, and
big-endian/little-endian issues.
- The second line contains a version number used by X-Plane. This usually implies the first version of X-Plane that can utilise the file format (eg. “740 version” implies that this file format was first available for use in X-Plane version 7.40). The version number is followed by my own long copyright message that also includes the sequential build number of the data and my own internal code for the metadata that drives the formatting). This copyright message is very long, and includes a reference to the GNU General Public Licence under which this data is published as modifiable freeware, and also an acknowledgement and a disclaimer for the US Department of Defense NIMA for the DAFIF data. The terms of this license require that this copyright message must be left intact if this file is modified and/or redistributed.
- The very last line of each file is marked by a “99”.
Here is an example of the two header lines, six nav-ads and a file termination line:
I
740 Version – DAFIF data cycle 200502, build 1921, metadata NavXP740, Copyright ©
2005, Robin A. Peel (robin@xsquawkbox.net). This data is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program (“AptNavGNULicence.txt”); if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA. This product was developed using DAFIF (the Defense Aeronautical Flight Information File), a product of the US National Imagery and Mapping Agency (NIMA). NIMA requires the following warranty statements: (A) Under 10 U.S.C. 456, no civil action may be brought against the United States on the basis of the content of a navigational aid prepared or disseminated by either the former Defense Mapping Agency (DMA) or the National Imagery and Mapping Agency (NIMA). (B) The DAFIF product is provided “as is,” and no warranty, express or implied, including, but not limited to the implied warranties of merchantability and fitness for particular purpose or arising by statute or otherwise in law or from a course of dealing or usage in trade, is made by NIMA as to the accuracy and functioning of the product. (C): Neither NIMA nor its personnel will be liable for any claims, losses, or damages arising from or connected with the use of this product. The user agrees to hold harmless the United States National Imagery and Mapping Agency. The user’s sole and exclusive remedy is to stop using the DAFIF product.
2 34.987022 -106.620384 5304 247 50 0.000 ILT Isleta NDB
3 35.043796 -106.816312 5740 11320 130 13.000 ABQ Albuquerque VORTAC
4 35.044026 -106.570548 0 11190 18 90.428 ISPT KABQ 08 ILS
6 35.043212 -106.614641 5352 11190 10 300090.428 ISPT KABQ 08 GS
7 35.046352 -106.742583 0 0
0 90.428 —- KABQ 08 OM
8 35.044686 -106.628247 0 0
0 90.428 —- KABQ 08 MM
99
The codes used to identify data are:
Line
codes used in nav.dat (740 version) |
Code (nav.dat) |
Used for |
2 |
NDB. |
3 |
VOR, VORTAC or VOR-DME. |
4 |
Localiser (LLZ) that is part of a
full ILS. |
5 |
Stand-alone localiser (LLZ),
also including LDA (Landing Directional Aid) and SDF (Simplified Directional
Facility). |
6 |
Glideslope (GS). |
7 |
Outer marker (OM). |
8 |
Middle marker (MM). |
9 |
Inner marker (IM). |
12 |
DME (including the DME element of
an ILS, VORTAC or VOR-DME). |
Sequencing of data is conceptually unimportant. But it controls the display of data on X-Plane’s menu options. By default, data is sorted by the “line code”, then alphabetically by nav-aid name.
Changes from previous file versions
- The previous file version for nav.dat was 600 version (no documentation available here).
- A new field has been added to define the range of a nav-aid. This is based upon DAFIF data, or upon defaults calculated from the nav-aid type and class..
Example data
Here is a simplified file fragment some nav-aids in nav.dat:
2 34.987022 -106.620384 5304 247 50 0.000 ILT Isleta NDB
3 35.043796 -106.816312 5740 11320 130 13.000 ABQ Albuquerque VORTAC
4 35.044026 -106.570548 0 11190 18 90.428 ISPT KABQ 08 ILS-cat-I
6 35.043212 -106.614641 5352 11190 10 300090.428 ISPT KABQ 08 GS
7 35.046352 -106.742583 0 0
0 90.428 —- KABQ 08 OM
8 35.044686 -106.628247 0 0
0 90.428 —- KABQ 08 MM
12 49.201986 -123.164006 28 11190 130 0.000 IRD Vancouver DME
This shows an NDB, VORTAC and an ILS (including localiser, glideslope, outer marker and inner marker) and a DME. The meaning of the data (for the first record) is:
Meaning
of example nav-aid data (nav.dat 740 version) |
Nav-aid
example |
Example
Usage |
2 |
Type of
nav-aid |
34.987022 |
Latitude of nav-aid in decimal
degrees |
-106.620384 |
Longitude of nav-aid in decimal degrees. |
5304 |
Elevation of nav-aid in feet above MSL. |
247 |
Frequency of nav-aid. (Always an integer – so VOR and localiser frequencies multiplied by 100). |
50 |
Range of the nav-aid in nautical miles. |
0.000 |
Used
for several purposes, depending upon the type of nav-aid:
Indicates the slaved variation of a VOR/VORTAC in degrees (ie. how the VOR is aligned
compared to true north). This value often differs slightly from the local magnetic variation. Eastern variations are positive, western ones are negative.
In the above data, Albuquerque VORTAC has a slaved variation of 13.000 degrees East.
Indicates the heading of a localiser in true (not magnetic) degrees. Also required for glideslopes (when it is combined with the glideslope angle – see below for details) and marker beacons.
Indicates the DME bias in nautical miles – often used for DMEs associated with an ILS
that are not located near the runway threshold. This bias must be subtracted from the calculated distance to
the DME to give the desired cockpit reading. This is typically used for a DME located in the centre of an airport that
serves multiple l ILS approaches, so that the DME will read zero at the
threshold of a runway. This is a common set up in Europe. |
ILT |
Identification of nav-aid (broadcast in Morse code in X-Plane).
Note that these are not unique. |
Isleta NDB |
Name of nav-aid.
Note that for ILS components these are carefully structured (see below)
to identify the airport and runway.. |
Localisers (code 4 and 5) are very similar, except that:
- They include the heading of the localiser (as described above).
- The nav-aid name is replaced by the airport code, runway number and ILS component type (eg. “KABQ 08 ILS-cat-I”). This data is not used by X-Plane, but is used by my import programmes that allocate the ILS elements to a valid runway in the master
database. I cannot import ILS data without these codes.
- For a localiser-only (code 5), the name will be similar to “KABQ 08 LOC”.
Glideslopes (code 6) have very similar data to localisers, except that the glideslope angle (typically 3 degrees) is combined with the heading in a slightly complex fashion. A glideslope of 3.00 degrees on a heading of 90.428 (true) will be listed as “300090.428”. This is calculated by:
- Rounding the glideslope angle (3 degrees in our example data) to two decimal places
(3.00).
- Multiplying the result by 100,000 (giving 300,000).
- Adding the result to the heading (300,000 + 90.428 = 300090.428).
ILS marker beacons (codes, 7, 8 and 9) are formatted just like localisers, but note that:
- They have no associated frequency (use “0”).
- They have no range (use “0”)
- The heading is important, to ensure that they are oriented and displayed correctly on X-Plane’s approach charts.
- Marker beacons do not have a Morse code identification, so “—-“ is used as a default. X-Plane will automatically generate the correct series of beeps for each type of beacon, if the aeroplane’s instrument panel is equipped with a marker beacon receiver.
- For a Locator Outer Marker (LOM), which is an NDB co-located with an OM, the NDB
must be added to nav.dat as a separate, stand-alone NDB (at the same location!). The name of the OM must remain in the “KABQ 08 ILS” format – but the NDB may have the appropriate name (eg. “Wobin LOM”).
DMEs (code 12) are shown for:
- Stand-alone DMEs (common in Europe, and often associated with an NDB).
- The DME component of a VORTAC or VOR-DME (often identical position data to the co-located VOR)
- DMEs associated with an ILS – often co-located with (or very close to) the localiser aerial.
- The DME bias is displayed in the heading column, as described above.
© Robin Peel,
2005. Last updated September 09, 2006
Where are all the elements of an ILS positioned?
X-Plane requires all ILS components to be placed in their correct, real-world locations.
The localizer aerial is positioned beyond the far end of the runway it serves, pointing back down the runway towards approaching aeroplanes. This ensures that an aeroplane can have localizer guidance on the final stages of its flare to land (after it has crossed the runway threshold, or as it begins its missed approach). The localizer is almost always perfectly aligned with the runway it serves … but sometimes they are slightly offset, usually to provide terrain clearance on the approach. If so, the localizer position will be moved so that it still points across the touch down zone of the runway. You can see an example of this at KBOS.
The glideslope aerial is positioned to one side of the touch down zone, usually perpendicular to the touch down zone markings on the runway, close to the VASI / PAPI location. It operates on a frequency paired to the localizer frequency.
Marker beacons are becoming rarer, but are positioned along the final approach path. The outer marker is usually at the Final Approach Fix, usually 4NM to 7NM from the runway threshold, and is sometimes paired with short range NDB (called a Locator Outer Marker or LOM). The middle marker is closer to the runway, usually at point at which an aeroplane flying the glideslope should be at the Decision Height (DH) for the approach, typically about 3,500 feet out from the runway threshold. The inner marker is very close to the threshold, and is rare – they are used for Category 3 approaches to very low DHs.
How will my custom scenery affect the “master” airport data?
X-Plane scenery packs are loaded in priority order; in order to ensure that you see your payware or custom scenery, it must be higher priority than the global airports.
Scenery packs in “Custom Scenery” are loaded in the order of scenery_packs.ini (a text file in the Custom Scenery folder). Custom scenery packs at the top of the .ini file are loaded first and override packs below them. The scenery_packs.ini file lets users disable and re-prioritize scenery packs without having to rename anything.
Any time X-Plane runs and finds a scenery pack not in the .ini, it adds it to the top of the file; therefore when you install new scenery, it starts at the highest priority level. Usually this is what you want.
The airports from the X-Plane Airport Gateway are in a scenery pack called “Global Airports” in your custom scenery – this pack should be higher priority than any base meshes but lower priority than any custom airports.
Can I use custom nav-aid or fix data in a custom scenery package?
No. Any earth_nav.dat or earth_fix.dat files in a custom scenery package are ignored by X-Plane.
It is not possible to uniquely identify a nav-aid by its ID or frequency, so it would not be possible for X-Plane to match nav-aid information in a custom scenery package against the matching data in the ‘master’ earth_nav.dat file. (This process does work for airports because the airport ICAO codes are guaranteed to be unique.) In addition, the purpose of the custom nav-aid data may be to correct the ID or frequency of a ‘bad’ nav-aid, making making the suppression of the ‘bad’ master data impossible. Similarly, fix names are not unique at a global level.
So, changes to nav-aids must be made in the ‘master’ earth_nav.dat file and fixes must be changed in the earth_fix.dat file. Send any corrected data to be included in the master database via the bug reporter on the Airport Scenery Gateway.
My airport does not have an ICAO or FAA code. What should I use in X-Plane?
Within the USA, almost every airport has either an ICAO or FAA airport code. But in many other countries, smaller, disused or private airports do not have any kind of published code. But, X-Plane requires a unique code for every airport.
The way we traditionally solved this was by allowing airport authors to invent an identifier similar in style to the ICAO codes used in that region. So, for instance, since German civil airports follow the pattern EDxx, someone might have invented ED01. This causes a problem if ED01 gets assigned to another airport in the real world. As of X-Plane 10.40, we’re moving to prefixing these fictitious identifiers with an X. So, German civil airports that have real ICAO identifiers follow the pattern EDxx, while German airports with only made-up identifiers follow the pattern XEDxx.
If you need a new airport identifier created for either an airport with a long official identifier, or an airport with no identifier in the real world, just file a “New Airport Code Request” on the Airport Scenery Gateway bug reporter and we’ll get you taken care of.