X-Plane data file definitions

Airport data (apt.dat) 850 version

Version 1.15 updated June 26 2008

Scope
File structure
Data integrity rules
Changes from previous file versions
Example data and explanation
Codes used to define data
(NEW) Text on taxiway signs
(NEW) Best Pactices for using WED
Other resources

Return to the X-Plane File Definition home page

Scope

This document describes the file format and codes used in X-Plane's apt.dat file, 850 version.

• This data file format is usable with X-Plane version 8.50 onwards. 

• This is the "official" definition of the X-Plane file formats.  If you spot any errors or inconsistencies, then please let me know.  Likewise if you do not think that X-Plane is interpreting these data correctly.

• The apt.dat file defines many of the airport features in X-Plane, including runways, taxiways, lighting, and some other airport features.  It does not define cosmetic scenery objects, such as buildings (terminals, hangars, etc) but it does include small items of airport "furniture" such as windsocks and light beacons) that are essential to flying operations.

• Navigation aids at an airport (such as ILS components) are not defined in this file, but are contained in the nav.dat file. Note that X-Plane automatically creates a scenery object for each navigation aid (eg. localiser and glideslope aerials) which will be rendered visually at an airport.

• World Editor (WED) is now available as a beta release - it is a free utility to design airports in this new (850) file format.  It includes many great features, and though freeware, it is written by the X-Plane development team and supports the latest file formats.  Downloads are available for Windows and Mac OS, and WED includes a detailed manual. 

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, pavement, furniture, 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 Windows PC (“I” for Intel or IBM) or Macintosh (“A” for Apple).
• 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. "850 version" implies that this file format was first available for use in X-Plane version 8.50).   The version number is followed by an optional copyright message.  On files that I create, I include a sequential build number of the data and my own internal code for the meta data that drives the formatting). My copyright message can be very long, and includes a reference to the GNU General Public Licence under which this data is published as modifiable freeware, and also an acknowledgment 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”.
• This file format includes new features for defining polygonal pavement and linear features, both of which can that include curves defined by Bezier points.  These new features require a clear structure of data within the file:
  • Within an apt.dat file in the 850 format, airports can be defined in terms of the old (810 Version) data formats or this new (850 Version) format, and these formats can mixed within the same apt.dat file. 
  • Be careful mixing data - for example, an 810format  definition of a runway defines the VASI/PAPI for that runway, but VASI/PAPI definitions are separate data lines in the 850 format.

Here is an example of the two header lines, one airport (KSBD) in the 850 format (with one runway) and one airport (89TX) in the old 810 format (also with one runway),  and the file termination line:

I
850 Version - Copyright © 2006, Austin Goudge, v1.1. This data may be freely distributed and modified for any purpose, including commercial, providing this copyright notice remains at the top of the file.

1 1157 0 1 KSBD San Bernardino Intl
100 54.86 01 02 0.25 1 3 1 06 34.09073300 -117.25038500 0 304.8 3 0 1 2 24 34.09995200 -117.21935300 0 304.8 3 0 1 2

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 0000.0000

99


Each airport has a header line and one or more runway/taxiway lines,  followed by lines for pavement (taxiways and aprons), linear features (lines and lights), an airport tower viewpoint location, a startup location on the airport, airport light beacon location and windsocks, taxiway signs, VASI/PAPI approach slope indicators, runway guard "Wig-Wags",  locations and airport ATC (Air Traffic Control) frequencies.  At least one runway is required for each airport - all other data is optional.

Each pavement definition ("pavement chunk") is followed by a series of data lines (a "chain") that define the chunk's boundaries, with optional further set(s) chains that define 'holes' within that chunk. Each chain is composed of a series of lat/lon points, each with an optional Bezier control lat/lon point (to control the curviness of the implied line segment).  A special point type is used to define the termination of  a boundary chain, with an automatic closing of the boundary loop back to the first defined point of that chain.  Additional chains that follow define 'holes' in the pavement.  Each segment of the chain has additional parameters to define its attributes (such as shoulders, shoulder marking, edge lighting, edge lines, etc).

Linear features are defined in a very similar fashion, and can be used to define taxiway markings, strings of lights (eg. green centre-line lights) and airport boundaries.  Unlike the pavement boundary chains, the linear features can have an arbitrary termination point (eg. where a centre-line just stops.

Note the following sequence of the airport data:

• The runway data for each airport must follow the airport header line.
• Taxiways must follow the runways (if in old 810 Version format).
• Linear feature and pavement chunk definitions must be followed by their boundary chain definitions in an appropriate sequence.
• Other items of airport "furniture" can follow in any sequence, such as:
  • Tower viewpoints and startup locations
  • Airport light beacons and windsocks
  • Taxiway signs
  • VASI, PAPI and wig-wags
• ATC frequencies.

Data integrity rules

Rules define how the new, complex definition of pavement chunks and linear features must be structured in order to ensure accurate rendering in X-Plane::

• Pavement chunks (line code 110) must comply with the following:
  • Chunks MUST terminate in a node of type 113 or 114.
  • The outer boundary of a chunk must be defined in a counter-clockwise direction.
  • There can be only one outer boundary for each chunk.
  • Holes within a chunk must be defined in a clockwise direction (ie. the opposite direction to the outer boundary).  To define a hole in a chunk, terminate the outer boundary (with a node 113 or 114) then start the clockwise definition of the hole with a node code 111.
  • There can be multiple holes in each chunk.  Terminate each hole with a node code 113 or 114, then (if necessary) start a new hole with a node code 111.
  • Holes cannot overlap.
  • Holes must be fully contained within the outer boundary.
  • All polygons must be "simple" (ie. edges cannot overlap other edges).
  • Chunks can overlap each other (but this is not recommended and should not be necessary).  Note that a single pavement chunk cannot overlap with itself (and this might be illegal in some US states).
  • The sequence of the chunks in the files is the sequence in which they will be rendered.  So the last chunk in the file will overlay (if it has any overlaps) any other chunks.
• Linear features (line code 120) must comply with the following:
  • Linear features must terminate in a node of type 113, 114, 115 or 116.
  • Linear features do not need to be "closed".
• Airport boundaries (line code 130) must comply with the following:
  • Boundaries MUST terminate in a node type 113 or 114.
  • Boundary must be defined in a counter-clockwise direction.
  • Boundaries must be a closed loop.
  • Boundaries can contain holes (eg. for some forested areas inside an airport, such as at KBWI).   Terminate each hole with a node code 113 or 114, then (if necessary) start a new hole with a node code 111.
  • As with pavement chunks, the airport boundary cannot overlap itself.
  • An airport may have multiple boundaries, but each must be a closed loop and should not overlap any other boundary.

Changes from previous file versions

This file version represents a major update from the prior release, but we have attempted to retain backwards compatibility..

• The previous file version for apt.dat was 810 version.
• Runway data now more clearly defines features that are common to the entire runway, or that are unique to each runway end.
• All distances (eg. lengths and widths) are defined in metres.  A minimum of 1 metre is required.  (But note that any data in the old 810 Version format within the file will still be defined in feet).
• This version now supports a new technique for defining pavement (taxiways, aprons etc) and linear features at airports, to enable:
  • Arbitrary polygonal taxiway and apron shapes.
  • Curved pavement boundaries, using Bezier control points..
  • 'Holes' in the pavement.
  • Linear features such as taxiway centre lines, hold lines, strings of lights.  So green taxiway centre lights, red edge lights, yellow runway incursion warning lights etc. are all possible.
  • Airport boundaries with optional fences.
• Support also added for:
  • Taxiway signs.
  • Explicit VASI/PAPI location (allows multiple VASI/PAPI for each runway).
  • Wig-wag lights (the pulsating amber lights at taxiway edges warning of an active runway ahead).
  • New codes to support these many new features.
  • Precision of all co-ordinates extended to eight decimal places.
  • The old style (810 Version) of airport definitions continue to be supported.  However, it is not recommended to mix these two separate definitions for a single airport.  
  • There is one exception - old-style (810) taxiway data definitions can be included within a new-style (850) airport definition.
  • Additionally, snow and ice runway textures are now supported.  Useful in the Antarctic for optimistic penguins.
  • Runway markings (and some other lighting features) can now be specified for each runway end (previously, runway markings were always identical at each runway end).

Example data

Here is a grossly simplified subset of the data for X-Plane's default airport, KSBD (San Bernadino), which is now supplied with X-Plane 8.50 and later.  (You can find the full, latest version of this data in this folder: X-System\Custom Scenery\KSBD Demo Area\Earth nav data\apt.dat).  Many thanks to Austin Goudge for creating this data as an example of X-Plane 8.50's capabilities.

I
850 Version - Copyright © 2006, Austin Goudge. v1.1. This data may be freely distributed and modified for any purpose, including commercial, providing this copyright notice remains at the top of the file.

1 1157 0 1 KSBD San Bernardino Intl
100 54.86 01 02 0.25 1 3 1 06 34.09073300 -117.25038500 0 304.8 3 0 1 2 24 34.09995200 -117.21935300 0 304.8 3 0 1 2
102 H1 34.105478 -117.242497 150.0 30.48 30.48 02 0 0 0.25 1

21 34.09186800 -117.24858100 2 070.36 3.0 06 VASI
21 34.09866600 -117.22131500 2 250.36 3.0 24 VASI

110 1 0.25 70.0 Main Apron (asphalt)
111 34.10432100 -117.24139700 3 102
111 34.10433200 -117.24000600 3 102
112 34.10535700 -117.24000100 34.105726 -117.240006 3 102
111 34.10573100 -117.24038600 3 102
111 34.10571500 -117.24234500 3 102
111 34.10553400 -117.24272400 3 102
111 34.10562900 -117.24280200 3 102
111 34.10465100 -117.24487800 0
111 34.10460300 -117.24495100 0
111 34.10430900 -117.24475800 0
111 34.10534300 -117.24260300 0
111 34.10426300 -117.24183000 0
111 34.10425900 -117.24165300 0
111 34.10362800 -117.24123000 3 102
113 34.10374900 -117.24099400 3 102

120 Curve E->NW from alpha to echo
111 34.09920900 -117.22826100 51 101
112 34.09958300 -117.22790000 34.099857 -117.227923 51 101
115 34.09997400 -117.22825400

20 34.09210700 -117.25062000  0.0 0 2 {@L}A
20 34.09510400 -117.24276200 70.0 0 2 {@Y,^l}TERMINAL{@L}A{@Y}A1{^r}

14 34.09726500 -117.24283100 200.00 1 ATC
15 34.09800200 -117.24417400 0.00 Stand 1
18 34.10110500 -117.24326600 1 Light beacon
19 34.09270300 -117.24790700 1 Windsock

51 12297 CTAF/UNICOM
55 11965 SOCAL APP/DEP
55 12550 SOCAL APP/DEP
55 12725 SOCAL APP/DEP
55 13400 SOCAL APP/DEP

99


Any airport data in an 850 Version of an apt.dat file that uses the legacy 810 Version format should use the codes and definition in that specification for those data lines.  In some cases, codes have been revised in 850 Version and may appear to conflict with 810 Version, so it's very  important to use the right codes for each piece of data!

The meaning of the data in the above example 850 Version data is:

Meaning of example airport data (apt.dat)
Airport header	Example Usage
	1 1157 0 1 KSBD San Bernardino Intl
1	Identifies this as an airport header line.  Note that a code 16 will identify this as a seaplane/float plane base, and a code 17 will identify it as a heliport.
1157	Airport elevation (in feet above MSL).
0	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!).
1	Display X-Plane’s default airport buildings (1=yes, 0=no).  (No longer used in 850 Version - maintained for backward compatibility)
KSBD	Identifying  code for the airport (the ICAO code, if one exists).   Must be unique within an apt.dat file.  If additional apt.dat files are being used in custom scenery folders, then this ICAO code is used to match airports between the files.
San Bernadino Intl	Airport name.  Can contain spaces.  Minimise use of special characters and avoid all single or double quotation marks and apostrophes.
Runways	Example Usage
	100 54.86 01 02 0.25 1 3 1 06 34.09073300 -117.25038500 0 304.8 3 0 1 2 24 34.099952 -117.219353 0 304.8 3 0 1 2
100	Identifies this as a data line for a runway.
54.86	Runway width in metres (not feet).
01	Runway surface code for the runway.  The leading zero is optional.
02	Runway shoulder code.  Here, code 02 implies that there is a concrete runway shoulder.
0.25	Runway smoothness.  Used to cause bumps when taxiing 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.  (Not yet supported in X-Plane)
1	Runway centre-line lights: 0 = No centre-line lights 1 = Has centre-line lights
3	Runway edge lighting.  If any runway edge lighting exists, it also implies that there is runway threshold lighting (red towards a departing aeroplane, green towards an landing aeroplane).  Codes used are: 0 = No edge lights 2 = Medium intensity runway lights (MIRL)
1	'Distance remaining' 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. 0 = No distance remaining signs 1 = Show distance remaining signs
	The following rows are repeated for each end of the runway
06	Runway number for this end (eg “08” or “24R”).  If there is no runway suffix (eg. “L”, “R”, or “C”), then leave a blank. Always use leading zeros for single digit numbers (ie. "09", not "9"). (corrected May 30 2007) Runway numbers must always be assigned.   A future enhacement may allow "xxx" to be used in the rare cases where no runway number is assigned (nust be in lower case).  Nothing will be displayed in X-Plane.  (corrected July 29 2007)
34.09073300	Latitude (in decimal degrees) of runway threshold at centreline.  Up to eight decimal places of precision are used.
-117.25038500	Longitude (in decimal degrees) of runway threshold at centreline.  Up to eight decimal places of precision are used.
0	Length of displaced threshold in metres.  Note that the displaced threshold length is included in the implied overall runway length (ie. between the lat/lon of each runway end).
304.8	Length of stopway/blastpad/over-run at the approach end of runway 08 in metres.  The stopway/blastpad/over-run is usually marked with large yellow chevrons, and aeroplane movements are not permitted.  Note that the stopway length is excluded from the implied overall runway length.  (ie. between the lat/lon of each runway end).
3	Runway markings for the this end of the runway (the white painted markings on the surface of the runway), runway 08 in our example.  Here, code 3 implies precision runway markings (ie. there is an associated precision approach for the runway, either an ILS or MLS).
0	Approach lighting code for this end of the runway.
1	Runway touchdown-zone lights (TDZL): 0 = No touchdown-zone lights 1 = Has touchdown-zone lights
2	Runway End Identifier Lights (REIL), white strobe lights at the threshold to help identify the runway in an urban environment: 0 = No REIL. 1 = Has omni-directional REIL 2 = Has unidirectional REIL
Water runway	Example Usage
	101 49 1 08 35.04420900 -106.59855700 26 35.04420911 -106.59855711 (corrected May 30 2007)
101	Identifies this as a data line for a water runway.
49	Runway width in metres (not feet).
1	Indicates if the runway should be marked with buoys bobbing in the water. 0 = No buoys 1 = Show buoys
	The following rows are repeated for each end of the runway
08	Runway number for this end (eg “08” or “24R”).  This will not be used to display anything in X-Plane, but can be used to position an aeroplane ready for takeoff on the runway. If there is no runway suffix (eg. “L”, “R”, “C” or "S"), then leave a blank.   "XXX" can be used in the rare cases where no runway number is assigned.
35.04420900	Latitude (in decimal degrees) of runway threshold at centreline.   Up to eight decimal places of precision are used.
-106.59855700	Longitude (in decimal degrees) of runway threshold at centreline . Up to eight decimal places of precision are used.
Helipad	Example Usage
	102 H1 34.10547800 -117.24249700 150.0 30.48 30.48 02 0 0 0.25 1
102	Identifies this as a data line for a helipad.
H1	Designator for this helipad.  Must be unique at each airport in the format "Hn" where n is an integer (corrected July 26 2007)
35.10547800	Latitude (in decimal degrees) of helipad centre.  Up to eight decimal places of precision are used.
-117.2429700	Longitude (in decimal degrees) of helipad centre.  Up to eight decimal places of precision are used.
150.0	Heading of the helipad in true decimal degrees.  The helipad marking (eg. the yellow "H") will be aligned with this heading.
30.48	Helipad length in metres (not feet).
30.48	Helipad width in metres (not feet).
02	Helipad surface code for the runway.  The leading zero is optional.
0	Helipad markings.
0	Helipad shoulder code.  Here, code 0 implies that there is a no shoulder.
0.25	Helipad smoothness.  Used to cause bumps when taxiing 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	Helipad edge lighting: 0 = No edge lights 1 = Yellow edge lights
Pavement	Example Usage
	110 1 0.25 70.0 Main Apron (asphalt)
110	Identifies this row as a pavement chunk header, used to define chunks of pavement for taxiways and aprons.  Pavement can have holes included, and straight or curved line segments defining its boundaries.  There are important rules that define how complex shapes must be structured.
1	Pavement surface code.
0.25	Pavement roughness. Used to cause bumps when taxiing 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 surface type, and then uses this factor to determine the 'quality' of the runway surface.  The default value is 0.25.   (Not yet supported in X-Plane)
70.0	Pavement texture grain direction in true degrees - orientation of the texture applied to this pavement chunk
Main Apron (asphalt)	Optional name for this chunk.  Not used by X-Plane, but can help organise the file.
Linear feature	Example Usage
	120 Curve E->NW from alpha to echo
120 or 130	Identifies this row as a linear feature header, used to define objects such as lines or light strings, comprised of nodes that define one or more straight or curved line segments.  The type of linear feature might vary along its length.  If this is an airport boundary (code 130) then it must be followed by segments that form a closed loop (ie. terminate in segments with a line codes of type 113 or 114).   There are important rules that define how complex shapes must be structured.
Curve E->NW from alpha to echo	Optional name for this linear feature.
Nodes	Example Usage
	111 34.104321 -117.241397 3 102
111	Identifies this row as a node.  Possible codes are:: 111 = Node (simple point). 112 = Node with Bezier control point. 113 = Node (close loop) point (to close a pavement boundary). 114 = Node (close loop) point with Bezier control point (to close a pavement boundary). 115 = Node (end) point to terminate a linear feature (so has no descriptive codes). 116 = Node (end) point with Bezier control point, to terminate a linear feature (so has no descriptive codes). Each set of  nodes defining a pavement chunk must: Contain at least two nodes (111 - 114). Terminate with a node type 113 or 114. Have only one terminating row. Each set of nodes defining a linear feature must: Contain at least one node (111-112 or 115-116). Terminate with a node type 113 - 116. Have only one terminating row.
34.105357	[All]: Latitude of this node in decimal degrees.  North is positive.
-117.240001	[All]: Longitude of this node in decimal degrees. East is positive.
34.105726	[112, 114, 116 ONLY, so not in example data]: Latitude of Bezier control point in decimal degrees.
-117.240006	[112, 114, 116 ONLY, so not in example data]: Longitude of Bezier control point in decimal degrees.
	[NOT for 115 or 116]: The following of parameter(s) can be repeated as often as necessary to define multiple attributes of the linear feature  (eg. taxiway centre line and green centreline lights, or fences on airport boundaries).
3	[NOT for terminating node, 115 or 116]:  Code for a linear feature.  If we are defining a pavement boundary, then this might be a yellow edge line (as in this example).  If it's a linear feature, then this could be anything (eg. a taxiway centre line, green centre-lights ...).
102	[NOT for terminating node, 115 or 116]:  Additional linear feature definition (102 = blue taxiway edge lights).
VASI / PAPI / Wig-Wag	Example Usage
	21 34.09186800 -117.24858100 2 070.36 3.0 16L VASI(corrected July 30 2007)
21	Identifies this as a row for a VASI, PAPI or Wig-Wag.
34.09186800	Latitude of VASI/PAPI/Wig-Wag in decimal degrees.  For PAPIs and Wig-Wags, this is the centre of the display.  For VASIs, this is the mid point between the two VASI light units (or the centre unit for a three-box VASI).
-117.24858100	Latitude of VASI/PAPI/Wing-Wag in decimal degrees.  For PAPIs and Wig-Wags, this is the centre of the display.  For VASIs, this is the mid point between the two VASI light units (or the centre unit for a three-box VASI).
2	Indicator type type.  Here, code 2 corresponds to a VASI.  If VASI/PAPI/Wig-Wag is required on both sides of a runway or taxiway, then two lines (with code 21) must be created.
070.36	Heading of VASI/PAPI/Wig-wag in true decimal degrees.  This is the heading of an aeroplane flying directly towards the VASI/PAPI, and should therefore match the true heading of the associated runway.
3.0	Visual glidepath angle in degrees (typically 3.00).  Use a value of 0.00 for Wig Wags.
16L	Runway number to which this object relates.  Used in the master database to ensure objects are assigned to the appropriate runway.  Ignored by X-Plane. (corrected June 23 2007)
VASI	Type of lighting object represented.  Ignored by X-Plane. (corrected July 30 2007)
Taxiway signs	Example Usage
	20 34.09210700 -117.25062000 0.00 0 2 {@L}A  (corrected May 30 2007)
20	Identifies this as a row for a taxiway sign.
34.09210700	Latitude
-117.25062000	Longitude
0.00	Orientation in true degrees - heading of someone looking towards the front of the sign..
0	Taxiway sign style (Not yet supported in X-Plane) - use a default value of "0" for now 0 =  Default value
2	Taxiway sign size.   1 = Small taxiway sign 2 = Medium taxiway sign 3 = Large taxiway sign 4 = Large distance remaining sign 5 = Small distance remaining sign
{@L}A	Text of sign (specifications for signs are here)
Startup locations	Example Usage
	15 34.09800200 -117.24417400 0.00 Stand 1
15	Identifies this as a data line for an airport location (code 15).  Multiple locations are allowed as separate data lines.   Locations are used in X-Plane to define gate positions, ramp locations etc. at which the simulator can be started.
35.09800200	Latitude (in decimal degrees) of the location.
-117.24417400	Longitude (in decimal degrees) of the location.
0.00	Heading (in true degrees) of the aeroplane when placed at the location.
Stand 1	Name of location (will be displayed in X-Plane).
Tower viewpoints	Example Usage
	14 34.09726500 -117.24283100 200.00 1 ATC
14	Identifies this as a data line for a tower viewpoint (code 14). Only a single tower viewpoint is permitted.
35.09726500	Latitude (in decimal degrees) of the viewpoint.
-117.24283100	Longitude (in decimal degrees) of the viewpoint.
200.0	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. (IS THIS USED???)
ATC	Name of this viewpoint.
Airport light beacons	Example Usage
	18 34.10110500 -117.24326600 1 BCN
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.
34.10110500	Latitude (in decimal degrees) of the light beacon.
-117.24326600	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.  A beacon of type 0 (= no beacon) can be used to suppress the automatic generation of a default beacon.
Light beacon	Name for this light beacon (not used by X-Plane, but might be useful for file documentation).
Airport windsocks	Example Usage
	19 34.09270300 -117.24790700 1 WS
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 my 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.
34.09270300	Latitude (in decimal degrees) of the airport windsock.
-117.24790700	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 but might be useful for file documentation).
ATC frequencies	Example Usage
	51 12297 CTAF/UNICOM
51	Identifies this as an airport ATC frequency line.  Codes in the 50 - 59 range are used to identity different ATC types.
12297	Airport ATC frequency, in Megahertz multiplied by 100 (ie. 122.97 MHz in this example).
CTAF/UNICOM	Name of the ATC frequency.  This is often an abbreviation (such as GND for "Ground").

Codes used to define data

Codes used in apt.dat (850 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 (CLD).
53	Ground.
54	Tower.
55	Approach.
56	Departure.
Runway / Pavement  surface codes	Meaning of code
01	Asphalt.
02	Concrete.
03	Turf/grass.
04	Dirt.
05	Gravel.
12	Dry lakebed runway (eg. at KEDW Edwards AFB).
13	Water runways.  Nothing will be displayed in X-Plane.  May use buoys as edge markings.
14	Snow or ice runways.
15	Transparent.  Implies a hard surface but with no texture.
Light indicator codes	Meaning of code
	Note:  These codes have changed significantly from file version 810
1	VASI (Visual Approach Slope Indicator, 2 red-white lights behind each other).  VASIs can be sited on either (or both) sides of a runway.
2	PAPI (Precision Approach Path Indicator, 4 horizontal red-white lights) on the left side of a runway (as seen from a landing aeroplane.  The red lights always appear first on the side closest to the associated runway. Note that PAPIs can be sited on either (or both) sides of a runway..
3	PAPI (Precision Approach Path Indicator) (Precision Approach Path Indicator, 4 horizontal red-white lights) on the right side of a runway (as seen from a landing aeroplane).  The red lights always appear first on the side closest to the associated runway (hence the difference from code 2 above).  Note that PAPIs can be sited on either (or both) sides of a runway - for example, if a taxiway exit is situated where the VASI/PAPI should be located.
4	Space Shuttle Landing PAPI (steep 20 degree glide path) – its use is very rare!
5	Tri-colour VASI.
6	Wig-Wag lights.  Pulsating pairs of amber lights on either side of a taxiway at a hold line, facing aeroplanes approaching the hold line on the taxiway. Lights pulse alternately at between 30 and 60 Hz, and are always "on".
Approach lighting codes	Meaning of code
	Note:  These codes have all changed significantly from file version 810
0	No approach lights.
1	ALSF-I (high intensity Approach Light System with sequenced Flashing lights)
2	ALSF-II (high intensity Approach Light System with sequenced Flashing lights and red side bar lights (barettes) the last 1000’, that align with touch down zone 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 touch down zone 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). (changed from a code value of 13 on 27-Nov-2006)
	NOTE:  Other approach lighting systems can be added - just let me have a reference to a specification of the lighting system and (ideally) some images showing their usage at a specified airport.
Runway shoulder codes	Meaning of code
0	No runway shoulder.
1	Asphalt runway shoulder.
2	Concrete runway shoulder.