pkg://avdbtools-0.1-1.src.rpm:117982/avdbtools-0.1.tar.gz
info downloads
avdbtools-0.1/ 40750 144 144 0 6524231140 11412 5 ustar jcp users avdbtools-0.1/bin/ 40755 144 144 0 6523770330 12177 5 ustar jcp users avdbtools-0.1/bin/mknavdb 100555 144 144 4525 6523770316 13654 0 ustar jcp users #!/bin/sh
#
# mknavdb - bourne shell script to automate generation of nav format databases
#
# $Id: mknavdb,v 1.1 1998/05/06 05:09:56 jcp Exp $
#
# configure defaults
K_OPTION="-k"
MAG_VARIATION="-m fm"
FIELD_MODEL="-f wmm"
CONV_OPTIONS=${K_OPTION}" "${MAG_VARIATION}" "${FIELD_MODEL}" -t fplan "$*
TMP_FILE_ROOT=/tmp/faaconv.tmp.$$
# define function to execute a child process
execute_process()
{
eval "$1"
rc=$?
case $rc in
0) ;;
*) exit $rc ;;
esac
}
# define exit handler function
clean_up()
{
execute_process "rm -f ${TMP_FILE_ROOT}.[01].apt ${TMP_FILE_ROOT}.[01].vor"
}
trap "clean_up; exit \$rc" 0
# check for the input database files
if [ ! -f comma.apt -o ! -f comma.fix -o ! -f comma.nav ];then
echo "mknavdb: unable to open one or more input database files"
exit 1
fi
# start with empty temporary files
execute_process "cat /dev/null > ${TMP_FILE_ROOT}.0.apt"
execute_process "cat /dev/null > ${TMP_FILE_ROOT}.0.vor"
# generate airport and nav database
echo "mknavdb: creating airports.nav database"
execute_process "faaconv ${CONV_OPTIONS} comma.apt >> ${TMP_FILE_ROOT}.0.apt"
echo "mknavdb: creating vors.nav database"
execute_process "faaconv ${CONV_OPTIONS} comma.fix >> ${TMP_FILE_ROOT}.0.vor"
execute_process "faaconv ${CONV_OPTIONS} comma.nav >> ${TMP_FILE_ROOT}.0.vor"
# sort temporary files, remove any duplicate entries
echo "mknavdb: sorting the databases"
execute_process "sort -t: ${TMP_FILE_ROOT}.0.apt |uniq > ${TMP_FILE_ROOT}.1.apt"
execute_process "sort -t: ${TMP_FILE_ROOT}.0.vor |uniq > ${TMP_FILE_ROOT}.1.vor"
# display database file statistics
na=`wc -l ${TMP_FILE_ROOT}.1.apt` ; set $na ; na=$1 ;
nv=`wc -l ${TMP_FILE_ROOT}.1.vor` ; set $nv ; nv=$1 ;
echo "mknavdb: entries in generated airports database:" $na
echo "mknavdb: entries in generated vors database:" $nv
# pad the databases if paddb is installed
if [ -x paddb ]; then
execute_process "paddb ${TMP_FILE_ROOT}.1.apt airports.nav"
execute_process "paddb ${TMP_FILE_ROOT}.1.vor vors.nav"
else
execute_process "mv ${TMP_FILE_ROOT}.1.apt airports.txt"
execute_process "mv ${TMP_FILE_ROOT}.1.vor vors.txt"
echo "mknavdb: could not find the paddb application, distributed with fplan."
echo "mknavdb: you must pad the database files before they can be used by"
echo "mknavdb: fplan, generated files: airports.txt vors.txt"
fi
# all done
exit 0
avdbtools-0.1/lib/ 40755 144 144 0 6506127263 12177 5 ustar jcp users avdbtools-0.1/lib/wmm 100444 144 144 16313 6100014056 13022 0 ustar jcp users WMM-95 1995.00 12 8 0 1995.00 2000.00 -1.0 600.0 WMM-95 1
0 1-29682.1 0.0 17.60 0.00 WMM-95 2
1 1 -1782.2 5315.6 13.20 -18.00 WMM-95 3
0 2 -2194.7 0.0 -13.70 0.00 WMM-95 4
1 2 3078.6 -2359.1 4.00 -14.60 WMM-95 5
2 2 1685.7 -418.6 -0.30 -7.20 WMM-95 6
0 3 1318.8 0.0 0.80 0.00 WMM-95 7
1 3 -2273.6 -261.1 -6.60 4.00 WMM-95 8
2 3 1246.9 301.0 -0.50 2.20 WMM-95 9
3 3 766.3 -416.5 -8.50 -12.60 WMM-95 10
0 4 940.0 0.0 1.20 0.00 WMM-95 11
1 4 782.9 259.4 1.10 1.30 WMM-95 12
2 4 290.9 -230.9 -6.80 1.00 WMM-95 13
3 4 -418.9 99.8 0.30 2.50 WMM-95 14
4 4 113.8 -306.1 -4.50 -1.20 WMM-95 15
0 5 -209.5 0.0 0.90 0.00 WMM-95 16
1 5 354.0 43.7 0.50 0.50 WMM-95 17
2 5 238.2 157.6 -1.40 1.50 WMM-95 18
3 5 -122.1 -150.1 -1.70 0.60 WMM-95 19
4 5 -162.8 -59.2 0.00 1.70 WMM-95 20
5 5 -23.3 104.4 2.10 0.60 WMM-95 21
0 6 68.5 0.0 0.40 0.00 WMM-95 22
1 6 65.6 -15.2 -0.30 0.70 WMM-95 23
2 6 64.1 74.3 0.30 -1.50 WMM-95 24
3 6 -169.1 69.4 2.10 -0.50 WMM-95 25
4 6 -0.5 -55.3 0.00 -0.70 WMM-95 26
5 6 16.5 3.0 -0.40 1.10 WMM-95 27
6 6 -91.0 33.3 -0.40 2.60 WMM-95 28
0 7 78.0 0.0 -0.30 0.00 WMM-95 29
1 7 -68.1 -76.1 -1.10 0.30 WMM-95 30
2 7 0.1 -24.5 -0.50 0.00 WMM-95 31
3 7 29.6 1.6 0.50 0.70 WMM-95 32
4 7 6.0 20.0 1.30 -0.60 WMM-95 33
5 7 8.7 16.5 0.10 0.10 WMM-95 34
6 7 9.2 -23.6 0.00 -0.60 WMM-95 35
7 7 -2.4 -6.8 -0.90 -0.40 WMM-95 36
0 8 24.7 0.0 0.10 0.00 WMM-95 37
1 8 3.4 14.9 0.00 0.40 WMM-95 38
2 8 -1.5 -19.5 0.40 -0.30 WMM-95 39
3 8 -9.6 6.3 0.30 0.10 WMM-95 40
4 8 -16.5 -20.4 -1.30 0.80 WMM-95 41
5 8 2.6 12.2 0.50 -0.10 WMM-95 42
6 8 3.6 7.0 0.40 -1.30 WMM-95 43
7 8 -4.9 -19.0 -0.90 -0.90 WMM-95 44
8 8 -8.5 -8.8 0.10 -1.10 WMM-95 45
0 9 2.9 0.0 0.00 0.00 WMM-95 46
1 9 7.5 -19.8 0.00 0.00 WMM-95 47
2 9 0.4 14.6 0.00 0.00 WMM-95 48
3 9 -10.3 10.9 0.00 0.00 WMM-95 49
4 9 9.7 -7.5 0.00 0.00 WMM-95 50
5 9 -2.3 -6.8 0.00 0.00 WMM-95 51
6 9 -2.4 9.3 0.00 0.00 WMM-95 52
7 9 6.8 7.7 0.00 0.00 WMM-95 53
8 9 -0.5 -8.1 0.00 0.00 WMM-95 54
9 9 -6.5 2.6 0.00 0.00 WMM-95 55
010 -2.9 0.0 0.00 0.00 WMM-95 56
110 -3.3 3.2 0.00 0.00 WMM-95 57
210 2.8 1.7 0.00 0.00 WMM-95 58
310 -4.3 2.9 0.00 0.00 WMM-95 59
410 -3.1 5.6 0.00 0.00 WMM-95 60
510 2.4 -3.4 0.00 0.00 WMM-95 61
610 2.8 -0.7 0.00 0.00 WMM-95 62
710 0.7 -2.9 0.00 0.00 WMM-95 63
810 4.1 2.3 0.00 0.00 WMM-95 64
910 3.6 -1.6 0.00 0.00 WMM-95 65
1010 0.6 -6.6 0.00 0.00 WMM-95 66
011 1.7 0.0 0.00 0.00 WMM-95 67
111 -1.6 0.3 0.00 0.00 WMM-95 68
211 -3.6 1.0 0.00 0.00 WMM-95 69
311 1.2 -3.6 0.00 0.00 WMM-95 70
411 -0.6 -1.4 0.00 0.00 WMM-95 71
511 0.1 1.9 0.00 0.00 WMM-95 72
611 -0.7 0.2 0.00 0.00 WMM-95 73
711 -0.8 -1.3 0.00 0.00 WMM-95 74
811 1.3 -2.4 0.00 0.00 WMM-95 75
911 -0.3 -0.6 0.00 0.00 WMM-95 76
1011 2.2 -2.2 0.00 0.00 WMM-95 77
1111 4.2 1.3 0.00 0.00 WMM-95 78
012 -1.8 0.0 0.00 0.00 WMM-95 79
112 0.9 0.3 0.00 0.00 WMM-95 80
212 -0.1 1.4 0.00 0.00 WMM-95 81
312 -0.5 0.8 0.00 0.00 WMM-95 82
412 0.8 -3.0 0.00 0.00 WMM-95 83
512 0.2 0.7 0.00 0.00 WMM-95 84
612 0.5 0.5 0.00 0.00 WMM-95 85
712 0.4 -0.8 0.00 0.00 WMM-95 86
812 -0.4 0.6 0.00 0.00 WMM-95 87
912 0.3 0.1 0.00 0.00 WMM-95 88
1012 0.2 -1.3 0.00 0.00 WMM-95 89
1112 0.4 -0.4 0.00 0.00 WMM-95 90
1212 0.6 0.9 0.00 0.00 WMM-95 91
avdbtools-0.1/lib/igrf 100444 144 144 12342 6100014003 13137 0 ustar jcp users IGRF95 1995.00 10 8 0 1995.00 2000.00 -1.0 600.0 IGRF95 0
0 1-29682.0 0.0 17.60 0.00 IGRF95 1
1 1 -1789.0 5318.0 13.00 -18.30 IGRF95 2
0 2 -2197.0 0.0 -13.20 0.00 IGRF95 3
1 2 3074.0 -2356.0 3.70 -15.00 IGRF95 4
2 2 1685.0 -425.0 -0.80 -8.80 IGRF95 5
0 3 1329.0 0.0 1.50 0.00 IGRF95 6
1 3 -2268.0 -263.0 -6.40 4.10 IGRF95 7
2 3 1249.0 302.0 -0.20 2.20 IGRF95 8
3 3 769.0 -406.0 -8.10 -12.10 IGRF95 9
0 4 941.0 0.0 0.80 0.00 IGRF95 10
1 4 782.0 262.0 0.90 1.80 IGRF95 11
2 4 291.0 -232.0 -6.90 1.20 IGRF95 12
3 4 -421.0 98.0 0.50 2.70 IGRF95 13
4 4 116.0 -301.0 -4.60 -1.00 IGRF95 14
0 5 -210.0 0.0 0.80 0.00 IGRF95 15
1 5 352.0 44.0 0.10 0.20 IGRF95 16
2 5 237.0 157.0 -1.50 1.20 IGRF95 17
3 5 -122.0 -152.0 -2.00 0.30 IGRF95 18
4 5 -167.0 -64.0 -0.10 1.80 IGRF95 19
5 5 -26.0 99.0 2.30 0.90 IGRF95 20
0 6 66.0 0.0 0.50 0.00 IGRF95 21
1 6 64.0 -16.0 -0.40 0.30 IGRF95 22
2 6 65.0 77.0 0.60 -1.60 IGRF95 23
3 6 -172.0 67.0 1.90 -0.20 IGRF95 24
4 6 2.0 -57.0 -0.20 -0.90 IGRF95 25
5 6 17.0 4.0 -0.20 1.00 IGRF95 26
6 6 -94.0 28.0 0.00 2.20 IGRF95 27
0 7 78.0 0.0 -0.20 0.00 IGRF95 28
1 7 -67.0 -77.0 -0.80 0.80 IGRF95 29
2 7 1.0 -25.0 -0.60 0.20 IGRF95 30
3 7 29.0 3.0 0.60 0.60 IGRF95 31
4 7 4.0 22.0 1.20 -0.40 IGRF95 32
5 7 8.0 16.0 0.10 0.00 IGRF95 33
6 7 10.0 -23.0 0.20 -0.30 IGRF95 34
7 7 -2.0 -3.0 -0.60 0.00 IGRF95 35
0 8 24.0 0.0 0.30 0.00 IGRF95 36
1 8 4.0 12.0 -0.20 0.40 IGRF95 37
2 8 -1.0 -20.0 0.10 -0.20 IGRF95 38
3 8 -9.0 7.0 0.40 0.20 IGRF95 39
4 8 -14.0 -21.0 -1.10 0.70 IGRF95 40
5 8 4.0 12.0 0.30 0.00 IGRF95 41
6 8 5.0 10.0 0.20 -1.20 IGRF95 42
7 8 0.0 -17.0 -0.90 -0.70 IGRF95 43
8 8 -7.0 -10.0 -0.30 -0.60 IGRF95 44
0 9 4.0 0.0 0.00 0.00 IGRF95 45
1 9 9.0 -19.0 0.00 0.00 IGRF95 46
2 9 1.0 15.0 0.00 0.00 IGRF95 47
3 9 -12.0 11.0 0.00 0.00 IGRF95 48
4 9 9.0 -7.0 0.00 0.00 IGRF95 49
5 9 -4.0 -7.0 0.00 0.00 IGRF95 50
6 9 -2.0 9.0 0.00 0.00 IGRF95 51
7 9 7.0 7.0 0.00 0.00 IGRF95 52
8 9 0.0 -8.0 0.00 0.00 IGRF95 53
9 9 -6.0 1.0 0.00 0.00 IGRF95 54
010 -3.0 0.0 0.00 0.00 IGRF95 55
110 -4.0 2.0 0.00 0.00 IGRF95 56
210 2.0 1.0 0.00 0.00 IGRF95 57
310 -5.0 3.0 0.00 0.00 IGRF95 58
410 -2.0 6.0 0.00 0.00 IGRF95 59
510 4.0 -4.0 0.00 0.00 IGRF95 60
610 3.0 0.0 0.00 0.00 IGRF95 61
710 1.0 -2.0 0.00 0.00 IGRF95 62
810 3.0 3.0 0.00 0.00 IGRF95 63
910 3.0 -1.0 0.00 0.00 IGRF95 64
1010 0.0 -6.0 0.00 0.00 IGRF95 65
avdbtools-0.1/README 100444 144 144 3365 6523525132 12407 0 ustar jcp users ===============================================================================
avdbtools 0.1 README 1-May-1998
===============================================================================
$Id: README,v 1.1 1998/05/05 05:57:05 jcp Exp $
OVERVIEW
========
The avdbtools package (short for aviation database tools) is a
collection of software designed to assist in creating and maintaining
databases for aviation applications. As of this release, avdbtools
contains a single application that reads the databases distributed by
the (United States) National Flight Data Center, and converts them
into formats usable by various other aviation related applications.
DOCUMENTATION
=============
An user's guide is provided, the "master" copy is written in SGML
(Standard Generalized Markup Language) format. SGML documents are
translatable into other useful and popular formats such as LaTeX (and
dvi, postscript from there), as well as standard HTML. These derived
formats are provided, so you don't need any additional software.
CONFIGURATION and COMPILATION
============= === ===========
See the file "INSTALL" for details.
COPYRIGHT
=========
avdbtools is Copyright (C) 1998, John C. Peterson.
This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License, version 2. A copy is
included in this distribution in the file named "LICENSE".
This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License,
version 2, for more details.
Best Regards,
John C. Peterson FAA PP:ASEL,G
<mailto:jaypee@netcom.com>
avdbtools-0.1/doc/ 40755 144 144 0 6523770077 12204 5 ustar jcp users avdbtools-0.1/doc/faaconv.sgml 100644 144 144 6211 6523524675 14603 0 ustar jcp users <!doctype linuxdoc system>
<!--
$Id: faaconv.sgml,v 1.1 1998/05/05 05:54:54 jcp Exp $
-->
<manpage title="faaconv" sectnum="1">
<sect1>NAME
<p>
faaconv - convert NFDC database files to other formats
<sect1>SYNOPSIS
<p>
faaconv
[-f (igrf|wmm)]
[-h]
[-k]
[-m (db|fm)]
[-t (fplan|generic|icao|nav)]
inputfile
[outputfile]
<sect1>DESCRIPTION
<p>
<em/faaconv/ is an application that reads the comma delimited data files
distributed by the National Flight Data Center (NFDC), and converts them
into formats usable by other applications. The NFDC database files can be
obtained over the internet from their web site (see below). This release
of faaconv produces output files compatible with fplan, and ICAO Map.
<sect1>OPTIONS
<p>
<descrip>
<tag><tt/-f (igrf|wmm)/
<p>
Specify which coefficients to use in the Geomagnetic Field Model used to
estimate magnetic variation. When <tt/igrf/ is specified, the coefficients
from the International Geomagnetic Reference Field are used. When <tt/wmm/
is specified, the Department of Defense World Magnetic Model is used,
(default).
<tag><tt/-h/
<p>
Display a brief help message and exit.
<tag><tt/-k/
<p>
When enabled, this option provides a mechanism (one currently used
by many GPS manufacturers), for differentiating between an airport and
navigational aid with the same identifier. Any airport identifier that
consists of all alphabetic characters, and is exactly three characters
long, is prepended by the character "<tt/K/". This applies to <em/all/
such airports, regardless of the existence of a navigational aid with
the same identifier.
<tag><tt/-m (db|fm)/
<p>
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 <em/must be estimated/
using a model. For other entries, the NFDC database provides a value for
magnetic variation. When <tt/db/ is given as the argument to <tt/-m/,
the database value is used when it's available. When <tt/fm/ is given,
the magnetic variation value is always computed using the geomagnetic
field model (default).
<tag><tt/-t (fplan|generic|icao|nav)/
<p>
Specify the format of the output database. When <tt/fplan/, or <tt/nav/ is
specified, database files for Steve Tynor's fplan software are generated.
When <tt/icao/ is specified, the output database is compatible with Martin
Pauly's ICAO Map software. When <tt/generic/ is specified, a report like
output is produced (default).
</descrip>
<sect1>FILES
<p>
<descrip>
<tag>comma.apt
<p>
Airports database file.
<tag>comma.fix
<p>
Navigational fixes database file.
<tag>comma.ils
<p>
Instrument landing facilities database file.
<tag>comma.nav
<p>
Navigational aids database file.
<tag>comma.rwy
<p>
Runway descriptions database file.
</descrip>
<p>
All files are available from:
<tt>http://www.tgf.tc.faa.gov/nfdc/index.html</tt>
<sect1>BUGS
<p>
None that I know of. (I ain't saying there are none!)
<sect1>SEE ALSO
<p>
fplan(1), fplan(5)
<sect1>AUTHOR
<p>
John C. Peterson <jaypee@netcom.com>
</manpage>
avdbtools-0.1/doc/guide.sgml 100644 144 144 55756 6523770047 14321 0 ustar jcp users <!doctype linuxdoc system>
<!--
$Id: guide.sgml,v 1.1 1998/05/06 05:07:37 jcp Exp $
-->
<article>
<title>User's Guide for avdbtools
<author>John C. Peterson,
<tt><htmlurl url="mailto:jaypee@netcom.com"
name="<jaypee@netcom.com>"></tt>
<date>v0.1, 1 May 1998
<abstract>
The avdbtools package (short for aviation database tools) is a collection
of software designed to assist in creating and maintaining databases for
aviation applications. As of this release, avdbtools consists of a single
application that reads the databases distributed by the (United States)
National Flight Data Center, and converts them into formats usable by
other aviation related applications, as well as a small collection of
Bourne Shell scripts.
</abstract>
<sect>Introduction
<sect1>About avdbtools
<p>
This software was inspired by the discovery that the National
Flight Data Center is now on the World Wide Web, they can be found at
<tt><url url="http://www.tgf.tc.faa.gov/nfdc/index.html"</tt>. The web
site now distributes the database files that were once available only
on magnetic media.
<p>
I've been a long time user of Steve Tynor's flight planning software
called fplan which was posted to the comp.sources.misc USENET newsgroup.
The database files that were available for fplan were aging rapidly,
and the need for new database files was clear. The avdbtools package
also provides limited support for generating world files for ICAO Map.
<sect1>Copyright
<p>
The avdbtools software package is Copyright (C) 1998 John C. Peterson,
<tt><htmlurl url="mailto:jaypee@netcom.com"
name="<jaypee@netcom.com>"></tt>
<p>
This software package is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License,
version 2. A copy is included in this distribution in the file
named "LICENSE".
<p>
This software package is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License,
version 2, for more details.
<sect1>Changes
<p>
Release 0.1 is the first public release of avdbtools, so there are no
changes to report. The code should be considered reasonably stable, I
have done a fair amount of testing myself. (This should not be confused
with the claim that there are no bugs!) The low version number is mostly
indicative of the absence of desired features. The support for fplan
databases is relatively complete, while support for ICAO Map still
needs more work before it is complete.
<sect>Installation
<sect1>Obtaining the Distribution
<p>
I don't have enough disk space at my current ISP to host the distribution
myself, so I am using some of the popular archive sites for Linux
software. I will be distributing avdbtools in compressed tar format
as well as Red Hat Package Manager (RPM) format. You should be able to
get the distribution by anonymous ftp from the sites listed below. If the
files are not there, check the respective <tt>Incoming</tt> directories.
<itemize>
<item>Compressed Tar: <tt><url url="ftp://sunsite.unc.edu/pub/Linux/apps/aviation/"></tt>
<item>Red Hat Package Manager (RPM):
<itemize>
<item>Source: <tt><url url="ftp://ftp.redhat.com/pub/contrib/SRPMS"></tt>
<item>Binary: <tt><url url="ftp://ftp.redhat.com/pub/contrib/i386"></tt>
</itemize>
</itemize>
<sect1>Requirements
<p>
This software was developed and tested under Red Hat Linux, release 4.2.
The requirements are relatively modest, you should be able to build and
use this software under most any UNIX like environment with an Ansi C
compiler (such as the Free Software Foundation's gcc compiler), a make
utility, and the Bourne shell.
<sect1>Configuration and Compilation
<p>
To build faaconv, follow these easy steps;
<enum>
<item> Edit the <tt>Makefile</tt> and change the macros that are related
to specification of the environment, assigning values appropriate to your
situation. The only macros you should need to edit are; <tt>CC</tt>
to specify your C compiler, and <tt>BINDIR</tt>, <tt>DOCDIR</tt>,
<tt>LIBDIR</tt>, <tt>MANDIR</tt> to specify the directories where the
executable, documentation, model coefficients, and man page, respectively,
are to be installed.
<item> Run <tt/"make"/ to build the executable.
<item> Run <tt/"make install"/ to install the executable in
<tt>BINDIR</tt>, and the model coefficients in <tt>LIBDIR</tt>.
<item> Run <tt/"make install-man"/ to install the man page in
<tt>MANDIR</tt> and the user's guide in <tt>DOCDIR</tt>.
</enum>
<p>
This user's guide and the man page can be found in the <tt>doc</tt>
subdirectory of the source distribution tree. Both are written
in SGML (Standard Generalized Markup Language) format. The SGML format
documents are translatable into other useful and popular formats such
as LaTeX (and dvi, postscript from there), as well as standard HTML.
The converted formats are up to date with respect to the SGML versions
when distributed. If you make changes to the master SGML format documents,
you will need the Linuxdoc-SGML formatting system to update the other
formats. It is available from
<tt><url url="ftp://ftp.cc.gatech.edu/pub/people/gregh/linuxdoc-sgml/"></tt>
<sect>The faaconv Application
<sect1>About faaconv
<p>
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.
<sect1>Obtaining the NFDC Databases
<p>
As of this writing, the
<tt><htmlurl url="http://www.tgf.tc.faa.gov/nfdc/index.html"
name="National Flight Data Center"></tt> 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
<itemize>
<item> <tt><url url="ftp://ftp.tc.faa.gov/nfdc/apt.tar.gz"></tt>
<item> <tt><url url="ftp://ftp.tc.faa.gov/nfdc/fix.tar.gz"></tt>
<item> <tt><url url="ftp://ftp.tc.faa.gov/nfdc/ils.tar.gz"></tt>
<item> <tt><url url="ftp://ftp.tc.faa.gov/nfdc/nav.tar.gz"></tt>
<item> <tt><url url="ftp://ftp.tc.faa.gov/nfdc/rwy.tar.gz"></tt>
</itemize>
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 <tt><url url="ftp://ftp.ncftp.com/ncftp/"></tt>,
or wget with appropriate command line flags, available from
<tt><url url="ftp://prep.ai.mit.edu/pub/gnu/"></tt>). 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.
<p>
Please note that the home page of the National Flight Data Center web site
clearly states that the data files are <em>not to be used for navigational
purposes</em>. 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.
<p>
A fundamental limitation of this data that you should be aware of; there
is <em/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 <em/think/ about using this data for a precision
approach.
<sect1>Running faaconv
<p>
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.
<descrip>
<tag/<tt>-k</tt>/
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 "<tt/K/". This applies to <em/all/
such airports, regardless of the existence of a navigational aid with
the same identifier. So for example, <tt/HMT/ becomes <tt/KHMT/, while
identifiers like <tt/L78/ and <tt/CL35/ are not translated.
<tag/<tt>-m (db|fm)</tt>/
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 <em/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 <tt/db/ as the argument to this option. To always use
the value computed by the model, use <tt/fm/. The later is the default
and recommended value (the values in the NFDC database appear to be
somewhat out of date).
</descrip>
<sect1>The Geomagnetic Field Module
<p>
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.
<sect2>The Physical Model
<p>
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
<tt><url url="http://www.ngdc.noaa.gov/seg/potfld/geomag.html"></tt>
<sect2>Limitations of the Physical Models
<p>
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 <em/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.
<p>
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.
<sect2>Software Implementation
<p>
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 <tt>field_model.c</tt>. It was designed to use either of the
IGRF or WMM model coefficient data files <em/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
<itemize>
<item><tt><url url="ftp://ftp.ngdc.noaa.gov/Solid_Earth/Mainfld_Mag/Models/igrf95"></tt>
<item><tt><url url="ftp://ftp.ngdc.noaa.gov/Solid_Earth/Mainfld_Mag/Models/wmm95"></tt>
</itemize>
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 <em>sources other than NGDC</em>,
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.
<sect2>Software Programming Interface
<p>
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
<tt>field_model.c</tt> module contains three functions;
<descrip>
<tag/<tt>extern int init_field_model(char *filename);</tt>/
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.
<tag/<tt>extern int field_model(field_model_t *value);</tt>/
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 <tt>field_model_t</tt> which is described in
the module header file <tt>field_model.h</tt>. 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.
<tag/<tt>extern char *strerror_field_model(void);</tt>/
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.
</descrip>
<sect2>Accuracy of Software Implementation
<p>
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 <tt>GEOMAG.FOR</tt>, which can be obtained from the directory <tt><url
url="ftp://ftp.ngdc.noaa.gov/Solid_Earth/Mainfld_Mag/DoD_Model/Fortran_Software/"></tt>.
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).
<tscreen><verb>
+-----------------------+------------------+------------------+
| 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 |
+-----------------------+------------------+------------------+
</verb></tscreen>
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.
<sect1>Creating Output for fplan
<p>
The fplan software expects two database files; <tt/airports.nav/
and <tt/vors.nav/. The first file contains entries for airports,
(gliderports, heliports, and ballonports too), and is generated by running
faaconv with <tt/comma.apt/ as input. The second file contains entries
for navigational aids and is generated from the combined outputs from
faaconv with <tt/comma.fix/, <tt/comma.nav/ as inputs.
<p>
Unfortunately, the <tt/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, <tt/LAX/ has
multiple ILS systems, each with a unique identifier). The <tt/comma.rwy/
file is not used either, it simply doesn't contain any information that
fplan reads or uses.
<p>
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 <tt/mknavdb/.
<sect1>Creating Output for ICAO Map
<p>
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 <tt/comma.apt/, <tt/comma.fix/, <tt/comma.ils/,
<tt/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 <tt/icao-1.0.patch/ contains
a patch for the parser.
<sect>Additional Information
<sect1>Other Software
<sect2>fplan
<p>
The fplan flight planning software package was written by Steve Tynor. It
was designed for constructing VFR cross country flight plans. The last
public release by Steve was version 1.3 and was posted to volume 30 of
the comp.sources.misc USENET newsgroup. As a product of my efforts with
avdbtools I made some improvements and fixes to fplan. When I approached
Steve with the changes, he indicated he was too busy with other projects
and offered me the option of taking over as maintainer, which I accepted.
The next release of fplan should be available soon. It will include
support for the graphics previewer option that is based on the XView
Toolkit for X11 (release 1.3 required Suntools, making that option Sun
specific). The XView Toolkit, developed by Sun Microsystems, is available
in source code form, and has been ported to a wide variety of UNIX/X11
platforms including HP-UX, Linux, SVR4, and Solaris of course. When
everything is ready, I plan to distribute fplan from the directory
<tt><url url="ftp://sunsite.unc.edu/pub/Linux/apps/aviation/"></tt>.
<sect2>ICAO Map
<p>
ICAO Map is a program for generating and displaying maps for aviation
purposes. It was written by Martin Pauly, and runs under UNIX systems
with X11/Motif. It's input is a so called "world file", that contains
descriptions of objects such as airports, navigational aids, roads,
towns, etc. It can use either Lambert or Mercator projection to generate
a map from this world file, either on your screen or as Postscript output.
It also includes interactive features, such as scrolling, rubber band
lines to measure distances and tracks, etc. Additional features are
available for both motorized and soaring (glider) flights. For more
information, visit the ICAO Map home page on the World Wide Web at
<tt><url url="http://www.oih.rwth-aachen.de/~pauly/icao.html"></tt>.
<sect1>Future Plans
<p>
My immediate goal is to complete the support for ICAO Map, as well
as for the generic format output. Once this is complete, I have some
ideas for new features. A simple GUI interface to the Geomagnetic Field
Model, perhaps based on the Tk, Xforms or similar widget sets might be
useful. Another idea would be to generate database files for updating
GPS receivers. I find it quite annoying to be shelling out lots of
hard earned cash for something we basically paid for already in the
form of taxes. This isn't a trivial project however, since all of the
manufacturers zealously guard much of the necessary information (correct
me if I'm wrong). Another idea would be to create an interface to a high
quality database engine such as PostgreSQL. This idea is less interesting
in view of the fact that this sort of thing is already available over
the net, see <tt><url url="http://www.airnav.com/"></tt>.
<sect1>Contacting the Author
<p>
If you find a bug in this software (especially if you also have a
patch for it) you can contact me by electronic mail at <tt><htmlurl
url="mailto:jaypee@netcom.com" name="<jaypee@netcom.com>"></tt>.
Questions, comments, or suggestions are welcome. Please note that I
sometimes go through periods of time when I can't check my mail
regularly, so don't be alarmed if you don't get an immediate reply.
</article>
avdbtools-0.1/doc/Makefile 100644 144 144 711 6505654702 13714 0 ustar jcp users
all: faaconv.1 guide.html guide.ps guide.txt
guide.html: guide.sgml
sgml2html guide.sgml
guide.ps: guide.sgml
sgml2latex guide.sgml
(export TEXINPUTS=${TEXINPUTS}:/usr/lib/linuxdoc-sgml ;latex guide.tex)
dvips -o guide.ps guide.dvi
guide.txt: guide.sgml
sgml2txt guide.sgml
faaconv.1: faaconv.sgml
sgml2txt -man faaconv
mv faaconv.man faaconv.1
clean:
rm -f *.aux *.dvi *.log
veryclean:
rm -f *.1 *.aux *.dvi *.html *.log *.ps *.tex *.txt
avdbtools-0.1/doc/guide.html 100644 144 144 4130 6523770060 14252 0 ustar jcp users
<HTML>
<HEAD>
<TITLE>User's Guide for avdbtools</TITLE>
</HEAD>
<BODY>
Previous
<A HREF="guide-1.html">Next</A>
Table of Contents
<HR>
<H1>User's Guide for avdbtools</H1>
<H2>John C. Peterson,
<CODE>
<A HREF="mailto:jaypee@netcom.com"><jaypee@netcom.com></A></CODE></H2>v0.1, 1 May 1998
<P><HR><EM>The avdbtools package (short for aviation database tools) is a collection
of software designed to assist in creating and maintaining databases for
aviation applications. As of this release, avdbtools consists of a single
application that reads the databases distributed by the (United States)
National Flight Data Center, and converts them into formats usable by
other aviation related applications, as well as a small collection of
Bourne Shell scripts.</EM><HR></P>
<P>
<H2><A NAME="toc1">1.</A> <A HREF="guide-1.html">Introduction</A></H2>
<UL>
<LI><A HREF="guide-1.html#ss1.1">1.1 About avdbtools</A>
<LI><A HREF="guide-1.html#ss1.2">1.2 Copyright</A>
<LI><A HREF="guide-1.html#ss1.3">1.3 Changes</A>
</UL>
<P>
<H2><A NAME="toc2">2.</A> <A HREF="guide-2.html">Installation</A></H2>
<UL>
<LI><A HREF="guide-2.html#ss2.1">2.1 Obtaining the Distribution</A>
<LI><A HREF="guide-2.html#ss2.2">2.2 Requirements</A>
<LI><A HREF="guide-2.html#ss2.3">2.3 Configuration and Compilation</A>
</UL>
<P>
<H2><A NAME="toc3">3.</A> <A HREF="guide-3.html">The faaconv Application</A></H2>
<UL>
<LI><A HREF="guide-3.html#ss3.1">3.1 About faaconv</A>
<LI><A HREF="guide-3.html#ss3.2">3.2 Obtaining the NFDC Databases</A>
<LI><A HREF="guide-3.html#ss3.3">3.3 Running faaconv</A>
<LI><A HREF="guide-3.html#ss3.4">3.4 The Geomagnetic Field Module</A>
<LI><A HREF="guide-3.html#ss3.5">3.5 Creating Output for fplan</A>
<LI><A HREF="guide-3.html#ss3.6">3.6 Creating Output for ICAO Map</A>
</UL>
<P>
<H2><A NAME="toc4">4.</A> <A HREF="guide-4.html">Additional Information</A></H2>
<UL>
<LI><A HREF="guide-4.html#ss4.1">4.1 Other Software</A>
<LI><A HREF="guide-4.html#ss4.2">4.2 Future Plans</A>
<LI><A HREF="guide-4.html#ss4.3">4.3 Contacting the Author</A>
</UL>
<HR>
Previous
<A HREF="guide-1.html">Next</A>
Table of Contents
</BODY>
</HTML>
avdbtools-0.1/doc/faaconv.1 100644 144 144 6763 6523770056 14011 0 ustar jcp users .if n .ds Q \&"
.if t .ds Q ``
.if n .ds U \&"
.if t .ds U ''
.TH "faaconv" 1
.tr \&
.nr bi 0
.nr ll 0
.nr el 0
.de DS
..
.de DE
..
.de Pp
.ie \\n(ll>0 \{\
.ie \\n(bi=1 \{\
.nr bi 0
.if \\n(t\\n(ll=0 \{.IP \\(bu\}
.if \\n(t\\n(ll=1 \{.IP \\n+(e\\n(el.\}
.\}
.el .sp
.\}
.el \{\
.ie \\nh=1 \{\
.LP
.nr h 0
.\}
.el .PP
.\}
..
.SH NAME
.Pp
faaconv - convert NFDC database files to other formats
.Pp
.SH SYNOPSIS
.Pp
faaconv
[-f (igrf|wmm)]
[-h]
[-k]
[-m (db|fm)]
[-t (fplan|generic|icao|nav)]
inputfile
[outputfile]
.Pp
.SH DESCRIPTION
.Pp
\fIfaaconv\fP is an application that reads the comma delimited data files
distributed by the National Flight Data Center (NFDC), and converts them
into formats usable by other applications. The NFDC database files can be
obtained over the internet from their web site (see below). This release
of faaconv produces output files compatible with fplan, and ICAO Map.
.Pp
.SH OPTIONS
.Pp
.nr ll +1
.nr t\n(ll 2
.if \n(ll>1 .RS
.IP "\f(CR-f (igrf|wmm)\fP"
.nr bi 1
.Pp
Specify which coefficients to use in the Geomagnetic Field Model used to
estimate magnetic variation. When \f(CRigrf\fP is specified, the coefficients
from the International Geomagnetic Reference Field are used. When \f(CRwmm\fP
is specified, the Department of Defense World Magnetic Model is used,
(default).
.IP "\f(CR-h\fP"
.nr bi 1
.Pp
Display a brief help message and exit.
.IP "\f(CR-k\fP"
.nr bi 1
.Pp
When enabled, this option provides a mechanism (one currently used
by many GPS manufacturers), for differentiating between an airport and
navigational aid with the same identifier. Any airport identifier that
consists of all alphabetic characters, and is exactly three characters
long, is prepended by the character "\f(CRK\fP". This applies to \fIall\fP
such airports, regardless of the existence of a navigational aid with
the same identifier.
.IP "\f(CR-m (db|fm)\fP"
.nr bi 1
.Pp
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 \fImust be estimated\fP
using a model. For other entries, the NFDC database provides a value for
magnetic variation. When \f(CRdb\fP is given as the argument to \f(CR-m\fP,
the database value is used when it's available. When \f(CRfm\fP is given,
the magnetic variation value is always computed using the geomagnetic
field model (default).
.IP "\f(CR-t (fplan|generic|icao|nav)\fP"
.nr bi 1
.Pp
Specify the format of the output database. When \f(CRfplan\fP, or \f(CRnav\fP is
specified, database files for Steve Tynor's fplan software are generated.
When \f(CRicao\fP is specified, the output database is compatible with Martin
Pauly's ICAO Map software. When \f(CRgeneric\fP is specified, a report like
output is produced (default).
.if \n(ll>1 .RE
.nr ll -1
.Pp
.SH FILES
.Pp
.nr ll +1
.nr t\n(ll 2
.if \n(ll>1 .RS
.IP "comma.apt"
.nr bi 1
.Pp
Airports database file.
.IP "comma.fix"
.nr bi 1
.Pp
Navigational fixes database file.
.IP "comma.ils"
.nr bi 1
.Pp
Instrument landing facilities database file.
.IP "comma.nav"
.nr bi 1
.Pp
Navigational aids database file.
.IP "comma.rwy"
.nr bi 1
.Pp
Runway descriptions database file.
.if \n(ll>1 .RE
.nr ll -1
.Pp
All files are available from:
\f(CRhttp://www.tgf.tc.faa.gov/nfdc/index.html\fP
.Pp
.SH BUGS
.Pp
None that I know of. (I ain't saying there are none!)
.Pp
.SH SEE ALSO
.Pp
fplan(1), fplan(5)
.Pp
.SH AUTHOR
.Pp
John C. Peterson <jaypee@netcom.com>
.Pp
avdbtools-0.1/doc/guide-1.html 100644 144 144 4360 6523770060 14415 0 ustar jcp users <HTML>
<HEAD>
<TITLE>User's Guide for avdbtools: Introduction</TITLE>
</HEAD>
<BODY>
Previous
<A HREF="guide-2.html">Next</A>
<A HREF="guide.html#toc1">Table of Contents</A>
<HR>
<H2><A NAME="s1">1. Introduction</A></H2>
<H2><A NAME="ss1.1">1.1 About avdbtools</A></H2>
<P>This software was inspired by the discovery that the National
Flight Data Center is now on the World Wide Web, they can be found at
<CODE>
<A HREF="http://www.tgf.tc.faa.gov/nfdc/index.html">http://www.tgf.tc.faa.gov/nfdc/index.html</A></CODE>. The web
site now distributes the database files that were once available only
on magnetic media.</P>
<P>I've been a long time user of Steve Tynor's flight planning software
called fplan which was posted to the comp.sources.misc USENET newsgroup.
The database files that were available for fplan were aging rapidly,
and the need for new database files was clear. The avdbtools package
also provides limited support for generating world files for ICAO Map.</P>
<H2><A NAME="ss1.2">1.2 Copyright</A></H2>
<P>The avdbtools software package is Copyright (C) 1998 John C. Peterson,
<CODE>
<A HREF="mailto:jaypee@netcom.com"><jaypee@netcom.com></A></CODE></P>
<P>This software package is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License,
version 2. A copy is included in this distribution in the file
named "LICENSE".</P>
<P>This software package is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License,
version 2, for more details.</P>
<H2><A NAME="ss1.3">1.3 Changes</A></H2>
<P>Release 0.1 is the first public release of avdbtools, so there are no
changes to report. The code should be considered reasonably stable, I
have done a fair amount of testing myself. (This should not be confused
with the claim that there are no bugs!) The low version number is mostly
indicative of the absence of desired features. The support for fplan
databases is relatively complete, while support for ICAO Map still
needs more work before it is complete.</P>
<HR>
Previous
<A HREF="guide-2.html">Next</A>
<A HREF="guide.html#toc1">Table of Contents</A>
</BODY>
</HTML>
avdbtools-0.1/doc/guide-2.html 100644 144 144 6504 6523770060 14420 0 ustar jcp users <HTML>
<HEAD>
<TITLE>User's Guide for avdbtools: Installation</TITLE>
</HEAD>
<BODY>
<A HREF="guide-1.html">Previous</A>
<A HREF="guide-3.html">Next</A>
<A HREF="guide.html#toc2">Table of Contents</A>
<HR>
<H2><A NAME="s2">2. Installation</A></H2>
<H2><A NAME="ss2.1">2.1 Obtaining the Distribution</A></H2>
<P>I don't have enough disk space at my current ISP to host the distribution
myself, so I am using some of the popular archive sites for Linux
software. I will be distributing avdbtools in compressed tar format
as well as Red Hat Package Manager (RPM) format. You should be able to
get the distribution by anonymous ftp from the sites listed below. If the
files are not there, check the respective <CODE>Incoming</CODE> directories.
<UL>
<LI>Compressed Tar: <CODE>
<A HREF="ftp://sunsite.unc.edu/pub/Linux/apps/aviation/">ftp://sunsite.unc.edu/pub/Linux/apps/aviation/</A></CODE></LI>
<LI>Red Hat Package Manager (RPM):
<UL>
<LI>Source: <CODE>
<A HREF="ftp://ftp.redhat.com/pub/contrib/SRPMS">ftp://ftp.redhat.com/pub/contrib/SRPMS</A></CODE></LI>
<LI>Binary: <CODE>
<A HREF="ftp://ftp.redhat.com/pub/contrib/i386">ftp://ftp.redhat.com/pub/contrib/i386</A></CODE></LI>
</UL>
</LI>
</UL>
</P>
<H2><A NAME="ss2.2">2.2 Requirements</A></H2>
<P>This software was developed and tested under Red Hat Linux, release 4.2.
The requirements are relatively modest, you should be able to build and
use this software under most any UNIX like environment with an Ansi C
compiler (such as the Free Software Foundation's gcc compiler), a make
utility, and the Bourne shell.</P>
<H2><A NAME="ss2.3">2.3 Configuration and Compilation</A></H2>
<P>To build faaconv, follow these easy steps;
<OL>
<LI> Edit the <CODE>Makefile</CODE> and change the macros that are related
to specification of the environment, assigning values appropriate to your
situation. The only macros you should need to edit are; <CODE>CC</CODE>
to specify your C compiler, and <CODE>BINDIR</CODE>, <CODE>DOCDIR</CODE>,
<CODE>LIBDIR</CODE>, <CODE>MANDIR</CODE> to specify the directories where the
executable, documentation, model coefficients, and man page, respectively,
are to be installed.</LI>
<LI> Run <CODE>"make"</CODE> to build the executable.</LI>
<LI> Run <CODE>"make install"</CODE> to install the executable in
<CODE>BINDIR</CODE>, and the model coefficients in <CODE>LIBDIR</CODE>.</LI>
<LI> Run <CODE>"make install-man"</CODE> to install the man page in
<CODE>MANDIR</CODE> and the user's guide in <CODE>DOCDIR</CODE>.</LI>
</OL>
</P>
<P>This user's guide and the man page can be found in the <CODE>doc</CODE>
subdirectory of the source distribution tree. Both are written
in SGML (Standard Generalized Markup Language) format. The SGML format
documents are translatable into other useful and popular formats such
as LaTeX (and dvi, postscript from there), as well as standard HTML.
The converted formats are up to date with respect to the SGML versions
when distributed. If you make changes to the master SGML format documents,
you will need the Linuxdoc-SGML formatting system to update the other
formats. It is available from
<CODE>
<A HREF="ftp://ftp.cc.gatech.edu/pub/people/gregh/linuxdoc-sgml/">ftp://ftp.cc.gatech.edu/pub/people/gregh/linuxdoc-sgml/</A></CODE></P>
<HR>
<A HREF="guide-1.html">Previous</A>
<A HREF="guide-3.html">Next</A>
<A HREF="guide.html#toc2">Table of Contents</A>
</BODY>
</HTML>
avdbtools-0.1/doc/guide-3.html 100644 144 144 40016 6523770060 14435 0 ustar jcp users <HTML>
<HEAD>
<TITLE>User's Guide for avdbtools: The faaconv Application</TITLE>
</HEAD>
<BODY>
<A HREF="guide-2.html">Previous</A>
<A HREF="guide-4.html">Next</A>
<A HREF="guide.html#toc3">Table of Contents</A>
<HR>
<H2><A NAME="s3">3. The faaconv Application</A></H2>
<H2><A NAME="ss3.1">3.1 About faaconv</A></H2>
<P>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.</P>
<H2><A NAME="ss3.2">3.2 Obtaining the NFDC Databases</A></H2>
<P>As of this writing, the
<CODE>
<A HREF="http://www.tgf.tc.faa.gov/nfdc/index.html">National Flight Data Center</A></CODE> 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
<UL>
<LI> <CODE>
<A HREF="ftp://ftp.tc.faa.gov/nfdc/apt.tar.gz">ftp://ftp.tc.faa.gov/nfdc/apt.tar.gz</A></CODE></LI>
<LI> <CODE>
<A HREF="ftp://ftp.tc.faa.gov/nfdc/fix.tar.gz">ftp://ftp.tc.faa.gov/nfdc/fix.tar.gz</A></CODE></LI>
<LI> <CODE>
<A HREF="ftp://ftp.tc.faa.gov/nfdc/ils.tar.gz">ftp://ftp.tc.faa.gov/nfdc/ils.tar.gz</A></CODE></LI>
<LI> <CODE>
<A HREF="ftp://ftp.tc.faa.gov/nfdc/nav.tar.gz">ftp://ftp.tc.faa.gov/nfdc/nav.tar.gz</A></CODE></LI>
<LI> <CODE>
<A HREF="ftp://ftp.tc.faa.gov/nfdc/rwy.tar.gz">ftp://ftp.tc.faa.gov/nfdc/rwy.tar.gz</A></CODE></LI>
</UL>
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 <CODE>
<A HREF="ftp://ftp.ncftp.com/ncftp/">ftp://ftp.ncftp.com/ncftp/</A></CODE>,
or wget with appropriate command line flags, available from
<CODE>
<A HREF="ftp://prep.ai.mit.edu/pub/gnu/">ftp://prep.ai.mit.edu/pub/gnu/</A></CODE>). 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.</P>
<P>Please note that the home page of the National Flight Data Center web site
clearly states that the data files are <EM>not to be used for navigational
purposes</EM>. 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.</P>
<P>A fundamental limitation of this data that you should be aware of; there
is <EM>no</EM> 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 <EM>think</EM> about using this data for a precision
approach.</P>
<H2><A NAME="ss3.3">3.3 Running faaconv</A></H2>
<P>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.</P>
<P>
<DL>
<DT><B><CODE>-k</CODE></B><DD><P>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 "<CODE>K</CODE>". This applies to <EM>all</EM>
such airports, regardless of the existence of a navigational aid with
the same identifier. So for example, <CODE>HMT</CODE> becomes <CODE>KHMT</CODE>, while
identifiers like <CODE>L78</CODE> and <CODE>CL35</CODE> are not translated.</P>
<DT><B><CODE>-m (db|fm)</CODE></B><DD><P>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 <EM>must be estimated</EM> 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 <CODE>db</CODE> as the argument to this option. To always use
the value computed by the model, use <CODE>fm</CODE>. The later is the default
and recommended value (the values in the NFDC database appear to be
somewhat out of date).</P>
</DL>
</P>
<H2><A NAME="ss3.4">3.4 The Geomagnetic Field Module</A></H2>
<P>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.</P>
<H3>The Physical Model</H3>
<P>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
<CODE>
<A HREF="http://www.ngdc.noaa.gov/seg/potfld/geomag.html">http://www.ngdc.noaa.gov/seg/potfld/geomag.html</A></CODE></P>
<H3>Limitations of the Physical Models</H3>
<P>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 <EM>not</EM> 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.</P>
<P>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.</P>
<H3>Software Implementation</H3>
<P>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 <CODE>field_model.c</CODE>. It was designed to use either of the
IGRF or WMM model coefficient data files <EM>exactly</EM> 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
<UL>
<LI><CODE>
<A HREF="ftp://ftp.ngdc.noaa.gov/Solid_Earth/Mainfld_Mag/Models/igrf95">ftp://ftp.ngdc.noaa.gov/Solid_Earth/Mainfld_Mag/Models/igrf95</A></CODE></LI>
<LI><CODE>
<A HREF="ftp://ftp.ngdc.noaa.gov/Solid_Earth/Mainfld_Mag/Models/wmm95">ftp://ftp.ngdc.noaa.gov/Solid_Earth/Mainfld_Mag/Models/wmm95</A></CODE></LI>
</UL>
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 <EM>sources other than NGDC</EM>,
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.</P>
<H3>Software Programming Interface</H3>
<P>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
<CODE>field_model.c</CODE> module contains three functions;
<DL>
<DT><B><CODE>extern int init_field_model(char *filename);</CODE></B><DD><P>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.</P>
<DT><B><CODE>extern int field_model(field_model_t *value);</CODE></B><DD><P>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 <CODE>field_model_t</CODE> which is described in
the module header file <CODE>field_model.h</CODE>. 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.</P>
<DT><B><CODE>extern char *strerror_field_model(void);</CODE></B><DD><P>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.</P>
</DL>
</P>
<H3>Accuracy of Software Implementation</H3>
<P>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 <CODE>GEOMAG.FOR</CODE>, which can be obtained from the directory <CODE>
<A HREF="ftp://ftp.ngdc.noaa.gov/Solid_Earth/Mainfld_Mag/DoD_Model/Fortran_Software/">ftp://ftp.ngdc.noaa.gov/Solid_Earth/Mainfld_Mag/DoD_Model/Fortran_Software/</A></CODE>.
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).</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
+-----------------------+------------------+------------------+
| 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 |
+-----------------------+------------------+------------------+
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>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.</P>
<H2><A NAME="ss3.5">3.5 Creating Output for fplan</A></H2>
<P>The fplan software expects two database files; <CODE>airports.nav</CODE>
and <CODE>vors.nav</CODE>. The first file contains entries for airports,
(gliderports, heliports, and ballonports too), and is generated by running
faaconv with <CODE>comma.apt</CODE> as input. The second file contains entries
for navigational aids and is generated from the combined outputs from
faaconv with <CODE>comma.fix</CODE>, <CODE>comma.nav</CODE> as inputs.</P>
<P>Unfortunately, the <CODE>comma.ils</CODE> 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, <CODE>LAX</CODE> has
multiple ILS systems, each with a unique identifier). The <CODE>comma.rwy</CODE>
file is not used either, it simply doesn't contain any information that
fplan reads or uses.</P>
<P>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 <CODE>mknavdb</CODE>.</P>
<H2><A NAME="ss3.6">3.6 Creating Output for ICAO Map</A></H2>
<P>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 <CODE>comma.apt</CODE>, <CODE>comma.fix</CODE>, <CODE>comma.ils</CODE>,
<CODE>comma.nav</CODE> 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 <CODE>icao-1.0.patch</CODE> contains
a patch for the parser.</P>
<HR>
<A HREF="guide-2.html">Previous</A>
<A HREF="guide-4.html">Next</A>
<A HREF="guide.html#toc3">Table of Contents</A>
</BODY>
</HTML>
avdbtools-0.1/doc/guide-4.html 100644 144 144 7421 6523770060 14421 0 ustar jcp users <HTML>
<HEAD>
<TITLE>User's Guide for avdbtools: Additional Information</TITLE>
</HEAD>
<BODY>
<A HREF="guide-3.html">Previous</A>
Next
<A HREF="guide.html#toc4">Table of Contents</A>
<HR>
<H2><A NAME="s4">4. Additional Information</A></H2>
<H2><A NAME="ss4.1">4.1 Other Software</A></H2>
<H3>fplan</H3>
<P>The fplan flight planning software package was written by Steve Tynor. It
was designed for constructing VFR cross country flight plans. The last
public release by Steve was version 1.3 and was posted to volume 30 of
the comp.sources.misc USENET newsgroup. As a product of my efforts with
avdbtools I made some improvements and fixes to fplan. When I approached
Steve with the changes, he indicated he was too busy with other projects
and offered me the option of taking over as maintainer, which I accepted.</P>
<P>The next release of fplan should be available soon. It will include
support for the graphics previewer option that is based on the XView
Toolkit for X11 (release 1.3 required Suntools, making that option Sun
specific). The XView Toolkit, developed by Sun Microsystems, is available
in source code form, and has been ported to a wide variety of UNIX/X11
platforms including HP-UX, Linux, SVR4, and Solaris of course. When
everything is ready, I plan to distribute fplan from the directory
<CODE>
<A HREF="ftp://sunsite.unc.edu/pub/Linux/apps/aviation/">ftp://sunsite.unc.edu/pub/Linux/apps/aviation/</A></CODE>.</P>
<H3>ICAO Map</H3>
<P>ICAO Map is a program for generating and displaying maps for aviation
purposes. It was written by Martin Pauly, and runs under UNIX systems
with X11/Motif. It's input is a so called "world file", that contains
descriptions of objects such as airports, navigational aids, roads,
towns, etc. It can use either Lambert or Mercator projection to generate
a map from this world file, either on your screen or as Postscript output.
It also includes interactive features, such as scrolling, rubber band
lines to measure distances and tracks, etc. Additional features are
available for both motorized and soaring (glider) flights. For more
information, visit the ICAO Map home page on the World Wide Web at
<CODE>
<A HREF="http://www.oih.rwth-aachen.de/~pauly/icao.html">http://www.oih.rwth-aachen.de/~pauly/icao.html</A></CODE>.</P>
<H2><A NAME="ss4.2">4.2 Future Plans</A></H2>
<P>My immediate goal is to complete the support for ICAO Map, as well
as for the generic format output. Once this is complete, I have some
ideas for new features. A simple GUI interface to the Geomagnetic Field
Model, perhaps based on the Tk, Xforms or similar widget sets might be
useful. Another idea would be to generate database files for updating
GPS receivers. I find it quite annoying to be shelling out lots of
hard earned cash for something we basically paid for already in the
form of taxes. This isn't a trivial project however, since all of the
manufacturers zealously guard much of the necessary information (correct
me if I'm wrong). Another idea would be to create an interface to a high
quality database engine such as PostgreSQL. This idea is less interesting
in view of the fact that this sort of thing is already available over
the net, see <CODE>
<A HREF="http://www.airnav.com/">http://www.airnav.com/</A></CODE>.</P>
<H2><A NAME="ss4.3">4.3 Contacting the Author</A></H2>
<P>If you find a bug in this software (especially if you also have a
patch for it) you can contact me by electronic mail at <CODE>
<A HREF="mailto:jaypee@netcom.com"><jaypee@netcom.com></A></CODE>.
Questions, comments, or suggestions are welcome. Please note that I
sometimes go through periods of time when I can't check my mail
regularly, so don't be alarmed if you don't get an immediate reply.</P>
<HR>
<A HREF="guide-3.html">Previous</A>
Next
<A HREF="guide.html#toc4">Table of Contents</A>
</BODY>
</HTML>
avdbtools-0.1/doc/guide.tex 100644 144 144 55604 6523770061 14143 0 ustar jcp users \documentstyle[linuxdoc-sgml,isolatin,qwertz,null]{article}
\input{epsf.tex}
\title{User's Guide for avdbtools}
\author{John C. Peterson,
{\tt {\(<\)}jaypee@netcom.com{\(>\)}}}
\date{v0.1, 1 May 1998}
\abstract{The avdbtools package (short for aviation database tools) is a collection
of software designed to assist in creating and maintaining databases for
aviation applications. As of this release, avdbtools consists of a single
application that reads the databases distributed by the (United States)
National Flight Data Center, and converts them into formats usable by
other aviation related applications, as well as a small collection of
Bourne Shell scripts.}
\begin{document}
\maketitle
\section{Introduction}
\subsection{About avdbtools}
This software was inspired by the discovery that the National
Flight Data Center is now on the World Wide Web, they can be found at
{\tt \url{http://www.tgf.tc.faa.gov/nfdc/index.html}{}}. The web
site now distributes the database files that were once available only
on magnetic media.
I've been a long time user of Steve Tynor's flight planning software
called fplan which was posted to the comp.sources.misc USENET newsgroup.
The database files that were available for fplan were aging rapidly,
and the need for new database files was clear. The avdbtools package
also provides limited support for generating world files for ICAO Map.
\subsection{Copyright}
The avdbtools software package is Copyright (C) 1998 John C. Peterson,
{\tt {\(<\)}jaypee@netcom.com{\(>\)}}
This software package is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License,
version 2. A copy is included in this distribution in the file
named "LICENSE".
This software package is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License,
version 2, for more details.
\subsection{Changes}
Release 0.1 is the first public release of avdbtools, so there are no
changes to report. The code should be considered reasonably stable, I
have done a fair amount of testing myself. (This should not be confused
with the claim that there are no bugs!) The low version number is mostly
indicative of the absence of desired features. The support for fplan
databases is relatively complete, while support for ICAO Map still
needs more work before it is complete.
\section{Installation}
\subsection{Obtaining the Distribution}
I don't have enough disk space at my current ISP to host the distribution
myself, so I am using some of the popular archive sites for Linux
software. I will be distributing avdbtools in compressed tar format
as well as Red Hat Package Manager (RPM) format. You should be able to
get the distribution by anonymous ftp from the sites listed below. If the
files are not there, check the respective {\tt Incoming} directories.
\begin{itemize}
\item Compressed Tar: {\tt \url{ftp://sunsite.unc.edu/pub/Linux/apps/aviation/}{}}
\item Red Hat Package Manager (RPM):
\begin{itemize}
\item Source: {\tt \url{ftp://ftp.redhat.com/pub/contrib/SRPMS}{}}
\item Binary: {\tt \url{ftp://ftp.redhat.com/pub/contrib/i386}{}}
\end{itemize}
\end{itemize}
\subsection{Requirements}
This software was developed and tested under Red Hat Linux, release 4.2.
The requirements are relatively modest, you should be able to build and
use this software under most any UNIX like environment with an Ansi C
compiler (such as the Free Software Foundation's gcc compiler), a make
utility, and the Bourne shell.
\subsection{Configuration and Compilation}
To build faaconv, follow these easy steps;
\begin{enumerate}
\item Edit the {\tt Makefile} and change the macros that are related
to specification of the environment, assigning values appropriate to your
situation. The only macros you should need to edit are; {\tt CC}
to specify your C compiler, and {\tt BINDIR}, {\tt DOCDIR},
{\tt LIBDIR}, {\tt MANDIR} to specify the directories where the
executable, documentation, model coefficients, and man page, respectively,
are to be installed.
\item Run {\tt "make"} to build the executable.
\item Run {\tt "make install"} to install the executable in
{\tt BINDIR}, and the model coefficients in {\tt LIBDIR}.
\item Run {\tt "make install-man"} to install the man page in
{\tt MANDIR} and the user's guide in {\tt DOCDIR}.
\end{enumerate}
This user's guide and the man page can be found in the {\tt doc}
subdirectory of the source distribution tree. Both are written
in SGML (Standard Generalized Markup Language) format. The SGML format
documents are translatable into other useful and popular formats such
as LaTeX (and dvi, postscript from there), as well as standard HTML.
The converted formats are up to date with respect to the SGML versions
when distributed. If you make changes to the master SGML format documents,
you will need the Linuxdoc-SGML formatting system to update the other
formats. It is available from
{\tt \url{ftp://ftp.cc.gatech.edu/pub/people/gregh/linuxdoc-sgml/}{}}
\section{The faaconv Application}
\subsection{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.
\subsection{Obtaining the NFDC Databases}
As of this writing, the
{\tt 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
\begin{itemize}
\item {\tt \url{ftp://ftp.tc.faa.gov/nfdc/apt.tar.gz}{}}
\item {\tt \url{ftp://ftp.tc.faa.gov/nfdc/fix.tar.gz}{}}
\item {\tt \url{ftp://ftp.tc.faa.gov/nfdc/ils.tar.gz}{}}
\item {\tt \url{ftp://ftp.tc.faa.gov/nfdc/nav.tar.gz}{}}
\item {\tt \url{ftp://ftp.tc.faa.gov/nfdc/rwy.tar.gz}{}}
\end{itemize}
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 {\tt \url{ftp://ftp.ncftp.com/ncftp/}{}},
or wget with appropriate command line flags, available from
{\tt \url{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 {\em 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 {\em 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 {\em think\/} about using this data for a precision
approach.
\subsection{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.
\begin{description}
\item[{\tt -k}] \mbox{}
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 "{\tt K}". This applies to {\em all\/}
such airports, regardless of the existence of a navigational aid with
the same identifier. So for example, {\tt HMT} becomes {\tt KHMT}, while
identifiers like {\tt L78} and {\tt CL35} are not translated.
\item[{\tt -m (db{\verbar}fm)}] \mbox{}
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 {\em 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 {\tt db} as the argument to this option. To always use
the value computed by the model, use {\tt fm}. The later is the default
and recommended value (the values in the NFDC database appear to be
somewhat out of date).
\end{description}
\subsection{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.
\subsubsection{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
{\tt \url{http://www.ngdc.noaa.gov/seg/potfld/geomag.html}{}}
\subsubsection{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 {\em 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.
\subsubsection{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 {\tt field\_model.c}. It was designed to use either of the
IGRF or WMM model coefficient data files {\em 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
\begin{itemize}
\item {\tt \url{ftp://ftp.ngdc.noaa.gov/Solid\_Earth/Mainfld\_Mag/Models/igrf95}{}}
\item {\tt \url{ftp://ftp.ngdc.noaa.gov/Solid\_Earth/Mainfld\_Mag/Models/wmm95}{}}
\end{itemize}
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 {\em 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.
\subsubsection{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
{\tt field\_model.c} module contains three functions;
\begin{description}
\item[{\tt extern int init\_field\_model(char *filename);}] \mbox{}
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.
\item[{\tt extern int field\_model(field\_model\_t *value);}] \mbox{}
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 {\tt field\_model\_t} which is described in
the module header file {\tt 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.
\item[{\tt extern char *strerror\_field\_model(void);}] \mbox{}
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.
\end{description}
\subsubsection{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 {\tt GEOMAG.FOR}, which can be obtained from the directory {\tt \url{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).
\begin{tscreen}
\begin{verbatim}
+-----------------------+------------------+------------------+
| 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 |
+-----------------------+------------------+------------------+
\end{verbatim}
\end{tscreen}
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.
\subsection{Creating Output for fplan}
The fplan software expects two database files; {\tt airports.nav}
and {\tt vors.nav}. The first file contains entries for airports,
(gliderports, heliports, and ballonports too), and is generated by running
faaconv with {\tt comma.apt} as input. The second file contains entries
for navigational aids and is generated from the combined outputs from
faaconv with {\tt comma.fix}, {\tt comma.nav} as inputs.
Unfortunately, the {\tt 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, {\tt LAX} has
multiple ILS systems, each with a unique identifier). The {\tt 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 {\tt mknavdb}.
\subsection{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 {\tt comma.apt}, {\tt comma.fix}, {\tt comma.ils},
{\tt 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 {\tt icao-1.0.patch} contains
a patch for the parser.
\section{Additional Information}
\subsection{Other Software}
\subsubsection{fplan}
The fplan flight planning software package was written by Steve Tynor. It
was designed for constructing VFR cross country flight plans. The last
public release by Steve was version 1.3 and was posted to volume 30 of
the comp.sources.misc USENET newsgroup. As a product of my efforts with
avdbtools I made some improvements and fixes to fplan. When I approached
Steve with the changes, he indicated he was too busy with other projects
and offered me the option of taking over as maintainer, which I accepted.
The next release of fplan should be available soon. It will include
support for the graphics previewer option that is based on the XView
Toolkit for X11 (release 1.3 required Suntools, making that option Sun
specific). The XView Toolkit, developed by Sun Microsystems, is available
in source code form, and has been ported to a wide variety of UNIX/X11
platforms including HP-UX, Linux, SVR4, and Solaris of course. When
everything is ready, I plan to distribute fplan from the directory
{\tt \url{ftp://sunsite.unc.edu/pub/Linux/apps/aviation/}{}}.
\subsubsection{ICAO Map}
ICAO Map is a program for generating and displaying maps for aviation
purposes. It was written by Martin Pauly, and runs under UNIX systems
with X11/Motif. It's input is a so called "world file", that contains
descriptions of objects such as airports, navigational aids, roads,
towns, etc. It can use either Lambert or Mercator projection to generate
a map from this world file, either on your screen or as Postscript output.
It also includes interactive features, such as scrolling, rubber band
lines to measure distances and tracks, etc. Additional features are
available for both motorized and soaring (glider) flights. For more
information, visit the ICAO Map home page on the World Wide Web at
{\tt \url{http://www.oih.rwth-aachen.de/~pauly/icao.html}{}}.
\subsection{Future Plans}
My immediate goal is to complete the support for ICAO Map, as well
as for the generic format output. Once this is complete, I have some
ideas for new features. A simple GUI interface to the Geomagnetic Field
Model, perhaps based on the Tk, Xforms or similar widget sets might be
useful. Another idea would be to generate database files for updating
GPS receivers. I find it quite annoying to be shelling out lots of
hard earned cash for something we basically paid for already in the
form of taxes. This isn't a trivial project however, since all of the
manufacturers zealously guard much of the necessary information (correct
me if I'm wrong). Another idea would be to create an interface to a high
quality database engine such as PostgreSQL. This idea is less interesting
in view of the fact that this sort of thing is already available over
the net, see {\tt \url{http://www.airnav.com/}{}}.
\subsection{Contacting the Author}
If you find a bug in this software (especially if you also have a
patch for it) you can contact me by electronic mail at {\tt {\(<\)}jaypee@netcom.com{\(>\)}}.
Questions, comments, or suggestions are welcome. Please note that I
sometimes go through periods of time when I can't check my mail
regularly, so don't be alarmed if you don't get an immediate reply.
\end{document}
avdbtools-0.1/doc/guide.ps 100644 144 144 1030526 6523770067 14030 0 ustar jcp users %!PS-Adobe-2.0
%%Creator: dvipsk 5.58f Copyright 1986, 1994 Radical Eye Software
%%Title: guide.dvi
%%Pages: 8
%%PageOrder: Ascend
%%BoundingBox: 0 0 612 792
%%DocumentPaperSizes: Letter
%%EndComments
%DVIPSCommandLine: dvips -o guide.ps guide.dvi
%DVIPSParameters: dpi=600, comments removed
%DVIPSSource: TeX output 1998.05.05:2208
%%BeginProcSet: tex.pro
/TeXDict 250 dict def TeXDict begin /N{def}def /B{bind def}N /S{exch}N
/X{S N}B /TR{translate}N /isls false N /vsize 11 72 mul N /hsize 8.5 72
mul N /landplus90{false}def /@rigin{isls{[0 landplus90{1 -1}{-1 1}
ifelse 0 0 0]concat}if 72 Resolution div 72 VResolution div neg scale
isls{landplus90{VResolution 72 div vsize mul 0 exch}{Resolution -72 div
hsize mul 0}ifelse TR}if Resolution VResolution vsize -72 div 1 add mul
TR[matrix currentmatrix{dup dup round sub abs 0.00001 lt{round}if}
forall round exch round exch]setmatrix}N /@landscape{/isls true N}B
/@manualfeed{statusdict /manualfeed true put}B /@copies{/#copies X}B
/FMat[1 0 0 -1 0 0]N /FBB[0 0 0 0]N /nn 0 N /IE 0 N /ctr 0 N /df-tail{
/nn 8 dict N nn begin /FontType 3 N /FontMatrix fntrx N /FontBBox FBB N
string /base X array /BitMaps X /BuildChar{CharBuilder}N /Encoding IE N
end dup{/foo setfont}2 array copy cvx N load 0 nn put /ctr 0 N[}B /df{
/sf 1 N /fntrx FMat N df-tail}B /dfs{div /sf X /fntrx[sf 0 0 sf neg 0 0]
N df-tail}B /E{pop nn dup definefont setfont}B /ch-width{ch-data dup
length 5 sub get}B /ch-height{ch-data dup length 4 sub get}B /ch-xoff{
128 ch-data dup length 3 sub get sub}B /ch-yoff{ch-data dup length 2 sub
get 127 sub}B /ch-dx{ch-data dup length 1 sub get}B /ch-image{ch-data
dup type /stringtype ne{ctr get /ctr ctr 1 add N}if}B /id 0 N /rw 0 N
/rc 0 N /gp 0 N /cp 0 N /G 0 N /sf 0 N /CharBuilder{save 3 1 roll S dup
/base get 2 index get S /BitMaps get S get /ch-data X pop /ctr 0 N ch-dx
0 ch-xoff ch-yoff ch-height sub ch-xoff ch-width add ch-yoff
setcachedevice ch-width ch-height true[1 0 0 -1 -.1 ch-xoff sub ch-yoff
.1 sub]{ch-image}imagemask restore}B /D{/cc X dup type /stringtype ne{]}
if nn /base get cc ctr put nn /BitMaps get S ctr S sf 1 ne{dup dup
length 1 sub dup 2 index S get sf div put}if put /ctr ctr 1 add N}B /I{
cc 1 add D}B /bop{userdict /bop-hook known{bop-hook}if /SI save N @rigin
0 0 moveto /V matrix currentmatrix dup 1 get dup mul exch 0 get dup mul
add .99 lt{/QV}{/RV}ifelse load def pop pop}N /eop{SI restore userdict
/eop-hook known{eop-hook}if showpage}N /@start{userdict /start-hook
known{start-hook}if pop /VResolution X /Resolution X 1000 div /DVImag X
/IE 256 array N 0 1 255{IE S 1 string dup 0 3 index put cvn put}for
65781.76 div /vsize X 65781.76 div /hsize X}N /p{show}N /RMat[1 0 0 -1 0
0]N /BDot 260 string N /rulex 0 N /ruley 0 N /v{/ruley X /rulex X V}B /V
{}B /RV statusdict begin /product where{pop product dup length 7 ge{0 7
getinterval dup(Display)eq exch 0 4 getinterval(NeXT)eq or}{pop false}
ifelse}{false}ifelse end{{gsave TR -.1 .1 TR 1 1 scale rulex ruley false
RMat{BDot}imagemask grestore}}{{gsave TR -.1 .1 TR rulex ruley scale 1 1
false RMat{BDot}imagemask grestore}}ifelse B /QV{gsave newpath transform
round exch round exch itransform moveto rulex 0 rlineto 0 ruley neg
rlineto rulex neg 0 rlineto fill grestore}B /a{moveto}B /delta 0 N /tai 