Previous Next Contents

3. Conversion of the US National Airspace Data Files

3.1 Obtaining the US National Airspace Data CD-ROM

The US National Airspace Data ISO 9660 CD-ROM can be obtained for a nominal fee by sending a request in writing to the FAA Aeronautical Information Services Division. The data is suitable for navigation purposes, and the effective dates coincide with the 56 day charting cycle. The data is generally available about 15 days before the starting effective date. A subscription plan is also available that includes a password for ftp access, and a four month advance notice of any pending format changes. More information can be obtained from the FAA web sites at;

3.2 Overview of the Conversion Process

The files on the National Airspace Data CD-ROM are stored in a format that uses fixed width data fields, and fixed length records. The formats of these files are described in detail in the documents provided on the CD-ROM. The conversion of these files is a two step process. The first step utilizes awk scripts to extract selected data fields, and write them out in a format with variable width data fields. The ":" character is used as a data field delimiter. The choice of the colon character for the delimiter was motivated by the fact that this is what the fplan databases use. These intermediate files are very similar to the comma delimited files that were once available for free download. The final step is to convert the intermediate files to the desired format using the nasdconv application.

3.3 Generating the Intermediate Files

There are three intermediate files with variable width data fields; containing airports, fixes, and navaids. To avoid the possibility of data corruption, we must insure that the character used to delimit data fields (the colon character), does not appear in the data itself. At the time of this writing, a check of the raw NASD files shows that they don't contain any colon characters. However, as a fail safe, the first step of the conversion process is to filter the NASD files with sed, to convert any colon characters to semicolons.

To generate the intermediate airport file, the apt.txt and twr.txt NASD files are converted using the nasd_apt.awk and nasd_twr.awk scripts respectively. The two output streams are merged and sorted by identifier and record type. The intermediate fix file is the result of converting the fix.txt NASD file using the nasd_fix.awk awk script. The intermediate navaid file is the result of converting the nav.txt NASD file using the nasd_nav.awk awk script.

3.4 Creating Output for fplan

The mkfplandb bourne shell script makes it easy to create database files for use with fplan. The script handles everything; the filtering of the raw data with sed, the creation and sorting of the intermediate files, running nasdconv and paddb, and so on. I have added more error checking in this release, which should make it robust enough for the casual user. Here is a step by step overview of how to use the script;

  1. If you have the NASD CD-ROM, place it in your drive and mount it with the "mount" command. Depending on permissions, you may need to be the root user to do this. Because the CD-ROM does not make consistent use of upper and lower case characters in the filenames, you should include the option "check=relaxed" in your "mount" command.
  2. Now run "mkfplandb" to generate the fplan database files. A brief description of all available options can be obtained by using the "-h" option. If you want to see what commands the script is executing, include the "-v" option on the command line.
  3. If mkfplandb has difficulty in determining where your CD-ROM is mounted in your file system, or if you have copied the NASD files to disk, you can specify the directory where they are located with the "-d" command line option.
  4. If mkfplandb has difficulty in locating any of the executables that it needs, you can specify the exact location on your system by setting the corresponding environment variable (e.g. AWK, NASDCONV, PADDB, SED, SORT).
  5. The NASDCONV_FLAGS environment variable can be used to specify the command line options passed to nasdconv. The default options are "-k -f wmm -m fm -t fplan".

The remainder of this section provides a closer look at the process of generating databases for use with fplan. The airports.nav data file is generated by running nasdconv with the intermediate airport file as input. The vors.nav file is generated from the combined outputs from nasdconv with the intermediate fix and navaid files as inputs. The files written by nasdconv must be sorted by identifier, and padded to fixed length records using the paddb utility supplied with fplan. (The fplan application uses a fast binary search that relies on fixed length records). Here is a simple diagram that shows the entire process.

apt.txt ->sed ->apt.awk -+
                        sort ->nasdconv ->paddb ->airports.nav
twr.txt ->sed ->twr.awk -+

fix.txt ->sed ->fix.awk ->nasdconv -+
                                   sort ->paddb ->vors.nav
nav.txt ->sed ->nav.awk ->nasdconv -+

3.5 Creating Output for ICAO Map

The ICAO Map software reads a single world database file that contains all airport and navigational aid information. You can simply merge the output from nasdconv with the intermediate airport, fix, and navaid files as inputs. To reduce the memory requirements of ICAO Map, you might consider creating separate world files for your state or region. The parser in release 1.0 of ICAO Map is not compatible with some of the characters output by nasdconv. The file icao-1.0.patch contains a patch for this problem, as well as support for printing to letter size paper.

3.6 Running the nasdconv application

In this section, we provide a brief overview of running nasdconv, a complete reference on command line syntax can be found in the provided man page. There are two options with important ramifications that we discuss below. What's right for you depends on your specific situation.


This option provides a mechanism for differentiating between an airport and navigational aid with the same identifier. (There are many examples of this in the airport database). This option implements a convention currently used by many GPS manufacturers. Any airport identifier that is all alphabetic, and is exactly three characters long, is prepended by the character "K". This applies to all such airports, regardless of the existence of a navigational aid with the same identifier. So for example, HMT becomes KHMT, while identifiers like L78 and CL35 are not changed by the translation algorithm.

-m (db|fm)

This option controls the convention used for determining the magnetic variation entries in the output databases. For some of the NASD database files, (the fix files for example), a magnetic variation value is not provided, so a value must be estimated using a model (see the following section). The other NASD database files provide a magnetic variation value. To use the database value when it's available, use db as the argument to this option. To always use the value computed by the model, use fm. This is the default and recommended value.

This option controls the convention used for determining the magnetic variation entries in the output databases. Some of the NASD files, the fix files for example, do not provide a value for the magnetic variation. For these inputs, a value will always be estimated using a model (see the following section). To use the database value when it's available from the input file, use db as the argument to this option. To always use the value computed by the model, use fm. This is the default and recommended value (see the next section for details).

3.7 The Geomagnetic Field Module

One of the problems with the NASD database files is that in many cases the magnetic variation values are either missing entirely or not very accurate. For example, the fix files have no magnetic variation entries of any kind. The nav files provide a value for magnetic variation, but only rounded to the nearest whole degree. In many cases, the epoch year associated with a magnetic variation value is quite dated, (this is undesirable because the values drift slowly with time). At any rate, this presented an unexpected complication that had to be dealt with. I needed a model to calculate the magnetic variation, given an arbitrary latitude and longitude referenced to some datum.

The Physical Model

After some research, I quickly concluded that the best solution was to use one of the geomagnetic field models in common use by the Geophysics community. The two most commonly encountered models are the International Geomagnetic Reference Field (IGRF), and the United States Department of Defense World Magnetic Model (WMM). In these models, the geomagnetic field potential is represented by a summation of spherical harmonics (using associated Legendre functions). The coefficients are found by fitting the model to very precise measurements of the earth's geomagnetic field. A secular change model is used to account for the slow drifting of the earth's magnetic field over time. The models are updated once every five years, with the next model due to come out in the year 2005. The model coefficients and a collection of support software are distributed in the United States by the National Geophysical Data Center (NGDC) located in Boulder, CO. They can be reached on the Internet at

Limitations of the Physical Models

These physical models have limitations that you should be aware of. The low order polynomials used in these models capture only the contribution to the earth's geomagnetic field from the earth's fluid outer core. The models do not have enough fidelity to capture the contributions to the total field from the earth's crust. These contributions, or other anomalies, are not uncommon, and in some cases can be quite significant (the iron ore deposits of the Mesabi Range in Northern Minnesota are a prime example). Anomalies can also be caused by magnetic storms in the ionosphere, man made sources such as high voltage electric power transmission lines, etc.

On the other hand, these models are well suited to the intended application. In fact, virtually all GPS receivers use one of these models to convert a true heading into a magnetic one. The literature suggests that these models are good to about 30 minutes of arc for the angles, and to within about 25 nanoTesla for the total intensity.

Software Implementation

I initially considered using some of the software distributed by NGDC. I really wanted a C language solution and most of the NGDC software was written in Fortran 77 (which I have nothing against in general). I decided to start from scratch using only a theoretical description of the model. The results of that effort can be found in the file field_model.c. It was designed to use either of the IGRF or WMM model coefficient data files exactly as distributed by NGDC (to make future updates of the model coefficients as easy as possible). The model coefficient files from NGDC are

The only change I made was to the file names, the contents were not changed in any way. If you try using coefficient files from sources other than NGDC, exercise appropriate caution. Some distributions of these models (WMM in particular) use different normalization factors for the associated Legendre functions, and would produce incorrect results when used with this software! Be warned, be careful.

Software Programming Interface

Since the field model seemed liked it might be useful for other projects, I tried to make the implementation as self contained as possible. The field_model.c module contains three functions;

extern int init_field_model(char *filename);

This function is called to initialize the model coefficients, which are read from the specified file. If you want to switch back and forth between different models, just call the function again with the appropriate model coefficient file. It returns TRUE if the initialization succeeded, and FALSE if not.

extern int field_model(field_model_t *value);

This function is used to compute the geomagnetic field at a specified point. The input position and computed field values are exchanged through a single structure of type field_model_t which is described in the module header file field_model.h. The specified position is assumed to be described by geodetic latitude, longitude and altitude (or height for you ground pounders), referenced to the WGS-84 datum. (The choice of the WGS-84 datum seemed best since that is the default for GPS which is become increasingly important in practical navigation). The computed declination (what we pilots call variation) and inclination (or dip) angles are returned in units of decimal degrees. The computed total field strength is in units of nanoTesla. The sign convention for the angles is; positive declination corresponds to east, and positive inclination is down. It returns TRUE if the computation succeeded, and FALSE if not.

extern char *strerror_field_model(void);

This function returns a pointer to a character string that contains an explanation of the last error that occurred. This allows the calling function to decide how to handle error recovery.

Accuracy of Software Implementation

I tested my implementation against some of the software distributed by the NGDC by anonymous ftp. It was a little disappointing to find that the various implementations available from them did not always agree with one another all that well (at least relative to my expectations). It was reassuring to find that my implementation agreed quite well with the software developed by the Defense Mapping Agency, the Fortran 77 subroutine named GEOMAG.FOR, which can be obtained from the directory The table below shows the statistics for the comparison of 5 million random evaluations. All inputs were allowed to vary uniformly over the entire valid range, except for latitude which was distributed uniformly over the interval from 80S to 80N degrees. (I haven't finished implementing the limiting case of the geographic poles, so I've limited the inputs to this range for now. Sorry, you guys planning flights to Northern Greenland or Amundsen-Scott Station in Antarctica will have to wait awhile).

  |       Computed        | sqrt of the mean | maximum absolute |
  |       Quantity        |  squared  error  |      error       |
  | declination (degrees) |   2.57954e-05    |    -0.0226572    |
  | inclination (degrees) |   1.04046e-05    |  -7.28456e-05    |
  |  total intensity (nT) |      0.010123    |      -0.06995    |

The average agreement is acceptable when measured by the square root of the mean of the squared error (quite good considering that the DMA software is only single precision). There are a few regions where the disagreement in declination is higher. In my tests it was always a point relatively close to one of the magnetic poles, near 78N 103W, or 65S 139W. This is not unreasonable since the horizontal component of the magnetic field vanishes (by definition), and the declination ceases to be well defined as one approaches the magnetic poles.

Previous Next Contents