ISPRS
SIPT
IGU
UCI
CIG
ACSG
Table of contents
Table des matières
Authors index
Index des auteurs
Search
Recherches
Exit
Sortir
DEVELOPMENT OF AN IKONOS COVERAGE PREDICTION APPLICATION
Captain Marc Rancourt, Kevin Pegler, M.Eng, Dr. David Coleman, and Dr. Ronald Pelot
Department of Geodesy and Geomatics Engineering
University of New Brunswick
Fredericton, N.B. Canada
Department of Industrial Engineering
Dalhousie University
Halifax, N.S. Canada
ABSTRACT
Satellite imagery of dynamic environments can only yield precise ground object positional information if temporally
accurate ground truthing occurs. Thus, detailed knowledge of satellite overpass characteristics permits ground truthing
activities to coincide with imagery acquisition, and also ensures that the deployment of such resources is done in an
efficient and cost effective manner. Although the determination of these characteristics is of relative ease for the agencies
which control the remote sensing platforms, the current reality of licensing is such that imagery providers are unwilling or
unable to guarantee the date/time of data acquisition.
Using orbital models and using orbital data publicly available, an imagery customer could determine the possible dates of
data acquisition of their area of interest. In fact, several software packages – ranging from open source to complete
commercial solutions – specialize in such predictive scenarios. Unfortunately, a survey of these packages reveals
shortcomings in filling the stated needs of the Marine Recreational Vessel Reconnaissance sub-project (part of a Geomatics
for Informed Decisions (GEOIDE) ) Network of Centres of Excellence research project). The main deficiency identified
was the inability to present spatial data which permits ground truth mission planning in a relatively low cost package.
In order to meet the specific requirements of this project, the senior author has undertaken development of an IKONOS-2
coverage prediction application within the Microsoft Visual Basic® development environment using Environmental
Systems Research Institute’s MapObjects™ software and open source code. In this paper, the authors will outline the
development process and implementation of the final product. After briefly describing the overall project requirements, the
paper will focus on development challenges and preliminary results.
1.
Introduction
As companies with operational high-resolution remote sensing platforms demonstrate financial viability, an increasing
number of such systems will continue to be deployed. Thus, the current generation of IKONOS-2 and QuickBird class
satellites are at the vanguard of the favourable impact on both the quantity and quality such competition entails. Not only
will Space Imaging Inc. (SII) and EarthWatch Inc. continue to provide data to potential users, but with nominal ground
resolutions of one metre for IKONOS-2 imagery [Space Imaging, 2002] and 61 centimetres for QuickBird imagery
[DigitalGlobe, 2001], such resolutions will undoubtedly improve and become available in the future. The unprecedented
availability of quality imagery has rendered possible new applications which simultaneously challenge existing technical
limitations. One such project, the Marine Recreational Vessel Reconnaissance (MRV Recon) project, is a Geomatics for
Informed Decisions (GEOIDE) sub-project that is intent on creating a working recreational vessel reconnaissance system
using civilian technology in support of Search and Rescue marine activity assessment [Pegler, 2001; Pelot, 2001].
While the main challenge of MRV Recon is to implement a sub-pixel detection strategy to detect and identify recreational
marine vessels, other constraints exist which impact the viability of such projects. In the past, publicly-funded Earth
imaging satellites such as Landsat provided the data at little cost to end users, coupled with a wealth of corollary
information [USGS, 2002]. Unfortunately, with a nominal 30 metre resolution, little positional information could be
extracted from the imagery. Current and planned privately-held remote sensing platforms however, can readily provide the
imagery necessary for such precise value-added positional applications. Thus, the advent of high-resolution imagery has
made projects such as MRV Recon possible, but corresponding need by corporations to generate steady revenues has also
Symposium on Geospatial Theory, Processing and Applications,
Symposium sur la théorie, les traitements et les applications des données Géospatiales, Ottawa 2002
made imagery acquisition an expensive proposition. In light of such increased expenditures, guarantees regarding data
suitability are rightly demanded.
The passive nature of IKONOS-2 complicates this determination, for use of such systems to determine the position of
highly dynamic objects requires close coordination between satellite data capture and ground truthing activities. Marine or
terrestrial activity does not cease for satellite overpasses, and even a few minutes difference between data collection and
ground truthing can lead to unrecoverable errors in positional accuracy. Indeed, an exact determination of the instant of
image capture and complementary temporally precise ground truthing are critical to the success of such projects. Therefore,
it is imperative that close coordination occurs between the ground truthing elements and data capture to ensure valid and
useful imagery.
1.2
Essential Need for a Planning Tool
Indiscriminate purchasing of vast swaths of imagery is no longer a viable option, nor a desirable situation, as little accurate
ground truthing could have occurred over such a large area. Therefore, an exact determination of imagery acquisition times
of the area of interest is required to permit coordination of ground truthing activities. Space Imaging Inc. (SII) does not
currently make any guarantees concerning dates or time of data capture, nor does it make available any tools for the
prediction of satellite coverages. With that in mind the user must calculate or interpolate the data. These restrictions permit
SII to guarantee delivery of clear imagery, as it does not release any imagery that has more than twenty percent cloud cover
over the area of interest [SII, 2001]. However, it is suspected that these restrictions are also the result of SII’s business
model, as fees increase rapidly for the delivery of higher precision products whose generation can only be guaranteed with
clear imagery.
SII does not provide any satellite positional parameters to users, as this would allow relatively low precision (and low cost)
products to be easily converted to higher precision products. Despite the fact that such techniques have been developed to
increase the precision of low cost IKONOS-2 imagery [Toutin and Cheng, 2000], in order for Space Imaging’s business
model to remain viable, it must maintain its current licensing policy. Therefore, there exists a clear conflict between the
imagery provided by SII and the data required to make a project such as MRV Recon a success. The requirement to
establish ground truth nearly simultaneously with satellite overpass, be it by direct observation or by the corollary use of
airborne sensors, generates a need for a planning tool that can predict coverages in order to minimize the costs associated
with ground truthing activities.
1. 1
Existing Planning Tools
Orbital mechanics is a mature science. Since launching and maintaining an artificial satellite is a costly process, satellite
tracking and position prediction is of great interest to governments, militaries and even commercial entities. While such
large institutions can justify the costs associated with the development and maintenance of satellite tracking tools, there also
exists a large community of amateur radio users and visual observation seekers which relies on such information for their
own use. Fortunately, well established channels exist for the dissemination of orbital information, and reference
implementations of public domain orbital model algorithms have led to the creation of a large number of software
packages. Such programs vary from entertaining (EarthView, [Walker, 2001]) to research grades (ImPredict, [Wu, Brewer
and Parker, 2001]), and generally specialize in satellite tracking (WXtrack, [Taylor, 2001]), telescope/antenna control
(Satellite Tracker, [Boshart, 1999]), and visual observation prediction (PocketSat, [Berry, 2001]).
During the period May/June 2001, 55 such applications were catalogued and tested for eventual integration with MRV
Recon. Targeted at various platforms, and ranging from applications which generated reams of tabular data to those which
were visually-pleasing, but ultimately uninformative [Rancourt, 2002]. Generally the applications catalogued either lacked
the temporal resolution required by MRV Recon, or failed to present the data in a manner easily accessible and understood
by the user. Furthermore, the main limitation proved to be a failure to accurately model the IKONOS-2 agile spacecraft,
with in-track and cross-track pointing. Of catalogued applications, Analytical Graphics Incorporated’s Satellite Tool Kit
(STK) met all requirements but at a price commensurate with its quality [AGI, 2002], was not suitable for integration into
MRV Recon.
1. 2
Objectives
In order to permit reasonably accurate planning, the critical components were adequate temporal resolution and accurate
platform modelling. Over the course of several discussions/interviews with the primary user, it also became apparent that
successful integration also rested with the ability of the planning tool to be easy to use and accomplish its task at minimal
expense. As previously mentioned, within the constraints of identified user requirements, existing tools proved either
inadequate or overly costly. To permit MRV Recon to coordinate its ground truthing activities with satellite overpasses, the
design and implementation of an application focused on the calculation and display of IKONOS-2 coverages was initiated.
2.
Development Process
In order to complement the ongoing MRV Recon project process, a software development methodology based on defining
and codifying exact and precise user requirements at the start of the project could not realistically be adopted. Thus
traditional waterfall and spiral software development methods were bypassed in favour of a Rapid Application
Development (RAD) methodology [McConnell, 1996]. Such a methodology permitted the relatively project agnostic
decisions to be made, such as those relating to orbital information sources/models and development platform, while still
tailoring the tool specifically to MRV Recon by concurrent development with the project. Adoption of existing standards
and use of third-party components ensured that the implementation would maintain its utility outside the confines of the
MRV Recon project.
2.1
Orbital Information
All artificial satellites, or a significant subset of them, are continuously tracked by several different organizations, each with
a vested interest in keeping accurate records concerning orbital characteristics and associated ground tracks, be it for
military, communications, research or collision avoidance purposes. Large commercial satellite operators often maintain a
tracking capability for platforms under their control, as do the various launching agencies and operating authorities, such as
the European Space Agency’s Space Operations Centre (ESOC) [ESOC, 2001]. Due to the expensive and extensive global
resources required to maintain a continuous tracking network, most of the tracking of space borne objects is carried out by
military organizations, such as the United States’ Space Surveillance Network (SSN) [USSPACECOM, 2002]. One of the
only agencies to make the data available publicly on the Internet in the form of a Space Catalogue is the North American
Aerospace Defense Command (NORAD) [USSPACECOM, 2001], in the form of NORAD Two-Line Element (TLE) files
[OIG, 2001], which provide mean Keplerian elements for tracked satellites (less United States military satellites).
While the SSN continuously tracks the satellites, NORAD only updates the elements as required. The TLEs provide each
satellite’s inclination – i, right ascension of the ascending node – Ω, eccentricity – e, argument of perigee – ω, mean
anomaly – Mo at epoch to, and mean motion – n and generally have no more than five days between updates [Kelso, 2002].
This information is then used to derived the Keplerian elements traditionally used to define the orbit (semi-major axis and
eccentric anomaly), and can thus be used to track satellites and predict their locations.
2.2
Orbital Model
Satellite position prediction is not only dependent on the availability of data, but also on the propagation algorithm chosen.
With remote sensing applications, determining the exact position of the satellite at the time of measurement of an image
element permits the corresponding ground location of the image element to be determined with commensurate accuracy
[Dilley and Elsum, 1994]. Therefore, precisely determining satellite positions using mean Keplerian elements requires the
use of one of the multitude of orbital models which exist, each with varying applications and precision levels. Those
designed for use with the NORAD TLEs were outlined by Hoots and Roehrich [1980], in their seminal report entitled:
“SpaceTrack Report No. 3: Models for Propagation of NORAD Element Sets”. The Simplified General Perturbations
(SGP), SGP Version 4 (SGP4) and SGP Version 8 (SGP8) orbital models differ mainly by the inclusion of a higher number
of perturbation correction terms. All are specifically targeted to near-Earth satellites (which NORAD defines as those
satellites having an orbital period < 255 minutes [Hoots and Roehrich, 1980]), while the Simplified Deep Space General
Perturbations models (SDP4 and SDP8) are used for satellites in ‘deep space’, i.e. with orbital periods > 255 minutes. The
mean Keplerian elements provided by NORAD are generated using the SGP4 model, and thus are intended to be used
exclusively with the SGP4/SDP4 model. Fortunately, the majority of Earth imaging satellites have orbital periods of
approximately 90 minutes, and thus SDP4 is the most appropriate manner in which to model the IKONOS-2 orbit. Whereas
the use of SGP4 versus SGP8 seems to limit accuracy, SGP4 has demonstrated accuracy in benchmarking tests on the order
of 0.1 degrees in both azimuth and elevation [Kelso, 1996], even with TLE data several days old. However, a note of
caution is warranted, for Alfriend and Paik [2000] have shown that the SDP4 accuracy decreases rapidly when attempting
long term predictions (> 30 days). In our case, NORAD TLEs and SGP4, combined with reasonable temporal search
windows provide adequately accurate predictions.
2.3
Data Display
Having determined the source of orbital data, and the applicable model, a method of displaying the predicted positions was
required. Tabular data, although simple to generate, does not provide the information in an easily understandable format.
Options for displaying the generated data were therefore examined, and consisted of implementing either a static graphical
representation, a display with minimal functionality, a somewhat interactive display using an Internet Map Server (IMS), or
a fully configurable display using an application development framework as the core of the application. The first option,
which is favoured by most catalogued applications, is relatively simple to implement. Unfortunately a global map on most
computer monitors offers a small scale, with correspondingly little useable information presented. The second option,
which essentially consists of developing/implementing a rudimentary Geographic Information System (GIS) was not
seriously considered, for reasons which are obvious. The use of an IMS was an intriguing proposition, but as the primary
user had not identified multiple-simultaneous usage as an essential requirement, the additional overhead required by such
an implementation was deemed unnecessary. Therefore, implementing the application either as an extension to an existing
GIS application, or using a some GIS-enabled component was examined closely.
GEOIDE Project ENV#60, whose GIS needs are met mainly by MapInfo’s MapInfo™, and the University of New
Brunswick’s (UNB) Geodesy and Geomatics Engineering (GGE) Department’s standardization on Environmental Systems
Research Institute, Inc.’s (ESRI) products produced some question as to which framework offered the best solution.
However, as the primary user of the application was intended to be MRV Recon, and deployment of the planning tool into
the UNB GGE environment was anticipated, targeting the ESRI product line was deemed beneficial. However, at the time
the design process was initiated, ESRI’s ArcGIS™ 8 had not yet been deployed within the GGE Department. This ruled out
the ArcObjects™ architecture, but left ArcView™ 3.2 or MapObjects™ as contenders. ArcView could provide high quality
infrastructure within its development framework, but the closed nature of the Avenue programming language, and its
planned obsolescence through eventual replacement by ArcObjects, meant ArcView was not the most appropriate
development target. MapObjects, an ActiveX control marketed as a lightweight GIS core, offered a robust userconfigurable interface ideally suited to this type of development work. As the MRV Recon satellite prediction application is
by far not a GIS in the traditional sense, the map display requirements of the implementation could easily be met by
MapObjects.
2.4
Development Platform
The NORAD TLE text files are essentially platform independent, as are the algorithms implementing the SGP/SDP family
of orbital models. While a reference implementation exists in FORTRAN [Hoots and Roehrich, 1980], the algorithms can
be implemented in any programming language, be it Pascal, C, C++, or Java. Since the release of the reference
implementations into the public domain in 1988, many authors have re-coded them in several different languages, with
much of the available source code considered mature (error-free). Within the context of this project, the use of such a stable
code base would provide immediate benefits, as the pitfalls of re-implementation could be avoided. However, as the
majority of open source development work is done on and for the Linux platform, the majority of such re-implementations
exist in C, and target the *nix platforms. PREDICT, one of the few implementations that is dually implemented in Linux
and DOS [Magliacane, 2002], is hosted by the Radio Amateur Satellite Corporation (AMSAT), and as a mature SGP4
implementation serves as the core of several tracking and prediction applications. Relatively platform agnostic, some of the
C code is tied to particular versions or types of platforms, through the use of specific code constructs or calls.
Whereas the development of the MRV Recon prediction application would have most likely proven simpler on the Linux
platform, having determined that MapObjects would serve as the basis of the cartographic display imposed some
constraints. As an ActiveX component, MapObjects requires a Microsoft® Windows® 32-bit development environment to
support it. Fortunately, as the UNB GGE Department is standardized on the Windows operating system, this does not
necessarily impose an undue burden. Several development environments are MapObjects-compatible, among them are
Borland’s C++ Builder® and Delphi 5™ and Microsoft’s Visual Studio™ 6. While any of the MapObjects-supported
languages could have been used, licensing at UNB is for Microsoft Visual Studio™ only, which left with a choice between
Visual Basic and Visual C++.
The RAD implementation methodology chosen favours a Visual Basic approach, as rapid graphical user interface (GUI)
development can be accomplished easily. However, Visual Basic is not well suited to heavy calculation loads (as required
by SGP4), the PREDICT C code would be integrated into the application as a Dynamic-Link Library (DLL). It was hoped
that the choice of Visual Basic could accelerate the development of a usable application, founded on the basis of
MapObjects and PREDICT.
3.
Preliminary Results
Application design refinement and early RAD iterations revealed some issues which required particular attention. One such
issue involves the use of coordinate systems within orbital models. As the SGP4 model algorithms are designed to return
satellite position in an Earth-Centered Inertial (ECI) coordinate system, calculation of sub-satellite points required
transformation to an Earth-Centered Earth-Fixed (ECEF) system prior to being of use for display purposes. In our case, the
World Geodetic System 84 (WGS84) ECEF was chosen as the baseline display coordinate system, mainly for its ease of
use with Global Positioning System (GPS) data. While such simple mathematical transformations could be rapidly
accomplished in the DLL, the display of disparate coordinate systems in MapObjects proved problematic, for despite the
multitude of Geographic and Projection coordinate systems supported, implementation is somewhat counter-intuitive.
The application’s main effort is therefore concentrated on sequentially calculating the satellite’s position, its sub-satellite
point, and finally the predicted coverage based on a buffer around the sub-satellite point. The resultant polygons are then
projected onto the display area, which consists of any of the MapObjects-supported data sets. The user therefore controls
the selection of satellites tracked (up to a maximum of three), their associated sensor capabilities and the period of time
over which to track them. The results, such as those shown in Figure 1, can be displayed at any desired resolution, and with
the option of displaying only the overpass with the highest elevation.
Specified Data
TLE Date 26 February 2002
Satellite
IKONOS-2
Tracked
Dates
1 March 2002
Tracked
00:00 – 23:59
Map
World Shapefile
Display
Best elevation only
Figure 1: User Interface
In order to accurately predict the position of any satellite in near-Earth orbit, large volumes of data must be generated and
analysed. In the case of IKONOS-2, which has an orbital period of 98 minutes, determining the sub-satellite point once per
minute for one day will only generate 3600 points, but with very low precision (one position calculation per 420 km
traveled). Determining position once per second will generate 86 400 points, with a corresponding precision of
approximately 7 km. With a claimed revisit rate of 3 days [SII, 2002], IKONOS-2 nadir are much more infrequent, and
therefore, a typical temporal search window of two weeks requires 1 209 600 position calculations. Increasing resolution to
measurements every ½ or ¼ second for higher precision would generate 2 to 4 times more data. Even though some
algorithms offer a higher temporal resolution [Wu, Brewer and Palmer, 2001], such increases always come at a cost of
increased processing time. Therefore, acceptable measurement resolution must be at the second-level, if only to maintain
reasonable processing times.
The satellite’s position is calculated by successive calls from the Visual Basic application to the C DLL. This algorithm
performed as expected, exhibiting a roughly linear relationship between the processing time and the number of sub-satellite
points to be calculated, which is shown in Figure 2. Although testing did not proceed past the calculation of 30 days worth
of data on the test machine (Pentium III 800Mhz, 512MB RAM), it is presumed that the only limitation to permissible
calculations is the amount of available memory.
45:00
40:00
35:00
Minutes
30:00
25:00
20:00
15:00
10:00
05:00
2
59
2
00
0
00
0
2
16
0
00
0
1
72
8
00
0
1
29
6
00
0
86
4
43
2
00
0
00:00
Number of Sub-Satellite Points
Figure 2: Processing Time Required to Calculate Sub-Satellite Points
Despite these encouraging results, the actual volume of calculations to be performed did not prove to be the largest
stumbling block. MapObjects was selected as the main display interface due to its GIS capabilities, which includes spatial
functions (point buffering), in the belief that such a capability could be useful in modelling remote sensing imagery swaths.
However, further benchmarking revealed that the buffering operation in MapObjects, although similarly of linear order,
was much slower than anticipated. As Figure 3 demonstrates, buffering of even a limited number of points (< one day’s
satellite sub-points) requires twice as much time as the calculations. What is not clearly shown in the Figure below is the
severe ‘thrashing’ which occurred on the test system when more than 4 days worth of points (345 600) are buffered, which
added several hours to the calculation completion times.
45
40
35
Minutes
30
25
20
15
10
05
2
59
2
00
00
0
2
16
8
72
1
0
0
0
00
0
1
29
6
00
00
0
86
4
43
2
00
0
00
Number of Sub-Satellite Points
Figure 3: Processing Time Required to Calculate Swaths
While slow point buffering created an application bottleneck, it was assumed that the display of such buffers would be
trivial, and thus such delays could be tolerated. However, rendering such a large volume of data in MapObjects proved to
be the largest of all problems. Notwithstanding the upper bound on the number of objects which could be displayed on the
Tracking Layer (a Visual Basic integer value, or 32 767 objects), which could safely be worked around, informational
clarity became an issue. Displaying calculated sub-satellite point data at a temporal resolution of one second, with
corresponding overlapping imagery swaths, reduced the display to an unintelligible dense tangle of overlapping polygons.
Reducing the number of displayed elements, through the union of overlapping swaths became both a priority and a
problem. As Figure 4 shows, despite a similar linear relationship as the previous calculations, simply creating the union of
one days’ worth of points took an inordinate amount of time. As this situation was clearly unacceptable, optimization of the
polygon union loop was begun, and is ongoing.
24
21
18
Hours
15
12
9
6
3
00
0
2
Number of Polygons Unioned
59
2
00
0
2
16
0
00
0
1
72
8
00
0
1
29
6
00
0
86
4
43
2
00
0
0
Figure 4: Processing Time Required to Union Swaths
3.1
Limitations
Understanding and exploiting the intricacies of Visual Basic, MapObjects, and the Windows Application Programming
Interface, all within the 180 days scheduled for the RAD iterations proved that development projects based entirely on the
efforts of a one-person design/development team are prone to frequent and serious setbacks. In order to translate
PREDICT’s C code into a functional DLL required a through understanding of Unix time representation and the open
source DJPP and LCC compilers (required for their Unix-like libraries), despite the implied DOS nature of the
implementation. Furthermore, a mixed language development environment rapidly devolved from being an asset into a
severe limitation, as data transfer between the C DLL and the Visual Basic application required carefully-controlled, welldefined, and restrictive interfaces. Programming issues of this nature, coupled with the disproportionate amount of time
required to debug the GUI have meant that the 1 824 lines of code written have still not reached 100% code-coverage test
status.
3. 2
Conclusions
In attempting to implement an effective planning tool to assist the MRV Recon project to focus its ground truthing
activities with regards to IKONOS-2 overpasses, the development of an application was undertaken. Through the use of
RAD methodology, the serious technical limitations imposed by third party components were addressed in a reasonable
time frame. Despite its slow processing speed, the major user requirements were met, and the tool is available for use
within the MRV Recon project. Although currently limited in its appeal to a broader public, additional developmental work
is being undertaken with the intention to release the application in the near future.
Acknowledgements
Government of Canada, specifically the Department of National Defence, who granted me the opportunity to pursue postgraduate studies.
Support graciously provided by the Geomatics for Informed Decisions (GEOIDE) Network of Centres of Excellence
program.
References
Alfriend K T, Paik S (2000). "Comparison of the US and Russian Algorithms for Catalog Maintenance for Geosynchronous
Satellites," presented at the 4th US/Russian Space Surveillance Workshop, US Naval Observatory, Washington, DC, Oct.
23-37, 2000. [Online], Available:
http://jungfrau.tamu.edu/~html/alfriend/alfriendpublications/GeosynchronousSatellites/Alfriend-WorkshopPaper.pdf
[26 Feb, 2002].
Analytical Graphics, Inc. (2002) Products Pricing & Support. [Online], Available:
http://www.stk.com/products/pricing.cfm [27 Feb, 2002].
Berry J (2001). PocketSat. [Online], Available: http://www.bigfattail.com/pocketsat/index.html [14 March, 2002].
Boshart B (1999). HeavenScape – Satellite Tracker. [Online], Available: http://sattracker.hypermart.net/ [14 March, 2002].
DigitalGlobe (2001) QuickBird Specifications. [Online], Available: http://www.digitalglobe.com/?goto=products/quickbird
[26 Feb, 2002].
Dilley A C, Elsum C C (1994). “Improved AVHRR Data Navigation Using Automated Land Feature Recognition to
Correct a Satellite Orbital Model”. CSIRO Division of Atmospheric Research Technical Paper No. 34, Commonwealth
Scientific and Industrial Research Organisation, Collingwood, Australia.
ESOC (European Space Operations Centre) (2001). Welcome to the XMM Flight Dynamics Operational Orbit
Determination Website. [Online], Available: http://msss.esoc.esa.de/xmm/welcome.html. [14 June 2001].
Hoots F R, Roehrich R L (1980). “SPACETRACK REPORT NO.3. – Models for Propagation of NORAD Element Sets”.
[Online], Available: http://celestrak.com/NORAD/documentation/spacetrk.pdf [14 June 2001].
Kelso T S (1996). CelesTrak: “Real-world Benchmarking”. [Online], Available:
http://www.celestrak.com/columns/v03n02/ [26 Feb, 2002].
Kelso TS (2002). Celestrak WWW: Master TLE Index [Online], Available:
http://celestrak.com/NORAD/elements/master.shtml [28 Feb, 2002].
McConnell S (1996). Rapid Development – Taming Wild Software Schedules. Microsoft Press, Redmond, Washington,
U.S.A.
Magliacane J A (2002). PREDICT – A Satellite Tracking/Orbital Prediction Program. [Online], Available:
http://www.qsl.net/kd2bd/predict.html [26 Feb 2002].
Misra P, Enge P (2001). Global Positioning System – Signals, Measurements, and Performance. Ganga-Jamuna Press,
Lincoln, Massachusetts.
National Aeronautics and Space Administration Orbital Information Group (NASA OIG) (2001). NASA/GSFC Orbital
Information Group Website - OIG welcome. [Online], Available: http://oig1.gsfc.nasa.gov/scripts/foxweb.exe/app01 [17
June 2001].
Pegler K (2001) A Reconnaissance System for Small Recreational Vessels Using High Resolution Remote Sensing
Imagery in Support of Search and Rescue Marine Activity Assessment. Ph.D. thesis proposal, Department of Geodesy and
Geomatics Engineering, University of New Brunswick, Fredericton, N.B., Canada.
Pelot R (2001). Marine Activity Geomatics and Risk Analysis in the Coastal Zone, Project ENV#60, GEOIDE Network of
Centres of Excellence. [Online], Available: http://www.geoide.ulaval.ca/Public/an/ProgrammesRD/Projets/Project60.html
[14 March, 2002].
Rancourt M (2002) Development of an IKONOS Coverage Prediction Application. Unpublished M.Eng. Report,
Department of Geodesy and Geomatics Engineering, University of New Brunswick, Fredericton, N.B., Canada.
Space Imaging Inc. (2001) Carterra™ geo FAQ. [Online], Available:
http://www.spaceimaging.com/carterra/geo/prodinfo/faq.htm#clouds [11 June 2001].
Space Imaging Inc. (2002) Space Imaging – IKONOS technical specs. [Online], Available:
http://www.spaceimaging.com/aboutus/satellites/IKONOS/ikonos.html#stats [26 Feb, 2002].
Taylor D (2001). WXtrack [Online], Available: http://www.david-taylor.pwp.blueyonder.co.uk/software/wxtrack.htm [14
March, 2002].
Toutin T, Cheng P (2000) “Demystification of IKONOS!” Earth Observation Magazine, Vol. 9, No. 7, pp. 17 – 21.
United States Geological Survey (2002). USGS/Eros Data Center Landsat 7 Website [Online], Available:
http://landsat7.usgs.gov/software/index.html [28 Feb, 2002].
United States Space Command (USSPACECOM) (2002). U. S. Space Command Fact Sheet. [Online], Available:
http://www.spacecom.af.mil/usspacecom/space.htm. [26 Feb, 2002].
United States Space Command (USSPACECOM) (2001). Satellite/Space Catalogue. [Online], Available:
http://www.spacecom.af.mil/norad/satcat.htm [18 June 2001].
Walker J (2001). View from satellite [Online], Available: http://www.fourmilab.ch/earthview/satellite.html. [14 March,
2002].
Wu S F, Brewer A, Palmer P L (2001). ImPredict: a Fast Image Predict Software and Its Application in the SSTL off-axis
Image Scheduling System. Paper presented at the 15th AIAA/USU Conference on Small Satellites [Online], Available:
http://www.aria.cec.wustl.edu/SSC01/papers/8a-1.pdf [26 Feb 2002].