REVISION HISTORY
16 Nov 2021 Updated new lines styles added in 11.30, correct wording in rowcode 21 name field. 11 April 2019 Updated with new COM frequency capabilities added in 11.30. 14 Feb 2018 Minor corrections to Definition of Data fields. 11 April 2017 Revised row code 1201. 18 Jan 2017 Spec created.
APPLICABILITY
This specification (APT.DAT 1100) is supported in X-Plane 11.00 and later and by WorldEditor 1.6b1 and later. The prior specification for airport data was APT.DAT 1050, which is recommended for X-Plane 10.50+. This spec is an extension to 1050 – all features in 1050 are fully supported.
SUPPORT FOR DEPRECATED FILE FORMATS
The deprecated file specification (APT.DAT 1050, 1000) is still supported. A dwindling quantity of custom airport data exists only in this format. So airports defined according to this specification can be included in a file otherwise complying with the APT.DAT 1100 specification.
The specification for APT.DAT 1050 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 (1100) introduces new service truck parking and destination features.
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 1.6 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 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 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. 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. |
| 1400 | Truck Parking Location | Not explicitly connected to taxi route network. |
| 1401 | Truck Destination Location | Not explicitly connected to taxi route network. |
| 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. |
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
Here is some example data for KSEA showing the 1050 metadata and 1100 ground truck additions:
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 APT1100 Spec pdf document.