Airport Data (apt.dat) 12.00 File Format Specification

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.

Support for Deprecated File Formats

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:

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.

Codes

Codes used to define airport data:

Further Information

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