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.
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
ftp://ftp.tc.faa.gov/nfdc/apt.tar.gz
ftp://ftp.tc.faa.gov/nfdc/fix.tar.gz
ftp://ftp.tc.faa.gov/nfdc/ils.tar.gz
ftp://ftp.tc.faa.gov/nfdc/nav.tar.gz
ftp://ftp.tc.faa.gov/nfdc/rwy.tar.gz
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.
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).
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.
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
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.
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
ftp://ftp.ngdc.noaa.gov/Solid_Earth/Mainfld_Mag/Models/igrf95
ftp://ftp.ngdc.noaa.gov/Solid_Earth/Mainfld_Mag/Models/wmm95
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.
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.
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
.
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.