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;
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.
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.
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;
"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.
"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.
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.
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
).
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 -+
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.
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.
-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 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).
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.
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
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.
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
ftp://ftp.ngdc.noaa.gov/Solid_Earth/Mainfld_Mag/Models/igrf2000.dat
ftp://ftp.ngdc.noaa.gov/Solid_Earth/Mainfld_Mag/Models/wmm2000.dat
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 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.