Previous Next Table of Contents

3. The faaconv Application

3.1 About faaconv

The faaconv application reads the databases distributed by the National Flight Data Center and converts them into formats usable by various other aviation related applications. It currently produces output in a format compatible with the fplan and ICAO Map applications as well as a generic format vaguely similar to the format used in the Airport/Facility Directory published by NFDC.

3.2 Obtaining the NFDC Databases

As of this writing, the National Flight Data Center makes 5 different database files available over the Internet. They contain information on airports, navigation fixes, instrument landing system facilities, navigation aids, and runways. These files can be retrieved by anonymous ftp from the following location

Although it's not absolutely necessary, I recommend that you fetch the files using client software that preserves the remote file time stamps. It's best if we know (as best as we can) the correct age of the information in the database, regardless of when the files were transferred. (Examples of such clients include ncftp, available from ftp://ftp.ncftp.com/ncftp/, or wget with appropriate command line flags, available from ftp://prep.ai.mit.edu/pub/gnu/). I may be missing something, but of the many browsers I've used to transfer files by ftp, all cheerfully use the current date for the file time stamp.

Please note that the home page of the National Flight Data Center web site clearly states that the data files are not to be used for navigational purposes. Given this clear warning, it's quite possible you could get into deep dung if you crashed and used this information without doing some additional homework. You've been warned.

A fundamental limitation of this data that you should be aware of; there is no mention of what datum the latitude and longitude are referenced to (GPS uses the World Geodetic System 84 datum by default). I'm only guessing, but it's possible that no uniform datum was used. Be aware that two points with identical latitude and longitude, but referenced to different datums, can be as far apart as several hundred meters! Given this, don't even think about using this data for a precision approach.

3.3 Running faaconv

In this section, we provide a brief overview of running faaconv, 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.

-k

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 translated.

-m (db|fm)

This option controls the convention used for determining the magnetic variation entries in the output databases. For some entries, such as fixes and navigational aids, the NFDC database does not provide a value for the magnetic variation, so a value must be estimated using a model (see the following section). For other entries, the NFDC database provides 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. The later is the default and recommended value (the values in the NFDC database appear to be somewhat out of date).

3.4 The Geomagnetic Field Module

While examining the format of the new comma delimited data files from NFDC, to my surprise I discovered that the navaid files no longer had any entry for magnetic variation! (This isn't something you can ignore considering the fact that a VOR radial corresponds to a magnetic, not true bearing). 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 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, 1995 Revision (IGRF-95), and the United States Department of Defense World Magnetic Model, 1995 Revision (WMM-95). 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 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 2000. 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 http://www.ngdc.noaa.gov/seg/potfld/geomag.html

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 reasonably well suited to the intended application. In fact, if you own a GPS receiver, it's quite possible you are already using one of these models. I saw a USENET posting that referenced an unofficial communication with at least one GPS manufacturer, indicating that they use the IGRF model in their navigation code 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 two files from NGDC that I used are

The only change I made was to remove the trailing 95 from the file names, the contents were not changed in any way. I did this to; 1) eliminate the need to change source code when the time comes to update to new coefficients, and 2) to avoid the involuntarily episodes of nausea I sometimes experience when I see the number 95. 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 ftp://ftp.ngdc.noaa.gov/Solid_Earth/Mainfld_Mag/DoD_Model/Fortran_Software/. 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 Antartica will have to wait awhile).

  +-----------------------+------------------+------------------+
  |       Computed        | sqrt of the mean | maximum absolute |
  |       Quantity        |  error  squared  |      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.

3.5 Creating Output for fplan

The fplan software expects two database files; airports.nav and vors.nav. The first file contains entries for airports, (gliderports, heliports, and ballonports too), and is generated by running faaconv with comma.apt as input. The second file contains entries for navigational aids and is generated from the combined outputs from faaconv with comma.fix, comma.nav as inputs.

Unfortunately, the comma.ils file is useless. Although the identifier of the airport associated with each ILS facility is provided, the ILS identifiers themselves are not. The trouble is that they are not always related to the associated airport identifier (for example, LAX has multiple ILS systems, each with a unique identifier). The comma.rwy file is not used either, it simply doesn't contain any information that fplan reads or uses.

The generated files must then 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). A simple bourne shell script is provided to automate this conversion. Simply change to the directory where the NFDC files are located and run the script mknavdb.

3.6 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 faaconv with comma.apt, comma.fix, comma.ils, comma.nav as inputs. To reduce the memory requirements of ICAO Map, you might consider creating seperate 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 faaconv. The file icao-1.0.patch contains a patch for the parser.


Previous Next Table of Contents