.* This file should be SCRIPTable without the need for any changes
.* or any specific formatting options. It has been set up to be
.* printer independent as much as possible.
.pm 5
.rc 1 |
.hy off
.ll 73
:gdoc
:frontm
:titlep
:title GCP: A Great Circle Program
:address
:aline Release 1.1
:aline
:aline May, 1989
:aline
:aline
:aline
:aline Garry Barker, VK5BUB
:aline VNET SYDVM1(ABABARK)
:eaddress
.ri on
:etitlep
.ri off
.ju on
:preface
:p.This program was written for the potential benefit of all
amateur radio operators and may be distributed freely to anyone
interested. No responsibility is taken by the author with regard to the
accuracy, currency or usefulness of the program.
.rc 1 on
:p.The initial release of the program was an attempt to sample the
usefulness or otherwise of the program and to judge the
benefits of further development based on feedback (or lack of it)
and so, it had a few niceties omitted.
:p.The release discussed in this document (Release 1.1), incorporates
the following enhancements:
:ul compact
:li.Some performance improvements through improved mathematics
:li.A more consistent menu interface
:li.Removal of a printing bug
:li.Inclusion of degree marker numbers on the circumference
of the printed circle
:li.Ability for users to specify their own reference locations
for inclusion on the printed map
:li.Ability to exclude reference locations from the printed map
:li.Ability to specify spacing of radial markers in both degrees
and kilometres on displayed and/or printed map
:li.Ability to exclude radial markers from displayed and/or printed map
:li.Requirement for about 20K more memory (enhancement??)
:eul
.rc 1 off
:p.All work was done using the author's own time and resources.
The hardware included a PC1 with maths co-processor and
colour graphics adaptor, with 640K of RAM and 1 hard disk.
The printer used was a 4201 Proprinter.
:p.The mathematics for distance and bearing calculations were taken
directly from the :cit.ARRL Antenna Book, 14th edition, page
16-4.:ecit.
:h5.Acknowledgments
.rc 1 on
:p.My thanks go to Garry Herden (VK5ZK), Hans Smit (VK5YX), Tony
Stanciewicz and Chas Franks for their help in testing and timing
the operation of the initial release of this program on their
equipment. Thanks also to those who offered suggestions and other
feedback on that release. It all gave me the incentive to produce
this next release.
.rc 1 off
:toc
:body
.* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
:h1.GCP Overview
:h2.Why a Great Circle Program
:p.The VK5BUB Great Circle Program (GCP) was written as a tool for
answering some questions I found myself asking, such as:
:ul
:li.How come I need to point a beam antenna due south from Adelaide
to contact Brazil? All atlas maps show Brazil either north-east or
north-west from Adelaide.
:li.Why do I hear strong Japanese signals when they are beaming long path
to Europe? Europe is "obviously" due west from Japan and Adelaide
is due south.
:li.How do I place my dipole so its major lobes favour
the "best" directions?
:li.Which signal paths lay over water?
:li.What countries are better worked on the long path?
:li.Why is it that I beam roughly north-west to Finland, but
.rc 1 on
Finnish
.rc 1 off
stations beam almost due west for Adelaide.
:eul
:p.I found I could get hold of great circle maps from several sources,
but, in the true tradition of amateur radio, I wanted to be able to
produce my own and so I took it up as a project.
As with many projects, the program became a challenge and an interest
for me and I was unable to find anyone who had such a program. There
seemed to be programs to do one-at-a-time calculations of distance
and bearing, but none to draw pictures.
:p.In most instances, one would assume that the program would only
be needed once and then discarded once a basic map had been
printed. I suspect that the extra capabilities of GCP may make
repeated usage likely, although its usage on a one-off basis by
a few people would justify the effort to me.
:h2.What the program does
.rc 1 on
:p.In essence,
.rc 1 off
GCP allows the user to specify the latitude and
longitude of the centre of the circle and then
:ul compact
:li.draw a great circle map on a graphics monitor,
:li.draw it and then print it, or
:li.print without review on the screen.
:eul
The printed map in this
.rc 1 on
release, as for the previous release,
.rc 1 off
of the program spans
4 print pages giving a circle of roughly 40 cm (16 in.) diameter.
The first 2 pages form the left half and the next 2 form the right
half of the map. The map is constructed by joining the 2
halves with glue in between the overlapping edges. See the section
on printer paper alignment in the chapter on "Using the Great Circle
Program" for a handy hint.
:p.At user request, the map can include a graphical representation
of the long path in the outer half of the circle with the short path
section then being half scale. This is useful in reviewing which countries
lie on a path all of its way around the globe.
:p.The printed map also includes numbered markers for a selected
set of locations to allow for easy identification of land masses
where the great circle representation makes shapes appear
distorted. At the bottom of the map is a legend for the
markers in numeric and concurrently alphabetic order.
.rc 1 on
:p.In this release, the markers and legend may be suppressed at
user option on the GCP menu. The particular locations to be used
as markers may also be changed by the user by editing the locations
source data file GCPLOCS.DAT. More on this later.
.rc 1 off
:h2.Required operating environment
:p.GCP has been written at the most machine-independent level
consistent with performance requirements. The lowest level
interfaces used are at the BIOS level for physical printing
and screen plotting.
:p.Basic machine requirements are:
:ul
:li.IBM PC or compatible.
.rc 1 on
:li.Approximately 430K of memory if maps are printed, 160K otherwise.
.rc 1 off
This does not include memory needed for DOS, BIOS etc..
:li.CGA or similar if maps are displayed,
any other DOS-supported monitor otherwise.
.rc 1 on
Release 1.0 has been tested
with CGA, EGA and VGA, the latter running in CGA mode.
.rc 1 off
:li.IBM Proprinter or compatible if maps are to be printed.
Should work with IBM graphics printer. The printer must be LPT1.
:li.Room for the .EXE file and GCPMENU.PAN on floppy or hard disk
- approximately 80K. If the GCPLOCS.DAT file is used, it is accessed
every time printing is performed. If the file is not found, defaults
will be used, but if the drive is not ready, errors may occur.
This file is approximately 1.5K as supplied (unmodified).
:li.A maths co-processor is not needed, but provides a significant
performance advantage.
.rc 1 on
(See appendix A for some performance measurements for Release 1.0).
:li.Operating system - GCP Release 1.0 was tested with PC-DOS 3.2,
PC-DOS 3.3 and MS-DOS 3.3.
.rc 1 off
:eul
:h2.Required files
:p.The following are the program files:
:ul
.rc 1 on
:li.GCP.EXE - the program for usage with maths co-processor. It will
either not execute, or run very slowly, if no co-processor
is available.
.rc 1 off
:li.GCPA.EXE - the program for usage with the Alternate maths library
ie. without the maths co-processor. It will ignore a maths co-processor
if it is present.
:li.GCP.SCR - the documentation in standard GML SCRIPT format, suitable for
printing in virtually any SCRIPT environment
(PC, host, 3800, 3820, 3287, 6670...).
:li.GCP.LST - the documentation as a file to be printed to
a PC printer
.rc 1 on
:li.GCPLOCS.DAT - the source file of reference marker locations. This
may be modified by the user.
:li.GCPMENU.PAN - this is the compiled menu format. It may not be
changed by the user.
.rc 1 off
:eul
.* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
:h1.Using the Great Circle Program
:h2.Known bugs
.rc 1 on
:p.This release of the program has been released with no known bugs.
However, it has not yet had the same degree of testing that the
previous release (1.0) had before release.
.rc 1 off
:h2.Performance
:p.Performance warrants brief comment right at the front of this
chapter. The production of maps done by GCP requires thousands
of trigonometric calculations. I have spent many hours improving
the performance of the program, with a reduction from the first cut
of nearly one hour to produce a graph without maths co-processor, to
under 8 minutes for a printable map and around 3 minutes for
a display-only map - both on a 4MHz PC1 with maths co-processor
turned off.
:p.The optimisation of both co-processor and non-co-processor
environments for performance is the reason for separating
the 2 environments into 2 separate .EXE files.
:p.To set expectations at a reasonable level, the table in Appendix A
provides a set of "stopwatch" measurements on time taken to produce
maps in a few different environments.
.rc 1 on
These measurements were made with release 1.0 and some small
improvements have been implemented in release 1.1.
.rc 1 off
:h2.Invoking and exiting GCP
:p.To invoke GCP, enter GCP from the DOS command line (or other
similar places) if you have a maths co-processor,
or GCPA if you do not. There are no parameters required and any
parameters included with the command will be ignored.
.rc 1 on
:p.To exit GCP, either:
:ol compact
:li.Hit the <ESC> key, or
:li.Shift the bounce-bar cursor to highlight the word "Quit" at
the top of the menu and hit <RETURN>. This does NOT work as for
some well-known products in that hitting the <Q> key will not
activate the "Quit" option. This is beyond the author's control.
:eol
.rc 1 off
:h2.Setting menu parameters.
.rc 1 on
:p.To change any of the data values appearing below the word
"General:" on the menu, move the bounce-bar cursor to highlight
the words "Update parms" and hit <RETURN>. You may now update any
values in the data fields. The cursor may be shifted up and down
using cursor shift and tab keys. When all values are correct, hit
<RETURN> and the values will be checked for validity. If valid,
the cursor will be placed back on the bounce-bar and you may
proceed with other activities. If not valid, a warning tone and
message will occur and the cursor will be placed in the offending
field.
:p.Note. The C/2 language will successfully interpret invalid values
such as "123.2A1". It stops interpreting this value when it strikes
the first invalid character. It would interpret the previous string
as 123.2. The menu is updated after the <RETURN> key is hit, so there
is no problem with not detecting an error of this sort if the user
checks the result.
.rc 1 off
:h3.Setting centre latitude and longitude
:p.Both values should be in degrees
with North and West values being positive and South and East being
negative. Values should be entered as decimal numbers eg. 43.7 or -139.5.
The values entered become the settings for the rest of the GCP session or
until changed by the same process. Values are checked for validity,
and will be requested again if invalid. Co-ordinates of poles are
recognised and approximations (+-89.99 degrees of latitude) are used
to ensure proper functioning of the program.
.rc 1 on
No warning message is issued.
.rc 1 off
:h3.Including long path map
:p.The long path map was described in chapter 1. To change from
having the long path excluded to having it included (or vice versa),
.rc 1 on
update the field marked "Include long path" as described above.
.rc 1 off
There is a small cost in processing time to include the long path.
:h3.Changing spacing or inclusion of radial markers
.rc 1 on
:p.The user may vary the spacing of radial markers on the screen
version and/or the printed version of the map in terms of both
degrees and kilometres apart. If 0 degrees is specified, radial
markers will not be included. If a map is being displayed and printed
in the one operation, the printing selection will be used and the
radial markers displayed will reflect the printing specification.
:p.For imperial measurement countries, a spacing of 1610 kilometres
would cause a radial spacing of 1000 miles etc.
.rc 1 off
:h3.Setting number of print copies
:p.If you wish to print several copies of the same map without
mathematically reconstructing the map each time,
.rc 1 on
update the field marked "Number of print copies" as described above.
.rc 1 off
You may specify between 1 and 99 copies.
:h3.Excluding reference location markers from printed map
.rc 1 on
:p.To exclude reference location markers and legend from the
printed map, change the field marked "Include ref locations".
.rc 1 off
:h2.Displaying maps on CGA
.rc 1 on
:p.To display a map on the screen, move the bounce-bar cursor
to highlight the word "Draw" and hit <RETURN>.
.rc 1 off
No check is made
for the presence of a suitable monitor adaptor. The display
construction may be interrupted at any time by striking any key.
.rc 1 on
In release 1.0, this happened almost immediately; in release 1.1,
this may take a few seconds depending on where the current drawing
activity is happening. The program checks for this situation less
frequently as an aid to performance.
.rc 1 off
(Ctl-Brk will abort the whole program. Aborting the program may leave the
screen in an unusual state.). The map will remain
on the screen until another key is struck. Resuming construction of
the display is not possible; it must be reselected from the menu.
:h2.Printing
:h3.Printing without screen review
.rc 1 on
:p.To print a map, move the bounce-bar cursor
to highlight the word "Print" and hit <RETURN>.
.rc 1 off
Print error handling uses DOS/BIOS mechanisms. Printing may be
interrupted by striking any key. The time taken to
construct the print array is longer than for the screen due to the
finer resolution requirement. Roughly 3 times as long is a reasonable
working estimate.
:h3.Printing after screen review
:p.To see the map on the screen and then request print,
.rc 1 on
move the bounce-bar cursor
to highlight the word "Both" and hit <RETURN>.
.rc 1 off
This displays the map on the screen and
.rc 1 on
later
.rc 1 off
asks for confirmation of
print requirement. The display will be constructed at print
construction speed ie. the map will be drawn on the screen
roughly 3 times as slowly as for option 1, because the print array
is constructed concurrently with the screen display.
:h3.Checking printer paper alignment
.rc 1 on
:p.Printing has been tested on continuous and single sheet
stationery. The single sheet approach
has been found to be useful by some amateurs, but does require more
cutting and pasting.
.rc 1 off
If the paper is positioned strategically
in the printer, then the joining together of the 2 halves of the
map can be done without any edge trimming of the paper after removing
the tractor hole edges. This has been found to be very useful. To aid
in aligning the paper for this purpose,
.rc 1 on
moveng the bounce-bar cursor to highlight the words "Print test"
will send
.rc 1 off
1 line to the printer, ending in a black rectangle. You should print
the line, then adjust the paper attempting to get the right hand edge of
the rectangle JUST on the paper, almost grazing the perforations on the
edge. Repeat the process until satisfied, occasionally rolling the
printer carriage backward and forward to allow for settling of the
tractors. There is no form feeding between attempts as that would be a
waste of paper. This method has been found to work well.
:h3.Changing the default reference location markers
.rc 1 on
:p.The file named "GCPLOCS.DAT" contains the source data for these
marker locations. The file may be erased if not needed, because the
default location data is hard-coded inside GCP as well. The user may
use an ASCII source editor to make the changes. (eg. EDLIN, E3)
:p.The format of the data is as follows:
.in 5
:p.Each data line consists of
latitude, longitude, name (up to 19 characters for the name).
Latitude is specified as negative for South, longitude
negative for East.
Lines starting with * are comments. More than 48 locations
means extra locations will be ignored - less than 48 means remaining
defaults will be included at the end of the list.
Sorting of data into alphabetical order is the user's responsibility,
and may be unpredictable if less than 48 locations are specified.
The user is responsible for all data validity checking. Any invalid
values may (or may not) cause unpredictable results.
:p.
:xmp
The following is a sample line of source data from GCPLOCS.DAT:
.sp
-34.9,-138.6,Adelaide
:exmp
.in 0
.rc 1 off
:h2.Support from the author
.rc 1 on
:p.GCP has been created by the author on his own time and equipment
and it has been rather a taxing task at times, for several reasons:
:ul compact
:li.the author learnt C not long before starting this exercise
and is not a trained programmer
:li.the size of the print array in memory disallows the standard
interactive debuggers from being active while constructing the
print array - bugs occurring during this activity are time-consuming
to sort out
:li.a single test of 1 change to the print routine involves 20 minutes
elapsed time to verify the result
:li.printers use ribbons and paper which cost money - hi!!!
:eul
:p.However, the author will be happy to hear of any bugs and/or
suggestions and will attempt to cater for them in due course - the
meaning of "due course" may vary with time. IBM amateurs should
use GCP FORUM on the IBMARC disk managed by PERFUTIL at SJEVM5
to report bugs, suggestions or comments.
.rc 1 off
:h1.Reading GCP maps
:p.The maps produced by GCP are largely self-explanatory
when the concept of Great Circle Maps is understood. However, a
few items may need pointing out:
:ol
:li.the centre of the circle is marked with a small circle on
printed copy and a cross on the display.
:li.the north and south poles are denoted by crosses on both screen
and printed copy.
:li.some points will not be displayed or printed because of the
impossibility of solving the mathematics involved. These are either
at the centre of the circle, or at the point directly opposite
on the globe from the centre. This may lead to very small sections
of missing coastline in these circumstances. For a better
understanding of why sections are missing rather than just points,
please read the chapter "Program assumptions, limitations and methods".
:li.some numbered markers may not be printed for similar reasons to
above. These will be listed in the legend at the bottom of the
printed map. The only distinction between these and the other
points is that the "=" sign after the relevant
number in the legend will be omitted.
.rc 1 on
:li.radial markers (points on the display or small crosses on the
printed copy) are used to allow for easy alignment with the bearing
markers at the edge of the circle and to show distance from the
centre of the circle. The markers are spaced according to user selection,
or suppressed completely also at user option.
.rc 1 off
The markers represent double these distances when the long path
maps are included.
:li.on the long path maps, an extra inner circle is added to denote
the point of demarquation between long and short paths (ie. at
approximately 20,000Km).
:li.coastal points less than 5,000Km from the centre of the circle
will not be included in the long path section due to the inaccuracy
of the calculations, the high resolution needed in the
interpolations and probable lack of value of the information for
practical purposes.
:eol
.* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
:h1.Program assumptions, limitations and methods
:p.This release of the program is the
.rc 1 on
second
.rc 1 off
and has not undergone
rigorous testing. As time goes by, bugs may be found and better
algorithms may become clear etc.. The following is a discussion
of the current design of the program.
:h2.Accuracy of map data
:p.The data used to draw the GCP maps is based on taking points
on a map from a standard atlas (Mercator projection) and reading
latitude and longitude from the map. The coastlines are treated
as being approximated by a set of straight lines, and so the choice
of points was done so as to render the greatest validity to
this approach. The points selected were chosen so that they represent
end points of the lines making up the coastline. On average, points
were specified to about the nearest .5 degree of latitude or longitude.
There are about 1400 coastal co-ordinates included in the data.
:p.The continuity of coastline is provided by interpolation of the
data between these coded points. The first attempt used linear
interpolation of the latitudes and longitudes between each pair of
points and then treated the in between points the same way as the
end points in the calculations of distance and bearing.
.rc 1 on
The first actual
.rc 1 off
release changed this for performance reasons (with now proven
performance gains) so that the joining of points in the final map
is by treating the join as a spiral section from one point to the
next. This allowed for linear interpolation of distance and
bearing between 2 points, saving the calculation of distance
and bearing for all the in between points. This was an enormous
saving in processing time, as the distance and bearing mathematics
are very processor intensive. Having made the adjustment, no
significant change in the final result
(other than the speed with which it was produced)
was noted even in the finer resolution printed maps.
.rc 1 on
:p.In release 1.1, the following mathematical relationships
were exploited, since the joining of two points was done using
a constant angular increment:
.sp
:xmp
    sin(a+increment)=sin(a)*cos(increment)+cos(a)*sin(increment)

    cos(a+increment)=cos(a)*cos(increment)-sin(a)*sin(increment)
:exmp
.sp
:p.This added a few
multiplications to the process of calculating the position of
each interpolated point, but removed 1 or 2 trigonometric
calculations, with a more significant benefit to the non-80x87 users.
.rc 1 off
:h2.Completeness of map data
:p.Not all land masses have been included in the maps. All major
continental masses are included, but many island groups and some
large islands are excluded, for several reasons:
:ul
:li.the resolution of the CGA is not sufficient to distinguish
coastal lines in congested areas - this becomes very clear in
the islands north of Canada.
:li.the accuracy with which the co-ordinates could be read from
an atlas was not good enough
:li.small islands would still have to have several coastal line
end points defined, and it is these end points which use
the greatest amount of processing to plot
:li.the author got tired of reading co-ordinates from atlases (hi!!)
.rc 1 on
:p.The author however acknowledges the generous offers made by 1 or
2 amateurs to assist in this task should I decide to do something
with it.
.rc 1 off
:eul
:h2.Accuracy of calculations
:p.GCP performs many trigonometric and other floating-point
calculations. Without a maths co-processor, this leads to a very
slow program. GCP has its own SIN and COS functions. These work
by keeping (accurately) the SIN and COS of 0-360 degrees
in 1-degree steps and using linear interpolation for inbetween
angles. This approach was verified to provide sufficient accuracy
(worst case error was shown to be approx .003%) and a 2- to
3-fold improvement in performance.
:h2.Memory usage
:p.The program uses about
.rc 1 on
160K
.rc 1 off
of memory for non-print
functions, not including DOS/BIOS areas. When print is requested,
an array big enough to hold all print data is allocated in memory.
This is to allow for only 1 pass through the coastal data while
constructing the print data, with clear performance implications.
The print array is approximately 288K, as follows:
:ul compact
:li.1920 dots across each "logical" page, but the compiler expects
the "horizontal" dimension of a huge array to be a power of 2,
hence 2048 bytes per row of array
:li.1152 dots down each map
:li.1 byte for every 8 dots
:eul
:ul compact
:li.2048 * 1152 * 2 / 8 = 288K
:eul
:h2.Numbers on printed maps.
:p.The numbers on markers on the printed maps were included as
graphic figures onto the map. Their shapes were defined by the author
and do no more than serve their purpose.
:h2.Program usage issues
:p.This is
.rc 1 on
only the second
release of GCP and as such is still missing
some usability features. No checking is done to verify relevant
hardware is available for selected functions (other than for
sufficient memory to construct a print array in memory).
There may be other areas where verification of requests
could have been included.
.* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
.rc 1 off
:h1.Possible future enhancements
.rc 1 on
:p.There are several possible future enhancements for this program.
It is yet to be seen whether the usefulness of this program warrants
further development. However,
.rc 1 on
many amateurs have offered suggestions as to possible improvements.
I have yet to decide on the value of doing further work on GCP.
I believe further gains in usefulness may be harder to
produce for a given amount of work.
.rc 1 off
.* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
:backm
:appendix
:h1.Performance of map production on various PC's
:p.The table overleaf is to provide a small sample of PC environments
and the performance of map production measured in those
environments. It is provided to allow for the setting of
realistic expectations of performance of the program given its
mathematically intensive nature. It is not to compare PC's and is
not intended to be accurate. Measurements were made by other IBMers
on their own equipment and using stopwatch methods only.
.in 5
.rc 1 on
:p.Please note that these measurements were made with release 1.0
and, although some improvements were made in release 1.1, no
measurements are available for comparison.
.in 0
.rc 1 off
:p.In the table, the map marked with an "*"
was plotted centred on several different locations and the
time varied between 29 and 35 seconds depending on the location chosen. This
is consistent with the design of the program and such variations would be
expected in all other measurements in the table.
.pa
:xmp
 PC              Monitor  DOS Release Activity             Min Sec

 IBM PC1         CGA      PC-DOS 3.3  Screen drawing
                                       (short path only)    03:50
                                      Print construction
                                       (short path only)    10:45

 IBM PC1 + Maths CGA      PC-DOS 3.3  Screen drawing
 co-processor                          (short path only)    00:33*
                                       (with long path)     00:42
                                      Print construction
                                       (short path only)    01:55
                                       (with long path)     02:55
                                      Concurrent print +
                                       screen construction
                                       (short path only)    02:27

 IBM PS/2-50     VGA      PC-DOS 3.3  Screen drawing
                                       (short path only)    00:45
                                       (with long path)     00:50

 IBM PS/2-60     VGA      PC-DOS 3.3  Screen drawing
                                       (short path only)    00:35
                                       (with long path)     00:35

 Non-IBM 9.6MHz  MCGA +   MS-DOS 3.3  Screen drawing
 8086            analog                (short path only)    01:20
                 mono

 Non-IBM 9.6MHz  MCGA +   MS-DOS 3.3  Screen drawing
 8086 + 8087     analog                (short path only)    00:14
                 mono

 Non-IBM 12MHz   VGA      MS-DOS 3.3  Screen drawing
 AT clone                              (short path only)    00:29

 IBM PC-AT       EGA      PC-DOS 3.2  Screen drawing
                                       (short path only)    01:12
                                      Print construction
                                       (with long path)     04:38

 IBM PC-AT +     EGA      PC-DOS 3.2  Screen drawing
 80287                                 (short path only)    00:26
                                      Print construction
                                       (with long path)     01:40
:exmp
:egdoc
