article_type: Legacy File Format Specification

Airport Data (apt.dat) 1050 File Format Specification

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:

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.

Airport Data (apt.dat) 850 Version

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.

Airport Data (apt.dat) 10.00 Version

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:

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.

Airport data (apt.dat) 715 version

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.

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:

Codes used to define data

The codes used to define the data are:

© Robin Peel,
2005.  Last updated March 29, 2005

X-Plane nav-aid data file definition (740 version)

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:

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:

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

Navigation Data (nav.dat & earth_nav.dat) File Format Specification

This information is historic and only relevant to X-Plane 10 and earlier

REVISION HISTORY

12 Nov 2015 Update to move spec to developer site
7 May 2009 Spec converted to this new format to support new web site (//data.x-plane.com).
8 Sept 2009 Error in usage of row type 13 fixed in “applicability” section below.
31 May 2010 Corrected error in specification of VOR and localizer radio frequencies. Added elevations to NDB spec. Corrected references to apt.dat.
29 July 2011 Fixed minor error in definition of nav-aid frequencies
27 Oct 2011 Fixed minor error in definition of glideslope approach angle
8 July 2012 Corrected error in definition of nav-aid ranges

This specification (XP NAV810) is supported in X-Plane 8.10 to X-Plane 10.52. It is identified in the data files as “810 Version” on the second row of the file. The prior specification for airport data was XP NAV740, which is recommended for X-Plane 7.40 – 8.09.

Changes in the spec for XP NAV810 were:

A new row code for DMEs (13) for which the frequency display will be shown on X-Planes charts. DMEs with a row type 12 will have their frequency display suppressed on X-Plane’s chart to prevent clutter (such DMEs are usually co-located with a VOR or an ILS).

OVERVIEW & SCOPE

This specification defines all radio navigation data for X-Plane, including NDBs, VORs (inc. VORTACs and VOR-DMEs), and ILS components (localisers, glideslopes, marker beacons). The effect of this data is to:

• Allow these radio navigation facilities to be used when flying in X-Plane.
• Display the navigation facilities on X-Plane’s chart.
• Render objects in the X-Plane scenery system to represent each facility

BASIC CONCEPTS

• Latitudes and longitudes are described in a decimal notation (eg. 20.12345678).
  • 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). X-Plane has an internal model of magnetic variation

FILE CHARACTERISTICS

The earth_nav.dat (and nav.dat) files are plain text files:

• Fields in the data can be separated by one or more white space characters.
• By default, the files are generated so that rows of data are consistently aligned, but this is not required.

FILE STRUCTURE

The navigation data can be edited in X-Plane in the “Location | Local Map” view, and by clicking on the “edit” button at the top of the screen. If data is changed here, then X-Plane will ask for confirmation that the new data should be saved when quitting X-Plane. This will ensure that all structural requirements listed here for airport data are met.

[Note that the current version of X-Plane displays headings for an ILS in magnetic degrees on this screen, but that this data is converted to a true heading when the data is saved to earth_nav.dat.]

In common with most other X-Plane data file specification, header rows of data define the origin (PC or 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
810 Version - data cycle 2009.01, build 20081054, metadata NavXP810. Copyright © 2009, Robin A. Peel (robin@xsquawkbox.net)...

The complete copyright message should 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 define each nav-aid. Sequence is not important, but by default this file is sorted by row code, then by nav-aid name.

The file is terminated by a ‘99’.

ROW CODES

Each row of data begins with an integer code that defines the type of data:

EXAMPLE DATA

Here is some example data for the Seattle, Washington, USA area (note the separate data row for the DME component of the Seattle VORTAC):

2 47.63252778 -122.38952778 0 362 50 0.0 BF NOLLA NDB
3 47.43538889 -122.30961111 354 11680 130 19.0 SEA SEATTLE VORTAC
4 47.42939200 -122.30805600 338 11030 18 180.343 ISNQ KSEA 16L ILS-cat-I
6 47.46081700 -122.30939400 425 11030 10 300180.343 ISNQ KSEA 16L GS
8 47.47223300 -122.31102500 433 0 0 180.343 ---- KSEA 16L MM
12 47.43433300 -122.30630000 369 11030 18 0.000 ISNQ KSEA 16L DME-ILS
12 47.43538889 -122.30961111 354 11680 130 0.0 SEA SEATTLE VORTAC DME

DEFINITION OF DATA FIELDS

For a complete table of example definitions, download the NAV810 Spec pdf file.

Fix Intersection (fix.dat) File Format Specification

This information is historic and only relevant to X-Plane 10 and earlier

This specification defines all fixes (also known as intersections) X-Plane 10. The effect of this data is to:

• Allow these fixes to be selected in X-Plane’s GPS and FMC systems.
• Display the fixes on X-Plane’s charts.

BASIC CONCEPTS

• Latitudes and longitudes are described in a decimal notation (eg. 20.12345678).
  • 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.
• Unlike other data files, no ‘row codes’ are used for fix data, since the file contains just one type of data.

FILE CHARACTERISTICS

The earth_fix.dat files are plain text files:

• Fields in the data can be separated by one or more white space (space, tab) characters.
• By default, the files are generated so that columns of data are consistently aligned, but this is not required.

FILE STRUCTURE

• 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.
• Subsequent rows of data define each nav-aid. Sequence is not important, but by default this file is sorted by row code, then by nav-aid name.
• The file is terminated by a ‘99’.

EXAMPLES

Here is example data for a fix:

37.428522 -097.419194 ACESI

DEFINITION OF DATA FIELDS

Airway Data (awy.dat) File Format Specification

This information is historic and only relevant to X-Plane 10 and earlier

The awy.dat file defines all airway segments in X-Plane 10. This data is used in X-Plane 10 to draw high and low level airways on X-Plane’s charts.

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. “640 version” implies that this file format was first available for use in X-Plane version 6.40). The version number is followed by Robin Peel’s long copyright message that also includes the sequential build number of the data and 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, three airway segments and the file termination line:

I
600 Version - DAFIF data cycle 200502, build 1922, metadata AwyXP640, 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.

ABCDE 32.283733 -106.898669 ABC 33.282503 -107.280542 2 180 450 J13
ABC 33.282503 -107.280542 DEF 35.043797 -106.816314 2 180 450 J13
DEF 35.043797 -106.816314 KLMNO 35.438056 -106.649536 2 180 450 J13-J14-J15
99

Sequencing of data is conceptually unimportant. By default the segments are sorted by the initial “from” fix and then by the “to” fix.

Example data

Here is a simplified data fragment for three airway segments in awy.dat:

ABCDE 32.283733 -106.898669 ABC 33.282503 -107.280542 2 180 450 J13
ABC 33.282503 -107.280542 DEF 35.043797 -106.816314 2 180 450 J13
DEF 35.043797 -106.816314 KLMNO 35.438056 -106.649536 2 180 450 J13-J14-J15

The meaning of this data is (subject to change):