By Robin Peel, June 17^th, 2001

robin@cpwd.com

Version FG1.4

This FAQ describes the contents and structure of the files that store airport, nav-aid (NDB, VOR, DME and ILS) and IFR intersection data within the Flight Gear flight simulator.

Sometime in 1997, I volunteered to Austin Meyer (the owner/developer of the X-Plane simulator) to try and improve upon the very basic airport data included in X-Plane version 3.x. I built an application in Microsoft Access 97 (now converted to Access 2000) to store and manipulate the airport, nav-aid and intersection data. I have worked with Austin to add additional airport and nav-aid details to X-Plane (such as custom taxiways, airports outside the boundaries of the USA, more accurate runway markings, etc) and during this time the master database has grown to over 20MB in size. This database is also now used to generate data for the FlightGear simulator, using data files that are different in format (and more sophisticated) than the X-Plane data files.

I perform this task as a volunteer. The data is published as a free resource to the X-Plane and FlightGear communities.

At present, I have around 450hrs of "real" flying experience, gained since 1989. I have a UK Private Pilot’s Licence (gained at White Waltham, EGLM), a US Private Certificate and a US Instrument Rating. I currently fly a rented new C-172 SP out of Albuquerque Double Eagle II (KAEG), or more elderly knackered C-172s out of Santa Fe (KSAF). I have just ordered a new Liberty XL-2 from Liberty Aerospace in Montrose, Colorado (www.libertyaircraft.com).

The master database is my Microsoft Access 2000 database that stores all the airport, nav-aid and intersection data. In database parlance, it is highly "normalized" and consists of over 35 Access tables accessed from a custom-designed Access 2000 application. The master database currently contains over 22,000 airports. I may "upsize" the database back-end to Microsoft SQLServer (7.0) in the very near future.

I regularly import updates and amendments to the master database using routines that will automatically read fragments of new data sent to me by other users, and save the new data into my Access tables. Similarly, I have routines that will generate the data required by FlightGear and X-Plane in the necessary form

The data is pretty complete for the USA (based upon FAA data sources). Quality data for other countries is harder to obtain, but dedicated FlightGear and/or X-Plane users have sent me data for much of Canada, Western Europe (with some gaps), Japan and Australia. Some other random major airports also exist (eg. in Central and South America).

First, you need to find a good source of information. An official chart of the airport (such as those published by Jeppesen) is a good starting point – they often have a helpful latitude/longitude scale around the edges that you can use to figure out the exact positions of runways and taxiways. Remember that these scales appear to be backwards for western longitudes and southern latitudes!

Then you need to get the data into the appropriate files (see below for file names and formats.

Finally, send errors, corrections and additions to me (robin@cpwd.com). The easiest way to send new or corrected data is to copy just the appropriate lines from your default.apt, default.nav, default.ils and/or default.fix files into a plain text file, and attach the text file to an e-mail. All of these files are just plain text files, and can be edited with any text editor (or a word processor operating in "text-only" mode). Note that in Windows, the Notepad editor sometimes balks at the size of these files (it seems to be a problem in Windows 95/98, but not in Windows 2000).

Please do not send me:

• Your entire file (with your corrections embedded somewhere in its midst) – these are impossible for me to sort through!
• Scanned copies of charts in the hope that I will spend several hours trying to plot the positions of runways and taxiways for you. Unless I have a personal interest in the particular airport, this takes just too much of my time. Sorry!

The following files contain airport, nav-aid and intersection data in FlightGear. They may be stored in the Airports and Navaid folders of your FlightGear installation as .gz archives:

When un-archived, they are all plain text files that can be viewed or edited with any text editor (such as Notepad on a Windows PC).

Features common to each file are:

• Each data "element" occupies a single line of the file.
• Any comments are preceded with a double slash ("//"). Typically, the first line of each file is a comment that includes a data version number and other descriptive information. Other comments may be added as required within the file.
• The last line of a file is marked with "[End]".
• The first character of each line describes the type of data that the line contains (eg. "A" for airport data, "R" for runway data.
• The order in which data is stored in the files is conceptually unimportant. BUT, airport data must be ordered so that the airport header data (prefixed by "A") is followed by its runway and taxiway data (prefixed by "R" or "T").

IMPORTANT: All headings referenced in the files are true (not magnetic). FlightGear has an internal model of magnetic variation that will be used to properly align VORs, etc.

The meanings of these line "prefix" codes in default.apt are:

A Airport header data

R Runway at an airport

T Taxiway at an airport

The meanings of these line codes in default.nav are:

D DME

N NDB, including NDB element of LOMs (Locator Outer Markers or ‘Compass Locators’)

V VOR

The meanings of these line codes in default.ils are:

L Localiser-only

I ILS and LOC/DME

S SDF (Simplified Directional Facility)

D LDA (Localiser Directional Aid)

M MLS (Microwave Landing System)

Since the default.fix file contains only IFR intersections, no "prefix" codes are used to differentiate the data

Individual data elements on each line can be separated by any number of spaces or other ‘white space’ – however, it is a good plan to keep them aligned in tidy columns (this is harder in default.apt, with its mixture of line types) – it is easier to spot silly errors and/or omissions in this way.

Each airport has a header line (code "A") and one or more runway/taxiway lines (code "R" or "T"). The runways for each airport MUST follow the airport header line. Taxiways should follow the runways. A blank line can be used to separate different airports – this helps improve readability but is not required.

Here is a simplified fragment for part of an airport in default.apt:

A KABQ 35.040361 -106.609306 5352 CYN Albuquerque International Sunport

R 08 35.044209 -106.598560 090.43 13775 150 NCPHN YNVQ 991 0 NYVN 0 0

R 03 35.032077 -106.618983 044.67 10000 150 NCPHN YNPO 0 0 NNPN 0 0

R 12 35.039105 -106.614064 128.98 5142 150 NAVMN NNNN 0 0 NYPN 0 0

R 17 35.044022 -106.611983 183.36 10000 150 NAVMN NYVN 890 0 NYVN 0 0

T A 35.044209 -106.588560 090.43 13775 100 GCB

This shows one airport header line, four runways and a taxiway. The order of the data on the airport header line is (using the above example):

A This is an airport header line

KABQ ICAO code for the airport. All airports must have a unique ICAO code.

35.040361 Airport Reference Point (ARP) latitude

-106.609306 Airport Reference Point (ARP) longitude

5352 Airport elevation in feet (above MSL).

C Airport usage (C=Civilian, M=Military) – determines airport beacon colours.

Y Control Tower (Y=Yes, N=No)

N Show default airport buildings (Y=Yes, N=No)

"Albuquerque International Sunport" Airport name - no limit to length.

The data on the runway lines is a little more complex. Using the first runway in the above example data:

R This is a data line for a runway.

35.044209 Latitude (in decimal degrees) of runway center.

-106.598560 Longitude (in decimal degrees) of runway center.

08 Runway number (eg. "08" or "27L")

90.43 True (not magnetic) heading of the runway in degrees.

13775 Runway length in feet.

150 Runway width in feet.

The next data chunk describe data common to both ends of the runway:

N Runway centre-line lights (Y=Yes, N=No)

C Runway surface (A=Asphalt, C=Concrete, T=Turf, D=Dirt, G=Gravel, W=Water, X=Other)

P Runway markings (V=Visual, P=Precision, R=Non-Precision, B=Buoys - water)

H Edge Lights (N=None, H=High intensity, M=Medium, L=Low, B=Blue taxiway)

N Runway guard lights (Y=Yes, N=No) – the flashing orange "wig-wags" that protect runway entrances.

The next two data chunks describe data for each end of the runway, starting with the end defined by the runway number (08 in our example data):

Y Touchdown zone lights (Y=Yes, N=No)

N REIL (Y=Yes, N=No)

P Visual glide scope indicator (N=None, V=VASI, P=PAPI). [I may make the codes more detailed soon]

Q Approach lighting (see code lists below)

991 Length of displaced threshold in feet

0 Length of stopway in feet

This data chunk format is then repeated for the other end of the runway (runway 26 in our example).

This data is then repeated (with appropriate values) for the opposite end of this runway (KABQ runway 26 in our example data).

Taxiway data is similar in structure to the runway data:

T This is a data line for a taxiway segement.

A Taxiway identifier, that may be repeated for multiple taxiway segments. Default is "-".

35.044209 Latitude (in decimal degrees) of taxiway center.

-106.598560 Longitude (in decimal degrees) of taxiway center.

90.43 True (not magnetic) heading of the taxiway segement in degrees.

13775 Taxiway segment length in feet.

150 Taxiway segment width in feet.

C Taxiway segment surface (A=Asphalt, C=Concrete, T=Turf, D=Dirt, G=Gravel, W=Water, X=Other)

B Edge Lights (N=None, B=Blue taxiway, R=Red edge lights)

Each nav-aid is on a separate line, usually sorted by the nav-aid name within each nav-aid type.

Here are some example lines, showing selected nav-aids in the Albuquerque area:

V 35.043796 -106.816312 5740 113.20 130 Y ABQ XXX Albuquerque VORTAC

N 34.987022 -106.620384 5304 247.00 50 N ILT XXX Isleta NDB

D 51.346667 -000.563889 104 109.85 50 Y FRK 05W Fairoaks DME

The meaning of this data for the first row (ABQ VORTAC) is:

V Navaid type (D=DME, N=NDB and V=VOR).

35.043796 Latitude of nav-aid in decimal degrees.

-106.620384 Longitde of nav-aid in decimal degrees.

5740 Elevation (in feet) of nav-aid.

113.20 Frequency.

130 Range of nav-aid (in nautical miles).

Y Co-located DME (Y=Yes, N=No).

ABQ Nav-aid identifier (note – these are not unique).

XXX Magnetic variation, if known, in format 13E for 13 degrees east.

"Albuquerque VORTAC" Nav-aid name.

Each ILS installation is on a separate line. Here are some example lines, showing the ILS 08 for KABQ (Albuquerque, New Mexico). These lines are long – so they are wrapped onto multiple lines here (but are on a single long line in default.ils):

I ILS KABQ 08 111.90 ISPT 090.43 35.044026 -106.570548

5352 3.00 35.043212 -106.614641 35.044750 -106.570577

35.046352 -106.742583 35.044686 -106.628247 00.000000 000.000000

This is not as bad as it looks! The meaning of this data is:

I ILS type (see code list below).

ILS ILS type description (used to aid file navigation). Other values are as in the list of ILS type codes below.

KABQ ICAO airport code for the runway this ILS serves.

08 Runway number that this ILS serves.

111.90 ILS frequency (usually the localiser frequency).

ISPT ILS identifier.

090.43 True heading of the localiser.

35.044026 Latitude of the localiser aerial.

-106.570548 Longitude of the localiser aerial.

5352 Elevation (in feet) of the glideslope aerial.

3.00 Gradient of the glideslope (typically 3.00 degrees).

35.043212 Latitude of the glideslope aerial.

-106.614641 Longitude of the glideslope aerial.

35.044750 Latitude of the associated DME aerial.

-106.570577 Longitude of the associated DME aerial.

35.046352 Latitude of the Outer Marker (OM).

-106.742583 Longitude of the Outer Marker (OM).

35.044686 Latitude of the Middle Marker (MM).

-106.628247 Longitude of the Middle Marker (MM).

00.000000 Latitude of the Inner Marker (IM).

000.000000 Longitude of the Inner Marker (IM).

• If an ILS component does not exist, its latitude/longitude will be set to zero (eg. the Inner Marker in the above example).
• For a Locator Outer Marker (LOM), which is an NDB co-located with an OM, the NDB must be added to default.nav as a separate, stand-alone NDB (at the same location!).

This is the easiest file to interpret! Each intersection is on a separate line. Here is an example line:

WOBIN 35.162472 -106.646500

The meaning of this data is:

WOBIN Intersection name (always five characters and must be unique).

35.162472 Latitude in decimal degrees.

-106.646500 Longitude in decimal degrees

Flight simulator pilots often get confused about where the aerials that form the components of an ILS are positioned in relation to the runway. Here is a simple example for a fictitious ILS for runway 09.

The localiser aerial (which provides left-right guidance to the pilot) is usually positioned just beyond (500 – 1000 feet) the far end of the runway it serves (ie. beyond the eastern end of our example runway). The localiser’s beam points back down the runway (westward in our example) towards an approaching plane – the center of the beam passes through the runway’s touch down zone. You can see the localiser aerial at your nearest major airport – the aerial is a wide, flat thing, usually painted red, and hidden amongst the forest of approach lighting for the opposite runway (runway 27 in our example). It is usually the first valuable thing destroyed by an aeroplane that over-runs the end of a runway – or by an aeroplane the approaches the opposite end of the runway a little low.

Some localisers exist in isolation from other components of an ILS. These form part of Localiser (LOC), Localiser Directional Aid (LDA) or Simplified Directional Facility (SDF) approaches. Such aerials can be positioned wherever is most useful … an extreme example is the LOC on top of a mountain near Aspen, Colorado (KASE) that is used to provide guidance for departures, not arrivals! Washington National (KDCA) runway 18 is served by a localiser positioned on the opposite side of the Potomac River in Maryland – it points to the north-west along the Potomac to provide guidance to aeroplanes following the river towards KDCA runway 18 – this approach heading is significantly offset from the runway heading..

The glideslope (GS) aerial (which provides up-down guidance to the pilot) is usually positioned just to one side of the runway’s touch down zone (TDZ), which is about 1,000’ along the runway from the threshold. Typically, a GS aerial might be 200 – 300 feet to the left (north in our example for runway 09) of the TDZ. Again, you can see this vertical aerial at your local airport – it often has a small shack close by housing the electrical gear. The shack is often painted in lurid red/white or orange – presumably in an attempt to stop errant from aeroplanes flying (or taxying) into it. The beam from the glideslope is typically angled up from the TDZ at 3 degrees, though this may vary. Steeper angles may not sound significant (say 5 degrees) but they are surprisingly disconcerting to nervous passengers.

The marker beacons (which provide information to a pilot about the distance from the runway) are placed on the ground at certain distances from the runway’s threshold. The Inner Marker (IM) is usually very close to (or at) the runway threshold. The Middle Marker (MM) is typically 3,500’ out from the threshold (to the west in our example) and usually indicates a point at which an approaching aeroplane on the glideslope should be 200’ above the TDZ elevation. The Outer Marker (OM) varies in location, but is usually 4 – 7 nautical miles for the runway. Not all ILS approaches have the full complement of marker beacons – inner markers are relatively rare.

Here is a summary for an ILS for our example runway 09:

OM MM IM #

() () ()09==========================27 @

Where:

# - Glideslope aerial

@ - Localiser aerial

= - Runway 09/27

() - Marker beacons

The FlightGear data files define all positions as "decimal degrees" to six decimal places (eg. –123.456789). This makes mathematical calculations faster.

But remember from your basic school geometry that a degree is traditionally subdivided into 60 minutes, and that a minute can be further subdivided in 60 seconds. Some aviation data sources choose not to use the "seconds" – instead they use decimal parts of a minute. Other sources use data defined in degrees and the decimal part of degrees, just as in FlightGear. Here are some example data formats (all refer to the same position):

N35.5000 W106.5000 (Decimal degrees, or dd.dddd)

35 30.00N 106 30.00W (Decimal minutes, or dd mm.mm)

35 30 00N 106 30 00W (Degrees, minutes and seconds, or dd mm ss)

A common convention is that that western longitudes and southern latitudes are negative numbers when converted to decimal degrees. So data for the USA will have positive latitudes and negative longitudes (see all the example data quoted above).

So, to convert a dd mm.mm format (eg. 35 30.00N) to decimal degrees), you need to:

• Divide the minutes by 60 (in our example: 30.00/60 = 0.5).
• Add this result to the degrees (in our example: 35 + 0.5 = 35.5).
• Check the sign – south or west is negative (in our example, north is positive).
• And so the converted answer is: 35.50.How do I calculate the position of somewhere in relation to somewhere else?

[From JJ Brennan] For those who don't like to do the math, there is a very useful little program called LLCALC that will do latitude/longitude calculations. It's also very useful if you wish to locate a point in some relation to another point (like placing an ILS GS transmitter alongside a runway, or finding the end points of a runway from its center point).

A copy can be found at:

ftp://ftp.kingmont.com/pub/kingmont/x-plane/llcalc.zip

[End]