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’:

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.