Creating a flight plan with fplan involves the following basic steps, determining the desired flight route(s), creating a planfile that reflects the desired route(s), and finally feeding the planfile to fplan which then grinds through all the calculations for computing the true and magnetic courses, estimated ground speeds, wind corrected headings, and so on. This section provides a brief overview of the steps required to create your own flight plans using fplan.
Any pilot who hasn't been living in a cave has very likely seen some of the commercial flight planning programs currently on the market. Some provide a GUI interface that allows you to point and click on the desired flight waypoints from a "sectional quality" chart display. I'd love to see fplan have this capability, but at this time it is not feasible. Digital charts of adequate quality (complete with victor airways, airspace boundaries and so forth) are simply not available from NOAA or any other government source at this time (see Future Plans below).
For the purpose of determining the best (and safest) flight route, your best resource is still a current NOAA Sectional Chart. While this doesn't rank very high on some people's "Gee Whiz" scale, it provides complete, accurate, and up to date navigational information which, should be an important consideration when preparing a flight plan. Just as with the "old fashioned" approach to flight planning, it's a good idea to mark your flight route(s) on the chart and take it with you on the flight.
The next step in the process is to create a planfile that reflects your chosen flight route. The user's personal and system wide or common database files allow you to specify a waypoint by its identifier for the case of an airport or navaid. You can also specify latitude and longitude for general landmarks, an intersection of radials from navaids or airports, or a point relative to an identifier (RNAV coordinates). At this point you may want to browse through some of the example planfiles to get a better feeling for how waypoints can be specified. The provided examples also serve as useful templates for creating your own planfiles. You will need a plain text editor to create the files (such as vi, Xemacs under Unix systems, or the Notepad application under MS-Windows).
In the case of navaids, you can get the associated identifier directly from a Sectional Chart. In the case of airports, you can refer to the "Airport/Facility Directory" published by NOAA, or similar publications available from commercial sources such as Airguide Publications, Inc. You should also be aware of the airport identifier convention used by the fplan databases (see Airport Identifier Convention). To verify that your identifiers are consistent with those in the provided databases, use fplan's lookup mode to retrieve the information associated with your identifiers (see execution modes).
At some point in time you should read the following section on the airport and navaid databases distributed with fplan. Impatient or experienced computer users can probably treat the section below that describes the planfile syntax as a reference and examine some of the provided example planfiles to get started. The fplan output is mostly self explanatory, but a section is included below that describes the fplan output in more detail. The fplan manual page provides detailed information on command line options when running fplan.
The database files distributed with fplan contain a list of airports,
balloonports, gliderports, heliports (in the file airports.nav),
fixes, intersections, and navaids (in the file vors.nav). Two
versions of the database are available; the complete version that contains
all airports, both public and private usage, and a version with only
public usage airports (although they could be privately owned). At this
time the database contains information only for the United States. You
may also wish to construct a personal database that contains entries for
points of interest in your local area (see
personal databases). When trying to locate information for a
given identifier, fplan always searches the user's personal databases
before searching the system wide, or common databases.
The databases distributed with fplan were created using information from the (United States) National Flight Data Center. I wrote another software package to reformat the NFDC data (see avdbtools below) for use with fplan. At one time, the National Flight Data Center distributed the databases on magnetic media only (no doubt one of the reasons that the old fplan database files were not updated very frequently). Now you can get the NFDC database files directly from their world web site at
This release of the airports.nav database uses the "K" convention to
distinguish between airports and navigation aids with the same identifier
(a convention used by many GPS manufacturers). In this convention, all
airport identifiers that are exactly 3 alphabetic characters long are
prefixed by the character, "K", regardless of whether there is a
navigational aid with the same identifier or not. Airport identifiers
that are longer than 3 characters or contain numeric characters are
unchanged. For example, HMT becomes KHMT, L78 remains L78, and CL35
remains CL35.
The creation of the fplan database files was greatly complicated by the fact that the navaid files from NFDC no longer had any entry for magnetic variation. To solve this problem, I needed a good model to calculate the magnetic variation for a given latitude and longitude referenced to some datum. 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 database files distributed with fplan use the DoD World Magnetic Model, 1995 Revision (WMM-95) to estimate the magnetic variation of all airports and navaids. I could have used the NFDC database entries for variation of airports. However a closer examination of some of the data seemed to suggest that it had not been updated to account for secular change. (Several spot checks did not agree well with values taken from a current NOAA Sectional Chart). For consistency, it seemed best to use the WMM-95 model for both airports and navaids. You can find a more complete discussion of the model physics, accuracy of the models, and my numerical implementation of them in the avdbtools user's guide (see section avdbtools below).
General aviation pilots have discovered the many advantages offered by GPS (Global Positioning System) units in a big way. A GPS receiver, together with a programmable navigation computer running on an embedded microprocessor, provides unsurpassed accuracy and convenience for as little as a few hundred dollars. The accuracy of civilian units that use only the C/A code on frequency L1 are such that the computed position is within 100 meters of the actual position about 95% of the time. However, don't be seduced by the accuracy of the system hardware itself. You probably won't do anywhere near that good using coordinates from this database.
An issue you need to consider is consistency of datums. A datum is a set of parameters that define a mathematical ellipsoid designed to approximate the earth's actual surface or geoid (the equatorial radius of the earth is about 21 nautical miles larger than the polar radius). You must specify the latitude, longitude, and the associated datum to uniquely describe a given point on the earth's surface. Most GPS receivers are configured by default to use the World Geodetic System of 1984, or WGS-84 datum, which is also the datum used on NOAA Sectional Charts. Some datums are designed to be a reasonably good fit over most of the earth's surface (like WGS-84), while others are carefully designed to provide the absolute best possible accuracy in a very small area (such as the one that was developed for the construction of the tunnel under the English Channel). Most GPS receivers can be configured to use any one of a wide variety of published datums (my trusty Garmin 89 has 104 choices).
The error associated with inconsistent datums can be almost a mile in some cases, and is greater than 100 meters to be sure! The bad news is that I have not been able to determine the datum associated with the latitude, longitudes values given in the NFDC databases. It's possible that no uniform datum was used (another possible reason why the NFDC does not represent the database as an official product). Of course you can always validate a latitude, longitude value from the database or a latitude, longitude value calculated by fplan by just taking the few minutes it takes to plot it on a current NOAA Sectional or VFR Terminal Area Chart. This also shows you exactly where a GPS unit (configured for the WGS-84 datum), would take you.
Don't feel bad if this is all news to you. It seems that even the US military is still educating itself on this issue. During the Gulf War, many of the errors in high altitude B-52 bombing runs over Iraq were traced to inconsistent datums. You can find an interesting discussion of this and datums in general at
You should be aware of the fact that the database files from the National
Flight Data Center (used to construct the ones distributed with fplan)
are not official products approved for navigation. To be more specific,
the NFDC world wide web site clearly states, "FOR RESEARCH PURPOSES
ONLY -- NOT CERTIFIED FOR NAVIGATION".
I don't know all the reasons why NFDC makes this disclaimer, they are listed in the "Airport/Facility Guide" as the main point of contact for reporting errors in that information. Funding is no doubt one issue. The issues related to the magnetic variation values discussed above are another obvious reason, but there could easily be many other issues as well. It would be prudent to heed this clear warning and validate information used from the database files with other available sources. For example, if you question the validity of a latitude and longitude value you can simply plot the point on a Sectional Chart. It's only common sense that any database of this size will have errors in it so exercise appropriate care.
For your convenience, fplan allows users to have personal databases of their own. They are always searched before the system wide or common database of the same type (airport or VOR). The common database files distributed with fplan only provide coverage for the United States. Users that live outside the United States will want to construct a personal database for their local area. No matter where you live, personal databases are useful for defining things like boundaries of controlled airspace, mountain passes or other geographical points of interest, emergency landing sites, and so on. It may be wise to choose personal identifiers that begin with an underscore (the "_" character) to distinguish them from identifiers in the common database. This is not a requirement, but it's a useful mechanism for eliminating any possible confusion.
The format of both the common and personal database files are described
in the fplan entry in section 5 of the man pages (users of non-Unix
systems can refer to the formatted version of this document in the
file fplan_5.ps or fplan_5.txt). Note that the text versions of
your personal database files must be processed by the paddb application
before they can be read by fplan. You can install your personal database
files anywhere you like. Simply set the FPLAN_USER_DBDIR environment
variable to the directory where it can be found. (The best place
to do this is in the initialization file for your command shell, the
~/.cshrc or ~/.profile files for Unix shell
users, the CONFIG.SYS file for OS/2 users, or the AUTOEXEC.BAT
file for MS-DOS users).
fplan reads a free format input language to specify the departure and destination airports, intermediate waypoints, fuel on board, fuel burn rates, winds aloft, etc. This section presents a detailed reference for the syntax of the planfile and planfile statements. However, you will likely find the syntax of the fplan language to be largely self explanatory. Impatient or experienced computer users may want to skip this section and examine some of the provided example planfiles instead. In any case, the provided examples serve as useful templates for creating your own planfiles. Here is an overview of the syntax of the planfile;
In the planfile, the default unit for distance (except for altitudes) is nautical miles and the default unit for speed (such as true airspeed of the aircraft and wind speeds) is knots (nautical miles per hour). You can specify different units by using appropriate keywords after any numeric value. The keywords are
In the output flight plan the default unit for distance is nautical
miles and the default unit for speed (such as true airspeed of the
aircraft and wind speed) is knots (nautical miles per hour). You can
change this to statue miles and statue miles per hour by including the
-s flag on the command line.
The planned flight route is specified by of a sequence of waypoint statements which begin with either the from, via, or to reserved words, corresponding to the departure waypoint, enroute waypoints, and destination waypoint, respectively. The planfile can contain more than one route. This is useful for computing several routes ahead of time and selecting the best one on the day of the flight.
The order in which the databases are searched is different for terminal
and enroute waypoints. For the case of a departure or destination
waypoint (the from or to keywords), the airports.nav
databases are searched first, then the vors.nav databases are
searched for the given identifier. For the case of an enroute waypoint
(the via keyword), the vors.nav databases are searched
first, then the airports.nav databases. In each of these cases,
when the airports.nav databases are searched, the user's personal
airports.nav database is searched before the system wide,
or common airports.nav database. Similarly, when the vors.nav
databases are searched, the user's personal vors.nav database is
searched before the system wide, or common vors.nav database.
The syntax of the waypoint statements are now described.
Specifies a waypoint by its identifier. It is an error if identifier cannot be found in any of the databases.
Specifies an intersection waypoint. Both radial_1 and radial_2 represent the magnetic direction from the reference points corresponding to the respective identifiers to the desired waypoint. The convention of magnetic direction is a natural choice since VOR radials are magnetic, rather than true. An error is issued if no intersection exists or the intersection is poorly conditioned (when the defining directions are almost parallel to each other). Up to three optional quoted strings corresponding to the name, city, and comment fields in the output form may be specified. It is an error if identifier_1 or identifier_2 cannot be found in any of the databases.
Specifies a relative waypoint (like an entry to an RNAV computer). The specified direction of the waypoint relative to identifier is assumed to be in degrees magnetic, rather than true. As always, the specified distance is in nautical miles, unless an appropriate distance qualifier keyword is present that specifies otherwise. One should avoid using a distance that is excessively large because the magnetic variation used for the waypoint is the same value as for identifier (a few tens of nautical miles is not a problem). Up to three optional quoted strings corresponding to the name, city, and comment fields in the output form may be specified. It is an error if identifier cannot be found in any of the databases.
Specifies a waypoint by its latitude and longitude. The format for latitude and longitude entries are; integer valued degrees, the ":" character, integer valued arc minutes, the ":" character, decimal arc seconds, a white space, and the north or south keyword for latitude, or the east or west keyword for longitude. The magnetic variation must be specified because it is required to convert a true course to a magnetic one. The format for the magnetic variation entry is; decimal degrees followed by a white space and either the east or west keyword. Up to three optional quoted strings corresponding to the name, city, and comment fields in the output form may be specified.
Specifies an incremental waypoint. Note that the incremental waypoint can be used only in an enroute context. If distance is positive, it specifies the distance from or after the last non-incremental waypoint. If negative, the absolute value of distance specifies the distance to or before the next non-incremental waypoint. Incremental waypoints are useful for dead reckoning flight where it is desirable to have checkpoints every so often. They are also a very useful for specifying the end of climb to cruise, or for specifying the beginning of descent (this admits more precise specification of fuel rates, and estimates of fuel consumption). Up to three optional quoted strings corresponding to the name, city, and comment fields in the output form may be specified. Note that successive incremental waypoints still refer to the same previous non-incremental waypoint and not to the last incremental waypoint as one might think. Thus the following two successive waypoint statements refer to exactly the same point
The following statements are used to specify the initial amount of usable fuel on board, the fuel burn rate(s), and any additional fuel used. In order for fuel consumption computations to be made, the initial amount of usable fuel on board and the fuel burn rate must be specified.
Specifies the initial amount of usable fuel on board. The value given for the numeric argument quantity must be a positive number. The units used for quantity are arbitrary; pounds, gallons, imperial gallons, quarts, liters or whatever units happen to be convenient. Note that quantity should not include any unusable fuel on board. This statement applies to the waypoint at the start of the current leg. It is an error for this statement to be applied to a waypoint that is not a departure waypoint (specified by the from keyword).
Specifies the fuel consumption rate. The value given for the numeric argument rate must be a positive number, and in units per hour, where the units used agree with those used in the fuel_amount directive above. This statement applies to the current and all successive legs until another fuel_rate statement is encountered. You may want to include a waypoint for the end of the climb to cruise, and at the start of the descent for landing, so that the fuel rates can be updated for the power settings used (incremental waypoints are a good choice).
Specifies any additional fuel used that is not accounted for by the enroute flight time and fuel burn rate (such as extra amounts used for taxi, run up, traffic related delays and so on). The units used for the numeric argument quantity must agree with the units used in the fuel_amount directive to remain consistent. This statement applies to the waypoint at the start of the current leg.
Specifies the flight altitude in feet above mean sea level. In the current version of fplan, the value is simply copied to the output form, but future versions may use it for density altitude or similar performance related computations.
The given string replaces the comment field of the previous waypoint in the route. If this statement appears before the first waypoint statement in the planfile, it has no effect.
Specifies that the VOR receiver given by number will be tuned to the station given by identifier. The binary distribution is configured to accept up to 6 navigation receivers. VOR fixes are computed for each receiver and waypoint in the route(s). It is an error if identifier cannot be found in any of the databases.
Note that when auto track is enabled (default is disabled), receiver
1 is automatically tuned to the next waypoint (if it is a navigation
aid), or to the previous waypoint (if it is a navigation aid) and user
specified values for nav 1 are silently ignored. Auto track can
be enabled with the -t command line switch.
Specifies the true airspeed of the aircraft. This statement applies to the current and all successive legs until another tas statement is encountered. If no tas statement is included in the planfile, enroute time and fuel consumption estimates can not be made.
Specifies the direction and speed of winds aloft. The direction argument must be in units of degrees relative to true north. This is the convention used in the winds aloft forecast from Flight Service. (Recall that winds are always reported in degrees with respect to true north, except when reported by the control tower or in (automated) airport surface observations, in which case they are relative to magnetic north, as runways are). This statement applies to the current and all successive legs until another wind statement is encountered. If no wind statement is included in the planfile, the winds aloft are assumed to be calm.
In this section, we provide a brief overview of running fplan. For a complete reference on command line syntax and options, see the provided man page. fplan can be run in one of four different major modes which are described below. The different modes are selected by using the appropriate flag as the first command line option.
In normal or default mode, the given planfile is parsed, the flight route(s) are computed, and a flight plan including wind corrected headings, distance, estimated time, and fuel consumption for each leg, VOR fixes for each checkpoint, and so on, are written to the standard output. Normal mode is the default mode of operation and does not require any special flag as the first command line option.
In graphics mode, the specified planfile is parsed, the flight route(s)
are computed, and the results are displayed in an XView window. (For
Unix/X11 systems with the XView Toolkit only, also installation
dependent). The window includes buttons for scrolling the chart to the
first and last waypoints, as well as for setting the magnification
scale factor of the chart. Graphics mode is selected by using -g
as the first command line option.
In the lookup mode of operation, all remaining command line arguments
are assumed to be airport or navaid identifiers. fplan will search the
user's personal and system wide databases and will print information for
each match to the standard output. If any identifier was found in both
the airports and navaid databases, then both entries are printed. Lookup
mode is selected by using -l as the first command line option.
In reverse mode, the given planfile is parsed, the flight route(s)
are computed, and a planfile for the return trip is written to the
standard output. All waypoints are reversed and incremental waypoints are
recomputed. Correct directives are included so that each waypoint uses
the same VORs as in the input planfile. Fuel, altitude, airspeed and wind
statements are not included in the reversed planfile. They may be
included in a future release. Reverse mode is selected by using -r
as the first command line option.
Although there are an infinite number of courses that connect two given points on the earth's surface, there are only two meaningful ones, the great circle and rhumb line courses. By definition, the great circle course minimizes the distance traveled. It can be visualized as the intersection of the earth's surface with the unique plane defined by the center of the earth and the two given points. A great circle course appears as a straight line on a chart that uses the Gnomonic projection system. The disadvantage of the great circle course is that the (calm wind) heading with respect to true north is not constant, except for the special case where the two given points are on the same meridian (i.e., have identical longitude). Great circle courses and close approximations to them are routinely used on long distance transcontinental flights.
This release of fplan computes a rhumb line course. By definition, it is the constant (calm wind) heading course that connects the two given points. A rhumb line course appears as a straight line on a chart that uses the Mercator projection system. At mid latitudes, the extra distance traveled for the rhumb line course is small when the points are a few tens or hundreds of nautical miles apart. The rhumb line course is probably a better choice than the great circle course for general aviation use. The only corrections to the estimated headings for each leg that the pilot needs to be concerned about, are those corrections associated with changing winds aloft.
The fplan output consists of three distinct groups of columns; the waypoint
information columns, the flight leg columns, and the optional VOR fix
columns (disabled by default, and enabled with the -w command line
option). In the fplan output, each route begins with a group of header
lines. They contain symbolic entries that describe the numeric entry at
that position in the data that follows. Most of them are self explanatory,
but because of space limitations, some of them are not obvious.
They are documented here for completeness.
WAYPOINT - waypoint or facility name (from database or planfile)CITY, ST - associated city and state (from database or planfile)COMMENTS - additional comments (from database or planfile)
IDENT - facility identifier (from the database)TYPE - fplan waypoint type (from the planfile)LAT LON - latitude and longitude (datum unknown)
FREQ - facility frequency (from the database)ELEV - facility elevation (from the database)
TOTD - total distance traveled to waypoint (computed by fplan)REMD - total distance remaining to waypoint (computed by fplan)
FUEL - usable fuel remaining at waypoint (estimated by fplan)ETA - estimated time of arrival at waypoint (estimated by fplan)ATA - actual time of arrival at waypoint (blank for pilot's entry)
WIND - winds aloft (degrees true, from the planfile)MC - magnetic course for this leg (computed by fplan)MH - magnetic heading for this leg (estimated by fplan)
TAS - true airspeed (from the planfile)EGS - estimated ground speed (estimated by fplan)AGS - actual ground speed (blank for pilot's entry)
DIST - distance traveled for this leg (computed by fplan)ETE - estimated time enroute for this leg (estimated by fplan)ATE - actual time enroute for this leg (blank for pilot's entry)
ALT - MSL altitude for this leg (from the planfile)FRATE - fuel burn rate for this leg (from the planfile)FUSED - fuel used for this leg (estimated by fplan)
[1-6] - navigation receiver number (from the planfile)IDENT - facility identifier (from the database)
FREQ - facility frequency (from the database)
RAD - magnetic radial to waypoint (computed by fplan)DME - over ground distance to waypoint (computed by fplan)
Note that fplan sends all of its output to the standard output, which in
most environments is the terminal screen. If you want to capture the
output to a file or print it, you will need to redirect the standard
output. On most systems you can redirect the standard output to a file
by appending "> filename" to the end of the fplan command line
(without the quotes).
To be useful in practice, we want a hardcopy of the flight plan that is as legible as possible. In the cockpit, it is desirable to quickly extract needed information, so we don't get too distracted from other tasks that are placing demands on our attention. Since the output from fplan is typically wider than the standard 80 columns supported by the default portrait mode of most printers, we will need some type of print utility software (that supports landscape mode and maybe selectable fonts) to get the best possible results. Note that you must print fplan output using fixed width fonts. If you print fplan output using fonts with proportional spacing (like most fonts used in word processors), the columns will no longer be aligned properly, rendering the output unreadable.
On Unix systems, the print utilities a2ps and nenscript are both good choices for pretty printing fplan output. Both support landscape orientation and selectable fonts, and both generate postscript output. If you are like me and don't have a printer with hardware support for postscript, don't worry. Just get the ghostscript package and follow the instructions for installing it as a printer filter. (Note that you don't have to install it as a filter, but it most definitely provides maximum ease of use).
For the a2ps utility, you will likely want to include the following
options; -1 to select one virtual page per physical page for
maximum readability, --landscape to enable landscape orientation,
--columns-per-page=98 to specify the width of the output (the
value given works for fplan wide format output with two VOR fixes),
and possibly --encoding=PCG to enable support for IBM PC Graphics
characters (they are present when fplan is run with the -e flag).
For the nenscript utility, you will likely want to include the following
options; -1 to select single column output for maximum readability,
-r to enable landscape orientation, -f font to specify the font
(for fplan wide format output with two VOR fixes, Courier12 works
very well).
The algorithms used by fplan for computing the course and distance between two waypoints, as well as the algorithms used to compute the location of intersection and relative waypoints have some practical limitations. Columbus was right, the earth is not flat, but it's not a perfect sphere either. The earth's shape is best described as an ellipsoid with the equatorial radius about 21 nautical miles larger than the polar radius. fplan uses algorithms based on spherical trigonometry which don't exactly account for the ellipsoidal shape of the earth's surface. The approximation used is quite reasonable provided that the distance between waypoints, or the distance from the defining identifier(s) and intersection or relative waypoints is not too large (a few tens of nautical miles is not a problem).