CORS AND OPUS

FOR ENGINEERS
Tools for Surveying and
Mapping Applications

SPONSORED BY

The Geomatics Division of

the American Society of Civil Engineers

The National Geodetic Survey

EDITED BY

Tomás Soler, Ph.D.

Published by the American Society of Civil Engineers

Cataloging-in-Publication data on file with Library of Congress

Published by American Society of Civil Engineers

1801 Alexander Bell Drive
Reston, Virginia 20191
www.asce.org/pubs

Any statements expressed in these materials are those of the individual authors and do not necessarily represent the
views of ASCE, which takes no responsibility for any statement made herein. No reference made in this publication
to any specific method, product, process, or service constitutes or implies an endorsement, recommendation, or
warranty thereof by ASCE. The materials are for general information only and do not represent a standard of ASCE,
nor are they intended as a reference in purchase specifications, contracts, regulations, statutes, or any other legal
document.

ASCE makes no representation or warranty of any kind, whether express or implied, concerning the accuracy,
completeness, suitability, or utility of any information, apparatus, product, or process discussed in this publication,
and assumes no liability therefor. This information should not be used without first securing competent advice with
respect to its suitability for any general or specific application. Anyone utilizing this information assumes all
liability arising from such use, including but not limited to infringement of any patent or patents.

ASCE and American Society of Civil Engineers—Registered in U.S. Patent and Trademark Office.

Photocopies and permissions. Permission to photocopy or reproduce material from ASCE publications can be
obtained by sending an e-mail to permissions@asce.org or by locating a title in ASCE’s online database
(http://cedb.asce.org) and using the “Permission to Reuse” link. Bulk reprints. Information regarding reprints of 100
or more copies is available at http://www.asce.org/reprints.

“Accuracy of OPUS Solutions for 1- to 4-h Observing Sessions” and “Accuracy Assessment of the National
Geodetic Survey’s OPUS-RS Utility” were originally published in GPS Solutions, as described on the first page of
each paper. Both papers appear with kind permission of Springer Science+Business Media.

“Continuously Operating Reference Station (CORS),” “Statistics of Range of a Set of Normally Distributed
Numbers,” “Heuristic Weighting and Data Conditioning in the National Geodetic Survey Rapid Static GPS
Software,” “Constraining Network Adjustments to OPUS-RS Coordinate Observations,” “Efficiency and Reliability
of Ambiguity Resolution in Network-Based Real-Time Kinematic GPS,” “Network Calibration for Unfavorable
Reference-Rover Geometry in Network-Based RTK,” and “Transforming Positions and Velocities between the
International Terrestrial Reference Frame of 2000 and North American Datum of 1983” were originally published in
ASCE’s Journal of Surveying Engineering, as described on the first page of each paper.

Front cover: artist’s rendering of a GPS Block IIR-M satellite in orbit courtesy of the U.S. National Executive
Committee for Space-Based Positioning, Navigation, and Timing; back cover: photograph of CORS reference
station LCRH courtesy of the U.S. National Oceanic and Atmospheric Administration.

Copyright © 2011 by the American Society of Civil Engineers.

All Rights Reserved.
ISBN 978-0-7844-1164-3
Manufactured in the United States of America.

18 17 16 15 14 13 12 11 12345
 Contents

Foreword.............................................................................................................................v
Juliana P. Blackwell
Introduction...................................................................................................................... vi
Tomás Soler
1 Continuously Operating Reference Station (CORS): History,
Applications, and Future Enhancements...................................................................1
Richard A. Snay and Tomás Soler
2 Criteria for Establishing and Operating a Continuously
Operating Reference Station (CORS)......................................................................11
Giovanni Sella, Mike Cline, and Don Haw
3 The “Online Positioning User Service” Suite (OPUS-S,
OPUS-RS, OPUS-DB)................................................................................................17
Tomás Soler, Neil D. Weston, and Richard H. Foote
4 A Synopsis of the IGS Orbits Used in OPUS...........................................................27
Jake Griffiths, Jim Ray, and Neil D. Weston
5 Accuracy of OPUS Solutions for 1- to 4-h Observing Sessions .............................30
T. Soler, P. Michalak, N. D. Weston, R. A. Snay, and R. H. Foote
6 Statistics of Range of a Set of Normally Distributed Numbers .............................41
Charles R. Schwarz
7 Basic TEQC Instructions for OPUS Users ..............................................................46
Richard H. Foote
8 OPUS-S Extended Data.............................................................................................51
Peter Lazio
9 Editing RINEX Files to Fix a Poor OPUS Run.......................................................62
Peter Lazio
10 Heuristic Weighting and Data Conditioning in the National
Geodetic Survey Rapid Static GPS Software ..........................................................67
Charles R. Schwarz
11 Accuracy Assessment of the National Geodetic Survey’s
OPUS-RS Utility.........................................................................................................74
Charles R. Schwarz, Richard A. Snay, and Tomás Soler

iii
12 Accuracy of Rapid Static Online Positioning User Service
(OPUS-RS) Revisited .................................................................................................88
Tomás Soler, Richard A. Snay, Charles R. Schwarz, and Kevin K. Choi
13 Understanding Error Messages Generated by the Rapid Static
Online Positioning User Service (OPUS-RS).........................................................100
Kevin K. Choi
14 Editing RINEX Observation Files for OPUS-RS..................................................107
Peter Lazio
15 GPS Vectors, OPUS-S and OPUS-RS Observations in a
Unified Adjustment..................................................................................................119
Peter Lazio
16 Constraining Network Adjustments to OPUS-RS
Coordinate Observations.........................................................................................125
Peter Lazio
17 Efficiency and Reliability of Ambiguity Resolution in Network-
Based Real-Time Kinematic GPS...........................................................................133
Dorota A. Grejner-Brzezinska, Israel Kashani, Pawel Wielgosz, Dru A. Smith,
Paul S. J. Spencer, Douglas S. Robertson, and Gerald L. Mader
18 Network Calibration for Unfavorable Reference-Rover Geometry
in Network-Based RTK: Ohio CORS Case Study ................................................143
Dorota A. Grejner-Brzezinska, Niyazi Arslan, Pawel Wielgosz, and
Chang-Ki Hong
19 Transforming Positions and Velocities between the
International Terrestrial Reference Frame of 2000 and
North American Datum of 1983 .............................................................................154
Tomás Soler and Richard A. Snay
20 Horizontal Time-Dependent Positioning Software: User’s Guide ......................161
Richard A. Snay
21 Best Methods for High Accuracy Real Time GNSS Positioning
from a Single Reference Station .............................................................................173
William Henning
22 Transforming OPUS Results to WGS84................................................................181
Tomás Soler and Richard A. Snay

Index................................................................................................................................185

iv
 Foreword
Juliana P. Blackwell, Director
National Geodetic Survey
The history of the National Geodetic Survey (NGS), an
office of the National Oceanic and Atmospheric
Administration (NOAA), spans more than 200 years. On
February 10, 1807, Congress endorsed the scientific vision of
President Thomas Jefferson by authorizing him to establish a
Federal agency to survey the coasts of the United States with
the following words:
“Be it enacted by the Senate and the House of
Representatives of the United States of America in Congress
assembled, That the President of the United States shall be,
and he is hereby authorized and requested, to cause a survey
to be taken off the coasts of the United States, in which shall
be designated the islands and shoals, with the roads or places
of anchorage, within twenty leagues of any part of the shores
of the United States; and also the respective courses and
distances between the principal capes, or head lands, together
with such other matters as he may deem proper for
completing an accurate chart of every part of the coasts
within the extent aforesaid.”
In 1878, the mission to survey the coasts was expanded and
the Coast and Geodetic Survey was created with the mission
to establish accurate geodetic control throughout the entire
United States and its territories. Since 1970, NGS has served
v
as the current link in the chain of scientific organizations tasked
with providing the most accurate geodetic framework for
supporting positioning activities conducted in our Nation.
In the mid-1980’s, Global Positioning System (GPS)
technology started to become operational in conjunction with
advancements in digital processing. Soon thereafter, NGS
seized this opportunity and pioneered the use of these modern
tools to accomplish its mission far more effectively than was
previously possible. In particular, NGS scientists implemented
two major innovations: the Continuously Operating Reference
Station (CORS) network, and a Web-based utility called the
Online Positioning Users Service (OPUS), both of them now
well established. These innovations have transformed the way
GPS surveying has been practiced in the United States for more
than a decade.
This Monograph is a collection of articles describing a wide
range of applications associated with CORS and OPUS. NGS
is sponsoring this Monograph with the goal of sharing with the
scientific community detailed information about CORS and
OPUS. Most articles were written by NGS staff; others by
investigators under contract with NGS. Still other articles were
written by independent professionals who have extensively
evaluated these innovative services. To all of the authors we
extend our sincere thanks for researching and expanding the
knowledge of NGS’ GPS-based services to the geospatial
community. The legacy of scientific exploration and innova-
tion envisioned by President Jefferson continues.
 Introduction
Tomás Soler, Ph.D., Chief Editor
Journal of Surveying Engineering
National Geodetic Survey
The broadening universe of Global Navigation Satellite
Systems (GNSS) has radically changed the way we
comprehend and practice surveying today. The Global
Positioning System (GPS) was the first GNSS constellation
put in place and still remains the most popular
georeferencing tool among a plethora of users because of its
useful practicality. Nobody questions anymore the
advancements that GPS has brought upon many scientific
disciplines in general, and all aspects of surveying and
mapping in particular. Undoubtedly, GPS surveying has
replaced traditional surveying in a variety of engineering,
topographic and mapping endeavors. The advantages of
reduced observation times in the field, automated data
processing, and the superb accuracy of the derived
coordinates are factors difficult to disregard lightly. Recently,
even the prices of required equipment and supplementary
software have been drastically reduced, ensuring the
continued dominance of GNSS technology into the future.
This Monograph originated around the theme of GPS
precise positioning. A source of inspiration has been the
work and numerous studies on this subject conducted at
NOAA’s National Geodetic Survey (NGS), eager to
accomplish its mission to define, maintain, and provide
access to the U.S. National Spatial Reference System. NGS
soon recognized the opportunity that GPS offered and
embarked on the arduous process of replacing its classical
observational methodologies while attempting to educate the
land surveying community of the advantages of performing
GPS positioning. The Continuously Operating Reference
Station (CORS) concept was the first to be developed, soon
followed by the Web-based utility called the Online User
vi
Positioning Service (OPUS) which provides positional
coordinates in each of two popular reference frames: the
International Terrestrial Reference Frame of 2000 (ITRF2000)
and the CORS96 realization of the North American Datum of
1983, (NAD 83 (CORS96)).
The Monograph comprises a collection of articles – about
half of them previously published in the ASCE’s Journal of
Surveying Engineering – describing various aspects associated
with CORS and OPUS applications. Thirteen additional
articles are published here for the first time. The ordering of
the papers does not follow a strict chronology although they are
sequentially organized with respect to three major topics:
CORS, OPUS-S (static), and OPUS-RS (rapid static). The
primary intent of this compilation is to provide detailed
information to the civil engineering community at large, in a
single, comprehensive publication, about new GPS technical
procedures available to professionals working in the field of
surveying engineering. Assembled as a unit, these
contributions represent the latest available literature describing
advanced methods for obtaining accurate positional coordinates
referred to modern sophisticated spatial reference frames such
as ITRF2000 and NAD 83 (CORS96).
The articles presented herein describe both theoretical to
empirical research. It is our hope that the articles of this
Monograph help develop an understanding of these current
GPS applications among academic researchers as well as
among professional engineers working on surveying, GIS, and
mapping applications.
I thank all contributors and the ASCE Publications
Department staff for providing the opportunity to produce this
Monograph with the hope that its dissemination may
significantly contribute to the knowledge of accurate GPS
positioning. Finally, special appreciation goes to the ASCE
Geomatics Division EXCOM members who debated and
approved the idea of publishing this Monograph.
 1
Continuously Operating Reference Station „CORS…:
History, Applications, and Future Enhancements
Richard A. Snay1 and Tomás Soler, M.ASCE2

Abstract: The National Oceanic and Atmospheric Administration’s National Geodetic Survey 共NGS兲 manages the National Continuously
Operating Reference Station 共CORS兲 system that comprises a network of over 1,350 sites, each containing a geodetic quality Global
Navigation Satellite System receiver. This network is currently growing at a rate of about 15 sites per month. NGS collects, processes, and
distributes data from these sites in support of high-accuracy three-dimensional positioning activities throughout the United States, its
territories, and a few foreign countries. CORS data are also used by geophysicists, meteorologists, atmospheric and ionospheric scientists,
and others in support of a wide variety of applications. This paper addresses the history of the CORS network, some of its applications,
and plans for enhancing it within the next few years.
DOI: 10.1061/共ASCE兲0733-9453共2008兲134:4共95兲
CE Database subject headings: Satellites; Geodetic surveys; History.

Historical Introduction niques provided positional coordinates with relative accuracies of

The history of the Continuously Operating Reference Stations
共CORS兲 system is intimately connected to the National Oceanic
and Atmospheric Administration’s 共NOAA’s兲 National Geodetic
Survey 共NGS兲 and this agency’s mission to define, maintain, and
provide access to the U.S. National Spatial Reference System
共NSRS兲. The NSRS constitutes the official system of the civilian
government for enabling a user to determine geodetic latitude,
longitude and height, plus orthometric height, geopotential, accel-
eration of gravity, and deflection of the vertical at any point
within the United States and its territories. The NSRS contains
information about its orientation and scale relative to international
reference frames, as well as the precise orbits of all satellites used
in defining or accessing the NSRS. Last, the NSRS also contains
all necessary information to describe how all of these quantities
change over time. The NSRS is crucial for meeting our nation’s
economic, social, and environmental needs.
NGS recognized the potential contributions of the Global Po-
sitioning System 共GPS兲 for enhancing the NSRS in the early
stages of GPS development. Hence, in the late 1980s, this agency
embarked on applying GPS instrumentation and field techniques
to improve the NSRS. NGS quickly converted its traditional hori-
zontal field operations 共which applied line-of-sight instruments兲
to three-dimensional 共3D兲 field operations using GPS instrumen-
tation. Snay 共1989兲 reported that traditional line-of-sight tech-
1
Chief, Spatial Reference System Division, National Geodetic Survey,
NOS, National Oceanic and Atmospheric Administration, 1315 East-West
Hwy., Silver Spring, MD 20910. E-mail: Richard.Snay@noaa.gov
2
Chief Technical Officer, Spatial Reference System Division,
National Geodetic Survey, NOS, National Oceanic and Atmospheric
Administration, 1315 East-West Hwy., Silver Spring, MD 20910.
E-mail: Tom.Soler@noaa.gov
Note. Discussion open until April 1, 2009. Separate discussions must
be submitted for individual papers. The manuscript for this paper was
submitted for review and possible publication on May 18, 2007; approved
on April 21, 2008. This paper is part of the Journal of Surveying Engi-
neering, Vol. 134, No. 4, November 1, 2008. ©ASCE, ISSN 0733-9453/
2008/4-95–104/$25.00.
approximately 1:250,000 among the primary horizontal reference
stations in the NSRS. GPS, on the other hand, easily yields rela-
tive accuracies exceeding 1:1,000,000. In addition, because of the
line-of-sight requirement, many of the older reference stations
had been installed in locations, like mountain tops, which are
difficult to access.
NGS first applied GPS to determine positional coordinates for
the brass disks and other monuments that served as traditional
reference stations. Starting with Tennessee in 1987, NGS collabo-
rated with various state and federal agencies and others to estab-
lish a high accuracy reference network 共HARN兲—also called a
high precision geodetic network—in each of the 50 states. For
each HARN survey, many new reference marks were positioned
so that, as compared to the preexisting reference marks, the new
ones would be located in more accessible places 共e.g., near public
roads兲 and/or they would provide a relatively less obstructed view
of the sky. These statewide HARNs were embedded into a more
accurate sparse nationwide network whose points were also posi-
tioned using GPS techniques, first in 1987 and again in 1990
共Soler et al. 1992兲. Once a HARN survey was completed in a
particular state, NGS performed a statewide readjustment of the
HARN data, together with all archived classical geodetic surveys
and local GPS projects performed in that state, to compute con-
sistent positional coordinates for the associated ground marks.
Anticipating the need to perform accurate HARN surveys,
NGS introduced, in the fall of 1986, the Cooperative International
GPS Network 共CIGNET兲 共Chin et al. 1987兲, the forerunner of the
CORS network. Each CIGNET site was equipped with a high-
quality dual frequency GPS receiver that continuously recorded
signals from GPS satellites. The primary intention was to make
dependable tracking data available from a network of ground sta-
tions to compute precise ephemeredes 共orbits兲 for the GPS satel-
lites. In 1989, CIGNET contained three stations in the United
States 共MOJA in Mojave, Calif.; RICH in Richmond, Fla.; and
WEST in Westford, Mass.兲. These early CORS were equipped
with Mini-Mac 2816-AT dual-frequency codeless receivers 共Aero
Service Division, Western Geophysical Company of America,
Houston兲. In 1990, CIGNET expanded into the southern hemi-

CORS AND OPUS FOR ENGINEERS 1

sphere. By the end of 1991, CIGNET comprised a total of 21 sites
spanning all continents except Antarctica. As is now the case, all
tracking data were collected by several partners and made freely
available to GPS investigators through NGS archives 共Sche-
newerk et al. 1990兲. Gradually, NGS augmented the CIGNET
network, generating the core of the first public global GPS net-
work that, unknowingly at the time, evolved into the current In-
ternational Global Navigation Satellite System 共GNSS兲 Service
共IGS兲 network under the auspices of the International Association
of Geodesy.
The concept of covering the entire United States with a net-
work of CORS to enhance the NSRS was first postulated by
Strange 共1994兲. Soon after, Strange and Weston 共1995兲 published
a preliminary description of the CORS system. Around this same
time, several other federal agencies were also starting to establish
networks of continuously operating GPS base stations, but for
different reasons. The U.S. Coast Guard 共USCG兲 wished to
supplement its LORAN radionavigation service by offering the
differential GPS 共DGPS兲 service to support safe marine naviga-
tion in U.S. coastal waters. Similarly, the U.S. Army Corps of
Engineers 共USACE兲 sought a cost efficient navigation system to
support their inland waterway operations 共dredging, hydrographic
surveys, etc.兲. They collaborated with the USCG to extend the
DGPS service inland along several of the major rivers. Finally,
the Federal Aviation Administration 共FAA兲 wanted to use some
type of CORS to support safe air navigation. The FAA developed
their Wide Area Augmentation System 共WAAS兲. Other federal
agencies like NASA’s Jet Propulsion Laboratory 共JPL兲 and the
U.S. Geological Survey were already heavily invested in using
CORS sites to determine satellite orbits and study crustal motion.
Because of the similarities between these projects, the U.S. Gen-
eral Accounting Office directed these agencies to work together
and to coordinate activities and equipment procurements to re-
duce the expense to the federal government and the U.S. taxpayer.
NGS found itself in an advisory role helping to define the GPS
equipment specifications needed to support the missions of all
these agencies 共Spofford and Weston 1998兲.
Since the late 1980s, data from both CIGNET and JPL sites
were used to support global GPS orbit computations 共Schutz et al.
1990兲. In 1994, NGS officially began building the CORS network
by installing a GPS receiver on the campus of the National Insti-
tutes of Standards and Technology, formerly called the National
Bureau of Standards, in Gaithersburg, Md. Six months later, NGS
installed a GPS receiver near Boulder, Colo. and with time incor-
porated into the CORS network a number of continuously oper-
ating GPS fiducial stations that originally were part of CIGNET.
Data from all these sites were made available via the Internet and,
progressively, NGS added selected U.S. permanent GPS base sta-
tions to the CORS network.
The USCG and USACE began installing their DGPS sites and
FAA their WAAS sites in 1995. NGS worked with these agencies
to incorporate both the DGPS and WAAS sites into the CORS
network. The initial phase of the USCG network was largely
completed by January 1996, although more sites have since been
added. Other federal, state, and locally sponsored continuously
operating receivers were identified and gradually included into
the CORS network from 1995 onwards. By 1995 NGS obtained
access to more than 50 geodetic quality GPS receivers, most of
them deployed by USCG and other participating agencies without
the need by NGS to install, maintain, or operate any of the sites.
The Texas Department of Transportation was the first state agency
to join the CORS system with the inclusion of their ten-station
Regional Reference Point network that provided significant cov-
2 CORS AND OPUS FOR ENGINEERS
erage in Texas. By 1996 the number of CORS sites had increased
to 85. By making contact with interested agencies and arranging
to exchange data, NGS expanded the network to 108 sites by
December 1997. The 200-site milestone was surpassed in 2000,
and since then the CORS network has grown to its current size of
approximately 1,350 sites, and it continues to grow in importance
as the primary way for the geodetic-surveying community to ac-
cess the NSRS. At present, the CORS network contains stations in
the United States, Canada, Mexico, Central and South America,
the Caribbean, and Iraq. More than 200 organizations participate
in the program. Recently some sites of EarthScope’s Plate Bound-
ary Observatory 共PBO兲, established in the western part of the
North American continent to detect crustal motions, have been
incorporated into the CORS network.
Although the number of CORS sites is currently growing
at a rate of about 15 sites per month, the total number of perma-
nent GPS tracking stations in the United States is probably grow-
ing perhaps twice as fast. An ongoing project, that may take
several years to complete, is to determine an accurate orthometric
height for each CORS site. Determining the orthometric height of
a CORS site may require special methodology 共Greenfeld and
Sens 2003兲 depending on the location and the type of antenna
mounting.
The latest international installation by NGS of a CORS an-
tenna was done near Fortaleza, Brazil, where the local tie between
the new and the old reference points was remeasured to about
1 mm accuracy. The receiver at this site is connected to an exter-
nal atomic hydrogen-maser clock. According to Ray et al. 共2007兲,
the performance of this clock is among the best of any H-maser
station in the combined CORS-IGS network.
The National CORS system is rapidly becoming the preferred
method for accurate 3D positioning in the United States and
abroad. The advantage to GPS practitioners is that they only need
to deploy one GPS receiver and download corresponding CORS
data via the Internet to process these data in differential mode.
The Web-based utility, UFCORS 共see the following兲, has made
such downloads easy. As part of the CORS project, NGS is
working with scientists around the world to develop digital
models and techniques that will enable GPS users to determine
accurate positions economically and in a timely manner. Fig. 1
shows the geographic distribution of CORS sites as of May
2008. The primary access for CORS information is via the Web
共具http://www.ngs.noaa.gov/CORS/典兲. See also the articles by Snay
et al. 共2002b兲 and Stone 共2006兲.
The CORS network continues to evolve as we speak. It is
expected to increase by ⬃200 stations in 2008 due to the large
number of organizations establishing real-time positioning net-
works and the project to build EarthScope’s PBO for monitoring
crustal motion. This rate of growth will result in a CORS network
with average intersite distances on the order of 100 km in the
contiguous United States. In light of this growth, NGS has re-
cently updated its guidelines for establishing CORS sites 共NGS
2006兲, improved its tracking of metadata, upgraded its GPS
analysis software 共called PAGES兲, and is planning a complete
reanalysis of all IGS plus CORS data observed since 1994. The
latter activity will be performed in collaboration with several
other IGS Analysis Centers, and it is expected to be completed
within the year 2010.
CORS and the Definition of the NSRS
NGS derived the original realization of the North American
Datum of 1983 共NAD 83兲 in 1986 by performing a rigorous ad-
 Fig. 1. 共Color兲 Operational CORS sites as of May 2008
justment of most of the classical geodetic observations in its ar-
chives together with Doppler observations and a few very long
baseline interferometry 共VLBI兲 baselines 共Schwarz 1989兲. This
original realization is called NAD 83 共1986兲. With improvements
in our knowledge of terrestrial reference frames, NGS has intro-
duced several newer realizations of NAD 83, refining at each step
the adopted coordinates. In 1998 NGS introduced the current re-
alization, called NAD 83 共CORS96兲, which is based on the CORS
network by defining a transformation from the International Ter-
restrial Reference Frame of 1996 共ITRF96兲 to NAD 83 共Craymer
et al. 2000兲. In both reference systems, ITRF and NAD 83
共CORS96兲, the 3D positional coordinates of each CORS is
complemented by a 3D velocity to account for crustal motion. A
more recent ITRF realization is known as the ITRF2000.
ITRF2000 coordinates and velocities may be transformed to cor-
responding NAD 83 共CORS96兲 values using equations and pa-
rameters described by Soler and Snay 共2004兲. The NAD 83
共CORS96兲 positional coordinates are published for an epoch date
of 2002.0, except in Alaska and California where epoch dates of
2003.0 and 2004.0, respectively, have been adopted because of
recent earthquakes. One must apply the adopted velocities to
compute positional coordinates for any other epoch date. At this
writing, the coordinates and velocities of the CORS sites form the
foundation of the NSRS and the recently completed NAD 83
共NSRS2007兲 readjustment 共Vorhauer 2007兲.
It is important to note that CORS sites located in Hawaii and
other Pacific islands have been used to define the NAD 83
共PACP00兲 reference frame for points located on the Pacific tec-
CORS AND OPUS FOR ENGINEERS
tonic plate. Similarly CORS sites located in Guam have been used
to define the NAD83 共MARP00兲 reference frame for points
located on the Mariana tectonic plate. More information about
the procedures used to define these two reference frames is
available in Snay 共2003兲. CORS sites have been also employed
to establish accurate geodetic control in other countries such as
Mexico 共Soler and Hernández-Navarro 2006a兲 and Jamaica
共Newsome and Harvey 2003兲
When a CORS site first comes on line, NGS uses at least ten
24-h GPS data sets to compute this station’s ITRF2000 positional
coordinates relative to other stations in the global IGS network.
Also, NGS uses the horizontal time-dependent positioning
共HTDP兲 software 共Snay 1999兲 to predict the station’s ITRF2000
velocity. NGS then transforms the ITRF2000 positional coordi-
nates and velocity for this CORS site into their corresponding
NAD 83 共CORS96兲 values via the adopted 14-parameter similar-
ity transformation 共Soler and Snay 2004兲.
Every few years, NGS reprocesses all CORS data collected
since 1994 to compute provisional positions and velocities for all
CORS relative to the current ITRF realization: call it ITRFxx. If,
for any station, these provisional ITRFxx positional coordinates
differ from the currently adopted ITRFxx positional coordinates
by more than 1 cm in the north-south or east-west component or
by more than 2 cm in the vertical component, then NGS adopts
the provisional position and velocity to supersede the previously
adopted ITRFxx position and velocity.
In addition to this validation process, NGS performs a solution
for each day to monitor the quality of adopted CORS positional
3
coordinates. Each solution includes all CORS data collected dur-
ing the 24-h period spanning that day. As a by-product, NGS
compiles plots showing differences between the published
ITRF2000 coordinates and the values obtained from the daily
solutions, corrected for crustal motion, for the latest 60 days. The
results are plotted relative to a local horizon 共north-east-up兲 coor-
dinate frame and are made available to the general public through
the CORS Web page 共ftp://www.ngs.noaa.gov/cors/Plots/
xxxx.pdf; where xxxx denotes the site’s four-character identifica-
tion兲. The movement or replacement of the antenna or an
unexpected natural phenomenon may displace the position of the
CORS reference point. Geophysical processes 共earthquakes, vol-
canic activity, etc.兲 may also produce significant station displace-
ments that should be documented. This information is critical to
CORS users if they want to use CORS data to determine accurate
positional coordinates for points of interest to them. When the
trend of the 60-day series of daily estimates differ from this sta-
tion’s adopted positional coordinates by more than the tolerances
described in the preceding paragraph 共1 cm horizontal; 2 cm
vertical兲, then NGS carefully analyzes the available data to de-
termine whether or not this station’s published positional coordi-
nates and velocities should be updated. Similar analysis is done
with respect to the adopted NAD 83 共CORS96兲 coordinates.
When the daily provisional transformed coordinates referred to
the NAD 83 frame differ by more than 2 cm in the north-south or
east-west component or by more than 4 cm in the vertical com-
ponent, then NGS adopts the provisional NAD 83 positional co-
ordinates and velocity to supersede the previously adopted NAD
83 values. As a result of these less stringent tolerances, adopted
NAD 83 共CORS96兲 positional coordinates and velocities are less
likely to be updated than their ITRF counterparts. However, this
NGS policy, established in 1999 is currently being discussed at
NGS for possible revision to lower tolerances in response to both
internal and external requests.
For those agencies whose sites are included in the CORS
network, NGS computes highly accurate 3D positional coordi-
nates and velocities in the NSRS for their site antennas, provides
an international data distribution mechanism, monitors the posi-
tions of the antennas on a daily basis, and notifies the agencies
when movements of the antennas are detected. In exchange, the
agencies notify NGS when they change equipment or software
so that NGS can keep CORS users abreast of the status of the
CORS sites. Scientific users who monitor very small move-
ments of the Earth’s crust are especially interested in any antenna
changes so that they can account for those effects when they
undertake long-term analyses of site locations. When antenna
changes are detected and corrections made, NGS immediately
publicizes this information through the CORS Newsletter 共http://
www.ngs.noaa.gov/CORS/newsletter1/兲.
In March 2001, efficient access to the NSRS through GPS was
introduced with the release of the On-line Positioning User Ser-
vice 共OPUS兲 utility. OPUS is an automatic service that requires
the user to input only a minimal amount of information; its in-
structions are self-explanatory and its Web page contains enough
details to be followed easily 共http://www.ngs.noaa.gov/OPUS/兲.
However, OPUS has a few restrictions users should be aware of:
first, and most importantly, OPUS provides a differential GPS
static solution. Second, a minimum of 2 h of GPS observations
are recommended to obtain surveying-geodetic accuracies 共Soler
et al. 2006b兲. Third, a maximum of 48 h of GPS data is permitted
共the GPS data can cross midnight only once兲. Fourth, the submit-
ted data file must contain dual-frequency 共L1/L2兲 carrier phase
observables. Finally, GLONASS observations cannot be pro-
4 CORS AND OPUS FOR ENGINEERS
cessed at this time, although in the future they will be accepted
along with Galileo data, as the constellation of this European
navigational system becomes available. Strictly based on Internet
access, OPUS provides the geospatial community with position-
ing referred to both the ITRF2000 and the NAD 83 共CORS96兲
reference frames. OPUS routinely achieves accuracies 共reported
as “peak-to-peak” values兲 better than 2 cm in the horizontal
dimensions and 5 cm in the vertical dimension by using corre-
sponding data from three nearby CORS sites. Readers interested
in knowing the statistical meaning of the peak-to-peak values
reported by OPUS should read Schwarz 共2006兲. More detailed
information about OPUS may be obtained in a number of refer-
ences, e.g., Mader et al. 共2003兲; Stone 共2006兲; Soler et al.
共2006c兲; and Weston et al. 共2007兲. The infrastructure of OPUS is
the GPS data and the fiducial control available from the CORS
sites. The original idea of creating CORS to support GPS survey-
ing activities reached a new level of efficiency with the introduc-
tion of OPUS. The geodetic, surveying, mapping, and GIS
communities have embraced OPUS with great enthusiasm. The
progress of this Internet-based utility has been nothing less than
spectacular since its inception in 2001. Fig. 2 depicts OPUS usage
by county during the 12-month period from May 2007 to April
2008. As Fig. 2 shows, during this period a total of 171,573
OPUS solutions were successfully processed. For completeness, it
should be reported that during the same 1-year period OPUS pro-
cessed a total of 23,502 data sets observed outside the United
States. The number of OPUS users is expected to increase signifi-
cantly now that NGS is broadening the functionality of OPUS. On
January 31, 2007, the first variation of OPUS, called OPUS-RS
共rapid static兲, was declared “initially” operational. Like the origi-
nal implementation of OPUS, OPUS-RS computes positions in
differential mode for dual-frequency data collected by a GPS re-
ceiver. What’s new about OPUS-RS is a new processing engine
共Schwarz 2008兲, allowing as little as 15 min of data, while 共gen-
erally兲 maintaining the accuracy of the original OPUS. The user
can send GPS data to OPUS-RS by accessing: http://
www.ngs.noaa.gov/OPUS/. For a brief introduction to OPUS-RS,
see Martin 共2007兲; Meade 共2007兲. A practical example of how
OPUS-RS can be applied to day-to-day work in surveying engi-
neering is described in Lazio 共2007兲. Another variation of OPUS
will be OPUS-DB 共database兲 that will require a minimum of 4 h
of observations but will give surveyors, geodetic engineers, and
others the option of archiving the resulting positional coordinates
in an NGS database for public accessibility. Finally, OPUS-
Mapper is being developed to process L1 code data to determine
positional coordinates accurate enough for mapping and GIS ap-
plications. Although each of these functionalities are being devel-
oped in phases, they will ultimately all be part of an integrated
“OPUS” utility.
Data Archives
All CORS data are collected at two facilities, one located in
Silver Spring, Md. and the other in Boulder, Colo. At each facil-
ity, the GPS data are organized into various types of formatted
files 共RINEX, Hatanaka, etc.兲 for public distribution. People may
freely access these data files and related metadata either via
anonymous file transfer protocol 共ftp://www.ngs.noaa.gov/cors/兲
or via the World Wide Web 共http://www.ngs.noaa.gov/CORS/兲. In
January 2000, NGS introduced a new interface to the CORS web
site. This new interface is known as CORSAGE 共CORS Amiable
Geographic Environment兲 because it enables people to access
 Fig. 2. 共Color兲 OPUS usage by county from May 2007 to April 2008
CORS data and metadata through a series of geographic maps.
The CORS homepage itself features an index map in which the
total area of CORS coverage has been partitioned into several
color-coded regions, each usually involving a few states. On a
regional map, a user can click his/her mouse on the map symbol
representing a particular CORS site to obtain a window contain-
ing a local map that pinpoints this site’s location relative to
nearby population centers, major roads, and other geographic fea-
tures. A menu appears to the left of the local map which enables
users to view/download particular information about this site, for
example, a file containing the site’s positional coordinates and
velocity. Another item on this menu enables users to view a cal-
endar displaying—with 10-min resolution—the time span when
CORS data are available for this site. Inspecting such calendars
can save users from downloading and processing files that contain
undesirable data gaps. Other menu items provide access to the
site’s GPS data and to files containing certain descriptive infor-
mation about this site 共type of GPS equipment, responsible insti-
tution, contact person, history of receiver and antenna
replacements, etc.兲 Access to CORS information using a geo-
graphic Google interface has recently been added.
UFCORS
In November 1998, NGS introduced the “user-friendly” CORS
共UFCORS兲 information server that enables users to request and
receive GPS data and associated metadata 共satellite ephemeris
and station-specific descriptive information兲 for stations in the
CORS network via the World Wide Web. UFCORS provides a
convenient alternative to both the anonymous FTP information
server and the Web-based “standard” CORS information server
for retrieving CORS information. UFCORS allows a user to se-
lect a comprehensive package of information for a particular sta-
tion and a particular time interval. Anonymous FTP and the
CORS AND OPUS FOR ENGINEERS
standard CORS information server provide the information only
in the format that is stored at NGS, whereas UFCORS can re-
package the information into any of several different formats. For
example, with UFCORS a person can download GPS data files
for any discretionary number of hours 共艋24兲. Also UFCORS al-
lows users to select how the requested data files should be com-
pressed. UFCORS also can interpolate GPS data to sampling
rates, other than the standard 30-s rate. Finally, UFCORS can
decimate archived CORS data of one sampling rate to a user
specified sampling rate of greater value.
Anonymous FTP remains the most popular CORS information
server in terms of data volume. More than 581 gigabytes of
CORS data were distributed via anonymous FTP in April 2008
关Fig. 3共a兲兴, whereas UFCORS distributed about 66 Gbytes in
April 2008 关Fig. 3共b兲兴. Anonymous FTP is the server of choice
among users that download GPS data from many CORS sites on
a regular basis. Users who download CORS data only occasion-
ally or only from a few stations prefer to use UFCORS.
CORS Applications
In addition to the primary application of CORS, to enable accu-
rate positioning relative to the NSRS, CORS has been pivotal in
advancing other, well documented, multidisciplinary investiga-
tions. The scientific literature is flooded with articles citing CORS
as the basis for their experiments and/or research projects. The
realm of applications is diverse and multifaceted and it is ex-
pected that this trend will continue in the future. CORS has al-
ready made an impact on solid Earth science and is on the fringe
of significantly impacting atmospheric science. In the following
sections, we describe a few areas where the use of CORS data
was significant in advancing scientific knowledge.
5
 FTP CORS Monthly Gigabytes Downloaded 8-h sessions, 40 nonoverlapping 6-h sessions and, finally, 60
nonoverlapping 4-h sessions. The results of this investigation
empirically demonstrated that the dependence of accuracy on

839
900

831
795
baseline length is negligibly small, whereas the dependence on

769
742
800

724
707
690

689
686
the duration time of the observing session obeys the following

682
681
678

671
Number of Gigabytes

700

625
616
609
604

599
simple mnemonic rule when the observing time spans 4 h or

581
576
573
570

567

561
600

522
longer:

499
494

494
486
485

484
477

472
再 冎
446

446

442
500
429

405

403
401

396

396
378
376

366
363

355
400 325 k = 1.0 horizontal 共north and east兲
323

k
295

293
287

共1兲
276

266 RMSE =

260
冑T k = 3.7 vertical 共up兲
251

300
200
100 In Eq. 共1兲, the root mean square error 共RMSE兲 is given in centi-
0 meters when T denotes the duration of the observation session in
hours and k is a constant 共cm冑h兲. Soler et al. 共2006b兲 reached
Aug-03

Apr-04

Aug-04

Apr-05

Aug-05

Apr-06

Aug-06

Apr-07

Aug-07

Apr-08
Dec-03

Dec-04

Dec-05

Dec-06

Dec-07
(a) similar conclusions for data sets having durations of 2, 3, and 4 h.
Experiments involving 1-h data sets suffered from an inability to
UFCORS Monthly Gigabytes Downloaded reliably determine the integer values of the carrier phase ambigu-
ities caused by the nonaveraging atmospheric conditions at the
120
control stations. Preliminary results, however, demonstrate that
110
109

OPUS-RS can produce accurate positional coordinates for observ-

103
97

97
ing sessions as short as 15 min in duration by interpolating atmo-
96
95

100
Number of Gigabytes

91
86

82
spheric conditions measured at CORS sites to the location where
81
80
75

80 the OPUS-RS user collected his/her GPS data.

71
70

68

67
67

66
66
65

62
59

57
55

60
52

51

51
50

50

Multipath Studies
41
41
40
39

39
38
38

38
38
37

40
34

33
32

32
30

30
29

29
28
27

27

For GPS antennas, multipath errors are caused by the interference

26
26

26
25

24
23

22

19
18
18
16

20 of signals that have reached the receiver antenna by two or more

different paths, usually caused by one path being bounced or re-
0
flected from the ground or nearby surfaces 共buildings, fences,
July-04
Nov-03

Nov-04

Nov-05

Nov-06

Nov-07
Mar-03
Jul-03

Mar-08

Mar-05

Jul-05

Mar-06

Jul-06

Mar-07

Jul-07

Mar-08

etc.兲. The understanding of multipath effects is important to deci-

(b)
pher the systematic errors associated with a particular station and
Fig. 3. Monthly volumes of CORS data downloaded 共a兲 using FTP;
antenna and the possibility to correct for them. Hilla and Cline
共b兲 using UFCORS
共2004兲 conducted an investigation to evaluate the amount of mul-
tipath occurring at each of 390+ sites contained in the National
CORS network. This study identified the most and least affected
sites in the network, compared different receiver/antenna combi-
Upgrading the NSRS
nations, and investigated closely those sites that appeared to be
NGS recently completed an adjustment involving GPS data ob- severely affected by multipath. Dual-frequency carrier phase and
served at ⬃70,000 geodetic marks during the past 20 years. This pseudorange measurements were used to estimate the amount of
adjustment termed NAD 83 共NSRS2007兲 held fixed the published L1 and L2 pseudorange multipath at each site over a one-year
NAD 83 共CORS96兲 3D positional coordinates of the CORS sites, period. A similar study 共Park et al. 2004兲 combining CORS and
to obtain a solution whose coordinates are consistent with the IGS sites also found that the postfit phase residuals were highly
NAD 83 共CORS96兲 frame. Once more, the CORS network fulfills dependent on the GPS antenna type. This investigation concluded
its primary mission of implementing the NSRS. Thus, because of that antenna types with choke rings are very effective in suppress-
the procedure followed 共Vorhauer 2007兲 these ⬃70,000 geodetic ing multipath and that multipath is highly dependent on the
marks now have positional coordinates that are compatible with unique environment at each site.
the NAD 83 共CORS96兲 reference frame.
Crustal Motion
Assessing GPS Observational Accuracies
Crustal motion monitoring is perhaps one of the most obvious of
The availability of continuous GPS data from stations well dis- all CORS applications. If CORS data are rigorously processed
tributed throughout the United States makes it possible to design and analyzed during a period of several years, then the motion of
experiments aimed to answer many questions related to GPS the Earth’s crust can be determined wherever the CORS network
methodologies now in vogue and to expand our understanding of provides sufficient coverage.
scientific phenomena. Eckl et al. 共2001兲 and Snay et al. 共2002a兲 Gan and Prescott 共2001兲 analyzed GPS data observed between
studied the accuracy of GPS-derived relative positions as a func- 1996 and 2000 for 62 CORS sites distributed throughout the cen-
tion of interstation distance and observing-session duration using tral and eastern United States. Their results suggest that no sig-
data from 19 CORS sites. Eleven baselines connecting pairs of nificant horizontal crustal motion occurred during this time period
these 19 sites were formed with lengths ranging from 26 to in this part of the country, except possibly in the lower Missis-
300 km. GPS data for each baseline was partitioned into 10 sippi River Valley. This particular area appears to be moving
nonoverlapping 24-h sessions. These same data were also sub- southward relative to the rest of the continent at an average rate of
divided into 20 nonoverlapping 12-h sessions, 30 nonoverlapping 1.7⫾ 0.9 mm/ year. Although this rate is not statistically signifi-

6 CORS AND OPUS FOR ENGINEERS

cant at the 95% confidence level, the fact that the motion occurs
near New Madrid, Mo.—where earthquake risk is thought to be
high—argues that the motion may be real.
Sella et al. 共2002兲 applied GPS data from the CORS network,
together with data from a worldwide distribution of stations, to
produce a global “recent velocity” 共REVEL兲 model that quantifies
the motions of 19 tectonic plates and continental blocks during
the 1993–2000 time interval.
Park et al. 共2002兲 used data from 60 CORS sites to estimate
the upper and lower mantle viscosity by comparing radial site
velocities with velocities inferred from glacial isostatic adjust-
ment 共GIA兲 models. In addition, their GPS-derived velocities are
consistent with previous estimates obtained using different meth-
ods and data over different time spans.
Recently, the deformation occurring within the North Ameri-
can plate interior was estimated using 10 years of GPS data from
the CORS network processed using both the GIPSY and GAMIT
software packages 共Calais et al. 2006兲. These authors analyzed
data from about 300 CORS stations covering the central and east-
ern United States. The investigation indicates that the velocity
field is described within uncertainties by a simple rigid plate ro-
tation that is distorted in some areas by a deformation pattern
consistent with GIA. Similarly, using CORS sites and episodic
GPS data in Canada and the United States, Sella et al. 共2007兲
show that the strongest signal within the nominally stable interior
of the North American plate is the effect of GIA due to mass
unloading during deglaciation. On a more local scale, Dokka et al.
共2006兲 used GPS data from CORS sites to infer that southeast
Louisiana, including New Orleans and the larger Mississippi
Delta, are both subsiding vertically and moving southward with
respect to the interior of the North American plate.
Sea Level Changes
The variations of vertical crustal velocities at CORS sites near
tide gauge stations may be used to determine the “absolute” sea
level change with respect to the International Terrestrial Refer-
ence Frame. This type of analysis was impossible to conduct be-
fore the proliferation of CORS in coastal areas. Recently, a study
by Snay et al. 共2007兲 involving 37 tide gauge stations, distributed
along the U.S. and Canadian coasts, such that each is located
within 40 km of a CORS site, determined rigorously the crustal
velocity near tide gauge stations from GPS observations spanning
between 3 and 11 years. After calibrating historical tidal data with
these derived crustal velocities, the results show that the mean
rate of absolute sea level change equals 1.80⫾ 0.18 mm/ year for
the 1900–1999 interval. The same investigation determined the
absolute rate of sea level change equals −1.19⫾ 0.70 mm/ year
along the southern Alaskan coastline. This lowering of absolute
sea level near southern Alaska is probably due to ongoing melting
of mountain glaciers and ice masses. With time, more CORS data
will become available near tide gauges to conduct investigations
able to accurately estimate vertical crustal velocities and thereby
absolute sea level rates with greater certainty.
Tropospheric Studies
The delay of GPS signals, which is caused by the refractivity of
the troposphere or electrically neutral atmosphere, is associated
with temperature, pressure, and the distribution of water vapor
up to a height of about 16 km. If the atmospheric pressure is
known with reasonable accuracy at the elevation of the GPS an-
tenna, then the total “wet” and “dry” delay at the site can be
CORS AND OPUS FOR ENGINEERS
effectively separated with little error. Mapping the resulting wet
signal delay into the integrated 共total column兲 precipitable water
vapor 共IPW兲 is accomplished in a straightforward manner if the
mean vapor-weighted temperature of the atmosphere is known.
Water vapor is one of the most important constituents of the
Earth’s atmosphere. It is the source of clouds and precipitation,
and an ingredient in most major weather events. IPW varies
greatly over the planet: ⬍5 mm near the poles and ⬎50 mm near
the equator. Most 共⬃95% 兲 of the water in the atmosphere resides
below 5 km 共or essentially below the 500 hPa pressure surface兲.
Significant changes in the vertical and horizontal distribution of
water vapor can occur rapidly 共minutes to hours兲 during active
weather.
NOAA’s Earth Systems Research Laboratory 共ESRL兲, for-
merly called NOAA’s Forecast Systems Laboratory, has devel-
oped the capability to estimate the spatial and temporal variation
of tropospheric delay within the contiguous United States
共CONUS兲 共Gutman et al. 2004兲. Their prediction process is based
on modeling the delay using GPS observations from the CORS
network in combination with other meteorological data. They up-
date their model every hour. It is possible to use CORS sites to
estimate the tropospheric signal delay at each station with high
accuracy because of stringent instrument requirements for high
accuracy GPS positioning. Data from a network of approximately
385 CORS sites are assimilated hourly into the operational ver-
sion of the rapid update cycle 共RUC兲 numerical weather predic-
tion model which refers the results to a two-dimensional 共2D兲
horizontal grid having a 13-km nodal spacing.
The Global Systems Division of NOAA’s ESRL has developed
NOAATrop, a new way to improve GPS positioning, navigation
and timing accuracy using real-time weather data at CORS sites
共Gutman et al. 2004兲. NOAATrop is available for download at
ftp://aftp.fsl.noaa.gov/gpsmet/zwdgrids/. This information pro-
vides zenith wet delay and ALT 共a proxy for zenith hydrostatic
delay兲 for a 2D grid with 13-km resolution over the CONUS.
NOAATrop is based on RUC, an operational model that is up-
dated hourly. The root mean square accuracy of the modeled de-
lays is currently ⬃2 cm in cold seasons and ⬍4 cm in warm
seasons.
Ionospheric Studies
Wide area ionospheric models have been developed to model and
mitigate local ionospheric effects. Such models are based on dual
frequency observations from a subset of the CORS network.
The ionosphere is a dispersive medium located in the region of
the upper atmosphere that begins at an altitude of around 50 km
and extends upwards several hundred kilometers. The radiation
from the Sun and particles precipitating from the magnetosphere
produces free electrons and ions that cause phase advances and
group delays in radio waves. The state of the ionosphere is a
function of the intensity of solar and magnetic activity, position
on the Earth, local time and other factors. As GPS signals traverse
the ionosphere, they are delayed by an amount proportional to the
total electron content 共TEC兲 within the ionosphere at a given
time. Daily maps showing the estimation of TEC over the
CONUS based on CORS data from about 180 stations have been
produced at NGS and distributed through the Internet since 1997
共Musman et al. 1997兲.
Recently NOAA’s Space Weather Prediction Center 共SWPC兲
began modeling TEC in 3D for CONUS using CORS data
共Fuller-Rowell et al. 2006兲. This model is updated every 15 min
with a latency of 30 min 共http://www.sec.noaa.ustec/index.html兲.
7
This product is designed to quantify TEC over CONUS in near
real time and has evolved through collaboration between the
SWPC, NGS, ESRL, and NOAA’s National Geophysical Data
Center.
Data from the CORS network have been used in studies of
large-scale ionospheric disturbances caused by geomagnetic
storms on a continental scale 共Tsugawa et al. 2003兲. Investiga-
tions to correct for ionospheric effects in local CORS networks
共e.g., Ohio State兲 established for real-time kinematics 共RTK兲
applications have proliferated lately with the deployment of state-
operated CORS networks 共Wielgoz et al. 2005a,b; Grejner-
Brzezinska et al. 2007兲. GPS data from CORS sites have been
used to test ionospheric models aimed to improve long baseline
differential GPS positioning of rovers using only L1 data 共Mo-
hino et al. 2007兲. Finally, Smith 共2004兲 experimentally introduced
an interesting alternative approach to compute absolute 共unam-
biguous兲 TEC values relying only on dual frequency ambiguous
carrier phase data from the CORS network, though the approach
was only a research prototype.
Geolocation of Aerial Moving Platforms
Data available from CORS sites has been used in many remote
sensing applications. The accurate positioning of aircrafts em-
ployed in aerial mapping is crucial to improve the reliability of
photogrammetric restitution primarily for large-scale aerial survey
applications over remote or inaccessible terrain. The same con-
cepts implemented for geolocating landmarks from the air with
digital cameras has been extended to a broad array of mapping
terrain applications using cutting edge technologies such as
scanning radar, light detection and ranging 共LiDAR兲, inertial sys-
tems, interferometric synthetic aperture radar, and/or sonar. The
use of CORS data in airborne mapping processes has proven to
provide a significant alternative 共Mostafa 2005兲. The utility of
CORS sites in differential GPS aircraft positioning was investi-
gated by Booth and Lunde 共2003兲 showing that very accurate
carrier phase differential results can be obtained using much
longer baselines than originally thought. The aerial mapping com-
munity will certainly benefit from the growing number of CORS
sites. Perhaps, the decisive factor in all these applications is the
accessibility to GPS data at a 1-s sampling rate instead of the
standard of 30-s sampling rate. NGS has cooperated with federal,
state, and private institutions to schedule ahead of time changes at
specified CORS sites to the 1-s sampling rate. This facilitates the
postprocessing of airborne GPS data to accurately estimate the
position of a plethora of aerial moving platforms. For example,
NGS’s Remote Sensing Division obtains aerial imagery to assess
hurricane damage. These missions are well served by CORS data,
collected at a 1-s sampling rate, to accurately determine the travel
path of the aircraft being used to collect aerial imagery. NGS
personnel worked closely with their CORS partners to tempo-
rarily increase data sampling rates after the hurricanes of 2005.
The imagery of areas affected by individual hurricanes is avail-
able at www.ngs.noaa.gov.
On the CORS Horizon
In December 2006, NGS installed a new CORS near the tide
gauge station located in Key West, Fla. This CORS will help
relate local sea level change at Key West to the globally consis-
tent, rigorously defined International Terrestrial Reference Frame.
Indeed, NGS plans to install a CORS at each of several additional
8 CORS AND OPUS FOR ENGINEERS
tide gauge stations contained in the U.S. National Water Level
Observation Network 共NWLON兲. Established in 1913, the Key
West tide gauge station is one of the longest continually opera-
tional stations contained in the NWLON.
The new CORS at Key West is also significant because it
is the first CORS, installed by NGS, which collects both GPS
and GLONASS data. A number of CORS partners have begun
upgrading stations to collect both GPS and GLONASS data,
and NGS will soon begin distributing such GNSS data to CORS
users.
Additionally, several CORS are streaming GPS data in real
time to NGS headquarters in Silver Spring, Md. NGS will broad-
cast these data to the public in real time to support the growth of
regional GNSS networks that enable real-time positioning in the
United States. In response to user demands, more than 40 orga-
nizations, both public and private, are now establishing such re-
gional GNSS networks. Also, many more of these regional real-
time positioning networks are expected to be established in the
near future. NGS needs to support these networks by developing
appropriate standards and guidelines so that:
• Promulgated positional coordinates and velocities for the cor-
responding GNSS base stations are compatible with the
NSRS;
• User equipment can operate with services from different real-
time GNSS networks to the greatest extent possible; and
• Stations contained in each real-time network meet prescribed
criteria in terms of stability and data quality.
Accordingly, NGS is considering the possibility of streaming
GNSS data from about 200 federally funded CORS so that this
agency may understand the intricacies involved in operating a
real-time GNSS network to the extent necessary to develop ap-
propriate standards and guidelines.
NGS encourages the institutions, who are providing real-time
positioning services, to use the NGS-provided data in their opera-
tions so as to 共1兲 supplement the data from other GNSS base
stations, and 共2兲 use the positional coordinates and velocities of
the GNSS stations contained in the NGS real-time network as
fiducial values for determining positional coordinates and veloci-
ties of other real-time GNSS stations.
Also, NGS is planning to stream these data because U.S. citi-
zens should have real-time access to data from federally funded
stations in the CORS network whenever it is economically and
technically feasible to do so. It is important to emphasize that
NGS intends to stream only the GNSS observables and not “cor-
rectors” to these observables. Also, NGS does not intend to
stream GNSS data that are already being streamed by another
organization. In all likelihood, NGS will use NTRIP 共networked
transport of RTCM standard via internet protocol兲 to broadcast
the stream of GNSS observables over the Internet.
Conclusions
The intent of this paper was to summarize the history, applica-
tions, and future prospects of the CORS network by describing
the more important contributions of the CORS system to the sci-
entific community. Many surveying engineers, geodesists, map-
ping specialists, as well as scientists from different backgrounds,
are using CORS on a daily basis by downloading GPS data
through UFCORS and anonymous FTP, and then postprocessing
these data for a variety of applications. The CORS network has
contributed significantly to geodetic positioning by providing
easy and accurate access to the NSRS. The CORS network should
also be recognized for supporting the research of numerous sci-
entific investigators. Finally, the CORS network serves as the
primary data source for all types of OPUS solutions.
Acknowledgments
This paper is dedicated to Bill Strange, the “Father of CORS.”
Bill’s vision and impetus when he served as NGS’s Chief Geod-
esist provided the inspiration that shaped the early days of the
CORS program. Although initially designed to support geodetic
activities, the CORS program has contributed to several addi-
tional scientific applications. Other important contributors from
NGS include, in alphabetical order: Gordon Adams, Donna Amo-
roso, Nancy Brantner, Hong Chen, Miranda Chin, Michael Cline,
Cindy Craig, Dave Crump, William Dillinger, Dave Doyle, Nancy
Doyle, Jim Drosdak, Robert Dulaney, Mark Eckl, Joseph Evjen,
Richard Foote, Steve Frakes, Don Haw, Steve Hilla, Michelle Ho,
Toni Hollingsworth, Ying Jin, William Kass, Gerald Mader, Ri-
chard Male, Ernie Marion, Frank Mowry, Linda Nussear, Julie
Prusky, Jim Ray, Jim Rohde, Bruce Sailer, Donna Sailer, Mark
Schenewerk, Charles Schwarz, Giovanni Sella, Dru Smith, Paul
Spofford, Lijuan Sun, Vicki Veilleux, and Neil Weston. Their con-
tinuous striving for perfection has been exemplary. Finally, the
success of the CORS program is due to contributions from more
than 200 organizations, with each organization operating at least
one CORS. For a current list of these organizations, please see the
CORS Newsletter at www.ngs.noaa.gov/CORS/. Comments on
the draft made by John Hamilton and two anonymous reviewers
are greatly appreciated.
References
Booth, J., and Lunde, T. 共2003兲. “Carrier-phase DGPS system accuracy
tests: Increasing baseline distance and using CORS network data.”
Proc., ION GPS/GNSS 2003, Institute of Navigation 共ION兲, Fairfax,
Va., 889–896.
Calais, E., Han, J. Y., DeMets, C., and Nocquet, J. M. 共2006兲. “Deforma-
tion of the North American plate interior from a decade of continuous
GPS measurements.” J. Geophys. Res., 111共B06402兲, 1–23.
Chin, M. M., Crump, D. R., and Berstis, K. A. 共1987兲. “The status of the
NGS GPS orbit tracking network 共abstract兲.” EOS Trans. Am. Geo-
phys. Union, 68共44兲, 1239–1239.
Craymer, M., Ferland, R., and Snay, R. 共2000兲. “Realization and unifica-
tion of the NAD 83 in Canada and the U.S. via the ITRF.” Towards an
integrated global geodetic observing system (IGGOS), R. Rummel, H.
Drewes, W. Bosch, and H. Hornik, eds., International Association of
Geodesy Symposia, Vol. 120, Springer, Berlin, 118–121.
Dokka, R. K., Sella, G. F., and Dixon, T. H. 共2006兲. “Tectonic control of
subsidence and southward displacement of southeast Louisiana with
respect to stable North America.” Geophys. Res. Lett., 33共L23308兲,
1–5.
Eckl, M. C., Snay, R., Soler, T., Cline, M. W., and Mader, G. L. 共2001兲.
“Accuracy of GPS-derived relative positions as a function of intersta-
tion distance and observing-session duration.” J. Geodesy, Berlin,
75共12兲, 633–640.
Fuller-Rowell, T., Araujo-Pradere, E., Minter, C., Codrescu, M., Spencer,
P., Robertson, D., and Jacobson, A. R. 共2006兲. “US-TEC: A new data
assimilation product from the Space Environment Center characteriz-
ing the ionospheric total electron content using real-time GPS data.”
Radio Sci., 41共RS6003兲, 1–8.
Gan, W., and Prescott, W. H. 共2001兲. “Crustal deformation rates in central
and eastern U.S. inferred from GPS.” Geophys. Res. Lett., 28共19兲,
3733–3736.
CORS AND OPUS FOR ENGINEERS
Greenfeld, J., and Sens, J. D. 共2003兲. “Determination of orthometric
height of NJI2 CORS station.” J. Surv. Eng., 129共3兲, 110–114.
Grejner-Brzezinska, D. A., Kashani, I., Wielgoz, P., Smith, D. A.,
Spencer, P. S. J., Robertson, D. S., and Mader, G. L. 共2007兲. “On
efficiency and reliability of ambiguity resolution in network-based
RTK GPS.” J. Surv. Eng., 133共2兲, 56–65.
Gutman, S. I., Sahm, S. R., Benjamin, S. G., Schwartz, B. E., Holub,
K. L., Stewart, J. Q., and Smith, T. L. 共2004兲. “Rapid retrieval and
assimilation of ground based GPS precipitable water observations at
the NOAA Forecast Systems Laboratory: Impact on weather fore-
cast.” J. Meteorol. Soc. Jpn., 82共1B兲, 351–360.
Hilla, S., and Cline, M. 共2004兲. “Evaluating pseudorange multipath ef-
fects at stations in the National CORS network.” GPS Solutions, 7共4兲,
253–267.
Lazio, P. 共2007兲. “Constraining network adjustments to OPUS-RS coor-
dinate observations.” J. Surv. Eng., 133共3兲, 106–113.
Mader, G. L., Weston, N. D., Morrison, M. L., and Milbert, D. G. 共2003兲.
“The on-line positioning user service 共OPUS兲.” Profess. Surv., 23共5兲,
26–30.
Martin, D. 共2007兲. “Geodetic connections—OPUS rapid static.” The
American Surveyor, 4共3兲, 44–48.
Meade, M. E. 共2007兲. “OPUS rapid static.” Point of Beginning, 32共8兲,
60–63.
Mohino, E., Gende, M., and Brunini, C. 共2007兲. “Improving long baseline
共100– 300 km兲 differential GPS positioning applying ionospheric cor-
rections derived from multiple reference stations.” J. Surv. Eng.,
133共1兲, 1–5.
Mostafa, M. M. R. 共2005兲. “Precise airborne GPS positioning alternatives
for the aerial mapping practice.” Proc., FIG Working Week 2005,
Fédération Internationale des Géometrès 共FIG兲, Frederiksberg, Den-
mark, 1–9.
Musman, S., Mader, G., and Dutton, C. E. 共1997兲. “Total electron content
changes in the ionosphere during the January 10, 1997 disturbance.”
Geophys. Res. Lett., 25共15兲, 3055–3058.
National Geodetic Survey 共NGS兲. 共2006兲. “Guidelines for new and exist-
ing continuous operating reference stations 共CORS兲.” 具http://
www.noaa.gov/PUBS_LIB/CORS_guidelines.pdf典 共May 10, 2007兲.
Newsome, G. G., and Harvey, B. R. 共2003兲. “GPS coordinate transfor-
mation parameters for Jamaica.” Surv. Rev., 37共289兲, 218–234.
Park, K.-D., Nerem, R. S., Davis, J. L., Schenewerk, M. S., Milne, G. A.,
and Mitrovica, J. X. 共2002兲. “Investigation of glacial isostatic adjust-
ment in the northeast U.S. using GPS measurements.” Geophys. Res.
Lett., 29共11兲, 1–4.
Park, K. D., Nerem, R. S., Schenewerk, M. S., and Davis, J. L. 共2004兲.
“Site-specific multipath characteristics of global IGS and CORS GPS
sites.” J. Geodesy, Berlin, 77共12兲, 799–803.
Ray, J., Crump, D., and Chin, M. 共2007兲. “New global positioning system
reference station in Brazil.” GPS Solutions, 11共1兲, 1–10.
Schenewerk, M. S., Mader, G. L., Chin, M., Kass, W., Dulaney, R.,
MacKay, J. R., and Foote, R. H. 共1990兲. “Status of CIGNET and orbit
determination at the National Geodetic Survey.” Proc., 2nd Int. Symp.
on Precise Positioning with the Global Positioning System. Ottawa,
179–189.
Schutz, B. E., Ho, C. S., Abusali, P. A. M., and Tapley, B. D. 共1990兲.
“Casa Uno GPS orbit and baseline experiments.” Geophys. Res. Lett.,
17共5兲, 643–646.
Schwarz, C. R., ed. 共1989兲. “North American Datum of 1983.” NOAA
Professional Paper NOS2, National Geodetic Survey, Rockville, Md.
Schwarz, C. R. 共2006兲. “Statistics of range of a set of normally distrib-
uted numbers.” J. Surv. Eng., 132共4兲, 155–159.
Schwarz, C. R. 共2008兲. “Heuristic weighting and data conditioning in the
National Geodetic Survey Rapid Static GPS 共RSGPS兲 software.” J.
Surv. Eng., 134共3兲, 70–75.
Sella, G. F., Dixon, T. H., and Mao, A. 共2002兲. “REVEL: A model for
recent plate velocities from space geodesy.” J. Geophys. Res.,
107共ETG11兲, 1–30.
Sella, G. F., Stein, S., Dixon, T. H., Craymer, M., James, T. H., Mazzotti,
H., and Dokka, R. K. 共2007兲. “Observation of glacial isostatic adjust-
ment in 具具 stable 典典 North America with GPS.” Geophys. Res. Lett.,
9
 34共L02306兲, 1–6.
Smith, D. A. 共2004兲. “Computing unambiguous TEC and ionospheric
delays using only carrier phase data from NOAA’s CORS network.”
Proc., IEEE PLANS 2004, Institute of Electrical and Electronics
Engineers 共IEEE兲, Piscataway, N.J., 527–537.
Snay, R. A. 共1989兲. “North American Datum of 1983.” NOAA Profes-
sional Paper NOS 2, C. R. Schwarz, ed., National Geodetic Survey,
Rockville, Md., 193–219.
Snay, R. A. 共1999兲. “Using HTDP software to transform spatial coordi-
nates across time and between reference frames.” Surv. Land Inf. Sys.,
59共1兲, 15–25.
Snay, R. A. 共2003兲. “Introducing two spatial reference frames for regions
of the Pacific Ocean.” Surv. Land Inf. Sys., 63共1兲, 5–12.
Snay, R., Adams, G., Chin, M., Frakes, S., Soler, T., and Weston, N.
共2002b兲. “The synergistic CORS program continues to evolve.” Proc.,
ION-GPS 2002, Institute of Navigation 共ION兲, Fairfax, Va., 2630–
2639.
Snay, R., Cline, M., Dillinger, W., Foote, R., Hilla, S., Kass, W., Ray, J.,
Rohde, J., Sella, G., and Soler, T. 共2007兲. “Using GPS-derived crustal
velocities to estimate absolute sea level rates from North American
tide gauge records.” J. Geophys. Res., 112共B04409兲, 1–11.
Snay, R. A., Soler, T., and Eckl, M. 共2002a兲. “GPS precision with carrier
phase observations: Does distance and/or time matter?” Profess. Surv.,
22共10兲, 20–24.
Soler, T., and Hernández-Navarro, A. 共2006a兲. “OPUS becomes available
in Mexico.” The American Surveyor, 3共9兲, 46–50.
Soler, T., Michalak, P., Weston, N., Snay, R., and Foote, R. 共2006b兲.
“Accuracy of OPUS solutions for 1- to 4-h observing sessions.” GPS
Solutions, 10共1兲, 45–55.
Soler, T., and Snay, R. A. 共2004兲. “Transforming positions and velocities
between the International Terrestrial Reference Frame of 2000 and
North American Datum of 1983.” J. Surv. Eng., 130共2兲, 49–55.
Soler, T., Strange, W. E., and Hothem, L. D. 共1992兲. “Accurate determi-
nation of Cartesian coordinates at geodetic stations using the Global
Positioning System.” Geophys. Res. Lett., 19共6兲, 533–536.
Soler, T., Weston, N. D., Snay, R. A., Mader, G. L., and Foote, R. H.
10 CORS AND OPUS FOR ENGINEERS
共2006c兲. “Precise georeferencing using on-line positioning user
service 共OPUS兲.” Proc., XXIII FIG Congress, Fédération Inter-
nationale des Géometrès 共FIG兲, Frederiksberg, Denmark.
Spofford, P. R., and Weston, N. D. 共1998兲. “National Geodetic Survey
continuously operating reference station project. Status and plans.”
ACSM Bulletin No. 172, 20–25.
Stone, W. 共2006兲. “The evolution of the National Geodetic Survey’s con-
tinuously operating reference station network and online positioning
user service.” Proc., 2006 ION-IEEE Position, Location, and Naviga-
tion Symp., Institute of Navigation 共ION兲, Fairfax, Va., and Institute of
Electrical and Electronics Engineers 共IEEE兲, Piscataway, N.J., 653–
663.
Strange, W. E. 共1994兲. “A national spatial data system framework con-
tinuously operating GPS reference stations.” Proc., 1st Federal Geo-
graphic Technology Conf., GIS in Government, GIS World, Fort
Collins, Colo., 37–41, USA.
Strange, W. E., and Weston, N. D. 共1995兲. “The establishment of a GPS
continuously operating reference station system as a framework for
the National Spatial Reference System.” Proc., ION Nat. Tech. Meet-
ing, Institute of Navigation 共ION兲, Fairfax, Va., 19–24.
Tsugawa, T., Saito, A., Otsuka, Y., and Yamamoto, M. 共2003兲. “Damping
of large-scale traveling ionospheric disturbances detected with GPS
networks during the geomagnetic storm.” J. Geophys. Res., 108共A3兲,
SIA7/1–14.
Vorhauer, M. 共2007兲. “National readjustment of 2007.” The American
Surveyor, 4共3兲, 48–54.
Weston, N. D., Soler, T., and Mader, G. L. 共2007兲. “NOAA’s online user
positioning service 共OPUS兲.” GIM Int., 21共4兲, 23–25.
Wielgosz, P., Grejner-Brzezinska, D., and Kashani, I. 共2005a兲. “High-
accuracy DGPS and precise point positioning based on Ohio CORS
network.” Navigation, 52共1兲, 23–28.
Wielgosz, P., Kashani, I., and Grejner-Brzezinska, D. 共2005b兲. “Analysis
of long-range network RTK during a severe ionospheric storm.” J.
Geodesy, Berlin, 79共9兲, 524–531.
 2
Criteria for Establishing and Operating a Continuously Operating
Reference Station (CORS)
Giovanni Sella1, Mike Cline2, and Don Haw3

Abstract: NOAA’s National Geodetic Survey (NGS) manages over 1500 GNSS stations that form the Continuously Operating
Reference Station (CORS) network. Data and products based on these stations are distributed by NGS, and are used by the public
to access the National Spatial Reference System (NSRS). This article summarizes the requirements and recommendations for the
establishment and operation of GNSS stations in the CORS network.

Author keywords: Continuously Operating Reference Stations; CORS; GNSS positioning; geodetic networks

Introduction Monument: The structure (e.g., pillar, building, metallic

NOAA’s National Geodetic Survey (NGS) Continuously
Operating Reference Station (CORS) network is a multi-
purpose cooperative endeavor involving over 1,500 GNSS
stations that are contributed by more than 150 government,
academic, commercial, and private organizations (Snay and
Soler, 2008). Fig 1 shows the present distribution of CORS
sites. Although participation in the CORS network is
voluntary, site operators must adhere to certain standards and
conventions. CORS sites are rapidly overtaking passive
control as the principal way of providing access to the
National Spatial Reference System (NSRS). In implementing
the guidelines NGS sought to provide minimum standards that
would maximize the quality of calculated positions with
particular emphasis on obtaining centimeter level accuracy.
NGS does not automatically include a station in the CORS
network solely because the station meets its guidelines
requirements. Inclusion of a site is made on a case-by-case
basis; taking into account current CORS network coverage,
the quality of data and robustness of communication of
existing or other proposed nearby stations.
This article summarizes the requirements for operating a
station in the NGS CORS network. The current version of the
guidelines are available on line (see the end of the next section
for the web link).
Nomenclature and Definitions
The following nomenclature and definitions have been
adopted for clarification.
The term “must” means that compliance is required; the
term “should” implies that compliance is strongly
recommended, but not required.
column, etc), including the mount, which keeps the GPS
antenna attached to earth’s surface.
Mount: The device used to attach the antenna to the
monument.
Mark: This is a unique and permanent point on the monument
to which the antenna reference point (ARP) is measured.
This mark must remain invariant with respect to the
monument.
Antenna Reference Point (ARP): The point on the bottom of
the antenna to which NGS references the antenna phase
center position. The vertical distance between this point
and the mark is the height (eccentricity) of the antenna.
Antenna phase center: The electrical point, within or outside
an antenna, at which the GPS signal is measured. The
realization of the phase center is determined by the set of
antenna phase center variations (PCV) corrections that
have been defined/adopted by NGS to account for the non-
ideal electrical response as a function of elevation and
azimuth angles (Mader, 1999).
Antenna eccentricity: The vertical and horizontal distances
from the mark to the ARP.
Site operator: Point of contact responsible for operating/
configuring a CORS site.
CORS Guidelines: refers to the current version of the CORS
site guidelines that are available at:
www.ngs.noaa.gov/CORS/Establish_Operate_CORS.html
Procedures for Becoming a CORS Site
1) Site operators must ensure that their proposed site meets
all the criteria outlined in the CORS Guidelines. NGS
strongly recommends that before a CORS site is built

1
CORS Program Manager, Spatial Reference System Division, National Geodetic Survey, NOS, National Oceanic and
Atmospheric Administration, 1315 East-West Hwy., Silver Spring, MD 20910. E-Mail: Giovanni.Sella@noaa.gov
2
Geodesist, Spatial Reference System Division, National Geodetic Survey, NOS, National Oceanic and Atmospheric
Administration, 1315 East-West Hwy., Silver Spring, MD 20910. Email: Mike.Cline@noaa.gov
3
Geodesist, Spatial Reference System Division, National Geodetic Survey, NOS, National Oceanic and Atmospheric
Administration, 1315 East-West Hwy., Silver Spring, MD 20910. E-Mail: Don.Haw@noaa.gov

CORS AND OPUS FOR ENGINEERS 11

 Fig. 1. Schematic map showing the coverage of all CORS sites in August of 2010

__________________________________________________________________________________________________________

NGS be consulted to obtain site specific advice on the
proposed location, choice of equipment, and
installation method; this should significantly reduce
the chance that a site is rejected or require major and
costly modifications
2) Provide the following items as a single compressed
archive file:
-At least 3 days of data in RINEX or native binary
format
-Suite of site photographs (Section E.1.)
-Complete site log (Section E.2.)
3) If between the time the site is proposed and the site is
evaluated any changes are made to the site or equipment
the site operator must update the site log and submitted
pictures as necessary.
4) The CORS Site Selection Team (SST) meets regularly
and evaluates the submitted information against the
CORS Guidelines. The site will be: accepted,
conditionally accepted, or declined. The SST consists of 5-
6 members of NGS that are involved in a variety of tasks
related to the CORS network including data analysis,
storage and distribution, site installation and software
development for GNSS processing.
If the site is conditionally accepted: The site operator must
comply with the requested changes. These may involve
changing the equipment setup, removing nearby
obstructions, or modifying metadata after which the
information is resubmitted with updated photographs, if
needed, to the SST.
If the site is accepted into the CORS network:
5) The site is transferred from the SST to the CORS
Operations and Management Team. This team will upload
all the site’s metadata to the NGS internal database.
Automated retrieval and analysis of the data will begin to
establish the coordinates and velocities for the site.

12 CORS AND OPUS FOR ENGINEERS

6) Official coordinates and velocities for the site are usually
published within 3-4 weeks after automated data
retrieval began.
7) The new site will be listed on the CORS web site and in
the CORS weekly newsletter.
8) Any changes that are made to the site or equipment must
be immediately communicated to the CORS team with a
description of the changes, e.g. new serial number(s) or
firmware versions and updated photograph(s).
If the site is declined: the site operator will be informed of
the reason why it was declined.
Guidelines for Establishing and Operating a CORS
A. General Site Operator Requirements
Since NGS does not operate the site NGS should not be
considered the primary verifier of a site’s data quality,
consequently, the site operators should have their own data
integrity checks.
The site operator must inform NGS of any planned
outages, changes in equipment and firmware -- especially
changes in receiver firmware, antenna, radome, and physical
space surrounding the antenna -- as soon as they are known
to the site operator.
A CORS site is expected to have high data quality and a
lifetime of at least 15 yrs. The latter also applies to the
critical volume of space around the antenna that should
remain undisturbed throughout the lifetime of the CORS
site. Power and internet outages should be infrequent and
short-lived.
B. Monument
Since there is no “perfect” monument, these guidelines
only aim to avoid designs that are known to cause (or are
likely to cause) data quality issues, based on designs used in
CORS/IGS (International Global Navigation Satellite
System Service) during the last 12 years.
GOALS: First, ensuring that the antenna is well
anchored to the ground is essential so the position and
velocity associated with a given site represents the crustal
position and velocity of the site, not just of the antenna or
monument. Second, minimize multipath and differences in
antenna phase center position as compared to models used
in data analysis.
B.1. Stability
A CORS monument should be designed to maximize its
stability (maintain a fixed position in a predefined three
dimensional frame) and minimize measurement of near-
surface effects. The uppermost part of the ground is subject
to the greatest amount of motion e.g. soil expansion and
contraction due to changes in water saturation, frost heave,
soil weathering, etc., thus increasing the depth of the
monument improves its stability. A detailed discussion of
benchmark stability that is equally applicable to CORS
CORS AND OPUS FOR ENGINEERS
monuments is given in (Floyd, 1978, p.1-11; Chao et al.,
2006).
CORS sites should be designed to be at least Class B and
hence minimize the impact of:
-Caverns, sink holes, and mines
-Areas where there is active fluid/gas pumping
-Frost heave, shrinking and swelling of soil and rock
-Soil expansion and contraction
-Slope instability
-Soil consolidation
-Motion intrinsic to a monument e.g. thermal expansion
and contraction
NGS strongly recommends that if the operator is in doubt
about the soil and geologic conditions, a conservative “worst
case” scenario be assumed.
B.2. Location, Obstructions and Radio Frequency
Environment
B.2.a. Location
Choose an open area with minimal obstructions and mini-
mum likelihood of change in the environment surrounding the
monument; e.g. avoid sites with future tree or shrub growth,
building additions, rooftop additions, new antenna masts,
satellite dishes, parking lots, chain link fences, etc.
B.2.b. Obstructions
No obstructions 10 degrees above the horizon from the ARP
and minimal obstructions from 0 to 10 degrees.
WHY: The greater the volume through which uninterrupted
and unreflected signal can reach the antenna, the greater the
likelihood of a robust position estimate. No lightning rods,
RTK broadcast antennas, or any other objects should extend
above the antenna or be anywhere within 3 m of the antenna
and all should be below the 0 degree of the horizontal surface
that contains the ARP.
B.2.c. Radio Frequency Environment
The signals collected by a CORS antenna and receiver can
be detrimentally affected by interference from other radio
frequency sources (e.g. TV, microwave, FM radio stations,
cellular telephones, VHF and UHF repeaters, RADAR, high
voltage power lines). This can cause additional noise,
intermittent or partial loss of lock or even render sites
inoperable. Every effort should be made to avoid proximity to
such equipment now and in the future, and all potential
equipment causing interference must be explicitly documented
in the site log.
B.3. Ground-based Monument
B.3.a. Pillar
A pillar should be approximately 1.5 m above the ground
surface to mimic the geometry used by NGS at its antenna
phase center calibration facility (Mader, 1999, 2004).
However, in light of possible obstructions (see B.2. Location,
13
Obstructions, and Radio Frequency Environment), a taller
monument may be necessary.
A pillar must have a deep foundation, Class B, that
extends at least 4 m below the frost line and/or the center of
mass of the pillar must be below the frost line (see B.1.
Stability).
The top of the pillar must be narrower than the widest part
of the antenna, and the smaller the surface the better. In
constructing the pillar, consider that future antennas may be
smaller; hence the narrower the top of the pillar the better.
The distance between the top of the pillar (if it has a surface)
and the antenna should be less than 5 cm or greater than 1
GPS wavelength (~20 cm). This will allow enough room to
manipulate a leveling and orienting device (see B.5.
Attaching Antenna, Mount, and Monument). These
recommendations apply to the top of the pillar only; a very
narrow pillar would be unstable and not recommended,
however tapered pillars are good.
WHY: This will mitigate multipath issues (e.g. Hilla and
Cline, 2004)
B.3.b. Braced
These monuments are especially stable and well anchored
to the ground, although more expensive than pillars (Beavan
2005). Extensive diagrams with details of all aspects of
construction of different type of braced monuments are
available at via UNAVCO: www.unavco.org (search under
project support, monumentation.
B.4. Roof-based Monument
B.4.a. Building characteristics
Only masonry buildings are permitted. Solid brick or
reinforced concrete ones are recommended. The building
should have been built at least 5 years previously, to
increase the likelihood that all primary settling of the
building has occurred. There should be no visible cracks on
the outside or inside walls. Buildings taller than two stories
are not recommended. No wood or simple metal frame with
metal walled buildings, and no metal roofs.
WHY: This will minimize the effects of thermal expansion
as well as multipath issues.
B.4.b. Location and Attachment to a Building
Stainless steel is recommended for longevity (angle iron
or circular pipe). Aluminum is not recommended as it has
approximately twice the thermal expansion of
steel/concrete.
The mount must be bolted directly to the main part of the
building; a load-bearing wall near a corner is recommended.
-The use of epoxy and threaded lock adhesives fasteners
(bolts/anchors/rods) is strongly recommended.
-Mounting on a chimney is not recommended unless it has
been filled with concrete or if it is particularly robust.
-The mount should not interfere with the building’s
replaceable roof. This will minimize the chance that the
mount will be disturbed when the roof is replaced.
14 CORS AND OPUS FOR ENGINEERS
Attaching laterally to a load bearing wall:
The mount should extend about 0.5 m above the roofline
and be attached to the building for a length of at least
1 m, with at least 3 anchors/bolts. The ratio of free-
standing part to bolted part should be approximately 1:3.
The bolts/anchors must penetrate directly through the
mount, e.g. no u-bolts or channel brackets with metal
ties/clamps. Spacers to keep the mount from sitting flush
against the wall are acceptable.
Attaching vertically to a master wall:
A bolt or rod must be anchored into a load-bearing wall.
Take care not to void a roof warranty. Avoid metal flashing
on a parapet wall.
B.5. Attaching Antenna, Mount and Monument
A device must exist between the monument and the antenna
that allows: First, the antenna to be leveled and oriented to
north (see B.6. Orienting Antenna). Second, if the antenna is
changed the new ARP must return to the exact same point in
3-dimensional space as the previous ARP, or the change in
position between the mark (See Nomenclature and
Definitions) and the ARP must be measured to within 1 mm.
WHY: If the antenna is simply attached to a threaded rod
when it is replaced, the new antenna may not return to the
same 3-D position or may be oriented differently (the latter
would be immaterial only if the phase center variation model
is perfectly symmetrical). Both events would require a new
position to be computed, which is undesirable.
The antenna must be leveled to within 0.15 degrees or 2.5
mm/meter (This is easily achieved using a good quality spirit
level available in most hardware stores)
Tribrachs are not permitted as there is no mechanism that
NGS is aware of to lock the adjustable wheels in place.
Consult the CORS Guidelines for a list of possible devices.
B.6. Orienting Antenna
The antenna must be oriented to true north using the
convention of aligning the antenna cable attachment point,
unless the antenna has a different inscribed North point.
Remember that declination is the angle between magnetic
north and true north. The calculated declination must be
recorded in the log file (see E.2. Site Log).
WHY: All antenna phase center patterns assume an
oriented antenna, and phase center values can be displaced by
up to one centimeter along the north and east components.
B.7. Antenna Cable
The antenna cable should not be under tension. Looping the
first section of cable next to the antenna and attaching it to the
mount can best avoid this problem. If the cable is not encased
in conduit, then care should be taken that it will not move
around and be damaged. Take particular care at any point
where the cable is subject to increased friction, e.g. edges and
egress points. Typical antenna cables for CORS
(RG213/RG214) have a signal loss of 9 db/100ft/30m at
1Ghz. Total loss for installed length of cable at a CORS
must be 9 db or less, implying a maximum cable length of
100ft/30m. If a longer cable is needed then a lower loss
cable must be used (the type, manufacturer, and length of
cable must be listed in the site log).
The antenna cable should directly connect to the receiver
and antenna, no intermediate connectors should be inserted
e.g. TNC to N-type. The junction point of the antenna after
the two have been connected should be sealed with
waterproof material e.g. butyl wrap.
Site operators are strongly recommended to insert a
lightning arrestor in the antenna cable between the antenna
and the receiver with its own independent ground. The
arrestor should be located on the outside of the building at
or near the egress point of the cable into the building. This
should protect the receiver in the event of a lightning strike
on or near the antenna.
C. Equipment
Site operators must keep all receiver firmware updated.
NGS strongly recommends that equipment be upgraded
and/or replaced as the technology changes, e.g. new signals
are added or additional GNSS constellations are available.
NGS must be informed as soon as any changes in equipment
hardware or firmware are made. Equipment changes should
however be minimized as they have the potential of
resulting in a change in position. If data quality decreases
and the site operator is unable to replace /upgrade
equipment or otherwise mitigate a problem, NGS may
choose to remove the site from the CORS network (see G.
Quality Control and Day-to-Day Site Operations)
C.1. Antenna
The antenna must be at least dual-frequency (L1 and L2).
NGS calibrated phase center values must be available for
the antenna model. If the user chooses to install a radome
(see C.2. Antenna Radome), an NGS calibrated antenna
phase center model for the antenna and radome pair must be
available. The NGS database of calibrated antenna and
radome combinations is available at:
http://www.ngs.noaa.gov/ANTCAL
WHY: A consistent phase center and ARP for the antenna
is essential to tie the GPS measurements to the mark.
Ignoring the phase center variations can lead to multi-
centimeter errors. All analysis of GPS data at NGS requires
that an NGS-validated phase center model be used to
calculate the official positional coordinates for a CORS site.
Antennas must be inspected regularly for damage.
C.2. Antenna Radome
NGS strongly recommends that no antenna radome be
used.
WHY: It is well documented (Schupler, 2001) that an
antenna radome changes the antenna phase center position.
Its benefit is limited as antennas are constructed so they do
not need the “protection” of a radome. The choice of
material used, the effects of UV radiation, as well as
possible manufacturing inhomogeneities in the thickness of
CORS AND OPUS FOR ENGINEERS
certain radomes, may create additional problems in using a
single Phase Center Variation (PCV) model for a particular
radome model. These two problems imply that either a time-
dependent effect on the PCV exists as the radome deteriorates
or a calibration of each individual radome is needed as a
general model calibration would not be valid e.g.
http://pasadena.wr.usgs.gov/scign/group/dome
If a radome is used, the antenna and radome pair must have
been calibrated together by NGS (see C.1. Antenna).
C.3. Receiver, Settings, and Power Supply
Receivers must be able to:
-Track at least L1 and L2
-Track at least 10 satellites above 0 degrees
-Automatically switch between operating modes to retain full
wavelength L2 when antispoofing (AS) is switched on
-Provide L1 C/A-code pseudorange or P-code pseudorange
and L1 and L2 full wavelength carrier phase
-Sample at a frequency of at least 30-seconds
Receivers must be programmed:
-So that no smoothing is applied to the observables
-Track with an elevation cutoff angle of 5 degrees and 0
degrees is strongly preferred
-Record at 30, 15, 10, 5 or 1-second sampling intervals
-Log hourly blocks (strongly preferred), or 24hr blocks of
GPS time.
-Track all satellites regardless of health status
WHY: The criteria used by the Department of Defense for
designating an unhealthy satellite are not always applicable
to certain CORS users.
Receivers must have an uninterrupted power supply with a
minimum of 5 minutes backup power, 30+ minutes strongly
preferred.
D. Communications and Data Archiving
All data transfers between NGS and the operator’s
distribution site must be done via the Internet.
The site operator’s web and ftp server must operate 24hrs a
day.
All data must be made freely available to the public for
NGS to distribute. All file names and associated dates must be
recorded with respect to GPS time not local or UTC.
The directory structure on the site operator’s distribution
site and file names must use specific conventions.
Manufacturer native binary files are preferred over RINEX
formatted files, but either must be made available as
compressed archives whenever possible. Details on the
naming conventions are given in the CORS Guidelines.
E. Site Metadata
E.1. Digital Photographs
A set of sharply focused digital photographs, at least 300
dpi at 5”x7”, are required to evaluate and document a site.
When taking photographs, please remember that their purpose
is to give a clear view of the equipment being used, how it is
15
assembled, as well as the space around it for someone who
has not visited the site. Jpeg format is preferred. The
photographs must include:
A photograph showing the monument (pillar/braced/
building) and antenna. The ground surface of the
building or monument and antenna must be visible.
A photograph showing the mark. If no unique mark exists
then a photograph of the threaded section of the
mount, either laterally or from above the monument
should be taken. (If the site has been collecting data
then DO NOT REMOVE the antenna and instead
ignore this photograph.
A close-up photograph that shows how the antenna is
attached to the monument.
-Four oriented (north, east, south, west) photographs taken
at the height of ARP surface. The antenna should be
included in the photograph, but it should not
significantly block the ability to view what lies
behind the antenna, stand about 3-5m away from it.
If you cannot take a photograph including the
antenna place the camera directly at the top center of
the antenna, and point the camera in the required
direction.
If the antenna is on a roof, you must include the following:
- A photograph showing “clearly” how the antenna is
attached to the building.
- A photograph showing the antenna and the roof surface.
Equipment photographs:
- A close-up photograph of the antenna showing its model
and serial number.
- A close-up photograph of the receiver showing its model
and serial number.
- A photograph of the receiver location.
These photographs must be updated if the equipment
changes or changes occur in the physical space around the
antenna.
E.2. Site Log
The site log used at NGS follows the format specified by
the IGS. This file contains all the current and historical
information about a site and details the equipment and
monument used. The site log is of equal importance as the
data collected at a site. The site log format is not particularly
user friendly, it is ASCII and as is meant for a Fortran 80
column reader. Ensuring that the log adheres to the format is
critical as NGS and other groups routinely parse the logs
using automated software. Consult the CORS Guidelines for
an online log compliance checker and additional
instructions.
F. Assessment of CORS
The main characteristics of CORS site are:
- Site operates 24 hours/day, 7 days/week
- NGS distributes data in RINEX format, publicly
- NGS maintains web site, with all metadata (photos, site
log, NGS position information)
16 CORS AND OPUS FOR ENGINEERS
- Site operator ensures NGS has accurate metadata
- NGS computes positional coordinates daily
-The NGS Online Positioning User Service (OPUS) will
automatically select CORS sites needed to compute
coordinates of data uploaded to it.
For a site to be included in the CORS network it must
significantly enhance: geographic coverage, data quality,
reliability, latency, equipment quality, etc.
G. Quality Control and Day-to-Day Site Operations
To ensure data quality NGS monitors the data provided by
the site operator using a variety of criteria. These include:
Data latency, total number of observables, pseudorange
multipath, number of slips, repeatability of coordinates,
amplitude of coordinate variation, linearity of time-series.
The combination of the aforementioned performance
measures will be used to recommend equipment upgrades for
prospective or existing sites whose data under-perform
compared to its established peers (CORS network). Certain
critical data quality issues will result in data not being posted
to the CORS online storage (e.g. loss of L1 or L2). Site
operators will be contacted to help resolve any data quality
issues identified by NGS. In addition, these performance
measures will be used to search for systematic effects in the
CORS network, such as a tendency for a model of receiver or
antenna to under-perform when compared to its peers.
References
Beavan, J. (2005). “Noise properties of continuous GPS data
from concrete pillar geodetic monuments in New Zealand
and comparison with data from U.S. deep drilled braced
monuments.” J. Geophys. Res. 110(B08410): 1-13.
Chao, K.-C., Overton, D.D., Nelson, J.D. (2006). “Design and
installation of deep benchmarks in expansive soil” J. Surv.
Eng. 132(3), 124-131.
Estey, L.H., Meertens, C.M. (1999) “TEQC: The multi-
purpose toolkit for GPS/GLONASS data.” GPS Solutions,
3(1), 42-49.Floyd, R.P. (1978). “Geodetic bench marks.”
NOAA Manual NOS NGS 1, US Department of
Commerce, National Oceanic Atmospheric
Administration, National Ocean Survey, Rockville, MD,
52 p.
Hilla, S, and Cline, M. (2004). “Evaluating pseudorange
multipath effects at stations in the National CORS
Network.” GPS Solutions 7(4), 253-267.
Mader, G.L. (1999). “GPS antenna calibration at the National
Geodetic Survey.” GPS Solutions 3(1), 50-58.
Mader, G.L. (2004). “A comparison of absolute and relative
GPS antenna calibration.” GPS Solutions 4(4), 50-58.
Schupler, B.R. (2001). “The response of GPS antennas – How
design, environment and frequency affect what you see.”
Phys. Chem. Earth., 26(6-8), 605-611.
Snay, R.A., Soler, T. (2008). “Continuously Operating
Reference Station (CORS): History, applications, and
future enhancement.” J. Surv. Eng. 134(4), 95-104.
 3
The “Online Positioning User Service” Suite
(OPUS-S, OPUS-RS, OPUS-DB)
Tomás Soler, M.ASCE1, Neil D. Weston2, Richard H. Foote3

Abstract: In March 2001, NOAA’s National Geodetic Survey (NGS) released a Web-based utility, called the Online
Positioning Users Service (OPUS), which has significantly changed how accurate positional information is obtained in surveying
and mapping applications. In particular, OPUS enables its users to submit a GPS data file to NGS via the Web; whereby the data
will be processed using NGS computers and software to determine the positional coordinates associated with the location where
the data were observed. OPUS has evolved into a suite of services, including the original OPUS static (OPUS-S) version, a rapid
static (OPUS-RS) alternative and the possibility, meeting certain criteria, of incorporating the final results (coordinates,
orthometric heights derived from GPS and GEOID09, etc.) into a recently created OPUS Data Base (OPUS-DB).

Author keywords: Online Positioning User Service; OPUS-S; OPUS-RS; OPUS-DB; GPS positioning; geodetic networks

engineers and GIS/LIS professionals who frequently use

Introduction
The National Geodetic Survey (NGS), an office of the
National Oceanic Atmospheric Administration (NOAA)
provides the framework for all positioning activities in the
Nation. The foundational elements – latitude, longitude,
elevation and shoreline information – contribute to informed
decision making and impact a wide range of important
activities including mapping and charting, flood risk
determination, transportation, land use and ecosystem
management. NGS’ authoritative spatial data, models and
tools are vital for the protection and management of natural
and manmade resources and support the economic prosperity
and environmental health of the Nation.
Thus, intertwined with NGS’ mission, is the provision of
accurate positioning for the establishment and development
of the basic framework defining the U.S. National Spatial
Reference System (NSRS). As part of this effort scientists at
NGS brought to fruition two major ideas based on the
innovative Global Positioning System (GPS) technology.
First, the Continuously Operating Reference Station (CORS)
network of permanent GPS receivers (currently about 1,500)
was established to consolidate an accurate and reliable
geodetic reference frame (Snay and Soler 2008).
Subsequently, the CORS stations were used to efficiently
disseminate accurate positioning referred to NSRS thanks to
the development of the Online Positioning User Service
(OPUS) software. The success of these two projects has
surpassed NGS’ original expectations as measured by the
compliments received from GPS users such as surveyors,
CORS and OPUS in their day-to-day work.
OPUS Fundamentals
NGS released the original OPUS static (OPUS-S) version in
2001. However, to satisfy the demands of its constituency,
NGS also implemented a rapid-static utility (OPUS-RS) that
made possible to submit high quality L1/L2 GPS data for
sessions as short as 15 minutes which, under reasonable
observing conditions, also provides centimeter coordinate
accuracies. A further step to consolidate the results was later
achieved when the possibility of uploading OPUS-S final
results into an NGS-managed data base was introduced after
launching the so-called OPUS-DB option. This OPUS
application provides interested users with the possibility of
publicly sharing their OPUS results with the rest of the
geospatial community.
The processing algorithms in all OPUS utilities use
satellite orbits from the International GNSS Service (IGS),
GPS data from a number of reference stations belonging to
regional and global networks (CORS, IGS), and a set of
computers located at NGS headquarters in Silver Spring,
MD that process the submitted GPS data. The advantage of
OPUS is that even a single user can work establishing
geodetic control using only one receiver-antenna
combination, therefore, reducing the investment in the
acquisition of multiple GPS instruments and the engagement
of extra field personnel. This single site setup scenario can
be used to collect GPS data for a period of time and
afterwards submitting it through the Internet to OPUS where

1
Chief Technical Officer, Spatial Reference System Division, National Geodetic Survey, NOS, National Oceanic and
Atmospheric Administration, 1315 East-West Hwy., Silver Spring, MD 20910. E-Mail: Tom.Soler@noaa.gov
2
Chief Spatial Reference System Division, National Geodetic Survey, NOS, National Oceanic and Atmospheric Administration,
1315 East-West Hwy., Silver spring, MD 20910. E-Mail: Neil.D.Weston@noaa.gov
3
Geodesist, Spatial Reference System Division, National Geodetic Survey, NOS, National Oceanic and Atmospheric
Administration, 1315 East-West Hwy., Silver Spring, MD 20910. E-Mail: Rick.Foote@noaa.gov

CORS AND OPUS FOR ENGINEERS 17

it will be processed with respect to reference stations from
the CORS/IGS network. OPUS results are obtained via
email typically in three to four minutes (longer for OPUS-
RS or during peak work hours) after submission.
The OPUS submittal Web page (www.ngs.noaa.gov/
OPUS/) can be link-accessed from two locations on the NGS
Web site – the main NGS homepage, or the Tools button (
Geodetic Tool Kit). The submittal page requires the user to
enter the following basic information through a
straightforward interface that contains supplementary
explanations:
1.- the user’s email address (to receive the results)
2.- observation file(s) in RINEX or most receiver raw
formats, optionally compressed
3.- vertical antenna height, in meters, from mark to ARP
(Antenna Reference Point)
4.- antenna type, chosen from dropdown menu (over 300
currently listed)
5.- the following information can be entered by clicking the
“Options” button, but is nor required:
5a- Select State Plane Coordinate System (SPC) zone
5b- Select specific CORS to include in the solution
5c- Select specific CORS to exclude from the solution
5d- Select the hybrid geoid model (default is GEOID09)
5e- Select whether extended output information is
desired
5f- Select whether XML output is desired
5g- Select whether the user wants to submit the data as a
project containing several sessions (OPUS-Projects;
in preparation)
5h- Select whether to capture a permanent user
configuration in a profile
5i- Select whether the user wants to archive the results in
the NGS GPS data base (OPUS-DB interface)
Finally, the user needs to choose the specific OPUS
processor, clicking either of the two options:
• Rapid Static (OPUS-RS) for observing sessions >15
min. and < 2 hrs
• Static (OPUS-S) for observing sessions > 2 hrs. and
< 48 hrs (can only cross UTC midnight once)
In either case, OPUS only accepts GPS observations. In the
future, NGS plans to also accept GLONASS observation
data that will be processed with corresponding GPS data.
This addition will increment the number of visible satellites
and improve the results in areas obstructed by buildings and
high surrounding mountains. OPUS only accepts data epochs
at intervals which are an integer divisor of 30 seconds (1, 2,
3, 5, 6, 10, 15, 30 seconds). Large 1 or 2 second files may
have to be converted to 30 seconds in order to prevent time-
out problems during the data upload process via the Web
portal.
OPUS Reports
The OPUS report (or output) provides coordinates for both
the realization of the 3-D International Terrestrial Reference
Frame of year 2000 (abbreviated ITRF2000 or ITRF00) and
18 CORS AND OPUS FOR ENGINEERS
the current realization, plate-fixed, of the North American
Datum of 1983 denoted NAD 83 (CORS96) (in the Pacific
tectonic plate, NAD 83 (PACP00), and in the Mariana plate
NAD 83 (MARP00); see Snay 2003) although for simplicity,
from now on, it will be truncated to NAD 83. The primary
products of each solution are the coordinates of the point
referred to the ITRF2000 frame at the mean epoch
(observation epoch) of the interval determined by the
start/end times of the session. Corresponding NAD 83
coordinates are subsequently obtained by transforming the
derived ITRF coordinates via a 14-parameter Helmert
transformation (Soler and Snay 2004) which was adopted for
use in Canada and the U.S. (Craymer et al. 2000). These
NAD83 coordinates are then transformed from the
observation epoch to a standard epoch date of January 1,
2002 (except points in Alaska determined at epoch January
1, 2003 to compensate for the Denali earthquake of 2002)
using the NAD83 velocity predicted by the Horizontal Time
Dependent Positioning (HTDP) software (Snay 1999)
(<http://ngs.noaa.gov/TOOLS/Htdp/Htdp.shtml>). In June
2008, the latest version (HTDP 3.0) was released. This
version includes a significantly more accurate model for
estimating velocities in the conterminous U.S. that previous
HTDP versions (Pearson et al. 2010). These authors also
encoded transformation parameters between ITRF2005 and
NAD 83(CORS96). In the near future, NGS will switch to
ITRF2008 and NAD 83 (CORS96A). The latter will be
defined so that the 14-parameter transformation between it
and NAD 83 (CORS96) will be the identity function. In
about 12 years, in conjunction with introducing a new
vertical datum for the U.S., as a result of the GRAV-D
(Gravity for the Redefinition of the American Vertical
Datum) project, NAD 83 will be replaced by a geocentric
terrestrial reference system, yet unnamed. That reference
frame may or may not be plate fixed, and user input is being
solicited on this very topic. (<http://www.ngs.noaa.gov/
2010Summit/Improving_the_NSRS.pdf>).
The standard OPUS output also provides the Universal
Transverse Mercator (UTM) coordinates globally and 2-D
coordinates in the State Plane Coordinates System (SPCS)
inside the U.S. For completeness, both projections include
the convergence, the point scale on the map, and the
combined factor involving the elevation reduction factor. For
advanced users who desire to investigate in detail the
adjustment of vector components, OPUS also has the option
of selecting an extended output containing more exhaustive
information.
OPUS will always use the best available orbit file for
processing. If an OPUS submission is made within a few
hours after the end of the user’s observing session, OPUS
will use the Ultra-rapid orbit file because that is the first
version that is available. If, however, there is a delay of a
day or two before the submission, the Rapid orbit will then
be available and will be used. The OPUS output will report
which orbit file was used. More information about the
effects of IGS orbits on OPUS is available at (Griffiths et al.
2010). For most users, the resulting coordinate accuracy
improvement realized in going from a solution based on the
Ultra-rapid orbits, which are partially predicted, to the Rapid
orbits, which are based fully on observations, warrants the
effort of waiting a day or so and resubmitting the file to
OPUS for reprocessing with the improved orbits. The
effective improvement for most users (working with
baselines up to several hundred kilometers in length),
however, in going from a solution based on the Rapid orbits
to one utilizing the Final precise orbits (available after 2
weeks) is so minimal that resubmission is typically not
warranted. OPUS processing utilizes 30-second sampling
rates and, although users often collect data at a faster rate,
there is no advantage (nor is any harm done, assuming the
sampling rate in the submitted file is an integer divisor of
30) to submitting higher-rate data.
There is a plethora of papers written describing the
different aspects of all types of OPUS versions and some of
their applications. Among them, see for example: Mader et
al. (2003), Stone (2006), Lazio (2006), Soler et al. (2006b),
Soler and Hernández-Navarro (2006), Lazio (2007), Weston
et al. (2007b), Martin (2007), Weston et al. (2009), and
Lazio (2010). The basic characteristics of the different
OPUS services briefly follow.
OPUS Static (OPUS-S)
As mentioned above, in order to provide GPS users with
easier access to the NSRS, NGS developed the Web-based
OPUS-S service (originally called just “OPUS”), which
enables its potential users to submit static GPS observation
files to NGS via Internet. OPUS-S computes positional
coordinates for the location associated with the GPS
observed data using NGS computers and the software
package called PAGES: Program for the Adjustment of GPS
Ephemerides (Schenewerk and Hilla 1999).
Final OPUS-S-derived coordinates reported back to the
submitter are the average of three separate single-baseline
solutions processed using the rover as unknown station from
the GPS measurements collected at the rover and the
corresponding data observed at each of three CORS. A
double differenced, ionospheric-free mathematical model is
implemented by NGS’ GPS processing software package,
PAGES, relying only on carrier-phase measurements which
are intrinsically more accurate that the pseudo-ranges. One
step before the baselines are processed, OPUS-S must first
determine the CORS sites that PAGES will use. This is an
iterative procedure involving a number of tests that examine
the availability and quality of data collected at candidate
stations, beginning with the optional user-specified sites,
which may include CORS sites which are closest to the
user’s data collection location. Data quality issues that are
investigated include signal multipath and cycle slips, the
presence of which can degrade the results’ accuracy. If the
GPS data of the user selected CORS or the closest CORS are
deemed insufficient – in quality or quantity – the search is
then expanded outward and other potential CORS data files
are examined, until three sites with suitable data are
identified. Typically, the result of the CORS selection
process is that the three closest CORS are picked, but there
are exceptions to this generalization. One such situation
could occur if a user performs an OPUS-S submittal with
CORS AND OPUS FOR ENGINEERS
very little delay following the end of the observing session.
Because some CORS sites transmit data to NGS only daily
while others do so hourly or in real time, data from some
nearby CORS might not yet be available for the required
time period, and OPUS-S would then expand its search to
more distant sites in order to find adequate data coverage.
This problem is just as important when using OPUS-RS that
uses up to nine CORS stations. It is important to note,
however, that users are allowed to submit their data as soon
as desired after it is collected. Because many CORS sites do
provide data to NGS on an hourly or real-time basis, there
will normally be a sufficient number of CORS with valid
data to allow OPUS to work, even with very little time delay
following the end of the user’s session. The CORS utilized
in such a situation, however, might be much more distant
than they would be if the user were to wait a number of
hours before submitting. To derive the ITRF results, OPUS
retrieves the published ITRF positions for the selected
CORS from the NGS Integrated Database. These coordinates
are then transformed (using HTDP) to the epoch represented
by the mid-point of the time span of the user’s data file, to
accommodate the plate 2-D rotation-induced changes (e.g.
approximately 1-2.5 cm annually for locations on the North
America tectonic plate) of ITRF coordinate values. In the
future a full 3-D time-variant transformation of coordinates
is envisioned. The time-transformed coordinates are then
used in the three distinct PAGES solutions that are
ultimately averaged to determine the final ITRF coordinates.
The OPUS-S output page contains a concise summary of
the results as processed automatically from the submitted
observation file. In addition to echoing back all of the user’s
input information, the output includes the following (marked
with a solid square are the parameters common to OPUS-
RS):
 IGS GPS satellite ephemeris used (Ultra-Rapid, Rapid, or
Final)
start/stop GPS time of observation file
- number of observations used/present and % used
- number of integer ambiguities fixed/total and % fixed
- overall RMS of vector processing
 NAD 83 (epoch 2002.000) and ITRF2000 (observation
epoch) coordinates in Cartesian (X, Y, Z) and curvilinear
latitude, longitude, and ellipsoid height
 NAVD 88 orthometric height based on Geoid09 model
- peak-to-peak error for each coordinate components
 UTM and SPCS metric planar coordinates, convergence,
and scale factors
 U.S. National Grid designator
 name, position, and distance to each CORS/IGS site used
in the OPUS solution
 published NGS control point nearest to the observation
point
And if the user requests the optional extended output, the
following information is included in the email:
 for each CORS, summary of derivation of time
transformed ITRF coordinates
 for user’s location (“rover” station), summary of
derivation of time transformed starting coordinates
19
 for each baseline, summary of derivation of coordinates
(Cartesian and curvilinear) at the “rover” point.
 G-file vector records for use in NGS’ ADJUST software
- Post-fit RMS residuals organized by satellite and baseline
- summary of number of double-difference observations
organized by satellite and baseline
- covariance matrix elements of computed coordinates for
inclusion in network adjustment software
- estimate of horizontal and vertical network accuracies
- summary of derivation of NAD83 vector components
- SPCS planar coordinates in feet, if a specific meter-to-foot
conversion has been adopted by the corresponding State
- a prototype orthometric height computed from the
ITRF2000/GRS-80 ellipsoid height and the latest
gravimetric geoid model from NGS
The OPUS-S final coordinates for the rover point are the
average of three baseline solutions. It should be emphasized
here, that the three distinct solutions, each based on a
connection to one of the three CORS, are not statistically
independent of each other. This is due to the fact that all
three solutions are affected by the atmospheric conditions at
the observing site. Each baseline solution is also affected by
other systematic errors at the rover, such as antenna height
and centering errors and multipath, among others.
The Web interface for OPUS-RS is the same as that for
OPUS-S. Most of the information and explanations offered
for OPUS-S also apply to OPUS-RS. Most of the options,
such as allowing the user to select reference stations and/or
the state plane coordinate zone, are also the same. The
reports returned to the user are also very similar.
OPUS-S Accuracies
The most important statistics to be concerned with when one
receives the OPUS-S report are the peak-to-peak errors
associated to the X, Y, and Z geocentric values and,
similarly, to the latitude, longitude, ellipsoid height, and
orthometric height (NAD 83 solution only) values. Peak-to-
peak errors (also called ranges) are simply the difference
between the maximum and minimum value of the three
estimates for each coordinate component. The peak-to-peak
errors provide a more straightforward characterization of the
quality of results compared with the formal errors derived
from GPS vector processing, which due to the typically high
weights (small standard errors) attached to the GPS
observables. The formal standard errors are known to be
unrealistically optimistic. In addition to providing more
meaningful estimates of the precision of the solutions, the
peak-to-peak errors have the added consideration that they
also reflect any error in the values to which the CORS
coordinate were fixed. The final quality of any OPUS-S
result is, in part, dependent on freedom from any systematic
errors in the process. Most typical user-caused errors are
related to the GPS antenna – errors in measuring or inputting
the mark-to-antenna’s ARP (in meters) vertical offset,
centering the antenna over the mark, or selecting the correct
antenna type on the OPUS submittal page. The use of an
incorrect antenna type could cause OPUS to use the wrong
20 CORS AND OPUS FOR ENGINEERS
antenna electronic phase center variation model during
processing and may lead to an error in height as great as 10
cm, or more. Systematic errors such as these would neither
be detected by OPUS nor would they be reflected in the
peak-to-peak errors. Besides the statistical information
inherent in the peak-to-peak values, the following list
provides a guideline set of minimum OPUS-S output criteria
that will help the user identify when an OPUS-S run has
been successful:
- > 90% of submitted observations have been used
- > 50% of integer ambiguities have been fixed
- < 3 cm for the overall RMS error of residuals
- < 5 cm peak-to-peak errors, in each component
- observers should confirm that the correct antenna type and
height were entered.
For OPUS-S users desiring to improve their results, the
obvious advice that may be given is quite simple: collect
more data (see Eckl et al. 2001; Snay et al. 2002).
Soler et al. (2006a) investigated the relationship between
the duration of observing session and coordinate accuracy
achieved by OPUS-S (at that time called OPUS). By
utilizing 30 days of CORS data, subdivided into sessions of
1, 2, 3, and 4 hours and submitting these test datasets to
OPUS-S, the authors compared the results with the
published positions of the CORS sites, corroborating that a
session of 2 hours is the minimum time needed to, on
average, provide reasonable RMS errors (0.8 cm north; 2.1
cm east; and 3.4 cm in ellipsoid height) for many surveying-
related tasks. Applications that are more demanding, in
terms of accuracy, will require longer datasets. The results
for the 3- and 4-hour sessions show substantial improvement
compared with the results for 2-hour sessions. Furthermore,
the study shows that a reduction of session length to 1 hour
greatly deteriorates the accuracy, due primarily to the
inability of the software to adequately determine the integer
ambiguities as a result of atmospheric (primarily
tropospheric delay) conditions. Another NGS study (Weston
et al. 2009) tested the submission to OPUS-S of over 200 2-
hour test datasets, again collected at CORS sites, to examine
the accuracy achieved with the recommended session length.
The results (RMS values of 0.8 cm, 1.4 cm, and 1.9 cm in
the north, east, and ellipsoid height components,
respectively) were slightly better, particularly in the vertical
(ellipsoid height) component, than the results earlier
mentioned. Previously, Eckl et al. 2001 have shown that for
static GPS processing, there is little relationship between the
achieved coordinate accuracies and the distance between
GPS receivers (the maximum baseline used in the
investigation was 280 km), assuming that there is adequate
observation data to fix the integer ambiguities and to
correctly estimate the tropospheric delay. The impact of the
results of these aforementioned studies is that OPUS-S users
can expect to achieve good results as long as they have
collected and submitted a sufficient quantity of data (> 2
hrs.) from a good quality collection site, even if OPUS-S
uses three CORS sites that are located at great distances
from the rover site.
Rapid Static OPUS (OPUS-RS)
OPUS-RS is the Rapid Static alternative of the National
Geodetic Survey’s On-line Positioning User Service
(OPUS). Like OPUS-S, OPUS-RS accepts a user’s GPS
tracking data and uses corresponding data from the CORS
network to compute the 3-D positional coordinates of the
user’s data-collection point, called the rover.
Research conducted by the Satellite Positioning and
Inertial Navigation (SPIN) group at The Ohio State
University (Wielgosz et al. 2004; Kashani et al. 2005;
Grejner-Brzezinska et al. 2005; Grejner-Brzezinska et al.
2007 ) originally developed a Multi Purpose GPS (MPGPS)
software from which NGS derived and implemented the
Rapid Static GPS (RSGPS) software (Schwarz 2008).
Thus, OPUS-RS uses a new processing engine, called
RSGPS, which is totally different from the PAGES software
used by OPUS-S. Experiments have shown that OPUS-RS
can generate coordinates with an accuracy of a few
centimeters for GPS data sets spanning as little as 15
minutes of time. OPUS-RS achieves such results by
computing the atmospheric delays, measured at several
CORS located within 250km of the rover, to predict the
atmospheric delays experienced at the rover. This prediction
involves an interpolation if the rover is located inside the
CORS-defined polygon or an extrapolation is the rover is
located outside the polygon. Consequently, standard errors
of computed coordinates depend highly on the local
geometry of the CORS network and on the distances
between the rover and the local CORS. Another major
difference with respect to OPUS-S is that OPUS-RS,
restricted by the possibility of using sessions as short as 15
min., requires four data types (L1, L2, P1(or C1), and P2) to
obtain a meaningful solution. The OPUS-RS search
algorithm sorts stations in the CORS network by distance
from rover. It selects up to nine CORS that are less than 250
km from rover and that have suitable data. No solution is
attempted if fewer than three CORS sites are selected, and
no solution is attempted if the distance from the rover to the
polygon enclosing the selected CORS sites is greater than 50
km.
Shorter dual-frequency data files, between 15-minutes and
2-hours in duration, are processed using the RSGPS
software. RSGPS employs more aggressive algorithms to
resolve carrier phase ambiguities but has more stringent data
continuity and geometry requirements; therefore, there are
many remote areas of the country in which OPUS-RS will
not work.
OPUS-RS uses RSGPS in two modes: network and rover.
In network mode, at least one hour of data from the selected
CORS (obtained from NGS GPS archives) are used to solve
for integer ambiguities, tropospheric refraction parameters,
and the double difference ionospheric delays at these CORS
with the coordinates of the CORS held fixed. In rover mode,
the ionospheric and the tropospheric parameters (from an
existing network-mode solution) are interpolated (or
extrapolated) from the selected CORS to the rover. Then the
delays at the rover are constrained to solve for the positional
CORS AND OPUS FOR ENGINEERS
coordinates of the rover. Again, the positional coordinates
of the CORS are held fixed.
Because in contrast to OPUS-S, the geometry of the CORS
sites is an important factor for obtaining an accurate OPUS-
RS solutions, a unitless parameter called the “interpolative
dilution of precision” (IDOP) that quantifies the local
geometry of the CORS network relative to the rover, was
introduced by Schwarz et al. (2009).
The estimated standard errors of the OPUS-RS-determined
coordinates may be estimated by using a function of the
form (Soler et al. 2010):
σ ( IDOP , RMSD ) = (α ⋅ IDOP ) + ( β ⋅ RMSD ) + γ
2 2 2
…………….(1)
Here ,  and  are constants, and RMSD equals the root-
mean-square distance between the rover and the individual
CORS involved in the OPUS-RS computations. The study
determined that for a 15 minute session  = 6.34 ± 0.13 cm,
 = 0.129 ± 0.031 ppm and  = 1.52 ± 0.57 cm in ellipsoid
height and that  = 1.78 ± 0.13 cm,  = 0.043 ± 0.006 ppm
and  = 0.31 ± 0.15 cm in either the east-west or north-south
dimension.
OPUS-RS Accuracies
Under reasonable conditions, OPUS-RS can easily
determine most positions with a few centimeters of accuracy
(see Soler et al. 2010). Estimating the accuracy for a specific
data file is difficult however as formal error propagation is
notoriously optimistic for GPS reductions. Instead, of the
peak-to-peak errors provided by OPUS-S, OPUS-RS gives
simple standard deviation (1) obtained through a
simultaneous least-squares adjustment.
The mathematical relationship between peak-to-peak
(range) errors and the sample standard deviation () was
investigated by Schwarz (2006) that arrived at the following
equation:
peak-to-peak = 1.6929 ×  (2)
The above formula shows that the peak-to-peak is a
statistic 1.6929 times larger than the sample standard error
and, therefore, more pessimistic than the standard deviation.
In other words, the coordinate results from OPUS-S,
realistically speaking, are actually known better than the
peak-to-peak errors would seem to imply. However, in
general, when doing statistical analysis, the statistic of
preference by most investigators is the standard deviation
often approximated by Root Mean Square (RMS) of the
deviations from the mean. The main reason why the range
(peak-to-peak) was selected as the statistic of choice for
OPUS-S is because with a sample of three quantities, one
cannot determine a meaningful standard error. OPUS-RS
does a simultaneous least-squares adjustment of all available
observations, thus the output in its report contains standard
errors.
When the values of an OPUS-RS solution are interpreted
one should check first for the magnitude of the standard
21
errors associated with each coordinate. As a second
alternative, when these values are not inside the tolerances
required by any given project, the user should rely in the
warning messages printed in the report to corroborate the
possible problems causing the unexpected accuracies.
OPUS-RS warning messages are issued for (see Schwarz
(2008) for more details):
• Quality indicators (based on the W-ratio from the
LAMBDA validation test) that are suspiciously low
• Normalized RMS (unitless) residual that is
suspiciously high.
• Coordinate standard deviations that are suspiciously
high.
Since RSGPS uses the double difference ionospheric
delays at the CORS to interpolate the delays at the rover, it
may not work during periods of high ionospheric
disturbance. In fact, it is best to avoid performing any GPS
survey during geomagnetic storms that cause large and
variable ionospheric refraction. Geomagnetic storm alerts
are issued by NOAA's Space Weather Prediction Center
(<http://www.swpc.noaa.gov>), so that the surveyor may
avoid collecting data during these unusual events. Similarly,
RSGPS performs a simple geographic interpolation to
predict the tropospheric delay at the location where the
user’s GPS data was observed. Under normal conditions this
works well. However, it may not work well during the
passage of a strong weather front, and these situations should
be avoided. There are a significant number of error messages
printed out in the OPUS-RS report to help users to better
understand the possible errors affecting the solutions. The
basic information for understanding OPUS-RS error
messages is given in (Choi 2010).
OPUS Data Base (OPUS-DB)
OPUS-DB, otherwise known as OPUS Database or OPUS
“sharing” is a mechanism for allowing OPUS-S users to
have the resulting OPUS report, along with two user
submitted photos, entered into the NGS managed OPUS-DB
database. The OPUS database is not fully linked to the
conventional NGS Integrated Database (NGSIDB), but it
may be in the future. Submissions can be for new marks, or
for recoveries (marks that exist in the NGSIDB). Fig. 1
shows a schematic flow chart of the interaction between
OPUS-S (formerly OPUS) and OPUS-DB. The diagram is
self explanatory.
A sample OPUS-DB Datasheet is shown in Fig. 2. The
datasheet contains several blocks of pertinent information.
The top left section next to the photo of the mark, gives brief
but specific metadata about the monument. This information
is exclusive to the OPUS-DB datasheet and is not reported in
the OPUS-S output. However, the information reported in
the middle of the OPUS-DB datasheet is exactly the same as
that the user will receive when submitting the same GPS
data file to OPUS-S. The only difference is that ITRF2000
coordinates at the mean epoch of observation are not
22 CORS AND OPUS FOR ENGINEERS
provided. The reason for their absence is that most
applications envisioned by users of this data base are
restricted to work to be referred to NAD 83. As described
before in conjunction with OPUS-S, the statistics associated
to the coordinates are peak-to-peak errors. Notice that the
person who submits the GPS data to OPUS-S (presumably
the observer) and his affiliation are identified in the
datasheet. This is one of the important caveats of using
OPUS-DB. The submitter and/or his/her organization are
solely responsible for the numbers appearing in the
datasheet, not NGS. The bottom of the report shows a
picture of the instrument set up and the location of the point
on a Google map.
Fig. 1. Schematic flow chart showing how OPUS-S
results could be integrated into the OPUS database
A sample OPUS-DB Datasheet is shown in Fig. 2. The
datasheet contains several blocks of pertinent information.
The top left section next to the photo of the mark, gives brief
but specific metadata about the monument. This information
is exclusive to the OPUS-DB datasheet and is not reported in
the OPUS-S output. However, the information reported in
the middle of the OPUS-DB datasheet is exactly the same as
that the user will receive when submitting the same GPS
data file to OPUS-S. The only difference is that ITRF2000
coordinates at the mean epoch of observation are not
provided. The reason for their absence is that most
applications envisioned by users of this data base are
restricted to work to be referred to NAD 83. As described
before in conjunction with OPUS-S, the statistics associated
to the coordinates are peak-to-peak errors. Notice that the
person who submits the GPS data to OPUS-S (presumably
the observer) and his affiliation are identified in the
datasheet. This is one of the important caveats of using
OPUS-DB. The submitter and/or his/her organization are
solely responsible for the numbers appearing in the
datasheet, not NGS. The bottom of the report shows a
picture of the instrument set up and the location of the point
on a Google map.
 Fig. 2- Datasheet example for a point (BBBS77) observed by NGS staff

status email from NGS headquarters, the user has another

OPUS-DB Restrictions
The objective of NGS by creating a data base of GPS-
positioned points requires the introduction of accuracy
restrictions to the submitted data in order to avoid spurious
or low quality information. Besides making sure that all
submitted data processed with OPUS-S are inside the
adopted tolerances, an in-house review of each submission is
performed to ratify the quality of the results. Fig. 3 shows at
the bottom the publishing requirements established by NGS
to assure that all published information is correct. If the
results are not inside the tolerances adopted by NGS, then
the OPUS-DB submitter will receive an email to that effect.
Then it is up to the user of the service to carefully scrutinize
the data and find where the problem may lay before
resubmitting any GPS files. Upon receipt of the submittal
chance to cancel or confirm the submission.
NGS has received many favorable reviews of OPUS-DB
from the surveying and mapping community, and the
popularity of this option is increasing rapidly. As of August
2010, approximately 2,500 submittals have been entered into
the OPUS Database, with approximately 70% representing
new marks and 30% representing recoveries of marks that
already had datasheets exist in the NGSIDB. Questions
about OPUS-DB can be sent to ngs.opus_db@noaa.gov.
Conclusions
OPUS is a well established Web service in which the user
can submit GPS data and obtain accurate positions that
primarily depend on the time span of the observed data,

CORS AND OPUS FOR ENGINEERS 23

 Fig. 3– OPUS-DB page showing the publishing requirements enforced by NGS before a solution is accepted
_______________________________________________________________________________________________________

Fig. 4– OPUS usage by county from September 2009 to August 2010

24 CORS AND OPUS FOR ENGINEERS

satellite visibility, and the atmospheric conditions at the
time the data was collected as well as share those position
solutions in a dynamic datasheet format. The positioning
services offered in OPUS are restricted to static (and rapid-
static) surveys and their main purpose is the establishment
of geodetic control. OPUS is the primary suit of software
used by many surveyors and engineers to support this kind
of work. As an extension of this application, the possibility
of using OPUS for establishing control for RTK work is
obvious. The coordinates of the base station to be used at
any project performed using RTK equipment can be
accurately determined by sending the data to OPUS from
the field, if possible, or after returning to the office. For
example, another common application is establishing
ground control for aerial mapping. Consequently, the
applications of OPUS cover the full spectrum of geodetic,
land surveying, surveying engineering, mapping and GIS
endeavors. The evidence to support this conclusion is in the
usage numbers. The popularity of OPUS users has been
increasing substantially with time. Today’s usage is
typically in the range of 16,000 and 9,000 files processed
per month for OPUS-S and OPUS-RS respectively. The
annual growth is approximately 32 percent for both
services. The combined number of OPUS-S and OPUS-RS
files processed during the September-2009 through August-
2010 period was 256,740. Fig. 4 depicts the combined
usage of OPUS-S and OPUS-RS by county during this 12
month period.
Future OPUS Plans
NGS presently has tentative plans for several future
additional services for OPUS that will greatly improve its
usefulness and flexibility. In the proposed forthcoming
enhanced OPUS more options will be available to the user.
It is important to note that the proposed OPUS additions
mentioned below, although at an advanced stage of
development, may be subject to change of name or even
operational steps and specific procedures as is the case with
the introduction of any new software. Each of these
potential new additions to OPUS will have specific
procedures expanding the spectrum of surveying and
mapping applications.
“OPUS-Projects” This addition to OPUS is a multi-
receiver, static processing tool. It will allow users to submit
several GPS sessions collected by a set of several receivers.
PAGES will process selected (or defaulted) baselines
between the multiple receivers and the selected CORS sites.
All sessions will be adjusted in a simultaneous least squares
adjustment that will contain many stations and many days
of observations (Weston et al. 2007a). There is no
restriction on the number of receivers allowed except the
limitation that the observation span of the sessions must
overlap. In OPUS-Projects the OPUS solutions can be
emailed to any number of persons associated with the
project, allowing data collection and quality to be closely
monitored. The data is also delivered to the project
directory for network processing as data collection for each
CORS AND OPUS FOR ENGINEERS
day is completed (Mark Schenewerk, private
communication). At the end, the project manager, will
monitor the data collection and final quality of the results.
Daily network solutions could be processed while the
project is underway providing near real-time feedback to
project personnel. Future plans call for the incorporation of
select OPUS-Projects results into NGS-managed data base.
OPUS-Net. This addition to OPUS is a single receiver,
static processing tool which will likely replace OPUS-S
over time. Initially uses 24 hours of data and only IGS
stations as fiducial points to determine the best coordinates
of the CORS sites. Then, it uses PAGES but does not solve
for only three baselines. Instead it has the capability of
selecting up to 10 CORS/IGS stations and performs a
simultaneous weighted least squares adjustment to solve for
the rover position, while allowing non-IGS CORS sites
coordinates to float. In addition, ocean tidal loading is
accounted for and implemented (Weston and Ray 2010).
The advantage of this procedure is that unknown systematic
errors affecting the coordinates of the non-IGS CORS sites
will be avoided.
“OPUS-Mapper”. This addition to OPUS is a single
receiver, static or kinematic processing tool. It will accept
single frequency data and kinematic data. This software
focuses on obtaining acceptable positioning results for the
mapping and GIS communities who may not be using
expensive, dual frequency geodetic receivers. Thus, it will
involve the use of very short occupation times and
differential range solutions to CORS to achieve coordinates
accuracies of a meter or better. A static as well as a
kinematic trajectory report will be provided. (Gerald
Mader, private communication).
Finally, the intent of NGS is to modify OPUS by making it
a seamless software package capable of discerning,
depending of the length of time submitted, which of the two
versions (OPUS-S or OPUS-RS) should be used in
processing the data. As a result of this implementation, GPS
sessions of less than 2 hrs would automatically be
processed by OPUS-RS while sessions longer than 2 hrs
would be sent to OPUS-S for processing without the direct
intervention of the user. The output report would be
consistent with the version of OPUS selected.
Acknowledgments
The authors of this paper would like to thank Dr. Richard
Snay for his thorough review of the manuscript.
References
Choi, K.K. (2010). “Understanding error messages
generated by the Rapid Static Online Positioning User
Service (OPUS-RS).” Article published in this
Monograph.
Craymer, M., Ferland, R., and Snay, R. (2000).
“Realization and unification of NAD 83 in Canada and
25
 the U.S. via the ITRF.” In Towards an Integrated
Global Geodetic Observing System (IGGOS), R. Rumel,
H. Drewes, W. Bosch, and H. Hornik, eds., IAG Section
II Symp., International Association of Geodesy
Symposia, Vol. 120, Springer, Berlin, 118-121.
Eckl, M.C., Snay, R., Soler, T., Cline, M.W., and Mader,
G.L. (2001). “Accuracy of GPS-derived relative
positions as a function of interstation distance and
observing-session duration.” J. Geodesy, Berlin, 75(12),
633-640
Grejner-Brzezinska, D.A., Weilgosz, P., Kashani, I., Mader,
G., Smith, D., and Robertson, D. (2005) “Performance
assessment of the new rapid static module of the Online
Positioning User Service -- OPUS-RS.” Proc. ION
GNSS 18th Int. Tech. Meeting Satellite Div. Institute of
Navigation, pp. 2595-2605.
Grejner-Brzezinska, D.A., Weilgosz, P., Kashani, I., Smith,
D.A., Spencer, P.S.J., Robertson, D.S., and Mader, G.L.
(2007) “Efficiency and reliability of ambiguity
resolution in network-based real-time kinematic GPS.”
J. Surv. Eng., 133(2), 56-65.
Griffiths, J., Ray, J., and Weston, N.D. (2010). “A synopsis
of the IGS orbits used in OPUS.” Article published in
this Monograph.
Kashani, I., Weilgosz, P., Grejner-Brzezinska, D.A., and
Mader, G.L. (2005) “A new network-based rapid-static
module for the NGS Online Positioning User Service --
OPUS-RS.” Proc. ION Annual Meeting. Institute of
Navigation, pp. 928-936.
Lazio, P. (2006). “OPUS observations.” Surv. Land Inf.
Sci., 66(3), 185-194.
Lazio, P. (2007). “Constraining Network Adjustments to
OPUS-RS Coordinate Observations.” J. Surv. Eng.,
133(3), 106-113.
Lazio, P. (2010). “OPUS-RS Pair Points - A case study.” J.
Surv. Eng., 136(2), 91-99.
Martin, D. (2007). “Geodetic connections. OPUS Rapid
Static.” The American Surveyor, 4(3), 44, 46-48
Mader, G.L., Weston, N.D., Morrison, M.L., and Milbert,
D.G. (2003). “The On-line Positioning User Service
(OPUS).” Professional Surveyor, 23(5), 26, 28, 30.
Pearson, C., McCaffrey, R., Elliot, J.L., and Snay, R.
(2010). “HTDP 3.0: Software for coping with the
coordinate changes associated with crustal motion.” J.
Surv. Eng., 136(2), 80-90.
Schenewerk, M., and Hilla, S. (1999). “PAGES: Program
for Adjustment of GPS Ephemerides.”
<http://www.ngs.noaa.gov/GRD/GPS/DOC/pages/
pages.html> (August 31, 2010)
Schwarz, C.R. (2006). “Statistics of range of a set of
normally distributed numbers.” J. Surv. Eng., 132(4),
155-159
Schwarz, C.R. (2008). “Heuristic weighting and data
conditioning in the National Geodetic Survey Rapid
Static GPS software.” J. Surv. Eng., 134(3), 76-82
Schwarz, C.R., Snay, R.A., and Soler, T. (2009). “Accuracy
assessment of the National Geodetic Survey's OPUS-RS
utility.” GPS Solutions, 13(2), 119-132.
26 CORS AND OPUS FOR ENGINEERS
Snay, R.A., and Soler, T. (2008). “Continuously Operating
Reference Station (CORS): History, applications, and
future enhancements.” J. Surv. Eng., 134(4), 95-104.
Snay, R.A. (2003). “Introducing two spatial reference
frames for regions of the Pacific Ocean.” Surv. Land Inf.
Sci., 63(1), 5-12.
Snay, R.A., Soler, T., and Eckl, M. (2002). “GPS precision
with carrier phase observations: Does distance and/or
time matter?” Professional Surveyor, 22(10), 20, 22, 24.
Snay, R.A. (1999). “Using HTDP software to transform
spatial coordinates across time and between reference
frames.” Surv. Land Inf. Sys., 59(1), 15-25.
Soler, T., and Snay, R.A. (2004). “Transforming positions
and velocities between the International Terrestrial
Reference Frame of 2000 and North American Datum
of 1983.” J. Surv. Eng., 130(2), 49-55.
Soler, T., and Hernández-Navarro, A. (2006). “OPUS
becomes available in Mexico.” The American Surveyor,
3(9), 46-49
Soler, T., Snay, R.A., Schwarz, C.R., and Choi, K.K.
(2010). “Accuracy of Rapid Static Online Positioning
User Service (OPUS-RS) revisited.” Article published
in this Monograph.
Soler, T., Michalak, P., Weston, N.D., Snay, R.A., and
Foote, R.H. (2006a). “Accuracy of OPUS solutions for
1- to 4-h observing sessions.” GPS Solutions, 10(1), 45-
55.
Soler, T., Weston, N.D., Snay, R.A., Mader, G.L., and
Foote, R.H. (2006b). “Precise georeferencing using the
On-line Positioning User Service (OPUS).” Proc. XXIII
International FIG Congress, 8-13 October 2006,
Munich, Germany, 12p.
Stone, W. (2006). “The evolution of the National Geodetic
Survey's Continuously Operating Reference Station
network and Online Positioning User Service.” Proc.
2006 ION-IEEE Position, Location, and Navigation
Symp., Institute of Navigation (ION), Fairfax, Va., and
Institute of Electrical and Electronics Engineers (IEEE),
Piscataway, N.J., 653-663.
Weston, N.D., and Ray, J. (2010). “Test of the use of
regional networks for OPUS processing.” EGU General
Assembly, Vienna, 2-7 May 2010 (Poster).
Weston, N.D., Soler, T., and Mader, G.L. (2009). “Rover
station positional accuracies from OPUS as a function
of reference station spacing and rover station occupation
time.” Proc. FIG Working Week, Eilat, Israel, 3-8 May
2009, 11 p.
Weston, N.D., Mader, G.L., and Soler, T. (2007a). “OPUS
Projects - A Web-based application to administer and
process multi-day GPS campaign data.” Proc. FIG
Working Week, Hong Kong, May 13-17, 10p.
Weston, N.D., Soler, T., and Mader, G.L. (2007b). “Web-
based solution for GPS data. NOAA OPUS.” GIM Int.,
21(4), 23-25
Wielgosz, P., Grejner-Brzezinska, D., and Kashani, I.
(2004). “Network approach to precise GPS navigation.”
Navigation, 51(3), 213-220.
 4
A Synopsis of the IGS Orbits Used in OPUS
Jake Griffiths1, Jim Ray2, and Neil D. Weston3

Abstract: The purpose of this short note is to provide a brief overview of the Online Positioning User Service (OPUS) and the
Global Positioning System (GPS) satellite orbits used in a processing session. Thus, this note summarizes basic information
about the orbits, including which orbits are used by OPUS, where the orbits can be retrieved and the level of inaccuracy of the
orbits. Then, using a well-known expression relating orbit error to positioning error (i.e., Beser and Parkinson, 1982), we show
that errors in current IGS orbits are insignificant for mm-level positioning using OPUS.

Author keywords: IGS orbits; OPUS; station position; GPS positioning; geodetic networks

positions of the satellites and CORS. The strategy of forming

Introduction
double-difference observation equations is chosen because it
eliminates common-mode errors, mainly from the station
The Online Positioning User Service (OPUS) is a free,
and satellite clocks, at the rover and base stations. For
highly automated web-based suite of products provided at
information about the performance of OPUS-S and the
http://www.ngs.noaa.gov/OPUS/ by the National Geodetic
PAGES engine, we defer to the several researchers who have
Survey (NGS) of the National Oceanic and Atmospheric
written on this topic (i.e., Eckl et al. 2001; Mader et al. 2003;
Administration (NOAA) for the processing of carrier phase
Soler et al. 2006; Griffiths et al. 2009; Kass et al. 2009;
observations of the Global Positioning System (GPS).
Rohde et al. 2009; Weston et al. 2009).
Currently, there are two positioning products in the OPUS
OPUS-RS accepts files containing between 15 minutes and
suite: OPUS-S (Static) and OPUS-RS (Rapid Static). The
2 hours of observations. Like OPUS-S, OPUS-RS also asks
processing engine in OPUS-S is the Program for the
for basic user information, and returns positioning results
Adjustment of GPS Ephemerides (PAGES) software (e.g.,
(including a formal accuracy estimate of the error in the
Schenewerk 1991), the same engine used by NGS for
rover position) to the user’s email address usually within
maintaining position and velocity estimates for the U.S.
minutes. Ample information about OPUS-RS is available in
Continuously Operating Reference Stations (CORS) (check
e.g., Schwarz (2008) and Schwarz et al. (2009). The purpose
the URL http://www.ngs.noaa.gov/CORS/coords.shtml) and
of this note is simply to summarize basic information about
for contributing products to the International Global
the orbits used in positioning products from the OPUS suite.
Navigation Satellite Systems (GNSS) Service (IGS).
OPUS-RS uses the Rapid Static GPS (RSGPS) engine
(Schwarz 2008).
Which Orbits are Used in OPUS?
OPUS-S is a remarkably simple tool for users to employ.
The user supplies a file containing between 2 hours and 48
hours of observations collected by a geodetic-grade antenna- GNSS products are available courtesy of the IGS, a
receiver pair, called a rover, and information about the voluntary federation of more than 200 worldwide agencies
rover’s antenna height and type. After submitting the pooling resources to provide satellite tracking data and
necessary files and antenna information, OPUS-S returns definitive station positions and velocities, station clocks,
positioning results (including a “peak-to-peak” estimate of satellite orbits and satellite clocks (see more at
the error in the rover position) to the user’s email address http://www.igs.org). IGS orbits are available as three product
usually within minutes. lines—Ultra-rapid, Rapid and Final—in the Standard
OPUS-S works by inverting double-difference phase Product 3 (SP3) format (e.g., Hilla 2002; Hilla 2007). The
observation equations (e.g., Strang and Borre 1997; Misra IGS file naming conventions, information about latency in
and Enge 2004) formed from observations at the rover and availability, product issue times and data spans for the
three or more CORS (Snay and Soler 2008). The observation different product lines are summarized in Table 1.
equations are inverted by PAGES, using least-squares, to Each IGS product line is intended to serve a different set of
solve for the position of the rover while holding fixed the applications. Latency, issue times and data spans in Table 1

1
Deputy, IGS Analysis Center Coordinator, Spatial Reference System Division, National Geodetic Survey, NOS, National
Oceanic and Atmospheric Administration, 1315 East-West Hwy., Silver Spring, MD 20910. E-Mail: Jake.Griffiths@noaa.gov
2
IGS Analysis Center Coordinator, Geosciences Research Division, National Geodetic Survey, NOS, National Oceanic and
Atmospheric Administration, 1315 East-West Hwy., Silver spring, MD 20910. E-Mail: Jim.Ray@noaa.gov
3
Chief, Spatial Reference System Division, National Geodetic Survey, NOS, National Oceanic and Atmospheric Administration,
1315 East-West Hwy., Silver Spring, MD 20910. E-Mail: Neil.D.Weston@noaa.gov

CORS AND OPUS FOR ENGINEERS 27

Table 1. Summary of IGS orbit product lines. The symbol WWWW represents the 4-digit GPS Week number of the data. The
symbol D represents the 1-digit day of GPS Week (i.e., 0 through 6). The symbol HH represents the 2-digit UTC hour (i.e., 00,
06, 12 and 18). It is important to note that the WWWWD_HH for the Ultra-rapid orbits and the WWWWD for the Rapid and
Final orbits refers to the midpoint of the data span in the file.
Series File name Latency Issue times Data spans (UTC)
(UTC)
Ultra-rapid iguWWWWD_HH.sp3 real-time 03:00, 09:00, +24 hours @ 00:00,
(predicted half) 15:00, 21:00 06:00, 12:00, 18:00

Ultra-rapid iguWWWWD_HH.sp3 3 – 9 hours 03:00, 09:00, -24 hours @ 00:00,

(observed half) 15:00, 21:00 06:00, 12:00, 18:00

Rapid igrWWWWD.sp3 17 – 41 17:00 daily ± 12 hours @ 12:00

hours

Final igsWWWWD.sp3 11 – 17 weekly, each ± 12 hours @ 12:00

days Thursday for 7 days

provide some clue about how and when the orbits can be
used, but, the IGS intends the predicted parts of the Ultra-
rapid orbits to be used for real-time applications; the fitted
parts of the Ultra-rapid orbits to be used for near real-time
applications; the Rapid orbits to be used for near-definitive
rapid applications; and the Final orbits to be used for
definitive applications (Kouba 2009).
Any GNSS positioning product in the OPUS suite will use
the Final, Rapid or observed half of the Ultra-rapid orbit,
depending on the epochs of observations in the user-supplied
data file and the issue times of the orbits (Table 1). For
example, if a data file containing observations from 12:00:00
UTC through 16:00:00 UTC on June 26, 2010 (i.e., day 0 of
GPS Week 1590) was submitted to OPUS within 17 hours of
the last observation, then the igu15901_00.sp3 orbit would
be used to process that session. If the data file was submitted
between 17 and 41 hours after the last observation, then
igr15900.sp3 would be used. Finally, if the data file was
submitted about 15 days after the last observations, then
igs15900.sp3 would be used.
model for sub-daily tidal Earth Orientation Parameters
(EOP) variations. The performance of the Rapid orbits is
very similar, including sharing the common long-period and
sub-daily tidal errors.
The high-frequency precision of the near real-time Ultra-
rapid observed orbits is only about 40% poorer than the later
Rapids and is about 3.5 times worse than the Rapids for the
first 6-hr of predictions. Rotational scatter also dominates
the precision of the Ultra-rapid orbits, but much more so for
the RZ axial component than the equatorial components.
Errors in EOP predictions are mainly responsible for this
rotational scatter. The daily 1D quasi-random weighted root-
mean-square (WRMS) scatter is about 2 cm for the 6-hr orbit
predictions, increasing to nearly 5 cm for predictions over 24
hr.
For more detailed information on the accuracy of the IGS
orbits, refer to recent presentations by Gendt et al. (2010)
and Ray and Griffiths (2010) available online at
http://www.ceg.ncl.ac.uk/igs2010 and
http://www.ngs.noaa.gov/PUBS_LIB/pub_GPS.shtml.

Accuracy and Precision of the IGS Orbits

Effect of IGS Orbit Errors on Relative Positioning
The accuracy of the Final orbits is about 2 cm (1 sigma).
According to Beser and Parkinson (1982), the effect of orbit
Errors in the along- and cross-track directions are about 75%
error on relative positioning can be estimated using the
larger than in the radial, but correlations are significant. The
following rule-of-thumb:
predominant errors are near the annual, semi-annual (and/or
2nd GPS draconitic harmonic at 175.6 d), the 3rd draconitic
harmonic (117 days) and fortnightly bands due to modeling
deficiencies. The higher-frequency precision at a few days Orbit error (mm) × d
Baseline error (mm) = (1)
and shorter is around 8 mm due mostly to rotational scatter 20,000
followed by quasi-random variations. The rotational errors
are about equal in all three components, (RX, RY, RZ), and
where d is the baseline length in km and 20,000 is the
are probably caused by effects of orbit mis-modeling,
approximate geocentric radius of the GPS orbits, in km.
reference frame realization and errors in the International
According to Eq. (1), the effect of orbit error increases
Earth Rotation and Reference Systems Service (IERS)

28 CORS AND OPUS FOR ENGINEERS

linearly with baseline length. For a 100 km baseline and a
1D orbit error of 50 mm, the expected baseline error is 0.25
mm. Thus, according to Eq. (1), the expectation for software
like OPUS is that errors in the IGS orbits should introduce
no more than 0.25 mm of position error at the rover. Thus,
mm-level positioning in OPUS is limited by errors other
than those in the IGS orbits. Recall, however, that IGS Final
orbits provide the best framework and are specifically
designed for definitive applications (Kouba 2009).
Conclusions
This overview answers a few common questions about how
OPUS uses IGS orbits in a processing session. Specifically,
we summarize where one can obtain IGS orbits, when the
orbits are available, their typical accuracies and how errors
in IGS orbits should impact the positioning of a rover.
According to the simple analysis, here, IGS orbit errors are
insignificant for mm-level positioning and large peak-to-
peak values (from OPUS-S) may indicate other error
sources.
References
Beser, J., and Parkinson, B.W. (1982). “The application of
NAVSTAR differential GPS in the civilian community.”
Navigation, 29(2), 107-136.
Eckl, M.C., Snay, R., Soler, T., Cline, M.W., and Mader,
G.L. (2001). “Accuracy of GPS-derived relative
positions as a function of interstation distance and
observing-session duration.” J. Geodesy, Berlin,
75(12),633-640.
Gendt, G., Griffiths, J., Nischan,, T., and Ray, J. (2010).
“IGS Reprocessing – Summary of Orbit/Clock
Combination and First Quality Assessment.” The 2010
International GPS Service Workshop, Newcastle Upon
Tyne, England.
Griffiths, J., Ray, J., Rohde, J.R., Kass, W.G., Dulaney,
R.L., Cline, M., Hilla, S., and Snay, R.A. (2009). “An
assessment of the NGS’ contribution to the reprocessed
IGS products.” Eos Trans. AGU, 90(52), Fall Meet.
Suppl., Abstract G11B-0631.
Hilla, S. (2002). “Extending the Standard Product 3 (SP3)
Orbit Format.” Proc., The 2002 International GPS
Service Workshop, Ottawa, Canada.
Hilla, S. (2007). “The Extended Standard Product 3 Orbit
Format (SP3-c).” <http://igscb.jpl.nasa.gov/igscb/data/
format/sp3c.txt> (Feb. 12, 2007).
IGS Central Bureau. (2010). “The International GNSS
Service.” <http://igs.org/> (Jul. 1, 2010).
Kass, W.G., Dulaney, R.L., Griffiths, J., Hilla, S., Ray, J.,
CORS AND OPUS FOR ENGINEERS
and Rohde, J. (2009). “Global GPS data analysis at the
National Geodetic Survey.” J. Geodesy, Berlin, 83(3-4),
289-295.
Kouba, J. (2009). “A guide to using International GNSS
Service (IGS) products.” IGS Products,
<http://igscb.jpl.nasa.gov/components/usage.html> (May
13, 2009)
Mader, G.L., Weston, N.D., Morrison, M.L., and Milbert,
D.G. (2003). The On-line Positioning User Service
(OPUS), Professional Surveyor Magazine, 23(5), 26, 28,
30.
Misra,, P., and Enge, P. (2004). Global Positioning System:
Signals, Measurements, and Performance, Ganga-
Jamuna Press, Massachusetts.
National Oceanic and Atmospheric Administration. (2010).
“Continuously Operating Reference Station (CORS).” <
http://www.ngs.noaa.gov/CORS/> (May 6, 2010).
Ray, J., Morrison, M., Hilla, S., Dillinger, W., and Mader, G.
(2005). “Geodetic sensitivity to surface meteorological
data: 24-h and 6-h observing sessions.” GPS Solutions, 9,
12-20.
Ray, J., and Griffiths, J. (2010). “Status of core IGS
products.” The 2010 International GPS Service
Workshop, Newcastle Upon Tyne, England.
Rohde, J.R., Griffiths, J., Cline, M., Dulaney, R.L., Hilla, S.,
Kass, W.G., Ray, J., Sella, G., and Snay, R.A. (2009).
“NGS2008-beta: A preliminary estimate of an update to
the North America CORS velocity field.” Eos Trans.
AGU, 90(52), Fall Meet. Suppl., Abstract G11C-0660.
Schenewerk, M. S. (1991). “GPS Orbit Determination at the
National Geodetic Survey.” Proc., Twenty-Third Precise
Time and Time Interval Applications and Planning
Meeting, NASA Conference Publication 3159, pp. 49-58.
Schwarz, C.R. (2008). “Heuristic weighting and data
conditioning in the National Geodetic Survey Rapid
Static GPS software.” J. Surv. Eng., 134(3), 76-82.
Schwarz, C.R., Snay, R.A., and Soler, T. (2009). Accuracy
assessment of the National Geodetic Survey’s OPUS-RS
utility.” GPS Solutions, 13(2), 119-132.
Snay, R.A., and Soler, T. (2008). “Continuouly operating
reference station (CORS): History, applications, and
future enhancements.” J.Surv. Eng., 134(4), 95-104.
Soler, T., Michalak, P., Weston, N.D., Snay, R. A., and Foote,
R. H. (2006), “Accuracy of OPUS solutions for 1- to 4-h
observing sessions.” GPS Solutions., 10(1), 45-55.
Strang, G., and Borre, K. (1997). Linear Algebra, Geodesy,
and GPS, Wellesley-Cambridge Press, Massachusetts.
Weston, N.D., Soler, T., and Mader, G.L. (2009). “Rover
station positional accuracies from OPUS as a function of
reference station spacing and rover station occupation
time.” Proc., FIG Working Week, Eilat, Israel, 3-8 May
2009.
29
GPS Solut (2006) 10: 45–55
DOI 10.1007/s10291-005-0007-3
5

T. Soler
P. Michalak
Accuracy of OPUS solutions for 1- to 4-h
N. D. Weston observing sessions
R. A. Snay
R. H. Foote

Abstract We processed 30 consecu- OPUS policy that recommends using

Received: 8 June 2005
Accepted: 14 June 2005
Published online: 1 December 2005
 Springer-Verlag 2005
T. Soler (&) Æ N. D. Weston
R. A. Snay Æ R. H. Foote
National Geodetic Survey, NOAA,
1315 East-West Highway, Silver Spring,
MD 20910, USA
E-mail: Tom.Soler@noaa.gov
Tel.: +301-713-3205
Fax: +301-713-4322
P. Michalak
Warsaw University of Technology,
Institute of Geodesy and Geodetic
Astronomy, Sq Politechniki 1,
00-661 Warsaw, Poland
tive days of Global Positioning Sys-
tem (GPS) data using the On-line
Positioning Users Service (OPUS)
provided by the National Geodetic
Survey (NGS) to determine how the
accuracy of derived three-dimen-
sional positional coordinates de-
pends on the length of the observing
session T, for T ranging from 1 h to
4 h. We selected five Continuously
Operating Reference Stations
(CORS), distributed widely across
the USA, and processed the GPS
data for each with corresponding
data from three of its nearby CORS.
Our results support the current
a minimum of 2 h of static GPS
data. In particular, 2 h of data yiel-
ded a root mean square error of 0.8,
2.1, and 3.4 cm in the north, east,
and up components of the derived
positional coordinates, respectively.
Results drastically improve for
solutions containing 3 h or more of
GPS data.
Keywords GPS Processing
services Æ OPUS Æ Position relative
to observation time

Introduction Atmospheric Administration (NOAA) manages such a

For more than a decade, the Global Positioning System
(GPS) has been revolutionizing the way surveyors,
engineers, GIS professionals, and others measure posi-
tional coordinates. In particular, GPS technology is
enabling surveying companies to realize greater pro-
ductivity. These companies, and geospatial profession-
als in general, are adopting GPS technology and
merging it with their standard measuring systems to
improve their efficiency and provide better customer
services. As more and more surveying companies adopt
GPS methodologies, they become the standard for the
rest to follow. Currently, three-dimensional (3-D)
positional coordinates of points can routinely be
determined with centimeter-level accuracy, relative to
GPS active control points that are continuously oper-
ated (Eckl et al. 2001). The National Geodetic Survey
(NGS) a Program Office of the National Oceanic and
network, the National and Cooperative Continuously
Operating Reference Station (CORS), serving a diverse
number of applications (Snay et al. 2002b; http://
www.ngs.noaa.gov/CORS/). This network of active
control points forms the basis for the National Spatial
Reference System (NSRS) by providing a framework
for surveying and mapping activities throughout the
USA.
As a means to provide GPS users easier access to the
NSRS, NGS developed the Web-based On-line Posi-
tioning Users Service (OPUS), which enables its users to
submit static GPS observation files to NGS via the
World Wide Web; whereby OPUS will compute posi-
tional coordinates for the location associated with the
data. The OPUS utility uses NGS computers and PA-
GES (Program for the Adjustment of GPS Ephemerides)
software (http://www.ngs.noaa.gov/GRD/GPS/DOC/
toc.html) to provide geodetic positions consistent with

30 CORS AND OPUS FOR ENGINEERS

NSRS. OPUS is automatic and requires the user to input
only a minimal amount of information (Mader et al.
2003). It processes submitted GPS data with corre-
sponding data from three nearby CORS sites. Its users
receive OPUS-derived positional coordinates via e-mail
in a timely fashion, usually a few minutes. The OPUS
report provides coordinates for both the current reali-
zation of the 3-D International Terrestrial Reference
Frame (called ITRF2000) and the current realization of
the North American Datum of 1983 (called NAD 83
(CORS96)). The adopted formulation for transforming
ITRF2000 coordinates to NAD 83 (CORS96) coordi-
nates is given in Soler and Snay (2004) and is practically
implemented through the Horizontal Time-Dependent
Positioning (HTDP) software (Snay 1999) (see http://
ngs.noaa.gov/TOOLS/Htdp/Htdp.shtml). The OPUS
standard output also provides the user with 2-D State
Plane Coordinates (SPC), Universal Transverse Merca-
tor (UTM) coordinates, and for completeness, includes
the convergence, the point scale on the map, and the
combined factor involving the elevation reduction fac-
tor. For professionals who desire to do their own
adjustment of vector components, OPUS also has the
option of selecting an extended output containing more
detailed information.
This investigation was motivated by the need to ad-
dress the question of how accurate OPUS solutions are
when the duration of the observing session (denoted T)
spans only a few hours, specifically 1 h £ T £ 4 h.
Shortening the total observation time hinders the reso-
lution of integer ambiguities associated with carrier
phase GPS data. Shortening T also provides less data for
estimating the nuisance parameters associated with tro-
pospheric refraction.
OPUS solutions
All OPUS solutions for this investigation used the ‘‘fi-
nal’’ precise orbits disseminated by the International
GNSS Service (IGS), which are readily available via the
Internet (http://igscb.jpl.nasa.gov). The IGS currently
disseminates 3-D satellite positions (ephemeris) at
a sample interval of 15 min, with accuracies of about
3 cm and a latency of approximately 13 days (http://
igscb.jpl.nasa.gov/components/prods.html). OPUS solu-
tions use the ionospheric-free model obtained by com-
bining the L1 and L2 carrier phase measurements, and a
data-recording interval of 30 s. OPUS derives ITRF2000
coordinates of an unknown point by selecting three
CORS sites as reference (fixed) stations. The positional
coordinates and velocities of these three sites are ex-
tracted from NGS‘ Integrated Data Base (IDB). The
criteria followed to select the reference stations were
primarily based on the quality of archived GPS data
during the time span of the observing session. The dis-
CORS AND OPUS FOR ENGINEERS
tance between CORS sites is not a major concern; more
emphasis is given to the compatibility between the user’s
data and the data for the three CORS sites. OPUS ap-
plies TEQC (Translate Edit Quality Control) software
developed by UNAVCO, Inc. (Estey and Meertens
1999) to check data quality and formatting problems.
The OPUS solution is not a solution using all data
simultaneously. Instead, it is the (unweighted) mean of
three separate single-baseline solutions. Consequently,
the choice was made to assume that checking ‘‘repeat-
ability’’ is more important than doing a true multi-
baseline solution. The three separate single-baseline
solutions yield the peak-to-peak error for the resulting
positional coordinates. This peak-to-peak error is
thought to provide a more realistic measure of the
quality of the determined positional coordinates, than
formal errors obtained via a simultaneous solution.
Formal error statistics do not account for unmodeled
systematic effects due, for example, to orbital, atmo-
spheric, multipath errors, and nonlinear motion of the
reference stations. The peak-to-peak error represents
the difference between the maximum and minimum
value of a positional coordinate, as obtained from the
three separate baseline solutions. Also it is always
greater in magnitude than the conventional root mean
square (RMS) error, preferred by many GPS users.
Methodology and data processing
We selected five CORS sites throughout the USA to
serve as unknown (‘‘rover’’) points. We assumed that the
‘‘true’’ coordinates of these rover points were provided
by ITRF2000 values at an epoch of 1997.00, which are
posted at http://www.ngs.noaa.gov/CORS/coordinates.
These coordinates are the result of a multi-year solution
involving GPS data ranging from 1994 to 2003. For each
rover point, we selected 30 days of data observed during
June 2004. We subdivided each day’s data into mutually,
nonoverlapping sessions for each selected value of T
(1, 2, 3, and 4 h). For each subset of data we computed
the positional coordinates of each rover point using
OPUS. In each case, and to save time, we allowed OPUS
to automatically select a set of three reference stations.
Finally, we used only those solutions that, in each case,
involved the exact same set of these reference stations.
This restriction ensured that certain systematic errors
(e.g. errors in the relative positional coordinates among
the reference stations) were not introduced into the re-
sults. Figure 1 depicts (as black diamonds) the location
of rover points, identified by their four-character names.
The figure also shows (by open circles) the correspond-
ing CORS sites selected as reference stations by OPUS.
For clarity, Table 1 contains the distances and azimuths,
from the rovers, to each of their three associated refer-
ence stations.
31
Fig. 1 Location of the reference
stations used in this study

On-line Positioning Users Service computes velocities along the Cartesian components x, y, and z on
ITRF2000 positional coordinates at the mean epoch of the ITRF2000 frame, as explicitly given in the published
the observations, denoted t. Consequently, before com- coordinate sheet of each CORS station.
paring results it was necessary to transform these coor- Thus, the final coordinates on the ITRF2000 at
dinates from epoch t to a common epoch 1997.00, epoch 1997.00 are:
according to the well-known equation: 8 9 8 9 8 9
8 9 8 9 8 9 < xð1997:00Þ = < xðtÞ = < vx =
< xðtÞ = < xð1997:00Þ = < vx = yð1997:00Þ ¼ yðtÞ þð1997:00  tÞ  vy
yðtÞ ¼ yð1997:00Þ þðt1997:00Þ vy ð1Þ : ; : ; : ;
zð1997:00Þ zðtÞ O vz P
: ; : ; : ;
zðtÞ O zð1997:00Þ vz P
ð2Þ
where the subindices P and O stand for ‘‘published’’ and
The differences between published and OPUS-deter-
‘‘OPUS-derived,’’ respectively, and vx ; vy ; vz are the
mined coordinates using Eq. 2 can be written as
Table 1 Location of base stations with respect to rovers 8 9 8 9 8 9
< dxð1997:00Þ = < xð1997:00Þ = < xð1997:00Þ =
CORS station (Rover) Base stations Distance (m) Azimuth () dyð1997:00Þ ¼ yð1997:00Þ  yð1997:00Þ
: ; : ; : ;
dzð1997:00Þ zð1997:00Þ P zð1997:00Þ
SLAI LTMH 261189.9 188.9208
NEDR 280708.3 244.4947 ð3Þ
OMH1 184261.9 266.5105
MBWW CASP 103025.6 350.9761 In order to have a visual representation it is more
TMGO 212628.7 157.5125 convenient to plot these differences (residuals) with re-
ZDV1 210428.2 154.6049
MIA3 MTNT 76331.5 281.2888 spect to a local geodetic frame pointing east, north, and
RMND 26048.3 239.6354 up (geodetic vertical).
ZMA1 18916.8 302.5571 Therefore, the following well-known transformation
TCUN NMSF 223296.7 287.6911 is applied:
SUM1 104313.9 105.7375 8 9 8 9
TXAM 157964.6 86.7427 < deð1997:00Þ = < dxð1997:00Þ =
GODE ANP1 18886.9 93.7874
dnð1997:00Þ ¼ ½R dyð1997:00Þ ð4Þ
GAIT 36312.7 290.1976 : ; : ;
ZDC1 62594.7 278.3690 duð1997:00Þ dzð1997:00Þ

32 CORS AND OPUS FOR ENGINEERS

where [R] is the 3·3 rotation matrix of the transforma-
tion between the local global frame (x, y, z) and the local
geodetic frame (e, n, u), namely (e.g. Soler and Hothem
1988),
2 3
 sin k cos k 0 presentation in this paper for no particular reason except
½R ¼ 4  sin / cos k  sin / sin k cos / 5 ð5Þ
cos / cos k cos / sin k sin /
where / and k denote the geodetic latitude and longitude
of the point in question, respectively.
Resulting statistics
For each point P and for each considered value of T
(1, 2, 3, and 4 h), the various estimates for the positional
coordinates of the ‘‘unknown rover’’ were compared
with the published ‘‘true’’ coordinates; and corre-
sponding differences were plotted on the local horizon
frame along the components north (n), east (e), and up
(u) using the formulation described above. Mean and
RMS values in each component were then computed for
each site and each value of T. Any individual component
of a positional difference that exceeded its corresponding
RMS value by more than a factor of three was then
discarded, and the corresponding RMS was recom-
puted. Table 2 presents the number of solutions used
and the total number of rejected solutions (solutions
exceeding 3RMS+solutions with different station set).
The plots for station GODE along the north, east, and
up components are given explicitly in the Appendix. The
Appendix also contains histograms of the residuals for
the four observing times used in this investigation. If
desired, the results for all other stations can be
checked at http://www.ngs.noaa.gov/OPUS/Plots/Paper/
OPUSPlotsPaper.doc. Station GODE was selected for
that it belongs to the IGS network and is considered a
reliable station whose history spans several years.
When using GPS, the formal statistics associated with
the results are always optimistic because uncertainties
assigned to observables usually do not account for var-
ious systematic errors such as meteorological conditions,
multipath, etc. In the case of OPUS, NGS is studying the
possibility of replacing the peak-to-peak values currently
given on the output by another statistic able to repre-
sent, more realistically, the combined error of any OPUS
solution. The first step was taken with this particular
investigation where the peak-to-peak error was replaced
by the following empirical equation for the standard
error denoted s. This equation involves particular sta-
tistics available in the OPUS output:
sffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffi
   2  
RMSO 2 k p 2
s ðcmÞ ¼  pffiffiffiffi þ
1:5 T 1:7
8
< east :
> k ¼ 1; p ¼ pe
north : k ¼ 1; p ¼ pn ð6Þ
>
:
up : k ¼ 3:7; p ¼ pu
RMSO (cm)=overall RMS for the doubly differ-
enced iono-free carrier phase observables for the three
single baseline solutions as given in the OPUS output.

Table 2 The number of solutions performed and other statistics

CORS station T (h) Number of Number of solutions Number of Number of used Rejected
all computed with the same rejected solutions solutions solutions (%)
solutions station set (residual>3RMS)

SLAI 1 713 700 24 676 3.4

2 356 355 15 340 4.2
3 238 238 9 229 3.8
4 177 172 4 168 2.3
MBWW 1 708 629 10 619 1.6
2 354 314 15 299 4.8
3 237 210 8 202 3.8
4 179 159 4 155 2.5
MIA3 1 704 556 18 538 3.2
2 356 283 16 267 5.7
3 238 224 11 213 4.9
4 179 136 7 129 5.1
TCUN 1 690 580 22 558 3.8
2 347 294 13 281 4.4
3 229 190 6 184 3.2
4 170 135 6 129 4.4
GODE 1 712 565 22 543 3.9
2 358 293 17 276 5.8
3 237 196 10 186 5.1
4 178 144 7 137 4.9

CORS AND OPUS FOR ENGINEERS 33

Table 3 RMS values (cm) along the n, e, and u components for each point and each observing time window T. Observations were
collected during the month of June 2004

T (h) GODE MBWW MIA3 SLAI TCUN MEAN PRED

1 RMS n 1.92 2.29 2.57 2.21 1.61 2.12 0.95

e 5.28 5.86 8.10 6.85 5.21 6.26 0.99
u 7.31 7.35 12.63 8.12 6.91 8.46 3.65
2 RMS n 0.71 0.67 1.07 0.86 0.55 0.77 0.67
e 1.63 1.45 3.62 2.32 1.52 2.11 0.70
u 2.70 2.74 5.89 3.07 2.47 3.37 2.58
3 RMS n 0.39 0.42 0.67 0.52 0.43 0.48 0.55
e 0.60 0.43 1.48 1.05 0.77 0.87 0.57
u 1.67 1.53 3.30 1.89 1.76 2.03 2.11
4 RMS n 0.30 0.34 0.62 0.41 0.38 0.41 0.48
e 0.83 0.37 0.83 0.60 0.54 0.63 0.50
u 1.27 1.22 3.14 1.64 1.21 1.70 1.83

T=total session duration in hours (1, 2, 3, or 4 h). solutions of all the sites investigated. A cursory check on
pe; pn; pu (cm)=peak-to-peak errors along the east, north, the humidity plot reveals that the overall humidity for
and up components as given in the OPUS output. MIA3 is larger than TCUN every day of the month.
Values for k were derived empirically in a previous Furthermore, the range between the max. and min.
study (Eckl et al. 2001; Snay et al. 2002a). See also Eq. 7 humidity in the case of MIA3 always ranges between
later. about 50% and 90%. The temperature graph also cor-
RMSO measures how well GPS data (involved in a roborates the fact that higher humidity and tempera-
particular OPUS solution) fit the mathematical model tures (such as MIA3) may produce the muggy
incorporated in PAGES software. This quantity is di- conditions directly affecting the behavior of the tropo-
vided by 1.5 cm, which based on experimental results is sphere which, at present, is very difficult to model. Many
considered the average value for a good OPUS solution. researchers are investigating this particular topic, trying
The error bars depicted on the graphs are based on to fully understand the real impact of humid weather on
Eq. 6. Notice that they are primarily impacted by peak- the troposphere and GPS observations. In any case,
to-peak errors, which are the most pessimistic of the based on the empirical results of this exercise, cautions
sample statistics contained in Eq. 6. It is also apparent are in order when using GPS observations in general,
from the plots that the OPUS software has difficulty and OPUS in particular, during summer months in
fixing integer ambiguities to their correct values when tropical areas.
the time span of the observation is 1 h or 2 h. Hence,
peak-to-peak errors are sometimes small, but the plotted
point is located relatively far from the ‘‘true’’ value.
Table 3 summarizes the RMS errors. A perusal of
Table 3 immediately reveals that station MIA3 has the
largest RMS errors among the five rover points. In
particular the vertical component is systematically larger
by a factor of about two when compared to the other
tabulated values. Although no detailed investigation to
understand this dilemma was undertaken, the tropical
weather in Florida, marked by high humidity, and the
strong possibility that OPUS does not correctly model
for tropospheric effects, may have contributed to the
larger than usual RMS error for the height component
at station MIA3.
In order to understand the possible tropospheric
influence on the solutions obtained for this investigation,
Figs. 2 and 3 show the daily maximum and minimum
relative humidity and mean daily temperature for the
month of June for stations TCUN and MIA3, which Fig. 2 Daily maximum and minimum relative humidity for the
according to Table 3 are considered the best and worst month of June at MIA3 and TCUN

34 CORS AND OPUS FOR ENGINEERS


Fig. 3 Mean daily temperature at MIA3 and TCUN during the
month of June
The overall systematic improvement of the solutions
when observation time exceeds 1 h was expected. Also
accuracy for the northward component is usually better
Fig. 4 OPUS results plotted against the predicted curve (Eq. 7). Note that the scale of the ‘‘up’’ plot differs from that of the ‘‘north’’ and
‘‘east’’ plots
CORS AND OPUS FOR ENGINEERS
than that for the eastward component which, in turn, is
better than the accuracy for the upward (vertical) com-
ponent. The first NGS objective, while developing
OPUS, was to simplify the labor of its constituency by
freeing it from having to process GPS data. In fact
OPUS can be used as a ‘‘black box’’ alternative for
determining positional coordinates referred to the NSRS
with relatively minor decision-making from a user.
However, as Table 3 shows, the amount of total
observing time in the field should be carefully consid-
ered, to attain prespecified accuracies like those required
for some engineering/surveying projects. For example,
to obtain sub-centimeter RMS error in the horizontal
components, the observation time span should be at
least 3 h. Assuming standard weather conditions, a 3 h
observing session should yield ellipsoidal heights with an
RMS error of about 2 cm.
Figure 4 displays the mean RMS error of the five
tests performed for this investigation (Table 3). The
predicted results (PRED in Table 3) were determined
using the empirical formula presented in Eckl et al.
(2001) and Snay et al. (2002a). According to these au-
thors the RMS errors (expressed in cm) can be computed
by the ‘‘simple-to-remember rule of thumb’’ equation:
35
  This expected degeneration of results when the
k k ¼ 1:0;horizontal (north and eastÞ
RMS (cmÞ ¼ pffiffiffiffi
T k ¼ 3:7; vertical
ð7Þ
where T denotes the duration of the observing session
expressed
pffiffiffiffi in hours and k is a free parameter in units of
cm T : The efficacy of Eq. 7 rests in its ability to predict
RMS errors for other possible session duration, from
4 h to 24 h. As Fig. 4 and Table 3 shows, this empirical
formula extrapolates well to sessions of 3 h, however,
for 2 h and less, Eq. 7 should not be applied ‘ because of
the difficulty of fixing integer ambiguities. Notice that
the curve of Fig. 4 does not fit well the east component
for T<4 h.
As Fig. 4 show, the following conclusion can be
drawn: the RMS error for the north component fits well
the predicted curve, except for the 1 h case, however,
even when using only 1 h of observation time, the RMS
error in the north component is about 2 cm, which is
more than desirable for most surveying applications.
With the exception of the station located in Miami
(MIA3), the height (up) component fits the predicted
graph well, except for GPS observations lasting 1 h.
Finally, the east component is the weakest of the three
when the observations span a short time. This is clearly
seen in Fig. 4, where the RMS error (excluding MIA3)
for 2 h of data jumps to about 2 cm and, more impor-
tantly, the 1-h case gives an average RMS error of about
6.5 cm. Thus, the RMS errors of the east and up com-
ponents are greatly worsened for observation spans of
1 h or less.
36 CORS AND OPUS FOR ENGINEERS
observing time is 1 h or less, is not unique to OPUS.
The majority of on-line services, such as AUSPOS,
SCOUT, Auto-GIPSY, and PPP, give large errors
when short periods of time are observed (Ghoddousi-
Fard and Dare 2005; Tétreault et al. 2005), corrobo-
rating, primarily, that due to little or no change in
geometry and anomalous atmospheric conditions,
when the observation span is short it is very difficult
to fix integers properly.
Conclusions
Since 2002, NGS has been providing the GPS com-
munity with OPUS processing, free of charge. Among
the limitations for using OPUS, the time duration of
the GPS data set was always emphasized. A minimum
of 2 h of data is recommended to obtain results suf-
ficiently accurate for surveying applications. The re-
sults of this investigation indicate, when using 2 h of
data, results in the north, east, and vertical (up)
components have experimentally determined RMS er-
rors of 0.8, 2.1, and 3.4 cm, respectively. Reducing the
observation span to less than 2 h drastically increases
uncertainties due to difficulty in fixing integer ambi-
guities as consequence of poor geometry and local
atmospheric disturbances. NGS is currently trying to
develop alternative software capable of reliably fixing
integer ambiguities for time periods of 15 min and less
(Kashani et al. 2005).
Appendix

CORS AND OPUS FOR ENGINEERS 37

38 CORS AND OPUS FOR ENGINEERS
CORS AND OPUS FOR ENGINEERS 39
References
Eckl MC, Snay R, Soler T, Cline MW,
Mader GL (2001) Accuracy of GPS-
derived relative positions as a function
of interstation distance and observing-
session duration. J Geodes 75(12):633–
640
Estey LH, Meertens CM (1999) TEQC: the
multi-purpose toolkit for GPS/GLON-
ASS data. GPS Solutions 3(1):42–49
Ghoddousi-Fard R, Dare P (2005) Online
GPS processing services: an initial
study. GPS Solutions 9(3) (in press)
Kashani I, Wielgosz P, Grejner-Brzezinska
DA, Mader GL (2005) A new network-
based rapid-static module for the NGS
Online Positioning User Service—
OPUS-RS. ION 61st Annual Meeting,
June 27–29, Cambridge, MA, (Ab-
stract)
40
Mader GL, Weston ND, Morrison ML,
Milbert DG (2003) The On-line Posi-
tioning User Service (OPUS). Prof Surv
23(5):26, 28, 30
Snay RA (1999) Using HTDP software to
transform spatial coordinates across
time and between reference frames.
Surv Land Inf Syst 59(1):15–25
Snay RA, Soler T, Eckl M (2002a) GPS
precision with carrier phase observa-
tions: does distance and/or time matter?
Prof Surv 22(10):20, 22, 24
Snay RA, Adams G, Chin M, Frakes S,
Soler T, Weston ND (2002b) The syn-
ergistic CORS program continues to
evolve. In: Proceedings of the ION GPS
2002 (CD-ROM), Institute of Naviga-
tion, Alexandria, VA, pp2630–2639
CORS AND OPUS FOR ENGINEERS
Soler T, Hothem LD (1988) Coordinate
systems used in geodesy: basic defini-
tions and concepts. J Surv Eng
114(2):84–97
Soler T, Snay RA (2004) Transforming
positions and velocities between the
International Terrestrial Reference
Frame of 2000 and North American
Datum of 1983. J Surv Eng 130(2):49–
55
Tétreault P, Kouba J, Héroux P, Legree P
(2005) CSRS-PPP: an Internet service
for GPS user access to the Canadian
Spatial reference Frame. Geomatica
59(1):17–28
 6
Statistics of Range of a Set of Normally Distributed Numbers
Charles R. Schwarz1

Abstract: We consider a set of numbers independently drawn from a normal distribution. We investigate the statistical properties of the
maximum, minimum, and range of this set. We find that the range is closely related to the standard deviation of the original population.
In particular, we investigate the use of the online positioning user service 共OPUS兲 global positioning system 共GPS兲 precise position utility,
which produces three estimates of each coordinate and reports the range of these three estimates. We find that the range divided by 1.6926
is an unbiased estimate of the standard deviation of a single coordinate estimate, and that the variance of this estimate is 0.2755 ␴2. We
compare this to the more conventional method of estimating the standard deviation of a single observation from the sum of squares of
residuals, which is shown to have a variance 0.2275 ␴2.
DOI: 10.1061/共ASCE兲0733-9453共2006兲132:4共155兲
CE Database subject headings: Statistics; surveys.

Introduction timates are statistically independent. If x1, x2, and x3 are three
independent estimates of coordinate X, with variances ␴21, ␴22,
This investigation was motivated by users of the online posi- and ␴23, then the best estimate of the coordinate X is the
tioning user service 共OPUS兲 utility for computing precise coordi- weighted mean
nates for global positioning system 共GPS兲 geodetic receivers 共see
3
http://www.ngs.noaa.gov/OPUS兲. This utility, provided by the
U.S. National Geodetic Survey, computes highly accurate GPS 兺
i=1
w ix i
positions from a single data set provided by the user. It performs x̄ = 3
a differential GPS solution by searching for suitable reference
station data in the archive of Continuously Operating Reference 兺
i=1
wi
Station 共CORS兲 data. OPUS selects three CORS stations and
performs three single baseline solutions. This produces three where the weights are wi = 1 / ␴2i . The variance of the mean is
estimates for the coordinates of the user’s receiver in the U.S. then
National Spatial Reference System. The OPUS utility reports the
mean of these three estimates, together with their range, to the 1
user. Fig. 1 shows a typical solution report obtained from OPUS. ␴x̄2 = 3
The numbers following the coordinates show the range of the
three estimates of each coordinate.
兺
i=1
wi
Each single baseline solution is highly accurate by itself. The
reason to use three such baselines appears to be to provide some According to the OPUS user documentation, the designers
protection against blunders, not because they provide significant of OPUS declined to use this statistic, saying that
statistical or geometric redundancy. The range of the three esti- the variances from the single baseline solutions are
mates tells the user if blunders are present. If the range is signifi- notoriously overoptimistic 共http://www.ngs.noaa.gov/OPUS/
cantly larger than normally obtained with similar data sets, then UsingគOPUS.html#accuracy兲.
one or more of the reference station’s coordinates or tracking data 2. Linear error propagation, using external estimates of the vari-
may have contained a blunder. ances of single baseline solutions. A common method of ob-
There are several ways to estimate the uncertainty of the mean taining such external estimates is to perform a study using a
of the three single baseline estimates reported to the user. Among large number of single baseline solutions. Such studies may
these are produce rules for estimating variances from some property of
1. Linear error propagation, using the variances of the indi- the data, such as the time span of the data or the length of the
vidual single baseline solutions and assuming that these es- baseline.
3. Linear error propagation, assuming that all three single base-
1 line solutions have the same variance ␴2. Then the best esti-
Consultant, Geodesy, 5320 Wehawken Rd., Bethesda, MD 20816.
E-mail: charlies2@earthlink.net
mate of the coordinate X is the simple mean
Note. Discussion open until April 1, 2007. Separate discussions must
3
be submitted for individual papers. To extend the closing date by one
month, a written request must be filed with the ASCE Managing Editor. 兺
i=1
xi
The manuscript for this paper was submitted for review and possible
x̄ =
publication on May 10, 2005; approved on July 8, 2005. This paper is 3
part of the Journal of Surveying Engineering, Vol. 132, No. 4,
November 1, 2006. ©ASCE, ISSN 0733-9453/2006/4-155–159/$25.00. and its variance is

CORS AND OPUS FOR ENGINEERS 41

 冕
⬁
3
E关u兴 = uf u共u兲du = = 0.8463
−⬁ 2冑␲
and its variance 关Weisstein, undated, Eq. 共39兲兴 is

冕 4␲ − 9 + 2冑3
⬁
E关共u − E关u兴兲2兴 = u2 f u共u兲du − E2关u兴 = = 0.5593
−⬁ 4␲

Similarly, let v = min共x1 , x2 , x3兲. It is easy to show that

E关v兴 = − E关u兴
Finally, let w be the range of the standardized random variables.
Then

E关w兴 = E关u − v兴 = E关u兴 − E关v兴 = 2E关u兴

Application to the OPUS Utility

Returning to the original set of numbers X1 , X2 , X3 and comput-

ing their maximum, minimum, and range, we have
Fig. 1. Portion of an OPUS data sheet
3
E关max兴 = ␮ + ␴
2冑␲

␴2 3
␴x̄2 = E关min兴 = ␮ − ␴ and
3 2冑␲

3
While linear error propagation is formally correct, it is easily
contaminated by blunders in the data. Detecting such blun-
E关range兴 =
冑␲ ␴ = 1.6926␴
ders appears to have been the main concern of the designers This means that
of OPUS. Their methodology is to estimate the coordinate X
with the simple mean of the three single baseline solutions, s1 = range/1.6929
but report the range of the three estimates rather than a stan-
is an unbiased estimate of ␴, the standard deviation of the popu-
dard deviation. The range 共also called the peak-to-peak error兲
lation from which the three numbers were drawn. Furthermore,
will show the presence of a blunder more clearly than a
propagated variance. The explanation on the OPUS web site s1/冑3 = range/2.9317
suggests that the peak-to-peak error is intended to be a rough
guide to the accuracy of the reported coordinates. may be used as an unbiased estimate of the standard deviation of
A number of OPUS users have asked for a formal standard the mean of the three individual estimates.
deviation or variance for the reported coordinates. This has
prompted interest in the question of whether such a standard de-
viation can be computed from the reported range of the three How Good Is This Estimate?
single baseline solutions. Intuitively, it seems that such a relation-
ship must exist; if the uncertainties of the single baseline solu- If we want to use range/1.6926 as an estimate of ␴, it makes
tions are large, then one would expect the range of a sample of sense to ask how good is this estimate.
three of them to be large. We have already noted that

Var共u兲 = E关共u − E关u兴兲2兴 = E关u2兴 − 共E关u兴兲2 = 0.5593

Statistics of the Maximum, Minimum, and Range
Let X1, X2, and X3 be three numbers independently drawn from a
population with a normal distribution with mean ␮ and stan-
dard deviation ␴; i.e., X1 , X2 , X3⬃n共␮ , ␴兲. Standardize these
by x1 = 共X1 − ␮兲 / ␴, x2 = 共X2 − ␮兲 / ␴, and x3 = 共X3 − ␮兲 / ␴ so that
x1 , x2 , x3⬃n共0 , 1兲.
Let u = max共x1 , x2 , x3兲. Then u is also a random variable. Its
distribution is the extreme value distribution, a topic treated in the
subject of order statistics 共see Wilks 1962兲. Its expected value
关see Weisstein, undated, Eq. 共34兲兴 is
We can also easily show that Var共v兲 = Var共u兲.
With w = u − v as the range of the standardized random vari-
ables we have
Var关w兴 = E关共w − E关w兴兲2兴 = Var关u兴 + Var关v兴 − 2Cov关u,v兴
We are tempted to assume that the covariance between the maxi-
mum u and minimum v should be zero. After all, the maximum is
one of the random variables xi and the minimum is another one.
x j, and xi and x j are statistically independent. However, the analy-
sis in the Appendix shows that this is not the case. Instead, the
covariance is

42 CORS AND OPUS FOR ENGINEERS

 Cov关u,v兴 = E关共u − E关u兴兲共v − E关v兴兲兴 = E关uv兴 − E关u兴E关v兴 Var关w兴 = Var关u兴 + Var关v兴 − 2Cov关u,v兴
where 4␲ − 9 + 2冑3 9 − 4冑3
=2 −2 = 0.7892

冕冕
⬁ ⬁
4␲ 4␲
E关uv兴 = uv f uv共u, v兲dudv The variance of the range of the original random variables is then
−⬁ −⬁
Var关range兴 = 0.7892␴2
Using the expression for f uv共u , v兲 from the Appendix and setting
n=3 and the standard deviation of the range is 0.8884␴.
Recalling that we use s1 = range/ 1.6926 as an estimate of ␴,

冕冕
⬁ ⬁ the error in this estimate is
E关uv兴 = 6 关Fx共u兲 − Fx共v兲兴f x共u兲f x共v兲dudv
−⬁ v s1 − ␴
For the normal distribution, the probability density function is the and the expected squared value of this error is
Gaussian function
E关共s1 − ␴兲2兴 = E关共range/1.6926 − ␴兲2兴
1 −u2/2 1
f x共u兲 = G共u兲 = E关共range − E关range兴兲2兴
冑2␲ e =
共1.6926兲2
and the distribution function is 1
= Var关range兴
共1.6926兲2
+ Erf共u/冑2兲
1 1
Fx共u兲 = 0.7892 2
2 2 = ␴ = 0.2755␴2
共1.6926兲2
where Erf共z兲 = 2 / 冑␲兰z0e−t dt is the error function described in
2

many texts 共see, e.g., Abramowitz and Stegun 1977兲. Thus,

冕冕
⬁ ⬁ How Good Are Other Estimates?
E关uv兴 = 3 uv关Erf共u/冑2兲 − Erf共v/冑2兲兴G共u兲G共v兲dudv
The more conventional method of computing the variance of a

冕 冋冕 冑
v

册
−⬁
⬁ ⬁
single observation from a sample of three numbers is to compute
=3 vG共v兲 uErf共u/ 2兲G共u兲du dv the mean of the three numbers

冑 冋冕 册
−⬁ v 3

冕 兺
⬁ ⬁ Xi
−3 vG共v兲Erf共v/ 2兲 uG共u兲du dv i=1
X̄ =

冑 冋冕 册
−⬁ v 3

冕
⬁ u
and the residuals from the mean
=3 uG共u兲Erf共u/ 2兲 vG共v兲dv du

冑 冋冕 册
−⬁ −⬁
vi = Xi − X̄

冕
⬁ ⬁
−3 vG共v兲Erf共v/ 2兲 uG共u兲du dv Then
−⬁ v
3

冕 兺
⬁
v2i
=3 冑uG共u兲Erf共u/ 2兲关− G共u兲兴du i=1
−⬁ ␴
ˆ2=
2

冕
⬁
−3 冑 vG共v兲Erf共v/ 2兲关G共v兲兴dv is an unbiased estimate of ␴ . 2

−⬁ It is shown in many texts on least-squares adjustments 共e.g.,

冕
⬁ Leick 1995, Sec. 4.9.2兲 that the sum of squares of residuals, di-
=−6 冑 zG2共z兲Erf共z/ 2兲dz vided by the true value of the variance of a single observation, is
−⬁ distributed as chi squared with n − 1 degrees of freedom. Thus

冕 冑3
⬁
␴2 2
=−
3
冑 2
ze−z Erf共z/ 2兲dz = −
3 1
=− = − 0.5513 ˆ2⬃
␴ ␹
␲ −⬁ ␲ 冑3 ␲ 2 2

Then From this

␴2
Cov关uv兴 = E关uv兴 − E关u兴E关v兴 ˆ 2兴 =
E关␴ E关␹22兴 = ␴2, since E共␹22兲 = 2, and with Var共␹22兲 = 4
2

=−
冑3
␲
+ 冉冑冊 3
2 ␲
2
=
9 − 4冑3
4␲
= 0.1649
ˆ 2兴 =
Var关␴ 冉 冊 ␴2 2
Var关␹22兴 = 冉 冊
␴2 2
2 ⫻ 2 = ␴4
2 2
and the variance of the range of the standardized random vari-
ables is Thus, the expected squared error of ␴
ˆ 2 as a estimate of ␴2 is ␴4.

CORS AND OPUS FOR ENGINEERS 43

 Fig. 3. Another portion of OPUS extended output

Fig. 2. Portion of OPUS extended output

冑
3

It is tempting to conclude from this that ␴ ˆ is an unbiased

兺
i=1
v2i
estimate of ␴ and that its variance is ␴2. However, we find that ␴
ˆ =
2
this is not the case.
Let y = 兺3i=1v2i / ␴2. Then y is distributed as chi square with two This yields
degrees of freedom, and its probability density function is
␴lat = 0.005 m
1
f y共y兲 = e−y/2, where the Gamma function ⌫共1兲 = 0! = 1
2⌫共1兲
␴long = 0.003 m
ˆ = 冑␴2 / 2y and its expecta-
The estimated standard deviation is ␴
tion is
␴height = 0.014 m

冕 冑␲
⬁
␴ ␴
ˆ兴=
E关␴ y 1/2e−y/2dy = 冑2␲ = = 0.8662␴
3. Using the covariance matrices of the individual baseline so-
2冑2 −⬁ 2冑2 2 lutions. The single baseline processing engine used in OPUS
produces a covariance matrix for each baseline. These are
ˆ 2 is an unbiased estimate of ␴2, ␴
This says that even though ␴ ˆ combined to produce the covariance matrix of the mean of
underestimates ␴. However, we can still find the expected squared the three individual coordinate determinations, rotated into
error in this estimate as east, north, and up coordinates, and reported in the OPUS
extended output 共Fig. 3兲. The square roots of the diagonal
ˆ − ␴兲2兴 = E关␴
E关共␴ ˆ 兴 − 2E关␴
ˆ ␴兴 + E关␴2兴 = E关␴
ˆ 2兴 − 2E关␴
ˆ 兴␴ + ␴2 elements of this matrix also give the standard deviations of
= ␴2 − 2 ⫻ 0.8862␴ ⫻ ␴ + ␴2 the reported coordinates. By this method we compute

So, finally, ␴lat = 0.001 m

ˆ − ␴兲2兴 = 0.2275␴2
E关共␴
␴long = 0.003 m
This is slightly better than the expected squared error of 0.2755␴2
obtained when the range is used to estimate the standard deviation
of a single observation. This seems intuitively correct, since it is ␴height = 0.003 m
based on all three observations rather than just two.

Example Using the OPUS Data Sheet Concluding Remarks

The use of the range, or peak to peak errors, given on the data
The OPUS solution report with extended output provides three
sheet may be advantageously used to estimate the standard devia-
different ways of estimating the uncertainty of the computed co-
tions of the computed coordinates. This method of computing the
ordinates:
standard deviations is almost as good as the more conventional
1. Using the range of the three solutions in latitude, longitude,
method based on the sum of squares of residuals, and is also
and height. From Fig. 1, these are 0.011, 0.005, and 0.026 m.
much more robust against the effects of a blunder in the data.
We find the standard deviation of the reported latitude, lon-
gitude, and height by dividing by 2.9317, yielding

␴lat = 0.004 m Notation

␴long = 0.002 m The following symbols are used in this paper:

␴height = 0.009 m
2. Using the residuals from the mean. Fig. 2 shows the three
individual position determinations. The mean of these in
each coordinate is the published International Terrestrial
Reference Frame 共ITRF兲 position, and the maximum minus
minimum in each coordinate 共converted to meters兲 is the
reported range. From these, we can compute the residuals
and estimate the standard deviation in each coordinate by
Cov共 兲 ⫽ covariance of two random variables;
E关 兴 ⫽ expected value;
Erf共x兲 ⫽ error function;
Fx共x兲 ⫽ cumulative probability function associated with the
random variable x, evaluated at the number x;
f x共x兲 ⫽ probability density function associated with the
random variable x, evaluated at the number x;
G共x兲 ⫽ Gaussian probability function;
Var共 兲 ⫽ variance of a random variable; and
⌫共x兲 ⫽ Gamma function.

44 CORS AND OPUS FOR ENGINEERS

Appendix. Joint Probability Function Fuv共⬁, v兲 = 1 − 关1 − Fx共v兲兴n = Fv共v兲
of the Minimum and Maximum of a Set
of N Random Variables
and the marginal probability density functions
Let 兵x1 , x2 , . . . , xn其 be a set of n independent random variables
and let u = max兵x1 , x2 , . . . , xn其 and v = min兵x1 , x2 , . . . , xn其. The

冕 冕
joint probability distribution function of u and v is found ⬁ u

by determining the region of n-dimensional space such that f uv共u, v兲dv = n共n − 1兲 关Fx共u兲 − Fx共v兲兴n−2 f x共u兲f x共v兲dv
兵u ⬍ u & v ⬍ v其 and then finding the probability density contained −⬁ −⬁

in this region 共Papoulis 1965兲. Thus

x 共u兲f x共u兲 = f u共u兲
= nFn−1
Fuv共u, v兲 = Pr兵u ⬍ u & v ⬍ v其
= Pr兵x1 ⬍ u & x2 ⬍ u & , . . . , & ⬍ xn ⬍ u其
冕 冕
⬁ ⬁
− Pr兵v ⬍ x1 ⬍ u & v ⬍ x2 ⬍ u & , . . . , & v ⬍ xn ⬍ u其 f uv共u, v兲du = n共n − 1兲 关Fx共u兲 − Fx共v兲兴n−2 f x共u兲f x共v兲du
−⬁ v
The random variables x are all independent, so
= n关1 − Fx共v兲兴n−1 f x共v兲 = f v共v兲
Fuv共u, v兲 = 关Pr兵x ⬍ u其兴n − 关Pr兵v ⬍ x ⬍ u其兴n
The probability in the second term is Fx共u兲 − Fx共v兲 if u ⬎ v;
otherwise it is zero. Thus

再 冎
References
Fnx共u兲 − 关Fx共u兲 − Fx共v兲兴n , u ⬎ v
Fuv共u, v兲 =
Fnx共u兲, u⬍v Abramowitz, M., and Stegun, I., eds. 共1977兲. Handbook of mathematical
functions with formulas, graphs, and mathematical tables, Dover,
and the joint probability density function is New York.
⳵2Fuv共u, v兲 Leick, A. 共1995兲. GPS satellite surveying, Wiley Interscience, New York.
f uv共u, v兲 = Papoulis, A. 共1965兲. Probability, random variables, and stochastic pro-
⳵u⳵v

再 冎
cesses, McGraw-Hill, New York.
n共n − 1兲关Fx共u兲 − Fx共v兲兴n−2 f x共u兲f x共v兲, u ⬎ v Weisstein, E. W. 共undated兲. “Extreme value distribution,”
= from Mathworld—A Wolfram web resource, 具http://
0, u⬍v
mathworld.wolfram.com/ExtremeValueDistribution.htm典
It is straightforward to verify the marginal distribution functions Wilks, S. S. 共1962兲. Mathematical statistics, Wiley, New York.
具http://www.ngs.noaa.gov/OPUS典
Fuv共u,⬁兲 = Fnx共u兲 = Fu共u兲 具http://www.ngs.noaa.gov/OPUS/Using_OPUS.html#accuracy典

CORS AND OPUS FOR ENGINEERS 45

 7
Basic TEQC Instructions for OPUS Users
Richard H. Foote1

Abstract: Users of NGS’ software On-line Positioning Users Service (OPUS) may need to do a series of formatting changes, change
observation intervals, etc. to ensure that OPUS generates a useful solution that is properly understood. This article outlines the
different steps required to properly use the utility TEQC (Translate, Edit, and Quality Control) in order to investigate possible input
errors when submitting the raw GPS or RINEX (Receiver Independent Exchange Format) data to OPUS. Important TEQC commands
are described to facilitate the understanding of the types of input errors that OPUS users may encounter when submitting the GPS data
through the Web page.

Author keywords: On-line Users Positioning Service; OPUS; TEQC utility basic steps; GPS positioning; geodetic networks

Introduction
The utility TEQC (Translate, Edit, and Quality Control) is used
to format raw GNSS data into RINEX, check for formatting
compliance, change the observation interval, and more. OPUS
utilities require data to be in RINEX format, and will either do
the translation automatically or allow the user the use of TEQC
to perform their own translation. TEQC can translate most dual
frequency raw data into RINEX-format (Estey and Meertens
1999). RINEX, was developed by several scientists, most
notable Werner Gurtner, Astronomical Institute, University of
Bern, Dr. Gerry Mader, Geosciences Research Division,
NOAA’s National Geodetic Survey, Silver Spring, Md., and in
conjunction with the development of TEQC, Lou Estey,
UNAVCO, Boulder, Co. (See Gurtner and Mader 1990;
Gurtner 1994; Hatanaka 1996; de Jong and van der Marel
2001)
Command Prompt Setup and Checking File for
Formatting Compliance
The OPUS suite of utilities take most manufacturer’s raw data
formats as input, as well as RINEX observation files, but to
diagnose problems using TEQC, files should be converted to
RINEX in order to be viewable (raw files are in binary format
and are not readable). You will need to open a Command
Prompt (or DOS) window by clicking Start, Programs,
Accessories, then open a Command Prompt window. Set up
your Command Prompt window by creating a directory called
teqc (or whatever you want to call the directory). Then, set up
a directory typing the following commands:
Z:\>c:
C:\>mkdir teqc
C:\>cd teqc
C:\teqc>path %path%;c:\teqc
C:\teqc>_
The path setup shown is needed for the Command Prompt to
find the TEQC executable and the data files. The %path%
command keeps the current path, and the ;c:\teqc adds c:\teqc
to the existing path. Type the word PATH in Command
Prompt to see all of the directories that are searched when you
type a command, and you can see that the PATH c:\teqc is
listed last, since it was just added.
Some Common Command Prompt (DOS) Commands
Before using TEQC, users should familiarize themselves with a
few Command Prompt commands. The technology behind
Command Prompt commands is over 25 years old and predates
Windows, but is necessary when using TEQC. TEQC was
written to be used in a UNIX environment, where command
line commands are the standard for scientists. TEQC was later
converted to run in a PC environment and only runs in
command line mode. Some examples with definitions are
show below:
c: (this changes your drive to the “c” drive).
mkdir tmp (or md tmp)- this makes a directory called tmp
under the current directory. If you are in another directory at
the time, such as c:\programs, you should use the command
“mkdir \tmp” so that directory tmp isn’t under c:\programs
cd \tmp - this changes your directory to tmp. Note: the
forward slash indicates to start at the beginning of the drive. cd
c:\tmp accomplishes the same thing.
copy c:\programs\teqc.exe c:\tmp\teqc.exe – this copies the
program teqc from \programs to \tmp. (See next Section)
dir  show directory list.
del junk  delete the file named junk

1
Geodesist, OPUS-DB Administrator, Spatial Reference System Division, National Geodetic Survey, NOS, National Oceanic and
Atmospheric Administration, 1315 East-West Hwy., Silver Spring, MD 20910. E-Mail: Rick.Foote@noaa.gov

46 CORS AND OPUS FOR ENGINEERS


Fig. 1 DOS “move” command
Obtaining the TEQC Software
Go to http://www.ngs.noaa.gov/CORS/ and click on GPS
Links, Geodetic Resources, scroll half way down to Geodetic
Resources, then click on UNAVCO/TEQC. This takes you to
the desired UNAVCO TEQC page http://facility.unavco.org/
software/teqc/teqc.html . Alternatively, you can go directly to
the UNAVCO/TEQC site. Scroll down ¾ of the way until you
get to “… or Microsoft Windows zip files:”. Download the
compressed TEQC executable to your PC, in the directory
c:\teqc. The TEQC manual is available on the aforementio-
ned UNAVCO page, and you can also see all of the TEQC
commands quickly by typing the command:
teqc +help | more (return)
on the command line. Hit the space bar to advance the help
page, and the letter q or ctrl-C to exit out of the help screen.
You can also exit by continuing to hit the space bar (21 times)
to go through all of the help pages.
Next you will need to put data files into the directory c:\teqc
and run the initial test for formatting compliance, the +v
(verify) option. You can put the RINEX file into c:\teqc using
Windows move/paste or by copying using the Command
Prompt command “move”. However, Command Prompt does
have limits, and moving files from directory names that contain
spaces (ex: “Documents and Settings”) is easier using a
Windows utility. If you want to move a file from a directory
named c:\Projectxyz, the move command would be
move c:\Projectxyz\nji20010.10o c:\teqc
or if you only have one file with the extension .10o and you are
copying from the C drive to another location on the C drive and
you are already in the c:\teqc directory, you can save a few
keystrokes and use the command
CORS AND OPUS FOR ENGINEERS
“move \projectxyz\*.10o” (See also Figure 1).
The Appendix lists some of the more common TEQC
commands that are available. This edited list was obtained by
typing teqc –help.
Formatting Raw Data Into RINEX
The basic command for converting raw data into RINEX is as
follows:
TEQC (rawfile) > (RINEX_file_name.10o)
Note: the TEQC command as well as file names do not need to
be capitalized, and parenthesis are to display input and output
file names for the examples, and are not used with TEQC.
An example for a raw file named SCHL0010.DAT is shown
below:
teqc SCHL0010.DAT > SCHL0010.10o
The generally accepted naming convention for files is as
follows (using SCHL0010.DAT as an example):
SCHL 4 character file name
001 Day number of the year (should be in the range
001-365, or 366)
0 0=1st occupation of SCHL for day 001, 1 is the 2nd
occupation on the same day
10 year 2010
DAT raw data file extension example
o RINEX Observation file (as opposed to “n” for
navigation file)
However, some users name their raw files similar to
log0.010110 (The 010110 would be for January 1, 2010), and
log0 is automatically named by the receiver for the first file
logged into memory. When the file is converted to RINEX, the
name should reflect the site name (4 characters) for easier
identification, followed by the generally accepted format
shown above.
Changing Collection Interval
Files can be collected at various collection rates, and the
common collection rates are 1, 2, 5, 10, 15, and 30 seconds.
All OPUS processors (OPUS-S, OPUS-RS, etc.) process data
every 30 seconds, so there are times when users will want to
convert their file to 30 seconds. For example, we recommend
that users not upload more than 2 hours of 1 second data due to
the enormous size of 1 second files. A 24 hour file collected at
the 1 second rate may be as large as 70 megabytes! The
command to change the interval to 30 seconds is as follows:
teqc –O.dec 30 filein > fileout
47
The command above can be used with both raw and RINEX character or one line, it will make TEQC, and subsequently
data. OPUS, fail.

Check for Formatting Compliance TEQC Limitations

Assume that we use the following command:
teqc +v nji20010.10o
or the extended version that shows the satellite coverage,
satellites used, start and ending time, etc.
teqc +qc nji20010.10o
If the file is formatted correctly, you should receive the
following message:
TEQC does not interpret data from every receiver type (see
the TEQC documentation to see which receivers are
supported). Also, sometimes receiver firmware changes and
the updated firmware may not work with TEQC until a
subsequent TEQC release. For example, newer Trimble
software may work or may fail with TEQC. In cases where
TEQC fails due to not supporting a certain receiver or updated
firmware, it is recommended that users format data into
RINEX using the vendor’s RINEX conversion software.
References

teqc: nji20010.10o readable as RINEX V.2.11 format
Common TEQC failures using RINEX files are as follows:
• No XYZ position in file – All the fields, X, Y, and Z,
must contain numbers, representing the approximate
Earth Center Fixed position of the mark.
• Sometime the time interval between the first and
second epoch is different than what it is for
subsequent epochs.
• Also, sometimes there are few satellite observables
in the first few epochs. In both of these cases it is
advisable to use a text editor or the time windowing
feature in TEQC to remove the first few epochs.
• OPUS assumes that the data is static and is for one
occupation only.
• If the word MARKER shows up anywhere in the file
other than in the header, it could mean that the
antenna moved. If this is the case, remove the
smaller portion of data on either side of the word
MARKER. For example, if the file is 12,000 lines
long, and the header is 40 lines, and the word
MARKER is found on line 250, then all lines
between 41 and 250 must be removed.
It is advisable to run the TEQC verify (+v) command after
making any changes to a file, because if a file is off even one
de Jong, C.D., and van der Marel, H. (2001). “Proposal for a
binary receiver independent exchange format.” Phys.
Chem. Earth, Part A, 26(6-8), 551-554.
Estey, L.H., Meertens, C.M. (1999). “TEQC: The multi-
purpose toolkit for GPS/GLONASS data.” GPS Solutions,
3(1), 42-49.
Gurtner, W. (1994). “RINEX: The Receiver Independent
Exchange Format.” GPS World, 5(7), 48-52.
Gurtner, W., and Mader G. (1990). “Receiver Independent
Exchange Format” GPS Bulletin, 3(3), 1-8.
Hatanaka, Y. (1996). “A RINEX compression format and
tools.” Proc. ION GPS-96, 177-183.
Further OPUS Reading
See the following web pages for more help in OPUS informa-
tion and processing of GPS data:
For Articles see: <http://www.ngs.noaa.gov/CORS/Articles>
For Presentations see:
<http://www.ngs.noaa.gov/CORS/presentations.shtml>
For a complete RINEX 3.0 documentation:
<ftp://ftp.unibe.ch/aiub/rinex/rinex300.pdf>

APPENDIX. Sample common TEQC commands.

Usage: TEQC [opts] file1 [file2 [...]]

or: TEQC [opts] < stdin

-n_GPS # set maximum expected GPS SV PRN,0< # <256(default=32)

-n_GLONASS # set maximum expected GLONASS SV slot #,0< # <256(default=24)
-n_SBAS # set maximum expected SBAS SV PRN # - 100,0< # <256(default=19)
-n_Galileo # set maximum expected Galileo SV PRN #, 0< # <256 (default=32)
+igs check rx and ant designations with IGS list (default)
+igs check rx and ant designations with IGS list (default)
+G use all GPS SVs (default)

48 CORS AND OPUS FOR ENGINEERS

-G don't use any GPS SVs
+G<list> use only GPS SV PRN #s in <list>, e.g. 1,3,5-7,11
-G<list> don't use GPS SV PRN #s in <list>, e.g. 1,3,5-7,11
+R use all GLONASS SVs (default)
-R don't use any GLONASS SVs
+R<list> use only GLONASS SV slot #s in <list>, e.g. 1,3,5-7,11
-R<list> don't use GLONASS SV slot #s in <list>, e.g. 1,3,5-7,11
-P[codes] P-codeless (L2-squaring) or C/A-L1-only receiver
+P[codes] normal dual-frequency receiver(including L2C-capable)(default)
+C2 LC2 code pseudorange to be included in default observables
(i.e. no use of -O.obs[_types])
-C2 LC2 code pseudorange not to be included in default observables
(default)
+L2 expect and use L2-carrier data (default)
-L2 don't expect L2-carrier data
+L1_2 keep L1 cycle data if L1 is squared (default)
-L1_2 delete L1 cycle data if L1 is squared
+L2_2 keep L2 cycle data if L2 is squared (default)
-L2_2 delete L2 cycle data if L2 is squared
+CA_L1 use phase/SNR/doppler values in C/A code block (e.g. C/A phase
as RINEX L1) (default for TPS|JPS|SBF formats and Leica MDB 119)
-CA_L1 use phase/SNR/doppler values in P1 code block (e.g. P1 phase
as RINEX L1) (default except for TPS|JPS|SBF formats and Leica
MDB 119)
+L2C_L2 use phase/SNR/doppler values in L2C code block (e.g. L2C phase
as RINEX L2)
-L2C_L2 use phase/SNR/doppler values in P2 code block (e.g. P2 phase as
RINEX L2) (default)
+L5 expect and use L5-carrier data
-L5 don't expect L5-carrier data (default)
+v[erify] verify conformance to input format standard to stdout
-v[erify] output RINEX standard or other (such as qc output) (default)
-O.{header_option} to edit a specific RINEX OBS header field (see following)
-O.sum[mary] s for RINEX OBS file(s) and stdin not used as input, put
summary in new RINEX OBS header (two passes)
-O.sum[mary] e for RINEX OBS file(s) as input, put summary at end RINEX
OBS file (requires only one pass)
-O.sum[mary] . for native format or RINEX OBS as input, output summary
to stdout (requires only one pass)
-O.an "str" set RINEX OBS header antenna number to "str"
-O.at "str" set RINEX OBS header antenna type to "str"
-O.px[WGS84xyz,m] x y z set RINEX OBS header antenna WGS 84 position
to x y z (in meters)
-O.pg[eo,ddm] lat lon el set RINEX OBS header antenna WGS 84 position
to lat lon elevation (degrees degrees meters)
-O.pe[hEN,m] h E N set RINEX OBS header antenna position eccentricities
to h E N (in meters)
-O.mov[ing] 1 force RINEX OBS antenna position to be in kinematic
(roving) state initially
-O.ag[ency] "str" set RINEX OBS header operating agency to "str"
+O.c[omment] "str" append RINEX OBS header comment "str"
-O.dec[imate] # modulo decimation of OBS epochs to # time units
and sets RINEX OBS header interval value
# = 30s results in epochs nominally at 00 and
30 seconds
-O.def_wf i j set RINEX OBS header default wavelength factors
to i and j

CORS AND OPUS FOR ENGINEERS 49

 -O.mod_wf i j n {SV1 SV2 ... SVn} set RINEX OBS header modified wavelength
factors to i and j of n SVs
-O.e[nd] Y M D h m s set RINEX OBS header end time (last epoch)
to Y M D h m s
-O.int[erval,sec] # set RINEX OBS header observation interval
to # ( > 0.) seconds
-O.leap # set RINEX OBS header leap seconds to #
-O.mn "str" set RINEX OBS header monument number to "str"
-O.mo[nument] "str" set RINEX OBS header monument name to "str"
-O.o[perator] "str" set RINEX OBS header operator name to "str"
-O.rename_obs "str" rename RINEX OBS header observables to "str"
"str" = L1L2C1P2 renames 4 observables to be L1 L2
C1 P2, and in that order
-O.obs[_types] "str" change RINEX OBS header observables to "str"
"str" = L1L2C1P2 sets 4 observables to be L1 L2
C1 P2, and in that order
-O.rn "str" set RINEX OBS header receiver number to "str"
-O.rt "str" set RINEX OBS header receiver type to "str"
-O.rv "str" set RINEX OBS header receiver firmware version to
"str"
-O.r[un_by] "str" set RINEX OBS header run by to "str"
-O.s[ystem] # set RINEX OBS header satellite system to # (= G, R,
S, T, or M)
-O.sl[ant] s d dh set RINEX OBS header antenna position eccentricities
to dh+sqrt(s^2 - (d/2)^2) 0 0 (in meters)
-O.st[art] Y M D h m s set RINEX OBS header start time (first epoch) to Y M
D h m s
-N.{header_option} to edit a specific RINEX NAV header field (see
following)
-N.a[lpha] a0 a1 a2 a3 set RINEX NAV header ionosphere alpha parameters
to a0 a1 a2 a3
-N.b[eta] b0 b1 b2 b3 set RINEX NAV header ionosphere beta parameters
to b0 b1 b2 b3
+N.c[omment] "str" append RINEX NAV header comment "str"
-N.corr[_GLO] yr mon day sec set RINEX GLONASS NAV correction to system time
to yr mon day sec
-N.corr_SBAS yr mon day sec set RINEX SBAS NAV correction to system time
to yr mon day sec
-N.dec[imate] # modulo decimation of NAV ToE epochs to # time units
# = 12h results in ToE epochs at 00 and 12 hours
-N.leap # set RINEX NAV header leap seconds to #
-N.r[un_by] "str" set RINEX NAV header run by to "str"
-N.s[ystem] # set RINEX NAV header satellite system to#(= G, R, S)
-N.UTC A0 A1 t w set RINEX NAV header UTC time model to A0 A1 t w
-pos[ition] run TEQC normally (default)

50 CORS AND OPUS FOR ENGINEERS

 8
OPUS-S Extended Data
Peter Lazio, M.ASCE1

Abstract: Launched in March 2001, the National Geodetic Survey’s (NGS) OPUS (renamed OPUS-S) has changed the way
engineering surveyors access the National Spatial Reference System. The introduction of OPUS extended data three years later
extended the utility of OPUS. The extended data provide not only a means of trouble shooting a bad OPUS run but has also
allowed the knowledgeable user to utilize OPUS in way that were not envisioned when OPUS was first introduced to the public.

Author keywords: Online User Positioning Service; OPUS; GPS positioning; Measurement; Surveys; Adjustments

Introduction Three baselines are processed using the submitted GPS

observations and observations from three Continuously
In March 2001 the National Geodetic Survey (NGS) began Operating Reference Stations (CORS). The resulting three
offering web-based GPS processing with the On-line coordinates are averaged to derive a unique solution that is
Positioning User Service (OPUS) (Mader et al, 2003). OPUS returned to the user by email. With as little as 2 hours of data
allows a user to submit dual-frequency GPS observations OPUS yields results with an expected RMS error of 0.8, 2.1
using the World Wide Web to NGS where the observations and 3.4 cm, in north, east and up respectively (Soler et al.
are processed using NGS’ baseline processing software 2006a).
PAGES (Program for the Adjustment of GPS Ephemerides).
Table 1. Early OPUS Solution Report

1
GPS Survey Manager, Sidney B. Bowne & Son LLP, 235 East Jericho Turnpike, Mineola, New York 11501. E-Mail:
plazio@bownegroup.com; plazio@optonline.net

CORS AND OPUS FOR ENGINEERS 51

 The format of the output returned by OPUS has changed (Lazio 2006, 2007). To request extended data select the
several times over the seven years the service has been “OPTIONS” button on the OPUS main menu as shown in
available. Table 1 shows an early OPUS Solution Report. Figure 1. In the following sections an OPUS report with
With the addition of extended data in February 2004, the extended data will be dissected with an explanation of the
user can better evaluate a solution, trouble-shoot a problem constituent parts. An explanation will follow each segment
solution and extend an OPUS solution from simple point data of the report.
to a stochastic quantity usable in a least squares adjustment
Fig. 1. OPUS Main Menu (August 2010)

Table 2. Standard Report (from OPUS output)

From: "opus" <opus@ngs.noaa.gov>
To: <plazio@optonline.net>
Subject: OPUS solution : f330142a.06o 000402126
Date: Sunday, July 27, 2008 2:09 PM

FILE: f330142a.06o 000402126

NGS OPUS SOLUTION REPORT

========================

All computed coordinate accuracies are listed as peak-to-peak values.

For additional information: www.ngs.noaa.gov/OPUS/Using_OPUS.html#accuracy

USER: plazio@optonline.net DATE: July 27, 2008

RINEX FILE: f330142m.06o TIME: 18:07:43 UTC

SOFTWARE: page5 0612.06 master12.pl START: 2006/05/22 12:57:00

EPHEMERIS: igs13761.eph [precise] STOP: 2006/05/22 18:10:00
NAV FILE: brdc1420.06n OBS USED: 8761 / 9502 : 92%
ANT NAME: TRM22020.00+GP NONE # FIXED AMB: 69 / 70 : 99%
ARP HEIGHT: 2.000 OVERALL RMS: 0.018(m)

52 CORS AND OPUS FOR ENGINEERS

 Table 2. (Continue)

REF FRAME: NAD_83(CORS96)(EPOCH:2002.0000) ITRF00 (EPOCH:2006.3881)

X: 1382964.832(m) 0.015(m) 1382964.135(m) 0.015(m)

Y: -4637167.380(m) 0.034(m) -4637165.933(m) 0.034(m)

Z: 4141144.040(m) 0.014(m) 4141143.943(m) 0.014(m)

LAT: 40 44 47.88635 0.013(m) 40 44 47.91753 0.013(m)

E LON: 286 36 23.08768 0.005(m) 286 36 23.07684 0.005(m)
W LON: 73 23 36.91232 0.005(m) 73 23 36.92316 0.005(m)
EL HGT: -5.360(m) 0.037(m) -6.624(m) 0.037(m)
ORTHO HGT: 25.653(m) 0.043(m) [NAVD88 (Computed using GEOID03)]

UTM COORDINATES STATE PLANE COORDINATES

UTM (Zone 18) SPC (3104 NY L)
Northing (Y) [meters] 4511872.898 64580.407
Easting (X) [meters] 635620.500 351214.977
Convergence [degrees] 1.04868999 0.39664404
Point Scale 0.99982639 0.99999652
Combined Factor 0.99982723 0.99999736

US NATIONAL GRID DESIGNATOR: 18TXL3562011873(NAD 83)

BASE STATIONS USED

PID DESIGNATION LATITUDE LONGITUDE DISTANCE(m)
DI0624 NYVH VALHALLA CORS ARP N410456.221 W0734904.125 51639.4
DI0616 NYQN QUEENS CORS ARP N404310.261 W0734348.267 28583.4
DH5827 CTDA DARIEN CORS ARP N410357.069 W0733025.942 36719.5

NEAREST NGS PUBLISHED CONTROL POINT

KU2527 EAST FARMINGDALE STANDPIPE N404436.137 W0732407.113 795.3

Standard Report errors. In Schwarz (2006) it is shown that the standard

The standard OPUS solution report, shown in Table 2,
includes the point solution information referenced to both the
International Terrestrial Reference Frame of 2000 (ITRF00) at
the epoch of observation and the North American Datum of
1983 (CORS96) (NAD 83 (CORS96)) at January 1, 2002
(epoch 2002.0000). Included with the station coordinates are
the peak-to-peak errors for each coordinate. All
computations are done referenced to ITRF00. The NAD 83
(CORS96) coordinates are derived by transforming the
ITRF00 solution.
Peak-to-peak errors for the geocentric Cartesian coordinates
and curvilinear coordinates (latitude, longitude and ellipsoid
height) are the differences between the highest and lowest
coordinates computed from the three individual baseline
computations. The use of the peak-to-peak error statistic grew
out of the difficulty in characterizing the errors in GPS
baseline processing. Peak-to-peak errors incorporate both the
baseline computation errors and the small errors inherent in
the CORS network itself. The standard deviation of the
individual remote station solutions or of the final OPUS
coordinate solution can be derived from the peak-to-peak
deviation of a singe observation is equal to the peak-to-peak
error divided by 1.6926 and that the standard deviation of the
final coordinate solution is equal to the peak-to-peak error
divided by 2.9317. In Table 2 the standard error for the
individual solutions for latitude, longitude and ellipsoid height
are 0.008 meters, 0.003 meters and 0.022 meters respectively.
For the final solution the standard deviations are 0.004 meters,
0.002 meters and 0.013 meters in latitude, longitude and
ellipsoid heights respectively.
Computing the orthometric height peak-to-peak errors
combines the peak-to-peak errors of the ellipsoid height and
the uncertainties in the geoid model. In this computation the
ellipsoid peak-to-peak error is treated as a standard error. The
standard error of the geoid model is based on a state by state
assessment of the Geoid03 geoid model. Comparing the
geoid separation obtained from Geoid03 with the observed
geoid separation at benchmarks with GPS observations an
RMS, mean and standard deviation was determined for each
state. (Dan Roman, pers. Comm..) These values are listed in
table 1. The RMS value is treated as a standard error in the
computation of the orthometric height peak-to-peak errors
using the relationship

CORS AND OPUS FOR ENGINEERS 53

 This is a refinement assumed from the original method There have been several additions to the main body of the
when OPUS assumed the standard error of the geoid model to report since OPUS’ inception. The state plane coordinate and
be 2.5 centimeters across the entire United States. UTM coordinates have been augmented with the convergence
In addition to the point solution the OPUS report includes angle, point scale factor and combined scale factor at the
the number and percent of observations used, the number and occupied station. The US National Grid Designator (USNG)
percent of ambiguities fixed and the overall solution RMS. is an alpha numeric reference system that overlays the
Prior to the introduction of the extended data this information Universal Transverse Mercator (UTM) projection. As
and the peak-to-peak errors were the only indications of the presented in the OPUS report the USNG designator uniquely
quality of the solution. In solutions that do not include the defines a point with a precision of one meter. (Federal
extended report data the main body of an OPUS solution Geographic Data Committee 2001)
report concludes with the disclaimer found at the end of the
extended information.
Table 3. State by state statistics of Geoid03 MO 102 -0.0130 0.0341 0.0315
MT 166 -0.0101 0.0368 0.0354
Std Dev
NE 142 0.0202 0.0362 0.0300
STATE No. of pts Mean (m) RMS (m) (m)
NV 57 -0.0243 0.0542 0.0485
AK 180 0.0215 0.1199 0.1179
NH 16 0.0143 0.0396 0.0369
AL 178 0.0243 0.0452 0.0380
NJ 275 -0.0082 0.0238 0.0224
AZ 148 -0.0238 0.0413 0.0338
NM 76 -0.0171 0.0285 0.0228
AR 86 0.0113 0.0320 0.0300
NY 130 -0.0054 0.0216 0.0209
CA 549 -0.0427 0.1048 0.0957
NC 1152 -0.0013 0.0254 0.0254
CO 514 -0.0099 0.0397 0.0384
ND 44 -0.0153 0.0323 0.0284
CT 20 0.0142 0.0227 0.0177
OH 254 0.0029 0.0384 0.0382
DE 33 0.0035 0.0359 0.0357
OK 78 -0.0048 0.0253 0.0249
DC 18 0.0027 0.0227 0.0226
OR 160 -0.0112 0.0333 0.0314
FL 1727 -0.0039 0.0290 0.0287
PA 98 -0.0094 0.0379 0.0367
GA 109 0.0093 0.0427 0.0416
RI 22 0.0122 0.0320 0.0296
ID 97 -0.0035 0.0234 0.0232
SC 822 0.0011 0.0359 0.0359
IL 276 0.0053 0.0286 0.0281
SD 242 -0.0010 0.0321 0.0320
IN 106 -0.0155 0.0314 0.0274
TN 158 -0.0116 0.0349 0.0329
IA 89 -0.0172 0.0364 0.0321
TX 354 -0.0114 0.0639 0.0629
KS 101 -0.0278 0.0623 0.0558
UT 34 -0.0169 0.0309 0.0259
KY 107 -0.0187 0.0363 0.0311
VT 327 0.0099 0.0250 0.0229
LA 97 -0.0217 0.0710 0.0676
VA 173 -0.0074 0.0518 0.0512
ME 66 0.0042 0.0289 0.0286
WA 229 0.0003 0.0382 0.0382
MD 400 -0.0054 0.0320 0.0315
WV 48 0.0015 0.0292 0.0292
MA 40 0.0035 0.0258 0.0256
WI 255 -0.0072 0.0247 0.0236
MI 310 -0.0194 0.0479 0.0438
WY 93 -0.0119 0.0337 0.0315
MN 2856 -0.0312 0.0406 0.0260
Average 13784 -0.0109 0.0438 0.0424
MS 170 -0.0006 0.0432 0.0431

Table 4. Base station information (From OPUS extended output)

BASE STATION INFORMATION

STATION NAME: nyvh a 2 (Valhalla; Valhalla, New York USA)

ANTENNA: LEIAT504 LEIS S/N=103235
XYZ 1341803.3771 -4623883.0949 4169356.9015 MON @ 1997.0000 (M)
XYZ -0.0169 -0.0018 0.0037 VEL (M/YR)
NEU 0.0000 0.0000 0.0000 MON TO ARP (M)
NEU -0.0000 0.0000 0.1065 ARP TO L1 PHASE CENTER (M)
NEU -0.0000 0.0000 0.1254 ARP TO L2 PHASE CENTER (M)
XYZ -0.1586 -0.0169 0.0347 VEL TIMES 9.3873 YRS

54 CORS AND OPUS FOR ENGINEERS

 Table 4. (Continue)

XYZ 0.0000 0.0000 0.0000 MON TO ARP

XYZ 0.0224 -0.0771 0.0700 ARP TO L1 PHASE CENTER
XYZ 1341803.2408 -4623883.1889 4169357.0062 L1 PHS CEN @ 2006.3881
XYZ 0.0000 0.0000 0.0000 + XYZ ADJUSTMENTS
XYZ 1341803.2408 -4623883.1889 4169357.0062 NEW L1 PHS CEN @ 2006.3881
XYZ 1341803.2185 -4623883.1118 4169356.9363 NEW ARP @ 2006.3881
XYZ 1341803.2185 -4623883.1118 4169356.9363 NEW MON @ 2006.3881
LLH 41 4 56.25259 286 10 55.86221 62.1718 NEW L1 PHS CEN @ 2006.3881
LLH 41 4 56.25259 286 10 55.86221 62.0653 NEW ARP @ 2006.3881
LLH 41 4 56.25259 286 10 55.86221 62.0653 NEW MON @ 2006.3881

STATION NAME: nyqn a 2 (Queens; Queens, New York USA)

ANTENNA: LEIAT504 LEIS S/N=103215
XYZ 1356258.9646 -4647097.7775 4138865.2431 MON @ 1997.0000 (M)
XYZ -0.0168 -0.0018 0.0038 VEL (M/YR)
NEU 0.0000 0.0000 0.0000 MON TO ARP (M)
NEU -0.0000 0.0000 0.1065 ARP TO L1 PHASE CENTER (M)
NEU -0.0000 0.0000 0.1254 ARP TO L2 PHASE CENTER (M)
XYZ -0.1577 -0.0169 0.0357 VEL TIMES 9.3873 YRS
XYZ 0.0000 0.0000 0.0000 MON TO ARP
XYZ 0.0226 -0.0775 0.0695 ARP TO L1 PHASE CENTER
XYZ 1356258.8295 -4647097.8719 4138865.3482 L1 PHS CEN @ 2006.3881
XYZ 0.0000 0.0000 -0.0000 + XYZ ADJUSTMENTS
XYZ 1356258.8295 -4647097.8719 4138865.3482 NEW L1 PHS CEN @ 2006.3881
XYZ 1356258.8069 -4647097.7944 4138865.2788 NEW ARP @ 2006.3881
XYZ 1356258.8069 -4647097.7944 4138865.2788 NEW MON @ 2006.3881
LLH 40 43 10.29312 286 16 11.72135 -1.5348 NEW L1 PHS CEN @ 2006.3881
LLH 40 43 10.29312 286 16 11.72135 -1.6413 NEW ARP @ 2006.3881
LLH 40 43 10.29312 286 16 11.72135 -1.6413 NEW MON @ 2006.3881

STATION NAME: ctda a 2 (Darien; Darien, Connecticut USA)

ANTENNA: TRM29659.00 SCIS S/N=0220260478
XYZ 1367174.0900 -4617635.3598 4167930.9814 MON @ 1997.0000 (M)
XYZ -0.0169 -0.0018 0.0038 VEL (M/YR)
NEU 0.0000 0.0000 0.0000 MON TO ARP (M)
NEU -0.0000 0.0000 0.1065 ARP TO L1 PHASE CENTER (M)
NEU -0.0000 0.0000 0.1258 ARP TO L2 PHASE CENTER (M)
XYZ -0.1586 -0.0169 0.0357 VEL TIMES 9.3873 YRS
XYZ 0.0000 0.0000 0.0000 MON TO ARP
XYZ 0.0228 -0.0770 0.0700 ARP TO L1 PHASE CENTER
XYZ 1367173.9541 -4617635.4537 4167931.0870 L1 PHS CEN @ 2006.3881
XYZ -0.0000 -0.0000 -0.0000 + XYZ ADJUSTMENTS
XYZ 1367173.9541 -4617635.4537 4167931.0870 NEW L1 PHS CEN @ 2006.3881
XYZ 1367173.9314 -4617635.3767 4167931.0171 NEW ARP @ 2006.3881
XYZ 1367173.9314 -4617635.3767 4167931.0171 NEW MON @ 2006.3881
LLH 41 3 57.10139 286 29 34.04624 -14.4085 NEW L1 PHS CEN @ 2006.3881
LLH 41 3 57.10139 286 29 34.04624 -14.5150 NEW ARP @ 2006.3881
LLH 41 3 57.10139 286 29 34.04624 -14.5150 NEW MON @ 2006.3881

Base Station Information
Referring to Table 4, each CORS is identified by the 4
character designation, site name, antenna type and serial
number are listed. Following this is the ITRF00 earth
centered earth fixed (ECEF) Cartesian coordinate at epoch
1997.00 (January 1, 1997) with its ITRF00 velocity. The
north, east, up (NEU) relationship between the monument and
antenna reference point (ARP) is listed. For these three
CORS: NYVH, NYQN and CTDA the ARP is assumed to be
the monument so all the offsets are zeros. This is followed by
the NEU relationship between the ARP to L1 antenna phase
center (APC) and the ARP to L2 APC for the particular
antenna used in this example. The antenna type, serial
number and monument to ARP offset can be verified by

CORS AND OPUS FOR ENGINEERS 55

referring to the Site Log available at the following address
<ftp://www.ngs.noaa.gov/cors/station_log/>
Using the published XYZ velocity and the elapsed time
since January 1, 1997 the monument displacement since
1997.00 is computed. The NEU relationships of the
monument to ARP and ARP to L1 APC are transformed to
ECEF XYZ offsets. The XYZ relationship of the monument
to ARP is listed followed by the XYZ relationship of the ARP
to L1 APC. Using this information the ITRF00 ECEF XYZ
coordinate of the L1 APC is computed for the epoch of
observation (2006.3881). All GPS baseline reduction
computations take place from the L1 APC at a CORS to the
L1 APC at the remote station.
When PAGES processes baselines it does not rigidly fix the
coordinates of the CORS L1 APC. Instead the coordinates are
heavily weighted and allowed to vary in the baseline
computation. This is reflected in the XYZ adjustment listed
after the L1 PHS CEN @ 2006.3881. This adjustment is very
small, usually less than a millimeter. In each case above it is
zero for X, Y and Z. Using the XYZ adjustment and the XYZ
coordinate of the L1 APC at the epoch of observation a new
L1 APC is computed at the epoch of observation.
Reversing the calculations listed above new ARP and
monument coordinates are computed in XYZ followed by
those same coordinates transformed to curvilinear coordinates.
All the computations listed in Table 4, as well as those in
Tables 5 and 6 below, are referenced to ITRF00 at the epoch
of observation using the GRS80 ellipsoid. It is not until all
computations have been completed using the ITRF00
reference frame that the positions are transformed to NAD83
(CORS96) (epoch 2002.00) using the GRS80 ellipsoid.
.

Table 5. Remote Station Information (From OPUS extended output)

REMOTE STATION INFORMATION

STATION NAME: f330 1

ANTENNA: TRM22020.00+GP NONE S/N=UNKNOWN
XYZ 1382964.6690 -4637167.4925 4141145.3898 MON @ 2006.3878 (M)
NEU 0.0000 -0.0000 2.0000 MON TO ARP (M)
NEU -0.0000 0.0000 0.0742 ARP TO L1 PHASE CENTER (M)
NEU -0.0000 0.0000 0.0705 ARP TO L2 PHASE CENTER (M)
XYZ 0.4330 -1.4520 1.3054 MON TO ARP
XYZ 0.0161 -0.0539 0.0484 ARP TO L1 PHASE CENTER
XYZ 1382965.1181 -4637168.9984 4141146.7437 L1 PHS CEN @ 2006.3881

Remote Station Information
In Table 5, the first section lists the station name and antenna
type. The antenna name is the same as listed in the main body
of the report. The XYZ coordinate is an initial estimate of the
remote monument coordinate used in the baseline
computation. This coordinate is referenced to ITRF00 at
the epoch of obser-vation. The antenna height and the
relationship between the ARP to L1 APC and the ARP to L2
APC, referenced to the local geodetic frame (enu), are listed
similar to the CORS. The antenna height is the height
submitted to OPUS by the user through the OPUS web-site.
OPUS does not read the antenna height from the GPS
observation file. This is followed by monument to APR and
ARP to L1 APC relationship referenced to ECEF XYZ
coordinates. Using this information an initial coordinate for
the L1 APC is computed. .

Table 6. Individual Baseline Computation (From OPUS extended output)

BASELINE NAME: nyvh f330

XYZ -0.5400 1.5695 -1.4513 + XYZ ADJUSTMENTS
XYZ 1382964.5781 -4637167.4289 4141145.2923 NEW L1 PHS CEN @ 2006.3881
XYZ 1382964.5620 -4637167.3750 4141145.2439 NEW ARP @ 2006.3881
XYZ 1382964.1290 -4637165.9230 4141143.9385 NEW MON @ 2006.3881
LLH 40 44 47.91765 286 36 23.07672 -4.5616 NEW L1 PHS CEN @ 2006.3881
LLH 40 44 47.91765 286 36 23.07672 -4.6358 NEW ARP @ 2006.3881
LLH 40 44 47.91765 286 36 23.07672 -6.6358 NEW MON @ 2006.3881

BASELINE NAME: nyqn f330

XYZ -0.5382 1.5719 -1.4514 + XYZ ADJUSTMENTS
XYZ 1382964.5799 -4637167.4264 4141145.2923 NEW L1 PHS CEN @ 2006.3881
XYZ 1382964.5638 -4637167.3726 4141145.2438 NEW ARP @ 2006.3881
XYZ 1382964.1308 -4637165.9206 4141143.9384 NEW MON @ 2006.3881
LLH 40 44 47.91769 286 36 23.07682 -4.5630 NEW L1 PHS CEN @ 2006.3881

56 CORS AND OPUS FOR ENGINEERS

 Table 6. (Continue)

LLH 40 44 47.91769 286 36 23.07682 -4.6372 NEW ARP @ 2006.3881

LLH 40 44 47.91769 286 36 23.07682 -6.6372 NEW MON @ 2006.3881

BASELINE NAME: ctda f330

XYZ -0.5247 1.5377 -1.4374 + XYZ ADJUSTMENTS
XYZ 1382964.5934 -4637167.4607 4141145.3063 NEW L1 PHS CEN @ 2006.3881
XYZ 1382964.5774 -4637167.4068 4141145.2578 NEW ARP @ 2006.3881
XYZ 1382964.1443 -4637165.9548 4141143.9524 NEW MON @ 2006.3881
LLH 40 44 47.91726 286 36 23.07695 -4.5261 NEW L1 PHS CEN @ 2006.3881
LLH 40 44 47.91726 286 36 23.07695 -4.6003 NEW ARP @ 2006.3881
LLH 40 44 47.91726 286 36 23.07695 -6.6003 NEW MON @ 2006.3881

Individual Baseline Computation
OPUS computes thee individual baselines. In Table 6 each of
the baseline, XYZ adjustments are computed by the PAGES
baseline processing software. These adjustments are applied
to the initial estimate of the L1 APC coordinate for the remote
station to arrive at a new L1 APC at the epoch of observation.
Using the XYZ relationships between the L1 APC to ARP and
ARP to monument, the ARP and monument coordinates are
computed from the new L1 APC coordinate. The same
computations are carried out using curvilinear coordinates.
This results in three different coordinates for the remote
station. A unique solution is arrived at by taking the
arithmetic mean of each component of these three ITRF00
coordinates. The difference between the highest and lowest
value for each coordinate component is the peak-to-peak error
for that component. The mean and peak-to-peak values are
listed in the standard OPUS solution report.

Table 7. G-File (From OPUS extended output)

G-FILES

Axx2006 522 6 522

B2006 5221256 6 52218 9 1 page5 v0612.06IGS 222 1 2 27NGS 2008 727IFDDFX
Iant_info.003 NGS 20080718
C00090001 -411609105 9 132828112 20 282129978 19 X1426AF330X1426ANYVH
D 1 2 -6278959 1 3 4696916 2 3 -9003062

Axx2006 522 6 522

B2006 5221256 6 52218 9 1 page5 v0612.06IGS 222 1 2 27NGS 2008 727IFDDFX
Iant_info.003 NGS 20080718
C00090002 -267053239 9 -99318738 29 -22786596 25 X1426AF330X1426ANYQN
D 1 2 -5336327 1 3 5743021 2 3 -9361052

Axx2006 522 6 522

B2006 5221256 6 52218 9 1 page5 v0612.06IGS 222 1 2 27NGS 2008 727IFDDFX
Iant_info.003 NGS 20080718
C00090003 -157902130 11 195305781 25 267870647 23 X1426AF330X1426ACTDA
D 1 2 -8264196 1 3 3646740 2 3 -6972347

The G-File

This is a highly formatted file, used by the NGS that contains
the vector components with their corresponding standard
errors and the non-diagonal correlation matrix elements for
each observed vector. For more information on the format of
the G-File see <http://www.ngs.noaa.gov/FGCS/BlueBook/
pdf/Annex_N.pdf>.
The G-File as included in the OPUS extended data is shown
in Table 7. This G-File can be cut and pasted into a text file.
Many least squares adjustment software can read this file.
Extracting the G-File from the OPUS extended data
transforms OPUS from a point solution utility into a conduit
to the PAGES baseline reduction software. One can get the
benefits of a scientific GPS baseline processor without having
to learn new software. GPS baselines mined from the
extended data can be used like any other GPS baseline in a
network adjustment including all available observations.

CORS AND OPUS FOR ENGINEERS 57

 Table 8. Post-Fit RMS by Satellite vs. Baseline (From OPUS extended output)
POST-FIT RMS BY SATELLITE VS. BASELINE

OVERALL 02 04 05 06 07 08 09 10
nyvh-f330| 0.016 0.012 0.018 0.018 0.018 0.021 0.018 0.020 0.020
13 14 15 18 21 22 26 27 29
nyvh-f330| ... 0.015 ... 0.015 0.017 0.017 0.014 ... 0.014
30
nyvh-f330| 0.019

OVERALL 02 04 05 06 07 08 09 10
nyqn-f330| 0.018 0.012 0.020 0.025 0.019 0.023 ... 0.022 0.026
13 14 15 18 21 22 26 27 29
nyqn-f330| ... ... ... 0.016 0.017 0.019 0.015 ... 0.015
30
nyqn-f330| 0.022

OVERALL 02 04 05 06 07 08 09 10
ctda-f330| 0.020 0.012 0.019 0.023 0.019 0.029 0.021 0.018 0.030
13 14 15 18 21 22 26 27 29
ctda-f330| ... ... ... 0.022 0.020 0.022 0.018 ... 0.016
30
ctda-f330| 0.026

observations from a problem satellite can be isolated. Once

Post-Fit RMS by Satellite vs. Baseline isolated, these observations can be removed from the RINEX
file using TEQC (Estey and Meertens 1999) from UNAVCO
The individual RMS values are given for each satellite <http://www.unavco.org> and the RINEX file resubmitted to
observed. Using this information, shown in Table 8, OPUS.
Table 9. Observations by Satellite vs. Baseline (From OPUS extended output)
OBS BY SATELLITE VS. BASELINE

OVERALL 02 04 05 06 07 08 09 10
nyvh-f330| 2904 244 125 68 403 144 49 163 81
13 14 15 18 21 22 26 27 29
nyvh-f330| ... 24 ... 137 310 56 475 ... 501
30
nyvh-f330| 124
OVERALL 02 04 05 06 07 08 09 10
nyqn-f330| 2833 255 120 61 403 129 ... 176 62
13 14 15 18 21 22 26 27 29
nyqn-f330| ... ... ... 138 290 74 476 ... 525
30
nyqn-f330| 124
OVERALL 02 04 05 06 07 08 09 10
ctda-f330| 3024 250 120 68 415 144 70 163 78
13 14 15 18 21 22 26 27 29
ctda-f330| ... ... ... 140 341 74 496 ... 538
30
ctda-f330| 127

data file is not reflected in this section further investigation is

Observations by Satellite vs. Baseline warranted. The missing data may be indicative of a problem
The total number of observations from each satellite is listed tracking that particular satellite. Using the clues provided in
in Table 9. If satellite data know to be in the GPS observation this section the user may be able to edit the RINEX file to
produce a better OPUS solution.

58 CORS AND OPUS FOR ENGINEERS

 Table 10. Covariance Matrix (From OPUS extended output)

Covariance Matrix for the xyz OPUS Position (meters^2).

0.0000006289 -0.0000001066 0.0000000671
-0.0000001066 0.0000041467 -0.0000003159
0.0000000671 -0.0000003159 0.0000033667
Covariance Matrix for the enu OPUS Position (meters^2).
0.0000008578 0.0000005487 -0.0000006812
0.0000005487 0.0000032816 -0.0000002225
-0.0000006812 -0.0000002225 0.0000040028
Covariance Matrix
The section of the extended data report shown in Table 10 is empirically modified to account for those correlations. This
the covariance matrix of the point solution. The covariance empirical modification has the effect of scaling the
matrix is given referenced to ITRF XYZ and local enu. The unmodified covariance matrix by a factor of two. Even with
diagonal elements are the variances of the XYZ or enu this modification the OPUS covariance matrix is typically
coordinate as appropriate. The off diagonal elements are the optimistic. These optimistic results, frequently referred to as
covariance between the elements. “formal errors” are characteristic to all GPS baseline
This covariance matrix is derived using standard error processing in general.
propagation computations. Because OPUS processes the three The OPUS covariance matrix can be used to include the
baselines between the CORS and the remote station OPUS point solution stochastic quantities in a least squares
individually, rather than in a session, the correlations between adjustment, rather than as fixed points. (Lazio 2006; 2007)
the baselines are lost. The OPUS covariance matrix is

Table 11. Horizontal and Vertical Network Accuracy (From OPUS extended output)

Horizontal network accuracy = 0.00373 meters.

Vertical network accuracy = 0.00392 meters.

Horizontal and Vertical Network Accuracy
The horizontal network accuracy represents the radius of a
95% confidence circle. (Leenhouts 1985) The radius of the
95% confidence circle is computed using the semi-minor and
semi-major axis of the standard error ellipse. These are listed
in Table 11.
The vertical network accuracy is 1.95(σu) where σu is the
square root of the 3,3 element in the enu covariance matrix.
Since both these estimates are ultimately derived from the
OPUS covariance matrix they are usually optimistic.

Table 12. NAD83 Computations (From OPUS extended output)

Derivation of NAD 83 vector components

Position of reference station ARP in NAD_83(CORS96)(EPOCH:2002.0000).

Xa(m) Ya(m) Za(m)
NYVH 1341803.92297 -4623884.55068 4169357.02463 2002.00
NYQN 1356259.51058 -4647099.23777 4138865.37024 2002.00
CTDA 1367174.63622 -4617636.81709 4167931.10493 2002.00

Position of reference station monument in NAD_83(CORS96)(EPOCH:2002.0000).

Xr(m) Yr(m) Zr(m)
NYVH 1341803.92297 -4623884.55068 4169357.02463 2002.00
NYQN 1356259.51058 -4647099.23777 4138865.37024 2002.00
CTDA 1367174.63622 -4617636.81709 4167931.10493 2002.00

CORS AND OPUS FOR ENGINEERS 59

 Table 12. (Continue)

Velocity of reference station monument in NAD_83(CORS96)(EPOCH:2002.0000).

Vx (m/yr) Vy (m/yr) Vz (m/yr)
NYVH 0.00000 0.00000 -0.00000
NYQN -0.00000 0.00000 0.00000
CTDA -0.00000 0.00000 -0.00000

Vectors from unknown station monument to reference station monument

in NAD_83(CORS96)(EPOCH:2002.0000).

Xr-X= DX(m) Yr-Y= DY(m) Zr-Z= DZ(m)

NYVH -41160.90903 13282.82932 28212.98463 2002.00
NYQN -26705.32142 -9931.85777 -2278.66976 2002.00
CTDA -15790.19578 19530.56291 26787.06493 2002.00

NAD 83 Computations
In Table12, using HTDP (Snay 1999), the ITRF00 positions
of the CORS monument and ARP and the velocity of the
CORS monument are transformed to NAD83 (CORS96)
(epoch 2002.0000). The vector from the remote station to
each CORS is computed by subtracting the NAD83
(CORS96) (epoch 2002.0000) XYZ coordinate of the CORS
from the NAD 83 (CORS96) (epoch 2002.0000) XYZ
coordinate of the remote station. It is important to note that
these vectors are not observed quantities but rather derived
from the coordinate solutions. Subtracting these vectors from
each of the CORS coordinates will arrive at the same solution
for the remote station which would not be the case if the
vectors were actual observations.
This is a change since OPUS was initially released.
Originally OPUS rotated and scaled the three individual
ITRF00 vectors into the NAD 83 reference frame. These
transformed vectors were then added to the NAD83
coordinates of the CORS. This resulted in three individual
NAD 83 coordinates for the remote station. These three
coordinates were then averaged to derive a unique solution.
This method better preserved small localized distortions in the
NAD 83 (1986) and HARN reference frame, and provided a
more realistic determination of the NAD83 coordinate of the
remote station with respect to passive stations. (Soler
2002).The new method preserves the one-to-one relationship
between points referenced to ITRF00 and the same point
referenced to NAD 83 (CORS96). This is in line with the
International Association of Geodesy (IAG) recommendation
that reference systems by tied to the ITRS. (Craymer 1999)
With the readjustment of the National Spatial Reference
System (NSRS) in 2005-2007 those local distortions of the
NAD 83 have been removed.

Table 13. State Plane coordinates converted to feet (From OPUS extended output)

STATE PLANE COORDINATES - U.S. Survey Foot

SPC (3104 NY L)
Northing (Y) [feet] 211877.554
Easting (X) [feet] 1152277.803
Convergence [degrees] 0.39664404
Point Scale 0.99999652
Combined Factor 0.99999736

State Plane Coordinates
All OPUS computations are computed in meters. In the
standard report the state plane coordinates are reported in
meters. In the section of the extended data listed in Table 13
the state plane coordinates are converted to feet. The units are
either U.S. Survey Feet (39.37 inches = 1 meter) or
International Feet (1 inch = 2.54 centimeters) depending on
the state legislation for State Plane coordinates. In states that
do not specify a conversion this section is not included.

60 CORS AND OPUS FOR ENGINEERS

 Table 14. Disclaimer (From OPUS extended output)
This position and the above vector components were computed without any
knowledge by the National Geodetic Survey regarding the equipment or
field operating procedures used.

Disclaimer

If OPUS extended data is not requested the disclaimer, shown in Table 14, is included at the end of the standard report.

Table 15. Request for mark recovery (From OPUS extended output)

8002 The Opus solution for your submitted RINEX file appears to be
8002 quite close to an NGS published control point. This suggests that
8002 you may have set your GPS receiver up over an NGS control point.
8002 Furthermore, our files indicate that this control point has not
8002 been recovered in the last five years.
8002 If you did indeed recover an NGS control point, we would
8002 appreciate receiving this information through our web based
8002 Mark Recovery Form at
8002 http://www.ngs.noaa.gov/products_services.shtml#MarkRecoveryForm.

Request for Mark Recovery

If from the solution coordinates it appears that a station
included the NGS Integrated Data Base (NGSIDB) was
occupied as the remote station and there is no recovery record
of that station in the last five years a request to file a mark
recovery form appears after the disclaimer. This request is
listed in Table 15. Mark recoveries can be filed on line at
<http://www.ngs.noaa.gov/ngs-cgi-bin/recvy_entry_www.prl>
Conclusions
OPUS has changed the way the surveying engineering
community access the NSRS. The introduction of the OPUS
extended data section has increased the utility of OPUS. The
extended data provide not only a means of trouble shooting a
bad OPUS run but has also allowed the knowledgeable user to
utilize OPUS in way that were not envisioned when OPUS
was first introduced to the public.
References
Craymer, M., Ferland, R., and Snay, R. (1999).”Realization
and unification of NAD83 in Canada and the U.S. via the
ITRF.” Proc., IAG, Munich, Germany
Estey, L H., and Meertens, C. M. (1999). “TEQC: The multi-
purpose toolkit for GPS/GLONASS Data.” GPS Solutions,
3(1), 42-49
Federal Geographic Data Committee (2001). “United States
National Grid.” Standards Working Group, Reston, VA
Lazio, P. (2006).”OPUS observations.” Surv. Land Inf. Sci.,
66(3), 185-194
Lazio, P. (2007). “Constraining network adjustments to
OPU-RS coordinate observations.” J. Surv. Eng. 133(3),
106-113
Leenhouts, P.P. (1985). “On the computation of bi-normal
radial error.” Navigation, 32(1), 16-28.
Mader, G. L., Weston, N. D., Morrison, M. L., and Milbert,
D. G. (2003). “The On-line Positioning User Service
(OPUS).” Prof. Surveyor, 23(5), 26, 28, 30.
Schwarz, C.R. (2006). “Statistics of range of a set of
normally distributed numbers.” J. Surv. Eng.,132(4),
155-159
Snay, R. A.(1999). ”Using the HTDP software to transform
spatial coordinates across time and between reference
frames.” Surv. Land Inf. Sys., 59(1), 15-25
Soler, T., Weston, N. D., and Han, H. (2002). “Computing
NAD 83 coordinates using ITRF-derived vector
components.” Proc. XXII FIG Int. Congress, ACSM/
ASPRS Annual Conference, Washington, D.C.
Soler, T., Michalak, P., Weston, N. D., Snay, R.A., and
Foote, R. H.(2006a). “Accuracy of OPUS solutions for 1-
h to 4-h observing sessions.” GPS Solutions, 10(1), 45-
55.
Soler, T.,Weston, N.D., Snay, R.A., Mader, G.L., and
Foote, R. H. (2006b). “Precise georeferencing using the
on-line positioning user service (OPUS).” Proc., XXIII
Int. FIG Congress, Munich, Germany

CORS AND OPUS FOR ENGINEERS 61

 9
Editing RINEX Files to Fix a Poor OPUS Run
Peter Lazio, M.ASCE1

Abstract: OPUS is becoming a primary means of tying survey networks to the National Spatial Reference System (NSRS).
Once data is submitted to OPUS the process is automated with no human intervention. This is very convenient when it works.
On the rare occasions when the process returns a poor result, knowledge of the RINEX file format and editing tools such as
TEQC from UNAVCO can be used to transform a poor solution into an acceptable solution.

Author keywords: GPS positioning; geodetic networks

Introduction Original OPUS Run

The National Geodetic Survey’s (NGS) Online Positioning
User Service (OPUS) <http://www.ngs.noaa.gov/OPUS> is
rapidly becoming the primary means of tying engineering
surveys to the National Spatial Reference System (NSRS).
OPUS provides a convenient means of reducing dual
frequency GPS observations to coordinates. Once the data is
uploaded to the OPUS web site the process is automated and
the user will often get their results within several minutes. On
the rare occasions when the process returns a poor result,
knowledge of the RINEX (Gurtner and Estey 2007) format
and editing tools such as TEQC (Translate Edit Quality
Control) (Estey and Meertens 1999) from UNAVCO
(<http://www.unavco.org>) can be used to transform a poor
solution into an acceptable one.
Figure 1 shows a clip from an OPUS solution report with the
coordinate solution, peak-to-peak errors and quality control
statistics after submitting 5 hours 2 minutes and 30 seconds of
dual frequency GPS observations to the NGS OPUS web site
<http://www.ngs.noaa.gov/OPUS/> for a solution.
The “Using OPUS” page at the OPUS web-site
<http://www.ngs.noaa.gov/OPUS/Using_OPUS.html >
describes a good OPUS run as one that:
1. Uses 90% or more of the observations
2. Has at least 50% of the ambiguities fixed
3. Has overall RMS seldom exceeding 3 cm
4. Has peak to peak errors that seldom exceed 5 cm
Based on those criteria this is not a good OPUS run.

Fig. 1. OPUS Coordinate Solution

1
GPS Survey Manager, Sidney B. Bowne & Son LLP, 235 East Jericho Turnpike, Mineola, New York 11501. E-Mail:
plazio@bownegroup.com; plazio@optonline.net

62 CORS AND OPUS FOR ENGINEERS

 Fig. 2. Observations file in TGO Timeline window Fig. 3. Data summary from short TEQC quality control file
CORS AND OPUS FOR ENGINEERS

Fig. 5. Data summary with missing satellites highlighted

Fig. 4. OPUS Extended data - Observations by satellite vs. baseline
63

Table 1. TEQC QC symbols
Symbol Meaning
C Receiver clock slip
I Ionospheric phase slip
2 Mulitpath MP2 slip only
0 A/S on; L1 C/A L2 P2
L Bit 0 of LLI set (rx lost lock)
Analyzing the Data
The GPS observations from this occupation were also used to
reduce baselines radiating from this station. All those
baselines were reduced with good statistics and repeatability
so the data seemed fundamentally sound. Figure 2 shows the
GPS observations as presented in the timeline of Trimble
Geomatics Office (TGO) software (Trimble Navigation LTD,
Sunnyvale, CA). Reviewing the timeline there are no obvious
serious problems with the data. The minor L2 cycle slips for
SVs 16 and 28 should not cause the problems with this OPUS
run.
Analyzing the extended data section of the OPUS report and
particularly examining the Observations by Satellite vs.
Baseline section, as isolated in Figure 3, reveals that OPUS
did not use any satellite data for SVs 7, 13, 16, 17, 23 and 25.
The TGO time line indicates that this data is present in the
observation file.
To further investigate the observation file, the quality
control functions of TEQC were used. TEQC is a command
line program. To run TEQC on a Windows system click on
the Start Button > Run > and type cmd in the Run dialog box.
This will initiate a command line session in Windows. The
TEQC executable must be in the current directory or in a
directory specified in the PATH environment variable to run.
Executing TEQC with the following command line
arguments:
TEQC +qc filenm.06o
will produce a short report named filenm.06S. This report
contains a lot of detailed information about the observation
file. The first bit of information from that file is a graphic
summary of the file. This graphic representation, using ASCII
characters, is not as slick as the Time Line in TGO yet it
actually contains more information. Figure 4 is the TEQC QC
representation of the same data shown in Figure 2.
TEQC uses ASCII character to symbolize events in time
interval covered. In this case each symbol covers an interval
of approximately four and a half minutes. The specific
symbols used in this summary and their meanings are listed in
Table 1.
For a complete list of the symbols used by TEQC in this
graphic execute TEQC with the following command line
options:
TEQC ++sym.
64 CORS AND OPUS FOR ENGINEERS
Table 2. Bit coding for RINEX LLI
Bit 0 Lost lock between previous and current
set observation: cycle slip possible (phase only)
Bit 1 Opposite wavelength factor to the one defined
set for the satellite by the previous
WAVELENGTH FACT L1/2 line. Valid for the
current epoch only (phase only)
Bit 2 Observations under Antispoofing (may suffer
set from increased noise)
Figure 5 is the same TEQC observation summary highlighting
the observations for the satellites missing from the OPUS
extended data report. Without the missing satellites there is
about an hour and 20 minutes at the beginning of the file with
only three satellites observed. A minimum of four satellites
are needed to determine a 3D position. Note the “L” at the
initial observations for SVs 31, 25, 7, 23, 16, 13, 3 and 19.
This indicates a loss of lock on that particular satellite.
The RINEX Observation File
Figure 6 shows a clip from the RINEX file which includes the
last five lines of the RINEX header and the first three epochs
of data. The top line indicates the types of observables
included in the RINEX file. This file includes, in order, L1 -
phase measurement on L1, C1 - pseudorange using C/A on
L1, L2 - phase measurement on L2, P2 - pseudorange using P-
Code on L2 and D1 – L1 Doppler. In the first epoch of data
the L2 and P2 observables are missing entirely.
The RINEX standard calls for a F14.3 format for all
observables. An F14.3 format indicates floating point number
occupying 14-character field width with 3 decimal places.
What appears to be a fourth decimal place in the L1
observables of the first epoch of data is the Loss of Lock
Indicator (LLI). This is a bit coded integer in the range of 0 to
7. Table 2 indicates the bit coding for this field. A missing
value indicates no bits set.
In the first epoch the LLI for all L1 phase observables is 1
indicating the first bit is set for every L1 observable. This
indicates a loss of lock for all observed L1 observables.
Continuing to the second epoch the LLI for the L1 phase
observable is now clear indicating the receiver has locked
onto and is continuously recording the L1 phase observable.
The LLI for L2 phase is set to 5 indicating that bit 0 and bit 2
are set. These observations are being made under
antispoofing conditions but the receiver has not yet locked
onto the L2 phase observable. The LLI for P2 code is set to 4
indicating observations made under anitspoofing conditions.
Finally in the third epoch all the LLI bits are cleared for the
L1 phase observable; only bit 2 of the LLI is set for the L2
and P2 observables. Lock is maintained for all phase
observables on the third epoch and beyond. In Figure 6, the
shaded LLIs indicate a loss of lock.
 Fig. 6. Clip of RINEX file with problem data highlighted

Editing the RINEX Data

This information can be used to edit the RINEX file submitted
to OPUS while leaving the maximum valid data possible in
the observation file. Two methods will be discussed for
editing RINEX files.
Being an ASCII file, the most direct method of editing a
RINEX file is to use a text editor. The first two epochs can
simply be cut out of the RINEX file. One would then edit the
TIME OF FIRST OBS record in the header to coincide with
the first recorded observations. Figure 7 illustrates the
selection of the first two epochs of data using a text editor.
The second method involves using TEQC. The E in TEQC
stands for Edit. One of the editing features of TEQC is
windowing data from a larger data file. The –st argument
specifies a starting time for windowing data from a RINEX
file. Using the command line,
TEQC –st 135530 filenm1.06o>filenm2.06o
windows all data starting at 13:55:30 (the third epoch) from
filenm1.06o to filenm2.06o. This effectively removes the first
two epochs from the RINEX file.

Fig. 7. Selecting first two epochs of data using text editor

CORS AND OPUS FOR ENGINEERS 65

 Fig. 8. Part of OPUS report from edited RINEX file

2nd Submission to OPUS
After removing the corrupt data from the original RINEX file,
the edited RINEX file is resubmitted to OPUS. Figure 8
shows a clip of the relevant section of the OPUS report.
After removing just two epochs of data, the percent of
observations used, the number of fixed ambiguities, overall
RMS and the peak to peak errors all indicate a very good
OPUS run.
Conclusions
Assuming sufficient observation time and good observation
conditions, using the proper tools and analysis a poor OPUS
run may be transformed into a very good OPUS run. Using
TEQC to assess the quality of a RINEX file and an unders-
tanding of the RINEX file format one can determine the
minimum amount of data to remove from the RINEX file for
an optimal OPUS run.
References
Estey, L H., Meertens, C. M. (1999). “TEQC: The Multi-
Purpose Toolkit for GPS/GLONASS Data.” GPS
Solutions, 3(1), 42-49
Gurtner, W., Estey, L.H. (2007). “RINEX The Receiver
Independent Exchange Format Version 2.11.” Available
at <ftp://igscb.jpl.nasa.gov/igscb/data/format/rinex211.txt>
(July 23, 2008)

66 CORS AND OPUS FOR ENGINEERS

 10
Heuristic Weighting and Data Conditioning in the National
Geodetic Survey Rapid Static GPS Software
Charles R. Schwarz1

Abstract: NOAA’s National Geodetic Survey 共NGS兲 has developed the Rapid Static GPS software for use as the major processing engine
in the OPUS-RS utility 共online positioning user service—rapid static兲 共http://www.ngs.noaa.gov/OPUS/OPUS-RS.html兲. The software
was written specifically to support the computation of static positions from GPS tracking sessions as short as 15 min, while using
reference station data from the NGS archive of continuously operating reference stations 共CORS兲. When the reference stations are close
共50 km兲 to the user’s station, it is relatively easy to obtain an accurate solution. However, the CORS stations in the NGS archive are
separated by 200 km or more in many areas of the country. In this situation, much care must be taken in conditioning the data sets and
in selecting appropriate weights for the observations and constraints. This paper describes methods and weights that have been found to
work well for most 共but not quite all兲 data sets, and, therefore, can be used in an automated procedure such as OPUS-RS.
DOI: 10.1061/共ASCE兲0733-9453共2008兲134:3共76兲
CE Database subject headings: Global positioning; Data processing; Computer software; Geodetic surveys.

Introduction odology developed by the SPIN group and implemented in its

NOAA’s National Geodetic Survey 共NGS兲 has used the Program
for Adjustment of GPS Ephemerides 共PAGES兲 software 共National
Geodetic Survey 1999兲 for the computation of both orbits and
positions from GPS tracking data for many years. This program is
also the major processing engine for the NGS on-line positioning
user service 共OPUS兲 utility 共http://www.ngs.noaa.gov/OPUS/
OPUS.html兲. The OPUS utility is designed to handle baselines of
several hundred km in length, but requires long 共at least 2 h兲
tracking sessions to get accurate results 共Soler et al. 2006兲.
At a series of continuously operating reference station 共CORS兲
user forums, many OPUS users had asked for the capability to
handle shorter data sets 共as short as 15 min兲. It was known that
accurate differential positioning could be done with very short
data sets over very short baselines 共this is the basis for many RTK
programs兲. The challenge was to compute accurate positions
共within a few cm兲 from short data sets using reference stations
from the NGS CORS archive 共Snay and Soler 2008兲. This net-
work of reference stations provides baseline lengths of
100– 200 km in many areas, but in areas where the CORS net-
work is sparse, the baseline lengths are much longer.
Research conducted by the satellite positioning and inertial
navigation 共SPIN兲 group at the Ohio State University 共Wielgosz
et al. 2004; Kashani et al. 2005; Grejner-Brzezinska et al. 2005,
2007兲 indicated that the challenge could be met, at least for areas
in which the reference station data is well behaved. The new NGS
rapid static GPS software RSGPS is based on the ideas and meth-
1
Consultant, Geodesy, 5320 Wehawken Rd., Bethesda, MD 20816.
E-mail: charlies2@earthlink.net
Note. Discussion open until January 1, 2009. Separate discussions
must be submitted for individual papers. To extend the closing date by
one month, a written request must be filed with the ASCE Managing
Editor. The manuscript for this paper was submitted for review and pos-
sible publication on September 5, 2007; approved on December 27, 2007.
This paper is part of the Journal of Surveying Engineering, Vol. 134,
No. 3, August 1, 2008. ©ASCE, ISSN 0733-9453/2008/3-76–82/$25.00.
multipurpose GPS 共MPGPS兲 software. RSGPS became the major
processing engine for the OPUS-RS web utility 共http://www.
ngs.noaa.gov/OPUS/OPUS-RS.html兲, which became operational
in Jan. 2007.
During the development of RSGPS and OPUS-RS, it was
found that the reference station GPS tracking data obtained from
the CORS sites are not always as good as the data from the Ohio
CORS sites that had been selected by the SPIN group for their
analysis. Additional features were added to condition the data by
detecting cycle slips and by filtering the error-prone range obser-
vations. Furthermore, a series of experiments was carried out to
determine a weighting scheme that would work with almost every
data set.
RSGPS Software
RSGPS performs a network adjustment of GPS tracking data
contained in RINEX files 共Gertner 2001; Strang and Borre 1997,
p. 585兲. Special features are:
1. RSGPS uses P-code range observations as well as phase ob-
servations on both L1 and L2 frequencies.
2. After the network adjustment is available 共called the float
solution for all parameters兲, RSGPS uses the well-known
LAMBDA algorithm 共de Jong and Tiberius 1996; Chang et
al. 2005兲 to find the integer values of the ambiguities. The
W-ratio described in Wang et al. 共1998兲 is used to validate
the integer ambiguities selected by the LAMBDA process.
RSGPS has two processing modes: network and rover. The
network mode is intended for adjustment of the observations from
a set of reference stations. After the integer values of the ambi-
guities are computed by LAMBDA, the float solution and its
cofactor matrix are updated with the constraints that the ambigu-
ities must take on these integer values. RSGPS then uses the
geometry free equations 关Shaer 1999, p. 26; Strang and Borre,
1997, Eq. 共15.12兲; Leick 1995, Eq. 共9.55兲兴 to find the double
difference ionospheric delays.

CORS AND OPUS FOR ENGINEERS 67

 In the network mode, four types of information are saved for
possible later use in the rover mode. These are:
1. Reference station coordinates and their covariance matrix.
2. Tropospheric refraction parameters and their covariance ma-
trix at the reference stations.
3. Integer valued double difference ambiguities on baselines be-
tween reference stations.
4. Double difference ionospheric delays and their covariance
matrix at each epoch.
In the rover mode, RSGPS uses the parameters determined in
the previous network mode run and forms constraints to the so-
lution containing one or more new rover stations. The user may
specify that all, some, or none of the information saved from the
network mode adjustment are to be used. In the OPUS-RS appli-
cation, constraints are formed from the tropospheric refraction,
ambiguity, and double difference ionospheric delay information
共but not from the reference station coordinates兲.
RSGPS can spatially interpolate the tropospheric refraction
from the network solution to one or more new stations 共rovers兲.
When this program option is selected, a plane is fit to the values
at the reference stations, and values at the rover stations are com-
puted from this plane. This requires that at least three reference
stations be used in the network solution. Other models for pre-
dicting tropospheric refraction are possible, but were not used in
RSGPS.
RSGPS will also spatially interpolate the double difference
ionospheric delay from the reference stations to one or more rover
stations. As with the tropospheric delay, a plane is fit to the delays
from the network solution. The double difference delay at the
reference station is identically zero. In the OPUS-RS application,
the predicted tropospheric and ionospheric refraction delays are
always computed and used to form constraints.
The reference satellite at a particular epoch chosen by the
rover solution may differ from the one chosen by the network
solution. In this case, double difference ionospheric delays are
computed from Ikl km lm
ij = Iij − Iij , where m⫽reference satellite in the
network solution; and l⫽reference satellite in the rover solution.
If one or both of the double difference delays Ikm lm
ij and Iij are not
available from the network solution, no predicted delay at the
rover can be computed and no constraint is applied.
Methodology
RSGPS uses the double difference 共DD兲 observation equations
in the form described by Wielgosz et al. 共2004兲, Eq. 共1兲, based
on the undifferenced mathematical model given by Leick 关1995,
Eq. 共10.1兲兴. Four DD observations 关range on both carriers 共Pkl
1,ij
2,ij兲 and phase on both carriers 共␸1,ij and ␸2,ij兲兴 must be
and Pkl kl kl
available at each epoch. Their observation equations are written
␭1␸kl
1,ij − ␳ij − Tij + Iij
kl kl kl
− ␭1Nkl
1,ij =0
␭2␸kl
2,ij − ␳ij − Tij + Iij 共f 1/f 2兲 − ␭2N2,ij =0
kl kl kl 2 2 kl
共1兲
Pkl
1,ij − ␳kl kl kl
ij − Tij − Iij =0
Pkl
2,ij − ␳kl
ij − Tij − Iij 共f 1/f 2兲
kl kl 2 2
=0
where f 1 and f 2⫽L1 and L2 carrier frequencies; and ␭1 and
␭2⫽corresponding wavelengths.
The unknown parameters that appear in these observation
equations fall into four groups:
1. Corrections to a priori station coordinates 共earth centered,
earth fixed coordinate system兲 contained in the geometric
range ␳.
68 CORS AND OPUS FOR ENGINEERS
2. Corrections to station specific tropospheric refraction param-
eters Twi , contained in the double difference tropospheric re-
fraction Tklij through Eqs. 共2兲 and 共3兲 below.
3. Double difference ambiguities N 共in cycles兲 on L1 and L2 for
each double difference combination and each continuous
span of data.
4. Double difference ionospheric delays I for each double dif-
ference combination at each epoch. It is assumed that the
stations are spaced sufficiently far apart and the observations
are separated by enough time that the double difference iono-
spheric delays are uncorrelated. The OPUS-RS application
selects observations spaced 30 sec apart, irrespective of the
observation interval found in the input rinex files.
All unknown parameters are subject to a priori constraints ap-
plied as weighted constraint equations. The user may control the
numerical values of the weights.
The least-squares solution is carried out by the method of ma-
trix partitioning for sparse matrices as described by Schwarz
共1985兲. In the notation used there, the group of global unknowns
Ẋ comprises the station position, tropospheric refraction, and am-
biguity groups. The double difference ionospheric delay un-
knowns make up the local unknowns Ẍ. The observations are
processed epoch by epoch, with each epoch contributing the four
double difference observation equations for each baseline and sat-
ellite combination, according to Eq. 共1兲. Since the observation
equations for a single epoch involve only the double difference
ionospheric delay for that epoch, the submatrix N̈ is block diag-
onal, and the computing method detailed in Schwarz 共1985兲 can
be applied. In particular, at each epoch:
1. The observation equations for just that epoch are formed.
2. The corresponding partial normal equations are formed.
3. The partial normal equations are reduced by the elimination
of the double difference ionospheric delay unknowns.
4. The partial reduced normal equations are added to those al-
ready accumulated, so that at the end, the total set of reduced
normal equations is available.
After the observations from each epoch have been processed,
RSGPS may compute a solution using all the observations pro-
cessed so far. The float solution obtained by solving the normal
equations accumulated so far is passed to the LAMBDA algo-
rithm. This sequential process allows the analyst to watch the
evolution of the solutions 共both float and fixed integer ambigu-
ities兲 and the evolution of the LAMBDA validation statistics. If
all goes well, the solutions will converge to stable values and the
validation statistics will indicate that the LAMBDA selection of
the best set of integer ambiguities is valid.
The method of matrix partitioning used by RSGPS is algebra-
ically equivalent to the method of generalized least squares de-
scribed in the publications of the OSU SPIN group. However, it
takes advantage of knowledge of the structure of the observation
and normal equations, and is, thus, more appropriate for applica-
tion in a production environment.
Reference Station
All double differences are formed with respect to a single refer-
ence, or hub, station, which may be specified by the program user.
In the network mode, the default is that the first named reference
station is the hub. In the rover mode, the default is that the first
named rover station is the hub. The selection of the hub stations
affects which double differences can be formed; choosing a hub
in the middle of the network usually produces the largest number
of double difference observations.
Reference Satellites
At each epoch, the satellite that has the highest elevation angle as
seen at the hub station is selected as the reference satellite. This
means that the reference satellite may change several times over
the course of a tracking session. The DD ionospheric unknowns at
each epoch refer to the reference satellite at that epoch. DD am-
biguity unknowns all refer to the reference satellite at the first
epoch. If the reference satellite changes and the old reference
satellite is still visible at the first epoch after the change, RSGPS
will enforce continuity across the change. If the old reference
satellite is not visible, RSGPS will insert a cycle slip for all
ambiguities.
Tropospheric Refraction
Tropospheric refraction is modeled according to the international
earth rotation service recommendation 共McCarthy and Petit 2004,
Sec. 9.2兲. The double difference delay is
Tkl k l k l
ij = Ti − Ti − T j + T j 共2兲
and the one-way delay is
Tki = mh共eki 兲Thi + mw共eki 兲Twi 共3兲
Here Thi ⫽hydrostatic delay at the zenith; and Twi ⫽zenith wet
delay at station i; while mh and mw⫽hydrostatic and wet mapping
functions, respectively 共functions of the elevation angle eki from
station i to satellite k兲. The zenith hydrostatic delay accounts for
about 90% of the total tropospheric delay, but it can be accurately
computed from surface pressure and temperature 共Leick 1995, p.
308; McCarthy and Petit 2004, p. 100兲. A priori values of both the
hydrostatic and wet components can be computed from seasonal
values of pressure and temperature. It is difficult to separate the
corrections to both the hydrostatic and wet components, since the
mapping functions are very similar at moderate elevation angles.
In RSGPS, the hydrostatic zenith delay is fixed at its a priori
value Th0
i , and the wet zenith delay is modeled as an a priori value
plus an unknown correction Twi = Tw0 i + ␦Ti . Any errors in the com-
w
puted hydrostatic zenith delay will be largely absorbed by the wet
zenith delay ␦Twi .
Rover Constraints
In the rover mode, seven types of constraints are applied:
1. Constraints on the input coordinates of the rover station共s兲.
These must be specified by the user, since they depend on the
accuracy of the input coordinates.
The remaining constraints are those derived from the re-
sults of the network solution:
2. Constraints on tropospheric refraction values at reference
stations.
3. Constraints on tropospheric refraction values predicted for
rover stations.
4. Constraints on DD ionospheric delays involving only refer-
ence stations.
CORS AND OPUS FOR ENGINEERS
5. Constraints on DD ionospheric delays predicted for baselines
involving the rover station.
6. Constraints on DD ambiguities involving only reference sta-
tions. In the rover mode solution, these are constrained to the
integer values determined in the network solution.
7. Constraints on DD ambiguities for baselines involving the
rover station.
It may appear at first that these constraints are redundant, since
they are being applied in an adjustment in which the reference
station data are also being reprocessed. However, these con-
straints are largely statistically independent of the reference sta-
tion data, because:
1. The constraints are obtained from the network solution with
integer fixed ambiguities, not the float solution.
2. The data being reprocessed do not necessarily match the time
span of the data used in the network solution. The network
solution typically uses 1 – 2 h of data from the reference sta-
tions. The rover solution uses only the reference station data
that matches the time span of the rover data set, typically
15 min.
3. The constraints on predicted values involve a geographic in-
terpolation based on the best fitting plane, and the prediction
error generally dominates the other error sources.
In the rover adjustment, the tropospheric refraction parameter
at each reference station is constrained to its value from the net-
work adjustment 共after fixing ambiguities at integer values兲.
These values are also used to predict the value at the rover station.
The prediction is performed by reducing the values obtained at
the CORS sites in the network solution to sea level, fitting a plane
to those values, using the plane to interpolate to the rover hori-
zontal position, and raising the interpolated value to the input
elevation of the rover.
Similarly, the double difference ionospheric delays determined
in the network mode adjustment 共after fixing the ambiguities to
integer values兲 are used to constrain the double difference iono-
spheric delays in the rover mode adjustment. For the delays at the
rover station 共which did not take part in the network mode adjust-
ment兲, the delay is predicted by fitting a plane to the values from
the network solution.
Last, the integer ambiguities determined in the network adjust-
ment are used to form constraints for the rover adjustment. The
rover solution may have a different hub station 共say B兲 and ref-
erence satellite 共say r兲 than those used in the network solution.
Therefore, RSGPS computes
Nkr km rm km rm
1,AB = N1,AZ − N1,AZ − N1,BZ + N1,BZ 共4兲
Nkr km rm km rm
2,AB = N2,AZ − N2,AZ − N2,BZ + N2,BZ 共5兲
where m⫽reference satellite; and Z⫽hub station used in the net-
work solution. Here, the ambiguities Nkr kr
1,AB and N2,AB are known
exactly, since they are integer values.
The rover adjustment typically has one more station 共the
rover兲 than the network adjustment. Therefore, there will be some
ambiguities in the rover adjustment for which constraints are not
applied; all others are constrained.
Weights
The weighting schemes and values described below are used by
OPUS-RS when processing GPS dual-frequency phase and range
observations.
69
 A. Phase observations: in RSGPS, each one-way phase obser-
vation is considered to be statistically independent of every other
observation. Observations on L1 are considered to be independent
of those on L2. RSGPS assigns greater variance 共less weight兲 to
observations with lower elevation angles, allowing for the greater
effect of unmodeled refraction and multipath on these observa-
tions. Thus, the variances of the one-way phase observations on
L1 and L2 are given by
var共␸k1,i兲 = 共␴L1/sin共eki 兲兲2 共6兲
var共␸k2,i兲 = 共␴L2/sin共eki 兲兲2 共7兲
Here ␴L1 and ␴L2⫽configurable parameters whose default value
is 0.01 cycle; and eij⫽elevation angle of satellite k as seen from
station i. The weight of each observation is the inverse of its
variance.
B. Range observations: the same scheme is used for the range
observations
var共Pk1,i兲 = 共␴P1/sin共eki 兲兲2 共8兲
var共Pk2,i兲 = 共␴P2/sin共eki 兲兲2 共9兲
where ␴P1 and ␴P2⫽also configurable parameters with default
values ␴P1 = 0.2 m and ␴P2 = 0.256 m. However, the weights of the
range observations may be modified by the adaptive weighting
scheme described below.
C. Double difference observations: the covariance matrix of
the double difference observations is computed by linear error
propagation 关see Leick 共1995兲, Sec. 10.2.1兴. This covariance ma-
trix is full, reflecting the correlation of the double differences.
However, there is no covariance between a double difference
phase observation on L1 and one on L2 共or P1 or P2兲. Thus, there
are four covariance matrices at each epoch, and the dimension of
each is the number of double differences at that epoch. These are
inverted to produce four independent weight matrices.
D. Weighting of a priori values: a priori constraints are applied
to all unknown parameters in both network and rover modes. The
standard deviations of these constraints are all configurable. The
following values are used by OPUS-RS:
1. The default standard deviation of a reference station a priori
XYZ coordinate is 0.02 m in each coordinate, which is the
estimated error in the coordinates of the national CORS net-
work.
2. The a priori value of the zenith wet delay at each station is
typically in the range 0.15 to 0.35 m. The default standard
deviation is 0.025 m.
3. The a priori value of each double difference ionospheric
delay is 0.0. A default standard deviation of 0.4 m is used.
This value seems to be satisfactory even during periods of
high ionospheric activity 共because the large delays cancel out
in the double differences兲. A larger value may be selected if
the stations are spaced far apart.
4. The a priori value of an ambiguity is computed by comparing
the first phase measurement to the distance computed from a
priori values of the other parameters. Its accuracy depends on
the accuracy of the other parameters through the equations
␴N1共ref兲 = 0.5 * sqrt关␴2x 共ref兲 + ␴2I + ␴T2 + 共2.0 * ␭1兲2兴/␭1
␴N2共ref兲 = 0.5 * sqrt关␴2x 共ref兲 + ␴I2 + ␴T2 + 共2.0 * ␭2兲2兴/␭2 + 1.0
70 CORS AND OPUS FOR ENGINEERS
␴N1共rov兲 = 0.5 * sqrt关␴2x 共rov兲 + ␴2I + ␴T2 + 共2.0 * ␭1兲2兴/␭1
␴N2共rov兲 = 0.5 * sqrt关␴2x 共rov兲 + ␴2I + ␴T2 + 共2.0 * ␭2兲2兴/␭2
共10兲
E. Weights for rover mode constraints:
1. The coordinates of the rover station共s兲 are constrained ac-
cording to the standard deviations specified by the user.
2. The vector of a priori values of the tropospheric refraction
parameters at the reference stations and its covariance matrix
is extracted from the vector of values saved from the network
solution. The covariance matrix is inverted to form the
weight matrix for these constraints. The a priori constraints
described in the previous section are not used.
3. For predicted values of the tropospheric refraction parameter
共those involving the rover station兲, the default standard de-
viation is 0.01 m.
4. The vector of ionospheric refraction delays, and its covari-
ance matrix, is taken from the network solution. The covari-
ance matrix is inverted to form the weight matrix for these
constraints. If an a priori ionospheric delay cannot be found
in the data saved from network solution, the ionospheric
delay constraints described in the previous section are used.
5. For predicted values of the ionospheric refraction delays
共those involving the rover station兲, the assigned standard de-
viation is the greater of 共a兲 50% of the double difference
ionospheric delay on the nearest baseline, or 共b兲 0.05 m. This
heuristic scheme is based on the reasoning that the standard
deviation of the prediction should be greater when the iono-
sphere is more variable.
6. The vector of ambiguities is taken from the network solution
and used to apply constraints on the ambiguities among the
reference stations appearing in the rover adjustment. Being
integers, these ambiguities are treated as errorless.
7. Ambiguities on baselines involving the rover station are sub-
ject to the reasonableness ambiguity constraint described in
the previous section.
Conditioning the Input Data
A. Adaptive weighting for ranges: range observations 共P1 and P2兲
may contain both large isolated errors 共in the tens of meters兲 and
significant multipath effects. The factor 1 / sin共eki 兲 used in the ini-
tial weighting is intended to give less weight to observations at
low elevation angles, since these are the ones most likely to con-
tain multipath errors. However, even this measure may not be
enough to protect against blunders and large multipath effects.
The ranges are examined before the main adjustment begins.
At each epoch, and for each station, the ranges are corrected for
effects such as nominal tropospheric refraction, station antenna
offsets, antenna calibration, offset of the satellite antenna from the
center of mass, and satellite clock error. The ionosphere free 共IF兲
range combination 关Leick 共1995兲, Eq. 共9.46兲兴 is written for each
station and satellite
f 21 f 22
k
PIF,i = Pk1,i − Pk2,i = ␳ki − cdti − cdtk + Tki 共11兲
f 21 − f 22 f 21 − f 22
where f 1 and f 2⫽carrier frequencies on L1 and L2; Pk1,j and
Pk2,j⫽pseudorange measurements on L1 and L2; ␳ki ⫽distance
from station i to satellite k; dti⫽clock correction at station i;
dtk⫽satellite clock correction for satellite k; Tki ⫽tropospheric re-
fraction delay; and c, as usual, = speed of light.
The largest part of the tropospheric refraction in this combina-
tion can be computed from a priori values in such a way that the
remaining refraction is 10 cm or less. Furthermore, we assume
that the errors in the station coordinates are small 共less than 1 m兲.
This is certainly justified for reference stations taken from the
CORS, and is also justified for the rover station if we start the
adjustment with a good approximate position. Thus, the only un-
known left is the station clock correction dti. The observations at
this station 共and this epoch兲 are used to solve for the station clock
correction. The residuals to the ion-free range observations are
computed, and from these, the residuals to the P1 and P2 ob-
servations are found. If the absolute value of a residual is larger
than the variance already assigned to the observation, the residual
is substituted for the variance. This means that the weight of
this observation in the main adjustment is the inverse of its re-
sidual. This has the effect of deweighting observations with large
residuals, whether caused by isolated blunders or large multipath
effects.
B. Cycle slip detection: RSGPS examines both the one-way
phase observations and the double difference phase observations
for cycle slips.
The one-way cycle slip detector computes the time rate of
change of the ion-free linear combination of the phases. If the rate
of change between two epochs changes by more than one cycle at
the L1 frequency, a cycle slip is detected.
The double difference cycle slip detector uses the double dif- Fig. 1. Configuration of reference stations for the COLB test 共day
ference phase observations. At each epoch, both the ion-free and 8-31-2007兲
the geometry-free 共GF兲 combinations are computed for each sat-
ellite 共other than the reference satellite兲 and baseline. These are
monitored from one epoch to the next. A cycle slip at epoch tk−1 is Since it is often difficult to solve for the ambiguity unknowns
detected if on short data spans, RSGPS deletes all data and unknowns for
these particular data spans. A short data span is defined as one less
兩d␸ij,IF
kl
共tk兲 − d␸ij,IF
kl
共tk−1兲兩 ⬎ ␴DDIF 共12兲 than one-third of the total number of epochs.
D. Trimming the data set and forming double differences: at
or each epoch, the available observations are examined. An observa-
tion from a station to a satellite at an epoch is used only if all four
兩d␸ij,GF
kl
共tk兲 − d␸ij,GF
kl
共tk−1兲兩 ⬎ ␴DDGF 共13兲 observation types L1, L2, P1, and P2 are present 共except that C1
may be used if P1 is not present兲.
where ␴DDIF and ␴DDGF⫽configurable parameters 共default values
The set of satellites seen by each station is formed, and the
are 0.05 and 0.5 cycle, respectively兲. Here
intersection of these sets is computed. Only satellites in this in-
tersection are used. Thus, a satellite is used at a particular epoch
kl
d␸ij,IF k
= d␸i,IF l
− d␸i,IF − d␸kj,IF + d␸lj,IF 共14兲 only if it is seen by all the stations at that epoch. The resulting
set of observations contains 4共nsta − 1兲共nsat − 1兲 observations,
where nsat⫽number of satellites seen by all the stations, and
cf 1 cf 2
k
d␸i,IF = d␸k1,i − 2 2 d␸k2,i 共15兲 nsta⫽number of stations 共and nsta − 1⫽number of independent
f 21 − f 22 f1 − f2 baselines兲.
and

d␸k1,i = ␸k1,i − dk0 共16兲 Performance

i

where dk0i ⫽distance from station i to satellite k computed from a
priori values. A cycle slip is also detected if a cycle slip in any of
the four one-way phases that go into these double differences was
present. When a cycle slip occurs, a new ambiguity is introduced,
increasing the number of unknown parameters.
C. Short data spans: short data spans can occur if a satellite
sets soon after the beginning of the time span to be processed by
the program; if a satellite rises near the end of the time span; if a
cycle slip occurs near the beginning or end; or if two cycle slips
occur close together in time. Each new data span creates two new
unknowns 共ambiguities on L1 and L2兲.
The ability of the software, with the weights and heuristics de-
scribed above, was tested at two rover sites, COLB 共Columbus,
Ohio兲 and GNVL 共Gainesville, Fla.兲. Both of these are National
CORS sites, so their coordinates are well known 共within 2 cm
horizontal and 4 cm vertical兲. A set of reference stations was se-
lected for each rover site 共Figs. 1 and 2兲.
For each rover site, a full day’s data was retrieved from the
CORS archive and broken into 96 data sets of 15 min each. These
represented the rover data sets. For each data set, 1 h of data,
centered at the midpoint of the rover data set, was retrieved from
the publicly available CORS archive for each reference station.

CORS AND OPUS FOR ENGINEERS 71

 the COLB rover, there are no errors greater than a few centime-
ters, and the rms errors are quite small.
The situation is not quite as good for the GNVL rover. Here,
five of the 96 solutions appear to be outliers 共defined as solutions
for which a horizontal coordinate is in error by more than 5 cm or
the height is in error by more than 10 cm兲.
The reasons for these occasional outliers are not completely
understood. Some possibilities being investigated include:
1. Multipath effects beyond those accounted for by the adaptive
weighting scheme.
2. Unmodeled tropospheric refraction.
Many of the outlier solutions were investigated. In almost all
cases, it was possible to obtain an accurate solution by deleting
one or two satellites or by changing the weights on the a priori
parameter values or on the constraints. Unfortunately, the soft-
ware has no way of detecting when a solution is in error. While
errors can be detected for those tracking stations for which
we have external means of determining the coordinates, we have
not found a means to detect outliers reliably for unknown rover
stations.
Fig. 2. Configuration of reference stations for the GNVL test 共day The accuracy of a solution depends largely on whether the
8-13-2005兲 correct integer ambiguities have been determined. Although the
integer ambiguities are treated as errorless, this is not really the
case. In principle, the vector of integer ambiguities determined
The reference station data were adjusted in the network mode as by the LAMBDA method has the greatest probability of being
described above. The rover data were then adjusted, together with correct, but this probability is not 100%; other vectors of inte-
the reference station observation data sets, in the rover mode. ger ambiguities also have some probability of being correct
Initially, the known coordinates 共adopted CORS coordinates兲 of 共Verhagen 2005兲.
the rover station were purposefully assigned a 2.0 m bias in each The W-ratio of integer ambiguity validation was designed as a
coordinate. If the correction to any coordinate was greater than measure of the probability that the ambiguities determined by
3 cm, the solution was repeated, using the corrected coordinates LAMBDA are correct. It was at first thought that the W-ratio is
from the previous solution as the new a priori coordinates. Two distributed as Student’s t. This has since been shown to be incor-
rover mode solutions were sufficient to reach convergence in al- rect, and the determination of the probability of the integer ambi-
most all cases. The resulting coordinates were compared to the guities being correct remains an open problem 共Verhagen 2004兲.
unbiased known coordinates, with the results shown in the second In these tests, the outlying solutions were often associated with
and third columns of Table 1. low values 共less than 3.0兲 of the W-ratio. However, the associa-
These tests show that RSGPS is capable of solving for the tion is not perfect; there were both good solutions with low
coordinates of the unknown station with centimeter accuracy. For W-ratios and outlying solutions with acceptable W-ratios. All that
can be said at the moment is that solutions with low values of the
W-ratio should be treated with caution, and the search for reliable
Table 1. Summary of Two RSGPS Tests; All Time Units Are Given in
measures of integer ambiguity validation should be continued.
Minutes; All Tabulated Statistics Are Given in m There are a number of ways to reduce the likelihood of outli-
ers. One is to use more reference stations 共although in these ex-
Unknown 共rover兲 station COLB GNVL periments, the series of solutions at GNVL, using four reference
CORS reference PKTN, SIDN, XCTY, ZJX1, stations, contained five outliers, while the series at COLB, using
stations WOOS DUNN, PLTK only three reference stations, contained none兲.
Date 8/31/2007 8/13/2005 Another approach is to use a longer data span. The fourth
Average distance from rover column of Table 1 shows the results when 30 min rover data sets
to reference stations 112 km 81 km are used. Here, the number of outliers is reduced from five to one.
Time span of rover data 15 15 30 The other statistics are also improved.
Time span of network data 60 60 80
Number of solutions 96 96 48
Maximum latitude error 0.012 0.077 0.035 Conclusions
Maximum longitude error 0.011 0.096 0.072
Maximum height error 0.068 0.169 0.152 The rapid static GPS method can be used to find the position of
Average latitude error −0.005 −0.007 −0.006 unknown rover stations with an accuracy of a few centimeters
Average longitude error −0.005 0.006 0.003 using as little as 15 min of tracking data and reference stations
Average height error −0.023 0.003 0.008 separated by 200 km. However, the rover data set must be care-
RMS latitude error 0.004 0.014 0.009
fully conditioned to ensure that it is free of cycle slips, short data
spans, and excessive multipath effects. Furthermore, it is neces-
RMS longitude error 0.002 0.017 0.014
sary to constrain the a priori values of all parameters. With careful
RMS height error 0.021 0.051 0.048
selection of the weights associated with these constraints, accu-
Number of outliers 0 5 1
rate solutions can be achieved for almost all input data sets.

72 CORS AND OPUS FOR ENGINEERS

Acknowledgments
The work described in this article was performed under contract
to the National Geodetic Survey.
References
Chang, X-W., Yang, X., and Zhou, T. 共2005兲. “MLAMBDA: A modified
LAMBDA method for integer least-squares estimation.” J. Geodesy,
Berlin, 79共9兲, 552–565.
de Jong, P., and Tiberius, C. 共1996兲. “The LAMBDA method for integer
ambiguity estimation: Implementation aspects.” Publications of the
Delft Geodetic Computing Center No. 12, Delft Univ. Technology,
The Netherlands.
Gertner, W. 共2001兲. “RINEX: The receiver independent exchange format
version 2.10.” Available at 具http://www.ngs.noaa.gov/CORS/Rinex2.
html典.
Grejner-Brzezinska, D. A., et al. 共2007兲. “Efficiency and reliability of
ambiguity resolution in network-based real-time kinematic GPS.”
J. Surv. Eng., 133共2兲, 56–65.
Grejner-Brzezinska, D. A., Wielgosz, P., Kashani, I., Mader, G., Smith,
D., and Robertson, D. 共2005兲. “Performance assessment of the new
rapid static module of the online positioning user service—OPUS-
RS.” Proc., ION GNSS 18th Int. Technical Meeting Satellite Division,
Institute of Navigation, Farfax, Va., 2595–2605.
Kashani, I., Weilgosz, P., Grejner-Brzezinska, D. A., and Mader, G. L.
共2005兲. “A new network-based rapid-static module for the NGS online
positioning user service—OPUS-RS.” Proc., ION Annual Meeting,
CORS AND OPUS FOR ENGINEERS
Institute of Navigation, Fairfax, Va., 928–936.
Leick, A. 共1995兲. GPS satellite surveying, 2nd Ed., Wiley, New York.
McCarthy, D. D., and Petit, G., eds. 共2004兲. “IERS conventions 共2003兲.”
International Earth Rotation Service Technical Note No. 32, Frankfurt
am Main: Verlag des Bundesamts für Kartographie und Geodäsie.
National Geodetic Survey. 共1999兲. “PAGES: Program for the adjustment
of GPS ephemerides.” 具http://www.ngs.noaa.gov/GRD/GPS/DOC/
pages/pages.html典.
Schwarz, C. R. 共1985兲. “Helmert blocking.” in “North American datum of
1983.” NOAA Professional Paper NOS 2, National Oceanic and At-
mospheric Administration, Washington, D.C., 93–102.
Shaer, S. 共1999兲. “Mapping and predicting the earth’s ionosphere using
the global positioning system.” Ph.D. thesis, Univ. of Bern, Bern,
Switzerland.
Snay, R. A., and Soler, T. 共2008兲. “Continuously operating reference
station 共CORS兲: History, applications, and future enhancements.”
J. Surv. Eng., accepted.
Soler, T., Michalak, P., Weston, N., Snay, R. A., and Foote, R. H. 共2006兲.
“Accuracy of OPUS solutions for 1-4 h observing sessions.” GPS
Solutions, 10共1兲, 45–55.
Strang, G., and Borre, K. 共1997兲. Linear algebra, geodesy, and GPS,
Wellesley-Cambridge Univ. Press, Cambridge, U.K.
Verhagen, S. 共2004兲. “Integer ambiguity validation: An open problem?”
GPS Solutions, 8共1兲, 36–43.
Verhagen, S. 共2005兲. “On the reliability of integer ambiguity resolution.”
Navigation, 52共2兲, 99–110.
Wang, J., Stewart, M. P., and Tsakiri, M. 共1998兲. “A discrimination test
procedure for ambiguity resolution on-the-fly.” J. Geodesy, Berlin,
72共11兲, 644–653.
Wielgosz, P., Grejner-Brzezinska, D., and Kashani, I. 共2004兲. “Network
approach to precise GPS navigation.” Navigation, 51共3兲, 213–220.
73
GPS Solut (2009) 13:119–132
DOI 10.1007/s10291-008-0105-0
Accuracy assessment of the National Geodetic Survey’s OPUS-RS
utility
Charles R. Schwarz Æ Richard A. Snay Æ
Tomás Soler
Received: 7 July 2008 / Accepted: 26 September 2008 / Published online: 23 October 2008
 US Government 2008
Abstract OPUS-RS is a rapid static form of the National
Geodetic Survey’s On-line Positioning User Service (OPUS).
Like OPUS, OPUS-RS accepts a user’s GPS tracking data
and uses corresponding data from the U.S. Continuously
Operating Reference Station (CORS) network to compute
the 3-D positional coordinates of the user’s data-collection
point called the rover. OPUS-RS uses a new processing
engine, called RSGPS, which can generate coordinates with
an accuracy of a few centimeters for data sets spanning as
little as 15 min of time. OPUS-RS achieves such results by
interpolating (or extrapolating) the atmospheric delays,
measured at several CORS located within 250 km of the
rover, to predict the atmospheric delays experienced at the
rover. Consequently, standard errors of computed coordi-
nates depend highly on the local geometry of the CORS
network and on the distances between the rover and the local
CORS. We introduce a unitless parameter called the inter-
polative dilution of precision (IDOP) to quantify the local
geometry of the CORS network relative to the rover, and we
quantify the standard errors of the coordinates, obtained via
OPUS-RS, by using functions of the form
qffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffi
rðIDOP; RMSDÞ ¼ ða  IDOPÞ2 þ ðb  RMSDÞ2
here a and b are empirically determined constants, and
RMSD is the root-mean-square distance between the rover
and the individual CORS involved in the OPUS-RS
C. R. Schwarz (&)
Department of Geodesy, 5320 Wehawken Road,
Bethesda, MD 20816, USA
e-mail: charlies2@earthlink.net
R. A. Snay  T. Soler
National Geodetic Survey/NOAA, 1315 East West Highway,
Silver Spring, MD 20910, USA
74
11
computations. We found that a = 6.7 ± 0.7 cm and b =
0.15 ± 0.03 ppm in the vertical dimension and a = 1.8 ±
0.2 cm and b = 0.05 ± 0.01 ppm in either the east–west
or north–south dimension.
Keywords GPS  Geodesy  Rapid static techniques
Introduction
NOAA’s National Geodetic Survey (NGS) operates the
On-line Positioning User Service (OPUS) to provide GPS
users easy access to the National Spatial Reference System
(NSRS). This service (available at http://www.ngs.noaa.
gov/OPUS/) combines GPS tracking data from the user’s
site (called the rover) with tracking data from the U.S.
Continuously Operating Reference Station (CORS)
network (Snay and Soler 2008) to compute positional
coordinates for the rover’s location which are accurate to
within a few centimeters.
OPUS provides the user the means to obtain accurate
coordinates while operating a single GPS receiver. A
popular utility, OPUS is now processing over 20,000 user-
submitted data sets per month. OPUS is designed to handle
long baselines but requires relatively long (at least 2 h)
tracking sessions to produce coordinates to within an
accuracy of a few centimeters (Soler et al. 2006).
NGS has convened a series of forums to gather user
comments on the CORS and OPUS services. At these
forums, a recurring comment was that users wanted to
obtain similarly accurate coordinates, but with shorter
observing sessions. OPUS-RS (rapid static) is designed to
meet that requirement, producing coordinates with an
accuracy of a few centimeters from user data sets spanning
as short as 15 min.
CORS AND OPUS FOR ENGINEERS
 To accomplish this, an entirely new internal processing selected reference stations. The convex hull is the smallest
engine was constructed, replacing the PAGES program convex polygonal area encompassing the reference
used in the original OPUS. OPUS-RS also uses a more stations.
restrictive algorithm for selecting reference stations, and it The reference station selection algorithm now in use
places more restrictions on the data sets it will process. also restricts the search for reference stations to a radius of
However, the external interface for OPUS-RS is the 250 km from the rover. If the search algorithm does not
same as that for the original OPUS, and most of the find at least three acceptable reference stations, OPUS-RS
information and explanations offered for the original OPUS will not attempt a solution. The 250-km limit can be
apply to OPUS-RS. Many of the options, such as allowing overridden if the user manually selects reference station(s).
the user to select reference stations and/or the state plane Figure 1 summarizes some of the restrictions contained in
coordinate zone, are also the same. The reports returned to the station-selection algorithm currently used by OPUS-
the user are very similar as well. RS.
The construction of OPUS-RS presented two challenges:
1. Show that it is generally possible to obtain accurate
How OPUS-RS works
coordinates from GPS tracking sessions as short as
15 min, while using reference stations from the U.S.
OPUS-RS solves for the coordinates of the user’s receiver
CORS network. This network of reference stations
in two steps. In the first step, parameters associated with
provides baseline lengths of 100–200 km in many
the reference stations are determined. In the second step,
areas, but in areas where the CORS network is sparse,
the parameters determined in the first step are combined
the baseline lengths can be much longer.
with the tracking data from the rover to determine the rover
2. Design processing options and a station-selection
coordinates. RSGPS has two operating modes, network and
algorithm that will produce accurate coordinates for
rover, which are used to accomplish these two steps. In
almost all user data sets, even though these data sets
network mode, at least 1 h of data from the selected CORS
vary widely in terms of receiver type, antenna type,
are used to solve for integer ambiguities, tropospheric
antenna placement, station environment, tracking
refraction parameters, and the double difference iono-
quality, observing session length, and geographic
spheric delays at the chosen CORS, with the positional
location. Furthermore, construct algorithms that rec-
coordinates of the CORS held fixed. In rover mode, the
ognize and notify the user regarding situations that are
ionospheric delays and the tropospheric parameters (from
unlikely to compute a highly accurate solution.
an existing network-mode solution) are interpolated (or
Research conducted by the Satellite Positioning and extrapolated) from the selected CORS to the rover. Then
Inertial Navigation (SPIN) group at The Ohio State the delays at the rover are constrained to solve for the
University (Wielgosz et al. 2004; Kashani et al. 2005; positional coordinates of the rover. Again, the positional
Grejner-Brzezinska et al. 2005, 2007) indicated that the coordinates of the CORS are held fixed.
first challenge could be met, at least for areas with well In greater detail, OPUS-RS has six major processing
behaved reference station data. NGS developed and phases:
implemented the Rapid Static GPS (RSGPS) software
(Schwarz 2008) based on the ideas developed by the SPIN
group and expressed in the MPGPS software.
The second challenge required considerable experi-
mentation. The first approach was to select the three closest
CORS, as is done for regular OPUS. The spatial interpo-
lation used for predicting the tropospheric and ionospheric
refraction at the rover suggested that the reference stations
should be well distributed around the rover, so the algo-
rithm was modified to select the three closest stations
forming a triangle including the rover. This approach also
proved untenable; there are many areas, especially along
the coasts, where three CORS surrounding the rover cannot
be found.
Later, the reference-station-selection algorithm was
modified to select up to nine CORS, and the rover was Fig. 1 Major restrictions implicit in OPUS-RS station selection
allowed to be up to 50 km outside the ‘‘convex hull’’ of the algorithm

CORS AND OPUS FOR ENGINEERS 75

1. Initial quality control The user’s data set is examined.
The TEQC software (Estey and Meertens 1999) is used
to determine if the data file is properly formatted. The
beginning and ending times of the file are determined.
The observation time span for the RSGPS network
solution is computed as follows:
• If the time span for the rover’s data is less than 1 h,
the time span for the network solution is 1 h
4.
centered at the midpoint of the time span for the
rover.
• If the time span for the rover’s data is one hour or
more, the time span for the network solution begins
15 min before the time span of the rover’s data and
ends 15 min after.
2. Orbits Orbit files for the period spanned by the GPS
5.
data are retrieved from the NGS archive. If suitable
orbit files cannot be found in the NGS archive, the
archives at NASA’s Jet Propulsion Laboratory are
searched. If a final precise orbit cannot be found, a
rapid orbit is used, and if that cannot be found, an
ultra-rapid orbit is used. If necessary, orbit files for two
consecutive days are concatenated together.
3. Retrieve reference station RINEX files The TEQC
software, together with a broadcast orbit, is used to
determine the first approximation to the positional
coordinates of the rover. The accuracies of these
coordinates are approximately 2–10 m.
These positional coordinates are used to compute the
distance from the rover to each station in the CORS
network and the stations are then sorted by distance, thus
creating an ordered list of candidate reference stations.
User-selected stations are put at the top of this list.
Stations that the user specifies for exclusion are skipped.
For each station in the list of candidate reference
stations, an attempt is made to retrieve a RINEX file
covering the network-solution’s time span from the
NGS CORS archive. If the RINEX file is not found
there, the archives at Scripps Institute of Oceanography
(SOPAC) and CDDIS (NASA Goddard) are searched.
If necessary, hourly files are spliced together and/or
RINEX files from two consecutive days are retrieved
and spliced together. If the retrieval of a RINEX file is
successful, its contents are tested. The file is read to
determine how many of the potentially usable obser-
vations are actually present. The potentially usable
observations are those which are contained within the
network-solution’s time span, are observed at 30-s
epochs, and involve satellites at least 10 above the
local horizon. To be counted as actually present, the
observational record must contain all four required data
types (L1, L2, P1[or C1], and P2). If at least 90% of the
potentially usable observations are actually present, the
76 CORS AND OPUS FOR ENGINEERS
candidate station is added to the list of reference
stations to be used. The search is terminated when any
of the following are true:
• Nine reference stations have been found,
• The distance to the next candidate is greater than
250 km, or
• 50 candidates have been examined.
Improve the position A differential pseudo-range solu-
tion is performed using the RINEX file from the closest
reference station, the known coordinates of the refer-
ence station, and the rover’s RINEX file. The positional
coordinates of the rover obtained from this computation
are typically accurate to 0.5–2.0 m and this is the
beginning set of coordinates for the RSGPS program.
Run RSGPS
• The input file and configuration file for executing
the RSGPS software are set up.
• RSGPS is run in the network mode, using the
RINEX files from only the reference stations. The
first selected reference station is chosen as the base
station to be used in forming double difference
GPS observations (hub station).
• If the normalized RMS residual from this run is
larger than 1.0, the standard errors assigned to the
pseudorange observations are increased by a factor
of 2.5 and the entire network solution is restarted.
This process may be repeated as many as three times.
• The ‘‘quality indicator’’ produced by RSGPS is
examined. Based on the W ratio, the quality
indicator is a measure of the certainty that correct
values for all integer ambiguities have been found
(Wang et al. 1998). If this quality indicator is less
than 3.0, the entire network solution is restarted with
a different hub station. The process may be contin-
ued until all candidate hub stations have been tried.
• The values of the tropospheric zenith wet delay at
the reference stations are examined. If a value
appears to be unreasonable (e.g., the computed
tropospheric zenith wet delay is negative), the
corresponding reference station is deleted. If there
are still at least three reference stations left, the
network solution is restarted without that station.
• A series of single baseline rover mode solutions is
performed, each solution involving one reference
station and the rover (user’s receiver). Each of these
solutions is iterated until corrections to all coordi-
nates are less than 0.03 m. This produces a series of
estimates of the coordinates for the rover. The mean
of these estimates is computed for each coordinate,
and the individual differences from the mean are
computed. If any horizontal difference is greater
 than 0.05 m, or any vertical difference greater than
0.1 m, the station with the largest difference (in
terms of its absolute value) is deleted. If there are
still at least three reference stations left, the network
mode solution is restarted. This test will be applied
no more than two times. After two reference
stations have been deleted by this test, the solution
proceeds with the remaining stations, irrespective
of the scatter of the differences.
• A final rover-mode solution is performed, this time
using the data from all selected reference stations
together with the rover’s RINEX file and the
constraints saved from the network-mode solution.
This solution is also iterated until the correction to
each coordinate is less than 0.03 m, and this is the
final estimate of the rover’s coordinates.
• The single baseline solutions are reexamined for
the purpose of determining how well the individual
single baseline solutions agree with the final rover-
mode solution. This time, the residuals from the
final rover coordinates, rather than residuals from
the mean, are computed. The RMS of these
residuals in each coordinate is computed. The
values are used as estimates of the standard errors
of the final coordinates.
6. Create OPUS-RS solution report
• The ITRF2000 coordinates for the rover are taken
from the last iteration of the rover-mode solution
using all the selected reference stations.
• If the user’s receiver is within an area in which
NAD 83 is defined, NAD 83 coordinates are
computed with the HTDP software (http://www.
ngs.noaa.gov/TOOLS/Htdp/Htdp.shtml).
• UTM coordinates are determined.
• If NAD 83 is defined, the state plane coordinate
zone is determined and plane coordinates are
computed with the SPCS83 software (http://www.
ngs.noaa.gov/TOOLS/spc.shtml).
• The NGS data base is searched to find the NGS
published control point located nearest to the rover.
• If requested, the items required for the extended
output are computed.
• The OPUS-RS solution report is composed and
e-mailed to the submitter.
OPUS-RS statistics
There are two common ways to estimate the standard errors
of the coordinates determined by an adjustment such as that
performed by OPUS-RS:
CORS AND OPUS FOR ENGINEERS
• Formal error propagation. In a least squares adjust-
ment, the covariance matrix of the adjusted parameters
may be computed by multiplying the variance of unit
weight by the inverse of the normal equation coefficient
matrix. The formal variances (that is, the squares of the
formal standard errors) of the coordinates correspond to
the diagonal elements of this matrix. This procedure is
based on the assumption that the mathematical model
reflects physical reality, and only random errors are
present in the observations.
In many applications, including both OPUS and OPUS-
RS, this method produces standard errors which are far
too optimistic (often only a few millimeters). The reasons
why this occurs are unknown, but are thought to be related
to unmodelled effects. Because the formal standard errors
are seldom reliable indicators of the uncertainties in the
computed coordinates, they are not shown in the standard
OPUS and OPUS-RS reports. For users who want them,
they are available in the extended output.
• Repeated samples. If more than one estimate of a
quantity is available, the scatter of those estimates gives
a measure of the precision of any single one. In both
OPUS and OPUS-RS, we compute separate estimates
of the rover’s coordinates by single baselines, each
involving a known reference station and the rover.
These are not truly independent estimates, because they
all use the same data from the rover; however, they do
serve the purpose of isolating errors associated with the
accuracies of the adopted coordinates of the individual
reference stations and/or the observational noise con-
tained in the GPS data from these stations.
In the original OPUS, the computed coordinate (in a
given dimension) is the mean of the coordinates computed
by three separate single baseline solutions. This solution is
not completely rigorous, because it ignores the fact that the
results from the three single baselines are not statistically
independent. Furthermore, OPUS reports the range (peak-
to-peak) of the three individual estimates. As shown by
Schwarz (2006), this range is related to the standard error
of the mean by the factor 2.93. In practice, the peak-to-
peak error has been found to be a useful and realistic
indicator of the accuracy of the computed coordinate.
In OPUS-RS, the final coordinates are computed by
using data from all selected reference stations and the rover
in a single simultaneous least squares adjustment. How-
ever, single baseline solutions between the rover and each
CORS are also computed as a means of estimating the
accuracy. For the most part, the single baseline solutions
show if estimated coordinates using a particular reference
station fail to agree with the others, and this often indicates
the presence of non-random errors in the data or the
adopted coordinates from a particular reference station.
77
 The peak-to-peak range of the single baseline solutions
does not have the same meaning in OPUS-RS as it does in
regular OPUS because the number of reference stations
used in OPUS-RS varies (between a minimum of three and
a maximum of nine). The steps of the algorithm used in
OPUS-RS are:
• compute various estimates of the rover’s coordinates,
using each of the selected reference stations
individually
• compute the final coordinates of the rover by a
simultaneous least squares adjustment, using the data
from all the reference stations and the rover together
• compute the difference between each single baseline
estimate and the final coordinate in each of several
dimensions, that is, in the global X, Y, and Z dimen-
sions, as well as in the east (e), north (n), up (u)
dimensions.
• estimate the standard error in each coordinate by
computing the square root of the differences.
• insert the resulting number next to the coordinate on the
OPUS-RS report.
The numbers reported as standard errors are valuable
because they isolate problems with the reference station
coordinates or data. However, it is difficult to assign a
probability level to these numbers. Were the single base-
lines independent of each other and of the final coordinates,
these numbers would be the standard errors of the coor-
dinates determined by a single baseline. However, neither
of these conditions is met, so one can use only an empirical
measure. Experiments using data from the CORS stations
(whose coordinates are assumed to be known) show that
the actual error in a final coordinate is greater than the
number given as the standard error of this coordinate in
fewer than five percent of the cases.
Experience of the first 6 months
OPUS-RS was released for public operational use at the
end of January 2007. In the first 6 months of operational
use, approximately 40,000 files were submitted. Of each
100 files submitted, approximately:
Twenty were rejected because of user errors. Reasons
for this included:
• Submitted data file could not be converted to the
RINEX format.
• Submitted RINEX file did not conform to the RINEX
standards.
• Collection rate was incorrect (collection rate must be 1,
2, 3, 5, 10, 15, or 30 s).
• Submitted data were collected outside the geographic
boundaries where the use of OPUS-RS is allowed.
78 CORS AND OPUS FOR ENGINEERS
• No data were available for a user-selected reference
station.
• Submitted data set spanned too little time (minimum
time span is 14.4 min = 0.01 days).
• Submitted data set spanned too much time (maximum
time span is 4.0 h).
• Submitted data set did not contain the four observation
types—L1, L2, P1 [or C1], and P2—as required by
RSGPS.
Fifteen were data sets for which OPUS-RS did not
attempt a solution. Some common reasons for this were:
• OPUS-RS could not find three reference stations within
250 km of the rover.
• The rover was located more than 50 km outside of the
convex hull of the selected reference stations.
• The program could not determine the integer
ambiguities.
Sixty-five resulted in a solution which was e-mailed to
the submitter.
• Of these, about five carried a warning that the solution
may be weak. There are four warnings that could have
been issued:
• The scatter of the single baseline solutions was
greater than 5 cm in either horizontal coordinate or
greater than 10 cm in the vertical.
• The network solution quality indicator—a measure
of the ability of the software to fix the ambiguities
to the correct integer values—was less than 3.0.
• The rover solution quality indicator was less than
1.0.
• The normalized RMS from the final rover mode
adjustment was greater than 1.5.
• Solutions for the remaining 60 submitted jobs were
returned to the user with no warnings.
Brief introductions to earlier versions of OPUS-RS were
previously published by Lazio (2007) and Martin (2007).
Introducing IDOP
A primary reason why OPUS-RS can obtain accurate
coordinates with only 15 min of rover data is that it uses
at least an hour’s worth of data from several reference
stations to estimate both the tropospheric and ionospheric
delays at these stations, and then interpolates (or extra-
polates) these delays to predict corresponding delays at the
rover. Because interpolation/extrapolation is involved, the
accuracies of the rover’s derived coordinates should
depend on the geometry of the reference stations and on
the distances between the rover and the individual
reference stations. Such is not the case with the original oðIDOPÞ oðIDOPÞ
OPUS utility. In particular, Eckl et al. (2001) showed that ¼ ¼0 ð7Þ
ox0 oy0
both the orientation and length of a baseline between two
GPS data-collection stations have negligible influence on at this location and nowhere else. When using OPUS-RS,
the relative positional coordinates between these stations IDOP will always be greater than 0.33, because this utility
when their GPS data are processed with PAGES (the uses a maximum of nine CORS.
processing engine contained in the original OPUS). The Figure 2 provides an example of how IDOP depends on
influence of reference-station geometry on the accuracy of location. For this example, we have used only four refer-
the rover coordinates, as obtained with OPUS-RS, is ence stations, located at the corners of a square with sides
reflected in the following theorem. We will address the of length 2p, where p is an arbitrary parameter. The com-
influence of interstation distances in a later section of this putations in Appendix 2 show that for this example,
sffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffi
 2  2
article.
1 x0 y0
IDOP ¼ þ þ1 ð8Þ
Theorem 1 Suppose z = f(x, y) is modeled by the 2 p p
expression pffiffiffi
consequently, IDOP equals 0.5 ð¼ 1= nÞ at the square’s
z ¼ ax þ by þ c ð1Þ centroid, and IDOP increases as a function of the rover’s
and suppose there is a set of n independent observations, distance from this centroid in a radially symmetric manner.
denoted zi, at the points (xi, yi) for i = 1, 2, 3,…, n. Table 1 shows other values of IDOP at different locations
We choose to estimate the parameters a, b, and c by inside and outside the square. Thus, according to Theorem
least squares. We further suppose that the observations are 1, if we have statistically independent estimates for the
statistically independent and each has the (unknown) atmospheric conditions at the four corners of a square, and
standard deviation r. The predicted value of z at the point we assume that Eq. 1 is an adequate model for the spatial
(x0, y0) then has the standard error rz0 given by the distribution of these atmospheric conditions, then we can
expression predict the corresponding atmospheric conditions and their
rffiffiffiffi standard errors at a rover located anywhere in the plane,
R
rz 0 ¼ r ð2Þ but the accuracy of such predictions would depend simply
Q on the distance between the rover and the square’s cen-
where troid. With a more complicated reference-station geometry,
the values for IDOP would not be radially symmetric about
R ¼ ðRDx2i ÞðRDy2i Þ  ðRDxi Dyi Þ2 ð3Þ the centroid of these stations.
and
Q ¼ nR þ 2ðRDxi ÞðRDyi ÞðRDxi Dyi Þ  ðRDxi Þ2 ðRDy2i Þ
 ðRDyi Þ2 ðRDx2i Þ
ð4Þ
where Dxi = xi - x0 and Dyi = yi - y0.
Appendix 1 contains a proof of this theorem.
pffiffiffiffiffiffiffiffiffi
The mathematical expression R=Q is a unitless
quantity that we shall call the ‘‘interpolative dilution of
precision’’ or IDOP, for short. Thus
rffiffiffiffi
R
IDOP ¼ ð5Þ
Q
From Eq. 5, it follows that if (x0, y0) is located at the
P
centroid of the data points [that is, if x0 ¼ ð xi Þ=n and
P P P
y0 ¼ ð yi Þ=n], then Dxi ¼ Dyi ¼ 0 and
1
IDOP ¼ pffiffiffi : ð6Þ
n
Also, IDOP attains its minimum value at the centroid, Fig. 2 IDOP values as a function of location for the case of four
because CORS located at the corners of a square

CORS AND OPUS FOR ENGINEERS 79

Table 1 IDOP values at
(x0, y0) IDOP function f(x, y) can be ‘‘adequately’’ approximated by the
various locations when four linear mathematical expression ax ? by ? c over the area
CORS are at the corners of a (0, 0) 0.50
square whose sides have a
involved in interpolation.
length of 2p (0, p/2) 0.56 To test what happens otherwise, we examined a partic-
(p/2, 0) 0.56 ular case restricted to one function of one variable.
(0, -p) 0.71
Theorem 2 Suppose that z is a quadratic function of x,
(p, 0) 0.71
z = f(x) = ax2 ? bx ? c, and suppose there is a sample of
(p, p) 0.87
n independent observations zi at xi for i = 1, 2, 3,…, n.
(p, -p) 0.87
Suppose also that we attempt to approximate f(x) by the
(-p, -p) 0.87
linear expression b0 x ? c0 , then the error of approximation
(-p, p) 0.87
at x = 0 is c0 - c. Furthermore,
(0, 3p/2) 0.90
aRx2i
(0, 2p) 1.12
c0  c ¼ ð9Þ
(3p/2, 3p/2) 1.17 n
(2p, 2p) 1.50 for the case that Rxi ¼ 0.
Appendix 3 contains a proof of Theorem 2.
This theorem indicates that, for this particular case of
The IDOP should not be confused with the well-known
f(x), the linear interpolation process will generate a biased
unitless quantity called the geometric dilution of precision
prediction at the point x = 0. Moreover, the magnitude of
(GDOP). Nor should IDOP be confused with related mea-
this bias is proportional to ðRx2i Þ=n when Rxi ¼ 0:
sures, such as PDOP, HDOP, VDOP, TDOP, etc. GDOP and
We generalize this result to a function of two variables
its related measures are well explained in many textbooks,
and state (without proof) that whenever f(x, y) is itself a
including Leick (2004), and they quantify the geometry of
nonlinear function of x and y within the area of interpola-
the collection of GPS satellites visible from the rover. Thus,
tion (extrapolation), then the linear interpolation process
IDOP quantifies reference-station geometry relative to the
may generate a biased prediction of the atmospheric con-
rover, and GDOP quantifies satellite geometry relative to the
ditions at the rover. The magnitude of this bias will depend
rover. Both IDOP and GDOP will influence the accuracy of
on the nature of f(x, y). We will approximate this bias in
the coordinates obtained with OPUS-RS, but we have
this study by a quantity that is proportional to the root-
restricted our attention to IDOP for this study.
mean-square distance (RMSD) from the rover as defined by
the equation:
rPffiffiffiffiffiffiffiffiffiffiffiffi
n 2
ffi
The effect of interstation distances i di
RMSD ¼ ð10Þ
n
A curious characteristic of IDOP is that its value does not
where di equals the horizontal distance between rover and
depend on the distances between the rover and the indi-
the i-th reference station for i = 1, 2,…, n. We have thus
vidual reference stations in an absolute sense. Its values
identified two sources of error—the error committed by
depend on these distances only in a relative sense. That is,
using a simple plane to model the variation of atmospheric
if we scaled all the x and y coordinates by the factors sx and
conditions, and the error of interpolation. We combine
sy such that
these two sources into an ‘‘overall’’ standard error of the
x0 ¼ sx  x and y0 ¼ sy  y; predicted atmospheric conditions at the rover
qffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffi
then the IDOP value at (x’0, y’0) in the x0 y0 -frame would be rðIDOP; RMSDÞ ¼ ða  IDOPÞ2 þ ðb  RMSDÞ2 ð11Þ
the same as the IDOP value at (x0, y0)in the xy-frame. Thus,
in the example of four reference stations located at the where a and b are constants. Equation 11 embodies the
corners of a square: IDOP equals 0.5 at the centroid, it concept that the square of the total error equals the sum of
equals 0.56 at any point that is located at a distance of p/2 squares of the various error components. Here the term a
from the centroid, and it equals 0.87 at each reference IDOP quantifies the random error due to linear interpola-
station, no matter what value of p is used. This result may tion, and the term b RMSD approximates the systematic
be counterintuitive, because it seems that we should be able error due to the nonlinearity of the atmospheric delay as a
to predict the atmospheric conditions at the square’s cen- function of x and y. In the next section, we will describe an
troid better when p equals 50 km than when p equals experiment to estimate nominal values for a and b across
100 km. Nevertheless, this is the case so long as the the conterminous United States (CONUS) using GPS data

80 CORS AND OPUS FOR ENGINEERS

spanning a period of 10 months. The values of IDOP were
determined using Eq. 5 and the methodology described in
Appendix 4.
Empirical results
We selected each National CORS located in CONUS to
serve as a simulated rover. We assumed that the ‘‘true’’
positional coordinates of these rover-CORS are provided
by their NGS-adopted ITRF2000 values at epoch 1997.00
(=1 January 1997), as posted at http://www.ngs.noaa.gov/
CORS/coordinates. These ‘‘true’’ coordinates for recently
started CORS are an average from the first few weeks of
operation, computed from the 24-h data with the NGS-
developed software PAGES in a solution involving the
entire CORS network and having constraints at five North
American IGS stations (ALGO, DRAO, GODE, MDO1
and NLIB). Velocities for time-projection of the coordi-
nates for these recently started CORS are predicted by the
HTDP software (http://www.ngs.noaa.gov/TOOLS/Htdp/
Htdp.shtml); however, years of coordinates often reveal
insufficiencies in the predicted velocity, with a least-
squares fit to the history suggesting a revision to the
velocity and concomitant ‘‘true’’ coordinate, especially
when time-projected to a reference epoch such as 1997.00.
‘‘True’’ coordinates are therefore a mixture of these
velocity sources, based on the longevity of a given CORS
and on the predictive abilities of the HTDP model.
For each rover-CORS, we selected 15 min of data
(17:45–18:00 UTC) observed during the tenth day for each
of ten consecutive months (July 2007–April 2008). For
each 15-min data set, we used OPUS-RS to compute
positional coordinates for the rover-CORS. As is the case
with the original OPUS, OPUS-RS computes ITRF2000
positional coordinates at the mean epoch of the observa-
tional window, denoted t. Consequently, before comparing
results it was necessary to transform the coordinates from
epoch t to the common epoch of 1997.00 by using the
NGS-adopted 3-D velocities for the rover-CORS. The
specific steps to rigorously transform local geodetic
coordinates between epochs are detailed in Soler et al.
(2006).
We compared the various estimates for the ITRF2000
positional coordinates of the rover-CORS with their ‘‘true’’
coordinates. The corresponding coordinate differences
were transformed from a global Earth-centered-Earth-fixed
reference system to the local horizon frame centered at the
associated rover-CORS as expressed in the east (e), north
(n), and up (u) dimensions. The transformed differences
were then tagged with the IDOP and RMSD values at each
rover-CORS previously determined by OPUS-RS after
implementing Eqs. 5 and 10, respectively.
CORS AND OPUS FOR ENGINEERS
From the 10 days of data, we obtained a total of 7,409
‘‘successful’’ OPUS-RS solutions. The differences between
the ‘‘true’’ coordinates and the OPUS-RS results were par-
titioned into bins for each of the following IDOP intervals:
0.3–0.4, 0.4–0.5,…, 0.8–0.9; together with the following
RMSD intervals: 0–50 km, 50–100 km, 100–150 km, 150–
200 km, and 200–250 km. Table 2 presents, for the east
component, the standard deviation for the distribution of
differences contained in each bin and the corresponding total
number of successful solutions. We rejected a particular
solution if the east component of the difference exceeded
10 cm. Table 3 shows the same statistics for the up com-
ponent of the differences, except in this case an OPUS-RS
solution was rejected if the up component difference
exceeded 30 cm. We chose not to present corresponding
statistics for the north component of the differences, because
these statistics differ insignificantly from those for the east
component. Note that standard deviations for the up com-
ponent differences are about three times larger than the
corresponding standard deviations for the east component.
We expected that the standard deviations should
increase when either IDOP or RMSD increases. We
noticed that this was not always the case for the bins with
smaller sample sizes. We, therefore, restricted our analysis
to samples containing at least 80 solutions. These bins are
highlighted in Tables 2 and 3. We then estimated values
for a and b of Eq. 11 to quantify r(IDOP, RMSD) for the
east component. Similarly, values for a and b were esti-
mated for the north component and the up component,
yielding the following results:
ae ¼ 1:87  0:26 cm and be ¼ 0:0047  0:0010 cm/km
ðbe ¼ 0:047 ppmÞ
an ¼ 1:77  0:21 cm and bn ¼ 0:0050  0:0008 cm/km
ðbn ¼ 0:050 ppmÞ
au ¼ 6:69  0:71 cm and bu ¼ 0:0151  0:0028 cm/km
ðbu ¼ 0:151 ppmÞ ð12Þ
Note that the values for a and b for the north component
are statistically indistinguishable from the corresponding
values for the east component. Also, note that the standard
errors for the up component are about 3.6 times larger than
those for either the east component or the north component.
These empirical results corroborate similar findings
published by Eckl et al. (2001) who used a completely
different GPS processing engine, namely, the PAGES
software.
Visualizing accuracy as a function of IDOP and RMSD
To visualize the previous results, Figs. 3 and 4 depict the
standard errors as a function of RMSD and IDOP based on
81
Table 2 East component
standard errors tabulated on bins
0-50 km 50-100 km 100-150 km 150-200 km 200-250 km
of IDOP versus RMSD

IDOP e #. e # e # e # e #
(cm) sol. (cm) sol. (cm) sol. (cm) sol. (cm) sol.

0.3-0.4 0.822 212 0.775 1189 0.885 610 0.752 297 0.710 11
0.4-0.5 0.831 148 0.949 731 1.053 586 1.132 515 0.859 54
0.5-0.6 0.903 55 1.183 368 1.072 298 1.239 341 1.522 47
0.6-0.7 0.359 7 1.085 221 1.196 195 1.916 200 2.349 40
0.7-0.8 0.761 25 1.209 137 1.388 84 1.742 118 1.089 6
Entries with a sample size
0.8-0.9 0.412 2 1.083 25 1.041 38 2.034 80 2.281 12
greater than 80 are highlighted

Table 3 Vertical component

standard errors tabulated on bins
0-50 km 50-100 km 100-150 km 150-200 km 200-250 km
of IDOP versus RMSD

IDOP u #. u # u # u # u #
(cm) sol. (cm) sol. (cm) sol. (cm) sol. (cm) sol.

0.3-0.4 2.108 212 2.823 1189 3.067 610 2.775 297 2.701 11
0.4-0.5 2.998 148 3.649 733 4.458 587 4.054 515 3.775 56
0.5-0.6 0.903 55 3.650 368 3.869 299 4.475 343 5.721 52
0.6-0.7 0.359 7 5.086 224 4.083 193 5.004 198 3.952 40
0.7-0.8 0.761 25 4.540 137 4.400 83 5.689 119 4.707 6
Entries with a sample size
greater than 80 are highlighted 0.8-0.9 0.412 2 5.734 26 4.691 38 5.058 79 7.105 12

the values presented in Tables 2 and 3. Each figure also

incorporates the curves defined by the empirical model as
obtained by implementing Eq. 11 using the values of a and
b given in Eq. 12. As before, the graph corresponding to
the north–south component is essentially equal to Fig. 3
and is not included in this paper. Figures 5 and 6 are
related to Figs. 3 and 4, respectively. They are obtained by
interchanging the units of the abscissa axis from RMSD to
IDOP.
Figures 7 and 8 employ another method to show the
variation of standard error for the east and up compo-
nents, respectively, as a function of IDOP and the RMSD
from the rover. The contour lines are plotted using Eq. 11
with the corresponding values of a and b presented in
Eq. 12. The dependency of the accuracy of OPUS-RS
solutions on IDOP and the RMSD to the rover is evident
from the plots. Consequently, IDOP and RMSD are
essential parameters to discern the quality of the results Fig. 3 East component standard error as a function of IDOP (from
when using any process that interpolates atmospheric 0.3 to 0.8) and RMSD (from 0 to 200 km). Numbers next to the
symbols indicate sample size. The curves depict the theoretical model
conditions from the reference stations to the rover’s given by Eq. 11 and the parameters ae and be from Eq. 12
location. Further investigations are planned to study the
variability of the accuracy of OPUS-RS solutions when Discussion
the 15-min observational window varies during the course
of a 24-h day. Another relevant issue to address is to Figures 3, 4, 5, 6 exhibit some significant discrepancies
contrast the accuracy of OPUS-RS with that of the ori- between the standard deviations for some of the individual
ginal OPUS for observing sessions with durations bins and their corresponding curves. These discrepancies
between 1 and 4 h. perhaps reflect that Eq. 11 is too simplistic. This equation

82 CORS AND OPUS FOR ENGINEERS

Fig. 4 Vertical component standard error as a function of RMSD
(from 0 to 200 km) and IDOP (from 0.3 to 0.8). Numbers next to the
symbols indicate sample size. The curves depict the theoretical model
given by Eq. 11 and the parameters au and bu from Eq. 12
Fig. 5 East component standard error as a function of RMSD (from 0
to 200 km) and IDOP (from 0.3 to 0.8). Numbers next to the symbols
indicate sample size. The curves depict the theoretical model given by
Eq. 11 and the parameters ae and be from Eq. 12
may need other parameters in addition to IDOP and
RMSD. There are many other possibilities, such as the
satellite geometry (measured by GDOP), the spatial and
temporal variability of the ionosphere, and/or tropospheric
refraction. In particular, it will be interesting to see if our
current estimates for a and b change significantly as the
solar max, predicted to occur during the 2011–2012 time
frame, approaches. Our current results represent the situa-
tion for the 2007–2008 time frame, during which the
magnitude of ionospheric refraction is relatively low.
CORS AND OPUS FOR ENGINEERS
Fig. 6 Vertical component standard error as a function of RMSD
(from 0 to 200 km) and IDOP (from 0.3 to 0.8). Numbers next to the
symbols indicate sample size. The curves depict the theoretical model
given by Eq. 11 and the parameters au and bu from Eq. 12
Fig. 7 Expected values of the standard error in either the east
dimension or the north dimension, as determined using Eq. 11 and the
parameters ae and be from Eq. 12 (15 min observation span)
Vertical standard errors achievable in CONUS using
OPUS-RS
A simulation was performed to visualize the effect of IDOP
and RMSD on OPUS-RS solutions in CONUS. The values
of IDOP and RMSD were computed at hypothetical rovers
located at the intersections of a rectangular grid having a
0.5 9 0.5 spacing (*50 km 9 50 km spacing). Using
different colors, Fig. 9 depicts the estimated values for the
standard errors in the vertical dimension using Eq. 11 and
the values of au and bu from Eq. 12, taking into account the
83
 OPUS-RS may give poor results are also visible in this
figure. Of particular significance are the coastal zones
where, even with the presence of nearby CORS, an accu-
rate OPUS-RS solution cannot be obtained because the
CORS are distributed all to one side of a would-be rover.
As expected, OPUS-RS yields good vertical standard errors
(2 cm B ru B 3 cm) in regions possessing dense CORS
coverage (Ohio, Michigan, etc.). A map showing achiev-
able standard errors across CONUS for either the east–west
dimension or the north–south dimension would resemble
the map contained in Fig. 9, except that the values dis-
played for vertical standard errors should be divided by
about 3.6 to obtain the corresponding horizontal standard
errors.

Fig. 8 Expected values of the vertical standard error as determined
using Eq. 11 and the parameters au and bu from Eq. 12 (15 min
observation span)
geometry and distance to the CORS sites. It is immediately
evident from this map that OPUS-RS will not provide
coordinates that are accurate to a few centimeters in some
areas of CONUS. These areas appear in white in Fig. 9. In
particular, due to sparseness of the CORS network, regions
of the Dakotas and northern Minnesota are currently
located outside the range of good OPUS-RS solutions.
Clearly, not enough CORS are located within the required
250-km range in these regions. Other smaller areas where
Conclusions
This article has described the principal characteristics of
OPUS-RS as an alternative to OPUS for processing GPS
data for short observing sessions (as brief as 15 min). The
concept of interpolative dilution of precision (IDOP) is
introduced. Statistics are presented indicating the expected
standard errors achievable using OPUS-RS as a function of
IDOP and the RMSD to the rover. Results show that better
standard errors in horizontal and vertical components are
obtained with the lower values of IDOP and RMSD. The
present investigation was limited to 15-min data spans
observed at the same time of the day (starting at 17:45

Fig. 9 Estimated vertical

standard errors achievable with
15 minutes of GPS data when
using OPUS-RS in the
conterminous U.S. These
standard errors were computed
as a function of the IDOP and
RMSD values provided by the
CORS network as of September
2008

84 CORS AND OPUS FOR ENGINEERS

 8 9
UTC) during the tenth day of ten consecutive months (from < Dx =
July 2007 to April 2008). The results clearly show that r2z ¼ f Dx Dy 1 gRX Dy ð18Þ
IDOP and RMSD constitute important variables to consider : ;
1
when accurate GPS results are expected from OPUS-RS or,
for that matter, any other process that interpolates Let
2 3
(extrapolates) atmospheric conditions from several refer- s11 s12 s13
ence stations to the rover’s location, such as real-time ðAT AÞ1 ¼ 4 s22 s23 5 ð19Þ
GNSS reference station networks. sym: s33

Then, for (Dx, Dy) = (0, 0), i.e., at the location (x0, y0),
Appendix 1: Proof of Theorem 1 r2z0 ¼ r2 s33 ð20Þ

Let z = ax ? by ? c and suppose there is a set of n but

independent observations, denoted zi, at the points (xi, yi) detðBÞ
s33 ¼ ð21Þ
for i = 1, 2, 3,…, n. Suppose also that we choose to esti- detðAT AÞ
mate the parameters a, b, and c by least squares and use
these values to estimate the value of z at (x0, y0). where

Write z0 = ax0 ? by0 ? c, so that RDx2i RDxi Dyi
B¼ ð22Þ
zi ¼ aDxi þ bDyi þ z0 ð13Þ sym: RDy2i

where Dxi = xi - x0 and Dyi = yi - y0. Thus,

We use this as the basic observation equation. We also detðBÞ ¼ ðRDx2i ÞðRDy2i Þ  ðRDxi Dyi Þ2 ¼ R ð23Þ
assume that all the observations have the same standard
deviation r. The observation equations can be represented and
in matrix notation as: detðAT AÞ ¼ nR þ ðRDxi Þ½ðRDxi Dyi ÞðRDyi Þ
AX ¼ Z ð14Þ  ðRDxi ÞðRDy2i Þ  ðRDyi Þ½ðRDx2i ÞðRDyi Þ
where  ðRDxi ÞðRDxi Dyi Þ
8 9 ¼ nR þ 2ðRDxi ÞðRDyi ÞðRDxi Dyi Þ
8 9 > z1 >
<a= < z2 >
> =
 ðRDxi Þ2 ðRDy2i Þ  ðRDyi Þ2 ðRDx2i Þ
X¼ b ;Z¼ .. and
: ; > >
z0 : . >
> ; ¼Q ð24Þ
2 zn 3
Dx1 Dy1 1 Thus,
6 Dx2 Dy2 1 7 rffiffiffiffi
6 7 R
A ¼6 . .. .. 7: rz0 ¼ r ð25Þ
n3 4 .. . .5 Q
Dxn Dyn 1
Then the variance–covariance matrix of X, denoted RX ; Appendix 2: IDOP for a simple case—four reference
is given by the equation stations located at the corners of a square
RX ¼ ðAT PAÞ1 ð15Þ
Consider the simple case of having only four reference
where P ¼ 1
I and I is the n 9 n identity matrix. Hence
r2
stations located at the corners of a square whose sides are
2 31 of length 2p such that:
RDx2i RDxi Dyi RDxi
RX ¼ r2 ðAT AÞ1 ¼ r2 4 RDy2i RDyi 5 ðx1 ; y1 Þ ¼ ðp; pÞ;
sym: n ðx2 ; y2 Þ ¼ ðp; pÞ;
ð26Þ
ð16Þ ðx3 ; y3 Þ ¼ ðp; pÞ; and
Now the predicted value of z at the point (x, y) is given ðx4 ; y4 Þ ¼ ðp; pÞ
by the equation: here, we show that
z ¼ aDx þ bDy þ z0 ¼ f Dx Dy 1 gX ð17Þ s
ffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffi
  2
1 x0 2 y0
with a variance IDOP ¼ þ þ1 ð27Þ
2 p p

CORS AND OPUS FOR ENGINEERS 85

 Appendix 3: Proof of Theorem 2
at the point (x0, y0).
We first compute some necessary quantities, namely:
Let z = f(x) = ax2 ? bx ? c, and suppose there is a set of
ðDx1 ; Dy1 Þ ¼ ððp  x0 Þ; ðp  y0 ÞÞ n independent observations, denoted zi, at the points xi for
P
ðDx2 ; Dy2 Þ ¼ ððp  x0 Þ; ðp  y0 Þ i = 1, 2,…, n such that xi = 0. Suppose also that we
ð28Þ
ðDx3 ; Dy3 Þ ¼ ððp  x0 Þ; ðp  y0 ÞÞ choose to approximate f(x) by the linear expression
ðDx4 ; Dy4 Þ ¼ ððp  x0 Þ; ðp  y0 ÞÞ b0 x ? c0 and we use least squares to estimate the para-
meters b0 and c0 . Then
It follows that:  0

b
¼ ðAT AÞ1 AT Z ð34Þ
RDxi ¼ 4x0 c0
RDyi ¼ 4y0 where
RDx2i ¼ 4ðp2 þ x20 Þ ð29Þ 2 3 8 9
x1 1 > z1 >
6 x2 < z2 >
> =
RDy2i ¼ 4ðp þ y20 Þ 17
2
6 7
RDxi Dyi ¼ 4x0 y0
A ¼ 6 .. .. 7 and Z¼ .. :
4 . .5 > >
: . >
> ;
Thus, xn 1 zn

Thus,
R ¼ ðRDx2i ÞðRDy2i Þ  ðRDxi Dyi Þ2
( 0) " #1 ( )
¼ ð4ðp2 þ x20 ÞÞð4ðp2 þ y20 ÞÞ  ð4x0 y0 Þ2 ð30Þ b Rx2i Rxi Rxi zi
¼
¼ 16ðp4 þ p2 x20 þ p2 y20 Þ c0 sym: n Rzi
" #( )
and n Rxi Rxi zi
sym: Rx2i Rzi
Q ¼ nR þ 2ðRDxi ÞðRDyi ÞðRDxi Dyi Þ ¼ ð35Þ
2
nRx2i  ðRxi Þ2
 ðRDxi Þ ðRDy2i Þ
and
 ðRDyi Þ2 ðRDx2i Þ
ðRxi ÞðRxi zi Þ þ ðRx2i ÞðRzi Þ
¼ ð4Þð16Þðp4 þ p2 x20 þ p2 y20 Þ ð31Þ c0 ¼ ð36Þ
nRx2i  ðRxi Þ2
þ 2ð4x0 Þð4y0 Þð4x0 y0 Þ
Since Rxi ¼ 0 (the centroid of the reference stations is at
 ð4x0 Þ2 ð4Þðp2 þ y20 Þ the rover), then
 ð4y0 Þ2 ð4Þðp2 þ x20 Þ ðRx2i ÞRzi Rzi Rðax2i þ bxi þ cÞ aRx2i
c0 ¼ ¼ ¼ ¼ þc
nðRx2i Þ n n n
Finally,
ð37Þ
Q ¼ 64p4 þ 64p2 x20 þ 64p2 y20
Hence
þ 128x20 y20
aRx2i
 64x20 p2  64x20 y20 ð32Þ c0  c ¼ ð38Þ
n
 64y20 p2  64x20 y20
¼ 64p 4
Appendix 4: Computation of IDOP plane coordinates
Thus, in OPUS-RS

rffiffiffiffi sffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffi
ffi
Equations 3 and 4 use the relative coordinates (Dxi, Dyi) of
R 16ðp4 þ p2 x20 þ p2 y20 Þ
IDOP ¼ ¼ each CORS control station (xi, yi) with respect to the rover
Q 64p4
(x0, y0). In OPUS-RS these values are calculated on a local
s ffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffi
  2
1 x0 2 y0 geodetic horizon plane using the first two elements (com-
¼ þ þ1 ð33Þ ponents along the east and north, respectively) of the
2 p p
following standard formulation:

86 CORS AND OPUS FOR ENGINEERS

8 9 2 3
< Dx >  sin k cos k of ambiguity resolution in network-based real-time kinematic
> = 0
6 7 GPS. J Surv Eng 133(2):56–65. doi:10.1061/(ASCE)0733-9453
Dy ¼ 4  sin / cos k  sin / sin k cos / 5 (2007)133:2(56)
>
: >
;
Du i cos / cos k cos / sin k sin / Kashani I, Wielgosz P, Grejner-Brzezinska DA, Mader GL (2005) A
8 9 new network-based rapid-static module for the NGS online
< XiðCORSÞ  XROVER >
> = positioning user service—OPUS-RS. In: Proceedings of ION
Annual Meeting. Institute of Navigation, pp 928–936
 YiðCORSÞ  YROVER ð39Þ
>
: >
; Lazio P (2007) Constraining network adjustments to OPUS-RS
ZiðCORSÞ  ZROVER coordinate observations. J Surv Eng 133(3):106–113. doi:
10.1061/(ASCE)0733-9453(2007)133:3(106)
where X, Y, and Z are Earth-centered, Earth-fixed Cartesian Leick A (2004) GPS satellite surveying, 3rd edn. Wiley, New York,
coordinates. Here, k and u denote the geodetic longitude xxiv ? 664 p
Martin D (2007) Geodetic connections. OPUS rapid static. Am Surv
and latitude, respectively, of the rover.
4(3):44, 46–48
Schwarz CR (2006) Statistics of range of a set of normally distributed
numbers. J Surv Eng 132(4):155–159. doi:10.1061/(ASCE)0733-
9453(2006)132:4(155)
References Schwarz CR (2008) Heuristic weighting and data conditioning in the
National Geodetic Survey rapid static GPS program. J Surv Eng
134(3):76–82. doi:10.1061/(ASCE)0733-9453(2008)134:3(76)
Eckl MC, Snay RA, Soler T, Cline MW, Mader GL (2001) Accuracy
Snay RA, Soler T (2008) Continuously Operating Reference Station
of GPS-derived relative positions as a function of interstation
(CORS): history, applications, and future enhancements. J Surv
distance and observing-session duration. J Geod 75(12):633–
Eng 134(4):95–104
640. doi:10.1007/s001900100204
Soler T, Michalak P, Weston ND, Snay RA, Foote RH (2006)
Estey LH, Meertens CH (1999) TEQC: the multipurpose toolkit for
Accuracy of OPUS solutions for 1–4 h observing sessions. GPS
GPS/GLONASS data. GPS Solut 3(1):42–49. doi:10.1007/
Solut 10(1):45–55. doi:10.1007/s10291-005-0007-3
PL00012778
Wang J, Stewart MP, Tsakiri M (1998) A discrimination test
Grejner-Brzezinska DA, Wielgosz P, Kashani I, Mader G, Smith D,
procedure for ambiguity resolution on-the-fly. J Geod
Robertson D, Komjathy A (2005) Performance assessment of the
72(11):644–653. doi:10.1007/s001900050204
new rapid static module of the online positioning user service—
Wielgosz P, Grejner-Brzezinska D, Kashani I (2004) Network
OPUS-RS. In: Proceedings of the ION GNSS 18th International
approach to precise GPS navigation. Navigation 51(3):213–220
Technical Meeting of the Satellite Division. Institute of Navi-
gation, pp 2595–2605
Grejner-Brzezinska DA, Kashani I, Wielgosz P, Smith DA, Spencer
PSJ, Robertson DS, Mader GL (2007) Efficiency and reliability

CORS AND OPUS FOR ENGINEERS 87

 12
Accuracy of Rapid Static Online Positioning User Service
(OPUS-RS) Revisited
Tomás Soler, M.ASCE1, Richard A. Snay2, Charles R. Schwarz3 and Kevin K. Choi4

Abstract: In 2007, the National Geodetic Survey (NGS), an office of the National Oceanic and Atmospheric Administration
(NOAA), introduced OPUS-RS, the rapid static version of its Online Positioning User Service. OPUS-RS enables its users to
submit as little as 15 minutes of GPS data via the Web for obtaining 3D positional coordinates, with an accuracy of a few
centimeters, for the location where the data were observed. Schwarz et al. (2009) advanced empirical equations that predict the
accuracy of OPUS-RS-generated coordinates as a function of the local geometry of the CORS network in the vicinity of the data-
collection point for the case of a 15-minute data span. This paper will discuss a slightly refined form of the previously used
empirical equations and consider data spans of 1 hour and 4 hours as well as 15 minutes. Experiments with actual GPS data
demonstrate that OPUS-RS-generated coordinates obtained using 1-hour data sets are significantly more accurate than those
obtained with 15-minute data sets; while those obtained using 4-hour data sets are only marginally better than those obtained
using 1-hour data sets. The paper also describe an interactive Web utility that enables its users to view the expected accuracy of
OPUS-RS, as a function of geographic location, based on the current spatial distribution of stations in the CORS network.
Finally, this investigation compares the accuracies of coordinates obtained with OPUS-RS with corresponding accuracies for
coordinates obtained with the original version of OPUS, now called OPUS-S (where S stands for “static”). For this comparison,
we used 1-hour and 2-hour GPS data sets observed during June 2004 at three different CORS, each located in an extremely
different environment from the other two. This comparison demonstrates that OPUS-RS provides significantly better accuracies
than OPUS-S for 1-hour data sets, but only marginally better accuracies for 2-hour data sets. NGS recommends that OPUS-S be
used instead of OPUS-RS for data sets spanning more than 2 hours, because of the high computational load associated with the
use of OPUS-RS. Also, OPUS-S addresses several systematic errors, associated with GPS data, more rigorously than does
OPUS-RS. Thus, we expect that OPUS-S may generally provide more accurate results than OPUS-RS for those observing-
sessions spanning more than 2 hours.
Author keywords: Rapid Static Online Positioning User Service; OPUS-RS; GPS accuracy; GPS positioning; geodetic
networks

advantages of this innovative technology that in March

Introduction
2001 it launched the popular Online Positioning User
Service (OPUS) utility (Weston et al. 2007). OPUS is an
NOAA’s National Geodetic Survey (NGS), conscious of the
automated Web-based differential GPS post-processing
potential contributions of the Global Positioning System
service that requires the user to input a GPS data file and
(GPS) to the geospatial community, undertook the initiative,
only a minimal amount of metadata. OPUS has evolved from
as early as the middle of the 1980s, of switching to this
a single program into a suite of programs devised for
satellite-based technology even before the full impact of
specific applications. The original member of the family is
global navigation satellite systems (GNSS) was fully
now called OPUS-S (S for static). When OPUS-S was
realized. As a result of this decision, traditional horizontal
released, it was already known that the accuracy of GPS
field operations were progressively, but expeditiously,
solutions depended on the time span of the observing
replaced by applying new satellite-based geodetic
session. For example, Eckl et al. (2001) empirically found
methodologies.
that the accuracy of derived 3D coordinates, when using
Starting in 1994, NGS decided to strengthen the realization
GPS geodetic (dual frequency) receivers in differential
of the US National Spatial Reference System by establishing
mode, could be approximated by the following simple rule
its now emblematic CORS (Continuously Operating
of thumb:
Reference Station) network (Snay and Soler 2008). So
enthusiastic was NGS’ management in promoting the

1
Chief Technical Officer, Spatial Reference System Division, National Geodetic Survey, NOS, National Oceanic and
Atmospheric Administration, 1315 East-West Hwy., Silver Spring, MD 20910. E-Mail: Tom.Soler@noaa.gov
2
Former Chief, Spatial Reference System Division, 9505 Aspenwood Court, Montgomery Village, MD 20886. E-Mail:
rssnay@aol.com
3
Geodetic Consultant, 5320 Wehawken Road, Bethesda, MD 20816. E-Mail: Charlies2@earthlink.net
4
Geodesist, Spatial Reference System Division, National Geodetic Survey, NOS, National Oceanic and Atmospheric
Administration, 1315 East-West Hwy., Silver Spring, MD 20910. E-Mail: Kevin.Choi@noaa.gov

88 CORS AND OPUS FOR ENGINEERS

 k ­ k =1.0; horizontal (north and east) This dependency of accuracy on geometry and distance
R M S error (cm ) = ® was quantified by introducing the following two variables:
T ¯k = 3.7;vertical (along elli psoid normal)
Interpolative Dilution of Precision (IDOP) and Root Mean
(1) Square Distance (RMSD). Schwarz et al. (2009) gave
where T denotes the duration of the observing session explicit equations to compute IDOP and RMSD. Without
expressed in hours and k is a free parameter in units of repeating their derivation, the equations are included here for
cm·hr0.5. completeness.
In 2006 an investigation was performed to assess the
accuracy of OPUS-S (Soler et al. 2006). The analysis Interpolative Dilution of Precision (IDOP)
showed that Eq. (1) fit generally well the GPS results when
the observing sessions spanned more than 3 hours. IDOP is a variable quantifying the geometry of the CORS
Concurrently, it was inferred that local atmospheric being used as control stations relative to the rover. It can be
conditions at the time of observation often caused determined using the expression:
discrepancies when the observation window was less than 3
hours. The primary reason for these discrepancies was
attributed to the difficulty in fixing integers due to the R
IDOP = (2)
uncertainty introduced by tropospheric refraction. However, Q
it should be emphasized that if the observer collects more
where,
than 4 hours of data, Eq. (1) gives an excellent estimate of
the achievable RMS error under ideal conditions.
To shorten the time spent in the field, NGS developed a R = (Σei2 ) (Σni2 ) − (Σei ni ) 2 (3)
rapid static version of OPUS called OPUS-RS (Martin 2007;
Schwarz 2008). This utility uses different algorithms than and
OPUS-S and has the important particularity that besides
adapting a popular integer bias estimation software (least- 2 2 2 2
Q = mR + 2( Σei )( Σni )( Σei ni ) − ( Σei ) ( Σni ) − ( Σni ) ( Σei )
squares ambiguity decorrelation: LAMBDA) also
interpolates/extrapolates for ionospheric and tropospheric (4)
conditions at the rover (Schwarz 2008; Schwarz et al. 2009).
These are the major factors making OPUS-RS precise when In the above equations m is the total number of participating
using a minimum of 15 minutes of data in day-to-day stations ( 3 ≤ m ≤ 9 ) and i = 1,2,…,m. As it can be seen,
surveying applications (Lazio 2007; Lazio 2010). R / Q is a unitless quantity.
the mathematical expression
This paper presents new enhancements made to estimate
expected OPUS-RS accuracies superseding previously According to Equations (3) and (4) to compute the IDOP
reported results (Schwarz et al. 2009). OPUS-RS limits of each solution the location of each CORS control station
distances from the rover to the CORS control stations to be (ei , ni ) with respect to the rover is required. These values
less than 250 km. A maximum of nine and a minimum of are calculated on a local geodetic horizon plane following
three CORS control stations may be involved in any OPUS- the standard formulation:
RS solution. Furthermore, as explained later, the accuracy of
OPUS-RS results depends on the local geometry of the
CORS network and the distances from the rover to the ­e ½ ­dx ½
° ° ° °
individual CORS, used as control in the OPUS-RS solution. ®n ¾ = [ℜ] ®dy ¾ (5)
°u ° ° °
Background ¯ ¿i ¯ dz ¿i
Eckl et al. (2001) demonstrated that the accuracy of the The rotation matrix of the transformation from the local
coordinates computed with OPUS-S is independent of the terrestrial (global) frame to the local geodetic frame is a
CORS geometry and the distances from the rover to the three function of the approximate curvilinear coordinates of the
CORS control stations. As mentioned above, the main
variable affecting OPUS-S accuracy is the time span of the rover (λROVER , φROVER ) , and can be expressed by the well-
observations, and this accuracy can be easily approximated known matrix
by using Eq. (1). By contrast, the accuracy of the
coordinates computed with OPUS-RS depend on the spatial ª − sin λ cos λ 0 º
[ℜ] = «« − sin φ cos λ − sin φ sin λ cos φ »»
distribution of the CORS used to compute the solution. This
dependency arises because OPUS-RS uses GPS data from (6)
CORS located near the rover to estimate the atmospheric «¬ cos φ cos λ cos φ sin λ sin φ »¼ ROVER
conditions (ionosphere and troposphere) at these CORS, and
then this utility interpolates (or extrapolates) these
atmospheric conditions to predict corresponding atmospheric The right-hand column vector in Eq. (5) is given by:
conditions at the rover.

CORS AND OPUS FOR ENGINEERS 89

­ dx ½ ­ xi (CORS ) − xROVER ½
° ° ° ° other residual random errors not fully addressed by  and 
®dy ¾ = ® yi (CORS ) − yROVER ¾ (7)
° dz ° ° z ° multipath, etc.).
¯ ¿i ¯ i (CORS ) − z ROVER ¿
where (x, y, z) denotes a 3-dimensional Earth-centered-
Earth-fixed reference frame whose z-axis is directed towards
the conventional terrestrial pole (CTP) as defined by the
International Earth Rotation and Reference System Service
(IERS). The x-axis passes through the point of zero
longitude (approximately on the Greenwich meridian) as
defined by the IERS. The y-axis forms a right-handed
coordinate frame with the x- and z-axis.
Therefore, IDOP values can be computed at the rover’s
location by using Eq. (2) from the known coordinates of the
CORS control stations and the approximate spatial terrestrial
coordinates of the rover as may be computed e.g. by
differential pseudoranges.
Root Mean Square Distance (RMSD)
RMSD is a variable quantifying the collection of distances
from the rover to the CORS control stations. It is computed
by implementing the formula:
n CORS.
¦d i
2 We then compared the various estimates for the ITRF2000
RMSD = i
(8)
m
where di is the horizontal distance between rover and the i-th
reference station, namely:
di = ei2 + ni2 (9)
Using the parameters IDOP and RMSD as defined above,
Schwarz et al. (2009) empirically determined the expected
value of the standard error of an OPUS-RS session (in each
of three dimensions: north, east and up) according to the
formula:
σ ( IDOP, RMSD ) = (α ⋅ IDOP ) 2 + ( β ⋅ RMSD ) 2
(10)
where  and  are constants. Here, the term ·IDOP
quantifies the random error due to linear interpolation and
the term ·RMSD approximates the systematic bias due to
the non-linearity of the atmospheric delay as a function of ei
and ni. The values of  and  were originally determined
through a least-squares procedure that used the results (n,
e, u, IDOP, and RMSD) of a set of OPUS-RS solutions at
all CORS stations (see Schwarz et al. 2009).
However, new recent investigations that will be detailed in
the following section showed that a better fit of the data can
be obtained by extending the number of constants to three,
90 CORS AND OPUS FOR ENGINEERS
that is, incorporating a new term written as  that will absorb
(e.g. errors present in the CORS coordinates, errors due to
New equation to estimate OPUS-RS accuracy
Following the same line of reasoning as in the investigation
described by Schwarz et al. (2009), we selected each CORS
located in the United States to serve as a simulated rover.
We assumed that the “true” positional coordinates of these
rover-CORS are provided by their NGS-adopted ITRF2000
values at epoch 1997.00 (= 0h GPS time on January 1, 1997),
as posted at <http://www.ngs.noaa.gov/CORS/coordinates>.
For each rover-CORS, we selected 15 minutes of data
(17:45-18:00 UTC) observed during the 10th day for each of
seven consecutive months (Oct., Nov., and Dec. 2007; Jan.,
Feb., March, and April, 2008). For each 15-minute data set,
we used OPUS-RS to compute positional coordinates for the
rover-CORS. As is the case with OPUS-S, OPUS-RS
computes ITRF2000 positional coordinates at the mean
epoch of the observational window, denoted t. Consequently,
before comparing results, it was necessary to transform these
coordinates from epoch t to the common epoch of 1997.00
by using the NGS-adopted 3-D velocities (available at the
same coordinates web site mentioned above) for the rover-
positional coordinates of the rover-CORS solutions with
their “true” coordinates. The corresponding coordinate
differences (“residuals”) were transformed from a global
Earth-center-Earth-fixed reference frame to the local horizon
frame centered at the associated rover-CORS and expressed
in the north (n), east (e), and up (u) dimensions. (Note that
the up dimension corresponds to ellipsoid height.) The
transformed differences were then tagged with the IDOP
value and the RMSD from the rover for the reference
stations involved in the associated solution.
From the 7 days of data, and 783 unique CORS treated as
rovers, we obtained a total of 4,552 OPUS-RS solutions. A
successful solution requires that OPUS-RS find a minimum
of three other CORS, located within 250 km of the rover-
CORS, each with good quality data. The differences between
the “true” coordinates and the OPUS-RS results were
partitioned into bins for each of the following IDOP
intervals: 0.3-0.4; 0.4-0.5, …,1.9-2.0. We rejected a
particular solution if a horizontal-component (north and/or
east) of the difference exceeded 10 cm. The statistics for the
north-component differ insignificantly from those for the
east-component. An OPUS-RS solution was also rejected if
the up-component exceeded 30 cm. Note that according to
Eq. (1), the standard deviations for the up-component are
about three times larger than the corresponding standard
deviations for each horizontal component (north and east).
Most of these OPUS-RS solutions have IDOP values
between 0.3 and 1.0.
We then further partitioned the solutions into bins defined
both by IDOP intervals, as before, and the following RMSD
intervals: 0 – 50km, 50 – 100km, 100 – 150km, 150 –
200km, and 200 – 250km. Similarly, we computed the
standard deviations of the east-component differences for
each such bin. Again, the standard deviations for the north-
component of the differences differ insignificantly from
those for the east component. We decided that at least 80
OPUS-RS solutions are required to yield a sufficiently
reliable estimate of the standard deviation for the
corresponding differences within a bin.
Using only the standard deviations for those bins where the
sample size exceeded 80, we then estimated values for , 
and  in the following equation to quantify (IDOP, RMSD):

σ ( IDOP , RMSD ) = (α ⋅ IDOP ) + ( β ⋅ RMSD ) + γ

2 2 2

(11)

Values for  and  and  were estimated for the vertical (or
up) component and for each value of T ( = 15 minutes, 1
hour, and 4 hours), yielding the results of Table 1.
Similarly, values for  and  and  were estimated for the
horizontal using both results for the north component and
those for the east component, combined. Table 1 also shows
corresponding values for  and  which were estimated
using Eq. (10). In this table, the numbers appearing in
parentheses represent 1-sigma uncertainties associated with
corresponding estimates of  ,  and . In all but one case,
the estimate for  differs significantly from zero at the 95%
confidence level; that is, only for the vertical component
with T = 4 hours, is the estimate of  statistically equivalent
to zero in value.
The rightmost column of Table 1 contains the weighted
RMS (WRMS) residual defined by the equation
¦p j ⋅ (σ j − s j ) 2
WRMS residual =
j
¦p j (12)
j T = 15 minutes, the value of the vertical WRMS residual is
where j denotes the standard error computed for bin j
sj denotes the standard error predicted for bin j (using
either Eq. (10) or Eq. (11)), and
pj denotes the number of OPUS-RS solutions in bin j.
The summations in Eq. (12) are performed over the set of
all bins for which pj is greater than 80.
For each value of T (15 minutes, 1 hour and 4 hours) the
value of the horizontal WRMS residual is about 0.1 cm,
implying that Eq. (11) can predict the horizontal accuracy of
OPUS-RS results to within about 0.2 cm, on average, with
95% confidence for a “coherent” sample containing more
than 80 GPS data sets. Here, we consider a sample to be
coherent, if all of the data sets in the sample have similar
values for IDOP and RMSD.
Fig. 1.Expected vertical and horizontal standard errors,
achievable with OPUS-RS, as a function of RMSD for data
spans of 15 minutes, 1 hour and 4 hours and IDOP value of
0.45.
For T = 1 hour or T = 4 hours, the value of the vertical
WRMS residual is about 0.25 cm, implying that Eq. (11) can
predict the vertical accuracy of OPUS-RS results to within
about 0.5 cm, on average, with 95% confidence for a
coherent sample containing more than 80 GPS data sets.
For T = 1 hour or T = 4 hours, the value of the vertical
WRMS residual is about 0.25 cm, implying that Eq. (11)
can predict the vertical accuracy of OPUS-RS results to
within about 0.5 cm, on average, with 95% confidence for a
coherent sample containing more than 80 GPS data sets. For
about 0.4 cm, implying that Eq. (11) can predict the vertical
accuracy of OPUS-RS results to within about 0.8 cm, on
average, with 95% confidence for a coherent sample
containing more than 80 GPS data sets. The larger vertical
WRMS residual for T = 15 minutes, as compared to the
vertical WRMS residual for T = 1 hour and that for T = 4
hours, is likely due to the influence of both satellite
geometry and multipath on the OPUS-RS solutions. That is,
for the longer data sets of 1-hour and 4-hours duration, the
variability in satellite geometry and multipath will average
out better over the total data span than will the variability of
these quantities over a 15-minute data span. Thus, to
improve upon Eq. (11) for T = 15 minutes, it may be critical
to consider the dependency of OPUS-RS accuracy on
satellite geometry and/or multipath.
Figure 1 is based on the empirical results which led to the
parameters estimated in Table 1. This figure shows the
variation in horizontal standard error as a function of RMSD
for the three chosen values of T (15 minutes, 1 hour and 4
hours) and for IDOP = 0.45. This figure also shows the
variation in the vertical standard error under the same

CORS AND OPUS FOR ENGINEERS 91

Table .1 Comparison of the values of the constants in Equations (10) and (11) [bold] for different OPUS-RS session times
along the ellipsoid height and horizontal components, respectively. Numbers in parentheses are 1-sigma uncertainties.

   Weighted
RMS residual
cm ppm cm
cm

15-minute vertical 6.34 (0.62) 0.129 (0.031) 1.52 (0.57) 0.41

15-minute vertical 6.69 (0.40) 0.151 (0.027) 0.43

15-minute horizontal 1.78 (0.13) 0.043 (0.006) 0.31 (0.15) 0.13

15-minute horizontal 1.82 (0.09) 0.049 (0.005) 0.13

1-hour vertical 2.47 (0.61) 0.115 (0.013) 1.36 (0.24) 0.22

1-hour vertical 3.63 (0.34) 0.127 (0.014) 0.29

1-hour horizontal 0.50 (0.17) 0.023 (0.004) 0.55 (0.04) 0.07

1-hour horizontal 1.18 (0.09) 0.031 (0.004) 0.12

4-hour vertical 3.12 (0.46) 0.095(0.013) 0.71 (0.41) 0.23

4-hour vertical 3.43 (0.26) 0.098 (0.012) 0.24

4-hour horizontal 0.59 (0.16) 0.021 (0.004) 0.49 (0.04) 0.08

4-hour horizontal 1.14 (0.08) 0.028 (0.004) 0.11

circumstances. Note that the 4-hour solutions are only
slightly more accurate than the 1-hour solutions. horizontal
standard errors. Indeed, for the 4-hour solutions are
essentially indistinguishable from horizontal standard errors
for the 1-hour solutions.
Also, once more, note that the standard errors for the up
component are about 3.6 times larger than those for either
the east component or the north component. These empirical
results corroborate similar findings published by Eckl et al.
(2001) who used a completely different GPS processing
engine, namely, the PAGES software (Schenewerk and Hilla
1999).
Expected standard errors using OPUS-RS
In order to graphically visualize the expected accuracy of
OPUS-RS as a function of the current distribution of stations
in the CORS network, a simulation was undertaken. We
squares). Figure 2 depicts the estimated values of the
standard errors in the vertical dimension computed using Eq.
(11) and the values of  , , and  from Table 1 for T = 15
minutes using these values for IDOP and RMSD. It is
immediately evident from this map that OPUS-RS can
provide coordinates that are accurate to a few centimeters
only in some area. In particular, due to sparseness of the
computed the values of IDOP and RMSD at assumed rovers
located at the intersections of a rectangular grid, spanning
the United States, having a 0.2º × 0.2º spacing ( ~ 22km ×
22km). Figure 2 depicts the estimated values of the standard
errors in the vertical dimension computed using Eq. (11) and
the values of  , , and  from Table 1 for T = 15 minutes
using these values for IDOP and RMSD. It is immediately
evident from this map that OPUS-RS can provide
coordinates that are accurate to a few centimeters only in
some area. In particular, due to sparseness of the CORS
network, regions of the Dakotas and northern Minnesota are
outside the range of accurate OPUS-RS solutions. Clearly,
not enough CORS are located within the required 250-km
range in these regions. Other smaller areas where OPUS-RS
may give poor results are also visible in this figure. Of
particular significance are the coastal zones where, even
with the presence of nearby CORS, an accurate OPUS-RS
solution cannot be obtained because the CORS
CORS network, regions of the Dakotas and northern
Minnesota are outside the range of accurate OPUS-RS
solutions. Clearly, not enough CORS are located within the
required 250-km range in these regions. Other smaller areas
where OPUS-RS may give poor results are also visible in
this figure. Of particular significance are the coastal zones
where, even with the presence of nearby CORS, an accurate

92 CORS AND OPUS FOR ENGINEERS

Fig. 2. Map showing expected standard errors in ellipsoid height obtainable with 15 minutes of GPS data using OPUS-RS for
August 10, 2010. Dots represent available CORS (see http://www.ngs.noaa.gov/OPUSI/Plots/Gmap/OPUSRS_sigmap.shtml)

OPUS-RS solution cannot be obtained because the CORS How to use the map
are located all to one side of a would be rover, necessitating
• Use Google's map toolkit (upper left) to zoom and
extrapolation, rather than interpolation, of predicted
pan the map to your location. Use "opacity" to
atmospheric effects. As expected, OPUS-RS yields good
control the visibility of the map layer.
vertical standard errors (2cm  h  3cm) in those regions
possessing dense CORS coverage (Ohio, Michigan, etc.). • Use the map selectors to choose, based upon your
Recently, NGS created an interactive web-based map
coordinate axis (vertical or horizontal) and
(<http://www.ngs.noaa.gov/OPUSI/Plots/Gmap/OPUSRS_si observation time span (15- or 60-minutes).
gmap.shtml>) enabling its users with the ability to estimate
the standard errors of the results based on the geometry and • Click anywhere within the map; a discrete accuracy
the distance from an assumed rover to the closest (3 to 9) estimate will appear.
CORS (See Fig. 3). The software computes IDOP and
RMSD at each node and computes the expected horizontal • Drag the resulting point, or click again to see
and vertical standard errors at the rover location. When a site accuracy at other locations.
has more than one CORS antenna (as in the case of an
NDGPS site), only the primary antenna is used in the • This map is optimized for the Firefox browser.
simulation. Internet Explorer works too, but more slowly.
The user can click on any point on the map to obtain the
expected standard error at that point according to the What the map shows
selected options. The software can create as many points as
OPUS-RS depends upon a relatively dense and well
desired and they are draggable, so that it is possible to adjust
distributed CORS network to accurately resolve the rover's
the point’s location on the fly. Another option allows the
coordinates. We have estimated the standard errors
user to directly enter the horizontal coordinates of the
obtainable with OPUS-RS for any location by analyzing the
rover’s hypothetical location.
surrounding CORS geometry and distance. These estimated
standard errors are shown on the map as a color overlay.

CORS AND OPUS FOR ENGINEERS 93

 Fig. 3. Interactive web-based application, OPUS-RS Accuracy and Availability

located within 250 km of them. OPUS-RS will not

• The map is updated weekly, using the latest list of
operational CORS.
• Four different overlays are provided, two showing
estimated horizontal standard errors (one for 15-
minute observing sessions and the other for 60-
minute observing sessions). The other two overlays
show estimated vertical standard errors for 15- and
60-minute observing sessions, respectively.
• Geographic areas, located outside the color overlay,
encompass points that have less than three CORS
attempt a solution here.
Color overlays are projected into the Google Map using its
Application Programming Interface (API) (Check the web
site <http://code.google.com/apis/maps/>.) Users can zoom
and pan the map to any location in the world using Google
Map's control (upper left corner of the map). This
interactive map covers the whole Globe since OPUS-RS is
available in some non-US territories such as Canada, Iraq,
Mexico, Central America, Suriname, and Benin.
The user can retrieve accuracy at any location because
the utility interpolates corresponding results from the
four adjacent grid points using simple Inverse Distance

94 CORS AND OPUS FOR ENGINEERS

 1 2
D1
D2
A 30
D4
D3
3 4
Fig. 4. Schematic diagram of the Inverse Distance
Weighting method
Weighting method (Shepard 1968). In Figure 4, the number
in the black dots represent each grid so that,
4 wη Sη
SA = ¦ 4
(13)
η =1
¦
η
wη
=1
where the weighting factor that inversely correlates with the
distance is wη = 1/ Dηp and Dη is distance between each
adjacent grid point and the target point, A, and the power
parameter, p, is set to 2 for reduced smoothing in this
particular application. Sη is the standard error at location 
and S A is the interpolated value at A. In special cases
when Dη = 0 , Sη becomes S A .
If one clicks any location, a marker will be created and the
expected accuracy at the location will appear by requesting
the interpolated value to the server asynchronously in the
background using AJAX (Asynchronous JavaScript and
XML) technique. One can create more than one marker to
compare with each other. Also, the user can specify the
latitude and longitude for a marker and the accuracy at that
location will be shown. The marker can be dragged to adjust
the location and can be removed by right-clicking. Detailed
information about the interactive map service is available at
<http://www.ngs.noaa.gov/OPUS/Plots/Gmap/instructions.s
html>.
Preliminary comparison between OPUS-RS and
OPUS-S
In order to directly compare OPUS-S results with OPUS-RS
results, we revisited a previous experiment that investigated
the accuracies of OPUS-S results. Using GPS data from June
2004, we computed numerous OPUS-S solutions at five
stations distributed across the tectonically stable region of
the Conterminous United States (CONUS). The results were
CORS AND OPUS FOR ENGINEERS
Table .2 Number of OPUS-RS solutions used
T (minutes) GODE MIA3 TCUN
15 1777 635 1301
932 428 718
60 440 265 415
120 221 160 235
published in (Soler et al. 2006). We selected only three of
these five stations for comparing OPUS-S results with
corresponding OPUS-RS results: station GODE located in
Maryland about 10 km northeast of Washington, DC.,
because of the profusion of nearby CORS sites; station
MIA3 located near Miami, Florida, on account of the humid
atmospheric conditions experienced during June 2004; and
station TCUN located in northwest New Mexico because of
its dry climate. The local weather at GODE typically lies in
between the two extremes experienced at MIA3 and TCUN.
A series of tests were performed by obtaining OPUS-RS
solutions of several GPS data sets observed, as originally
done for OPUS-S, during the month of June 2004. For each
of these three CORS, we selected observing sessions of four
different durations: T = 15 minutes, T = 30 minutes, T = 60
minutes, and T = 120 minutes. Previously, for the OPUS-S
study, session durations of 1, 2, 3, and 4 hours were used.
Consequently, only the results of 1- and 2-hour sessions may
be directly compared. However, it was known in advance
that the results of OPUS-S deteriorate significantly when the
observations span less than 2 hours.
The intent of this new investigation was to quantify the
accuracy of OPUS-RS for short observation time intervals
(15 and 30 minutes) at the selected sites, so diverse with
respect to their meteorological environment. Furthermore,
due to their location in different areas of the United States,
the OPUS-RS results are also affected by differences in
IDOP and RMSD. For example, station GODE represents a
station with a low IDOP (= ~0.35) and a low RMSD (= 98
km). As compared to GODE, MIA3 has a higher IDOP (=
~0.65) and a higher RMSD (= 155 km). Finally, as
compared to GODE, TCUN also has a higher IDOP (=
~0.55) and a higher RMSD (= 188 km).
Table 2 presents the number of solutions used for each
CORS and each value of T.
Table 3 tabulates the standard errors obtained by
comparing the computed coordinates (for each OPUS-RS
solution) with “true” published CORS coordinates referred
to the ITRF2000 frame at epoch 1997.0. That is the OPUS-
RS-generated ITRF2000 coordinates (determined at the
mean epoch of observation) were transformed to ITRF2000
coordinates at the epoch of the adopted CORS values using
NGS-published velocities.
95
Table .3 Standard errors (cm) along the n, e and u components for each of four different observing session durations and at each
of three different CORS (GODE, MIA3, and TCUN) to compare results of OPUS-S with those of OPUS-RS.

GODE GODE GODE MIA3 MIA3 MIA3 TCUN TCUN TCUN PRED.
Observing
OPUS-S OPUS-RS OPUS-RS OPUS-S OPUS-RS OPUS-RS OPUS-S OPUS-RS OPUS-RS Eq. (1)
Session
Duration actual actual Eq. (11) actual actual Eq. (11) actual actual Eq. (11)

minutes

15 n 0.75 0.81 1.06 1.37 0.68 1.31 2.00

15 e 0.74 0.81 1.36 1.37 1.56 1.31 2.00

15 u 3.03 2.97 6.98 4.83 4.66 4.51 7.40

30 n 0.68 1.02 0.60 1.41

30 e 0.80 1.29 1.39 1.41

30 u 2.82 6.85 3.63 5.23

60 n 1.92 0.55 0.62 2.57 0.83 0.73 1.61 0.53 0.75 1.00

60 e 5.28 0.64 0.62 8.10 1.34 0.73 5.21 1.26 0.75 1.00

60 u 7.31 2.34 1.97 12.63 6.74 2.76 6.91 3.31 2.89 3.70

120 n 0.71 0.63 1.07 0.67 0.55 0.44 0.71

120 e 1.63 0.74 3.62 1.28 1.52 1.16 0.71

120 u 2.70 2.85 5.89 5.43 2.47 1.88 2.62

Table 3 also tabulates the results originally obtained by
processing the same GPS data with OPUS-S for T = 60
minutes and for T = 120 minutes, as previously published
by Soler et al. (2006).
Table 3 presents predicted standard errors for OPUS-RS
based on the empirical relationship expressed in equation
(11). It should be clarified here that these results were
obtained based on the geometry and distances (IDOP and
RMSD) of the CORS sites available in June 2004 and not
interactively through the map currently available on the
Internet.
The right-most column of Table 3 also presents, for each
value of T, the predicted standard error using the simplified
rule-of-thumb as expressed by Eq. (1).
It is important to clarify that possible errors in the adopted
coordinates of the CORS antenna reference points (ARP) at
each station will not affect the comparison between OPUS-S
and OPUS-RS. The “true” coordinates used at the three
CORS-rover stations (MIA3, TCUN and GODE) and the
coordinates at the fixed surrounding control stations used by
OPUS-S and OPUS-RS were identical. Thus, assuming that
some of the coordinates at these CORS sites were in error,
the same systematic bias will equally affect the results of
OPUS-S and OPUS-RS.
However, errors in published CORS coordinates and
velocities, if any, may contaminate the results of this and
other tests that we have performed to determine the
individual accuracies of OPUS-RS and/or OPUS-S. The
significance of these errors is difficult to ascertain although
with all probability they are random and may affect,
principally, the vertical component which is the most
vulnerable to atmospheric conditions. One alternative for the
OPUS user to circumvent the weakening of the accuracy of
the results is to select stations not showing biases in the plots
of estimated CORS coordinates for each of the past 60 days.
These plots are posted at <http://www.ngs.noaa.gov/CORS/
>. It should be noted that NGS has undertaken a project to
rigorously recompute CORS coordinates and velocities
(Rohde et al. 2009). The new values should become
available by the fall of 2010, and they should greatly
improve all OPUS results.

96 CORS AND OPUS FOR ENGINEERS

Fig. 5. OPUS-RS standard errors resulting from actual
observations (symbols connected by lines) and predicted
values (isolated symbols) obtained by using Eq. (11).
Fig. 6. OPUS-RS standard errors resulting from actual
observations (symbols connected by lines) and predicted
values (isolated symbols) obtained by using Eq. (11).
To facilitate a better understanding of Table 3, the same
data is graphically displayed in several figures (5 to 10). The
standard errors of OPUS-RS for each station along the three
components as a function of the observing-session duration
in minutes are given in the first three figures. The isolated
symbols on each figure are the predicted values using Eq.
(11) with the values of ,  and  of Table 1 and the IDOP
and RMSD corresponding to the distribution of the
active CORS network at the end of June 2004. The symbols
CORS AND OPUS FOR ENGINEERS
Fig. 7. OPUS-RS standard errors resulting from actual
observations (symbols connected by lines) and predicted
values (isolated symbols) obtained by using Eq. (11).
connected by lines are the actual results obtained from all
OPUS-RS solutions for each session time span. Figure 5,
presents the standard errors for the north-south component.
Notice that for an observation span of 15 minutes the actual
OPUS-RS accuracies are better than the predicted values
using Eq. (11) for the three tested stations. Figure 6 plots the
standard errors for the east-west component. Comparing the
results of Figure 5 with those of Figure 6 it appears that the
standard errors along the north-south component are
generally smaller than corresponding standard errors along
the east-west direction. Although results from a sample size
of 3 stations are limited, it may be said that the standard
errors along the east-west component for stations with high
IDOP (> 0.55), high RMSD (> 155km) and average
meteorological conditions are about 0.5 times smaller than
that for stations that experience extreme weather situations
(MIA3 and TCUN). Another remark that can be made is that
when the observational span is increased from 15 minutes to
2 hours, the standard errors of the OPUS-RS solutions along
the north-south component decrease at a larger rate than
their counterparts along the east-west direction. In fact, the
standard errors along the east-west component practically do
not change when the observational span is increased from 1
to 2 hours. Finally, Figure 7 shows OPUS-RS ellipsoid
height standard errors. It should be pointed out that due to
the meteorological conditions in MIA3 in the month of June
(extremely humid days) the actual accuracies obtained by
OPUS-RS are worst by several centimeters than their
corresponding empirically predicted values.
The same points and symbols depicted in Figures 5, 6, and
7 are re-plotted in Figures 8, 9, and 10 except that now the
scales along the axes of the standard error and observing-
session duration are different to the ones previously used.
This change of scale was introduced with the intention of
97
Fig. 8. OPUS-RS RS standard errors resulting from actual
observations compared with OPUS-S standard errors (from
the same observations when T = 60 min. and 120 min.). The
curve corresponds to predicted standard errors obtained by
using Eq. (1)
Fig. 9. OPUS-RS RS standard errors resulting from actual
observations compared with OPUS-S standard errors (from
the same observations when T = 60 min. and 120 min). The
curve corresponds to the rule-of-thumb prediction estimated
using Eq. (1)
comparing one-to-one the OPUS-RS accuracies of Figures.
5, 6, and 7 with the OPUS-S accuracies previously published
in (Soler et al. 2006) and reproduced in Table 3. These last
three figures also include a curve that corresponds to the
empirical rule-of-thumb embodied by Eq. (1).
A cursory review of Figs. 8, 9, and 10 reveals the
following important conclusions:
98 CORS AND OPUS FOR ENGINEERS
Fig. 10. OPUS-RS RS standard errors resulting from actual
observations compared with OPUS-S standard errors (from
the same observations when T = 60 min. and 120 min.). The
curve corresponds to predicted standard errors obtained by
using Eq. (1)
• OPUS-RS provides significantly more accurate
results than OPUS-S for T = 60 minutes (this is
likely because OPUS-S cannot reliably fix integers
when T = 60 minutes).
• OPUS-RS generally provides slightly more accurate
results than OPUS-S for T = 120 minutes. In only
one of nine cases (the up component of GODE), did
OPUS-S provide a lower standard error than OPUS-
RS (2.70 cm for OPUS-S versus 2.85 cm for
OPUS-RS).
• The empirical equations for predicting the standard
errors for OPUS-RS work rather satisfactorily
except for station MIA3. (Perhaps OPUS-RS cannot
adequately interpolate atmospheric conditions over
such long distances (RMSD = 155 km) in an
extremely humid climate.)
Conclusions
This paper presents a refinement to the study by Schwarz et
al (2009) on how the accuracy of OPUS-RS results depends
on local CORS geometry as measured by the variables of
IDOP and RMSD. For this refinement, a new parameter
was introduced into the empirical equation used to
characterize OPUS-RS accuracy. Denoted , this parameter
addresses error sources that are unrelated to local CORS
geometry. As compared to Eq. (10), the new Eq. (11) fits
better the analyzed data. This conclusion is corroborated by
the fact that the estimate for  differs significantly from zero,
at the 95% confidence level, in five out of the six cases
considered in this paper.
 As a result of adopting a new equation containing three
parameters, updated OPUS-RS accuracy maps depending on
IDOP and RSMD were developed. A series of maps showing
geographically the expected accuracy of OPUS-RS results
along the horizontal and vertical (ellipsoid height
component) were devised for GPS observing time spans of
15 minutes and 1 hour. Furthermore, to facilitate the use of
this methodology, the NGS web page contains an interactive
map. Prospective users of OPUS-RS can now determine the
expected accuracy (under typical atmospheric conditions) of
his/her survey by simply clicking on the map.
Finally, for the first time, a direct comparison between
NGS’ two independent online GPS processing services
(OPUS-S and OPUS-RS) is presented. The research
indicates that to optimize the results, OPUS-S should be
used for observing sessions longer than 2 hours while
OPUS-RS is more accurate for processing GPS sessions with
time spans between 15 minutes and 2 hours.
Future research
In the future it may be possible to improve OPUS-RS results
somewhat if OPUS-RS models the tropospheric delay as a
linear function of time as opposed to a constant function of
time. Another enhancement that could be investigated is to
give a more preponderant weight to Eq. (11) for discerning
the rejection criteria that OPUS-RS may use to reject bad
solutions at the rover location. This metric could replace any
other quality indicators as, for example reject any solution
with σ ( IDOP , RMSD ) above previously adopted toleran-
ces for the horizontal and vertical results observed with
some specified time spans. As an alternative, the solution
could be provided to the user but with a warning indicating
the values of IDOP and RMSD. The same equation could
even be used as part of the reference station selection
algorithm in such a way that the chosen stations provide the
minimum predicted σ ( IDOP , RMSD ) at the rover.
Finally, it will be interesting to know how the results of
OPUS-RS behave when observation sessions of 15 minutes
are obtained at different times of the day, or on different
days of the year. This is an area not well researched but that
may be an important element to consider before planning
surveying campaigns employing short observing sessions.
All in all, the knowledge of this interaction among time of
day, day of year, and observing session duration may be
CORS AND OPUS FOR ENGINEERS
directly applied to understand the full accuracy capabilities
of modern real time networks (RTN).
References
Eckl, M.C., Snay, R., Soler, T., Cline, M.W., and Mader,
G.L. (2001) “Accuracy of GPS-derived relative positions
as a function of interstation distance and observing-
session duration.” J. Geodesy, Berlin., 75(12), 633-640.
Lazio, P. (2007). “Constraining network adjustments to
OPUS-RS coordinate observations.” J. Surv. Eng,.
133(3), 106-113.
Lazio, P. (2010). “OPUS-RS pair points – A case study.” J.
Surv. Eng., 136(2), 91-99.
Martin, D. (2007). “Geodetic connections. OPUS-Rapid
Static.” The American Surveyor. 4(3), 44, 46-48.
Rohde, J.R., Griffiths, J., Cline, M., Dulaney, R.L., Hilla, S.,
Kass, W.G., Ray, J., Sella, G., and Snay, R.A. (2009).
“NGS2008-beta: A preliminary estimate of an update to
the America CORS velocity field.” American Geophy-
sical Union, Fall Meeting 2009, abstract #G11C-0660.
Schenewerk, M., and Hilla, S. (1999). “PAGES: Program for
Adjustment of GPS Ephemerides.” <http://www.noaa.
gov/GRD/GPS/DOC/pages/pages.html> (July 31, 2010).
Schwarz, C.R. (2008). “Heuristic weighting and data
conditioning in the National Geodetic Survey Rapid
Static GPS software.” J. Surv. Eng,. 134(3), 76-82.
Schwarz, C.R., Snay, R.A., and Soler, T. (2009). “Accuracy
assessment of the National Geodetic Survey’s OPUS-RS
utility.” GPS Solutions., 13(2), 119-132.
Shepard, D. (1968). “A two-dimensional interpolation
function for irregularly-spaced data.” In Proc. Assoc. of
Comput. Mach. Nat. Conf., doi: 10.1145/800186.
810616.
Snay, R.A., and Soler, T. (2008). “Continuously Operating
Reference Station (CORS): History, applications, and
future enhancements.” J. Surv. Eng., 134(4), 95-104.
Soler, T., Michalak, P., Weston, N.D., Snay, R.A., and
Foote, R.A. (2006). “Accuracy of OPUS solutions for 1-
to 4-h observing sessions.” GPS Solution,. 10(1), 45-55.
Weston, N.D., Soler, T., and Mader, G.L. (2007). “Web-
based solution for GPS data. NOAA OPUS.” GIM
Int.,21(4), 23-25.
99
 13
Understanding Error Messages Generated by the Rapid Static
Online Positioning User Service (OPUS-RS)
Kevin K. Choi1

Abstract: After a user submits GPS data to the Rapid-Static Online Positioning User Service (OPUS-RS), this web-based utility
emails the user a report providing either estimated coordinates for the location where the data were observed or an error message
describing why it was unable to estimate such coordinates. Error messages for the period from January 2008 to June 2010 are
examined here together with a description of each error type encountered during this 30-month period. Most of these errors are
due to violations of OPUS-RS requirements. The two most frequent error types are: (1) the GPS data spans more time than the
current 2-hour limit and (2) there are less than three CORS located within 250 km of the rover. Error counts can be reduced by
NGS making additional efforts to ensure that users are aware of the OPUS-RS instructions and rules and also by making small
changes to the software.

Author keywords: Rapid Static Online Positioning User Service; OPUS-RS; Output errors; GPS positioning; geodetic
networks

3. When an approximate position of the rover has been

Introduction
determined, OPUS-RS searches for appropriate CORS
reference sites unless the user has selected a priori
NOAA’s National Geodetic Survey (NGS) has provided the reference sites. The program searches for at least 3 and
Rapid-Static Online Positioning User Service (OPUS-RS) to
up to 9 sites inside a 250 km range and also checks if
the surveying and mapping community since January 2007 the rover resides either inside or outside but closer than
(Schwarz 2008). The primary difference between OPUS-S 50 km to the convex hull (envelope) of these reference
(Static) and OPUS-RS is the time span of the input GPS
stations.
files; OPUS-RS is designed to handle as little as 15 minutes 4. Runs Network Mode solution using only the data from
of GPS data. In order to achieve this, the ionospheric and the reference stations.
tropospheric delays must be interpolated accurately from
5. Runs a single baseline Rover Mode solution for each
nearby Continuously Operating Reference Station (CORS) reference station using its data together with the rover’s
to correctly fix integer biases. Therefore, the core software data. A combined solution involving all reference
had to be designed differently than the static version of stations and the rover is subsequently performed.
OPUS (OPUS-S). Also, some software requirements such as
the maximum number of reference sites and convex hull
checking – rover location with respect to the polygon of
reference sites – had to be treated differently. Thus, because
of the different inherent requirements, output error messages
have been introduced accordingly. Error Codes in the
6000’s are exclusively for OPUS-RS, while other code
numbers are shared with OPUS-S.
OPUS-RS has six major processing phases (Schwarz et al.
2009), and a series of quality checks is performed at each
step as follows:
1. When the user’s data set is uploaded and converted to
RINEX format, the TEQC program (Estey and
Meetens 1999) is used to determine if the file is
properly formatted.
2. The best orbit files for the period of the observing
session are retrieved from the archive. Depending upon
availability, it can be one of the following three IGS
(International GNSS Service) orbit products: precise, Fig. 1. Number of submitted observation files to OPUS-RS
rapid, or ultra-rapid. for each month from January 2008 to June 2010 (30 months).

1
Geodesist, Spatial Reference System Division, National Geodetic Survey, NOS, National Oceanic and Atmospheric
Administration, 1315 East-West Hwy., Silver Spring, MD 20910. E-Mail: Kevin.Choi@noaa.gov

100 CORS AND OPUS FOR ENGINEERS

 Statistics of OPUS-RS error messages

OPUS-RS can generate 99 different types of error messages,

but only 31 messages have been generated during the
selected 30 months. Figure 2 shows the histogram of
occurrences for each Error Code. Error codes are
categorized into four groups depending on the source of the
errors (Table 1).
• Group 1 errors are related to the input RINEX file
format. RINEX files caught in this group are also likely
to fail in other applications because they are not
correctly formatted.
• Group 2 errors are related to OPUS-RS requirements
such as dual-frequency check, data time span check,
data interval check, and so on. Currently, OPUS-RS
only accepts GPS data up to 120 minutes long and a
Fig. 2. Histogram of occurrences for each Error Code. recommended minimum of 15 minutes with 1, 2, 3, 5,
10, 15, or 30-second interval.
• Group 3 errors are related to the reference sites. For
6. Creates an OPUS-RS Solution Report and emails the example, this group includes errors generated when
output to the submitter. there are less than 3 CORS sites located within 250 km
OPUS-RS is designed to send an email to the submitter of the rover or if the rover is located more than 50 km
when the process has ended. A solution report is sent only outside the convex hull (Reference site selection criteria
when the data are successfully processed; otherwise, the described here are as of July 19, 2010).
error code with a brief description is sent. A brief 6-month’s • Group 4 errors include miscellaneous errors such as
investigation of statistics was introduced in Schwarz et al. solution quality check failure, orbit errors, and
(2009), and longer and more detailed history is shown in this unexpected internal software errors.
manuscript. The ten most frequent error messages are shown in Table 2
indicating that nine out of the top ten errors are in Groups 2
and 3. These errors comprise about 86 % of the total. The
Data most frequent error is Error Code 6007, which is generated
An error log is generated whenever the process finishes when the input data span more than 2 hours (Table 2). The
abnormally. It contains the date, time, a 4-digit error code
and a very brief description of the error. Only error logs
Table 2. Top ten frequent error codes and corresponding
generated between January 1, 2008 and June 30, 2010 (30
error group numbers.
months) are analyzed in this manuscript. A total of 73,334
unique input data/error code combinations were selected Error Occurr
after removing duplicated records. Figure 1 shows the Rank Description Group
Code ences
number of monthly submissions. The monthly occurrence 1 6007 RINEX file is too long 14186 2
rate with respect to the total monthly submissions for each 2 6014 Cannot find 3 reference 13664 3
error code was examined. stations within 250 km.
3 6029 Less than 3 reference 5454 3
sites after single baseline
Table 1. List of errors for each group. analysis.
4 6019 RINEX file is too short. 5399 2
Group Related error codes 5 6015 Convex hull check fail (> 5053 3
Description
number (Table 3) 50 km outside).
1 RINEX related errors 1010, 1013, 1015, 1032 6 1014 More than one 4876 2
caught by TEQC MARKER detected in
the RINEX.
2 Not meeting OPUS-RS 1000, 1007, 1014, 1020,
7 1007 Start and end time is not 4150 2
requirements 1021, 1022, 6007, 6019
determined in RINEX.
3 Reference sites (CORS) 1025, 1026, 1031, 6014, 8 1025 Data for the user selected 3891 3
related errors 6015, 6029, 6032, 6033 site are not available.
4 Other errors such as 1024, 3003, 6005, 6009, 9 1026 RINEX for the reference 3523 3
antenna, orbit, 6013, 6022, 6034, 6035, sites are not available
network/rover solution, 6037, 9009, 9012 yet.
and server errors 10 6005 Network solution error. 2934 4

CORS AND OPUS FOR ENGINEERS 101

 Group 1
Fig. 3. Time history of the occurrence rate of the Error
Codes related to the RINEX file caught by internal quality
check by TEQC (Group 1).
Group 2
Fig. 4. Time history of the occurrence rate of the Error
Codes related to the OPUS-RS requirements (Group 2).
fourth ranked error is also related to the input data time span:
input data span is too short (currently, less than 15 minutes).
The second and the third most frequent error codes are
related to each other: less than 3 reference sites available.
The convex hull distance check ranks fifth. The user can
examine beforehand whether or not OPUS-RS can work by
using NGS’ web-based interactive map at the URL address
http://www.ngs.noaa.gov/OPUSI/Plots/Gmap/OPUSRS_sig
map.shtml. This web site is discussed further in (Soler et al.
2010).
Error Code 1014 (6th rank) is triggered when the submitted
data were collected at more than one location. This RINEX
file can be made acceptable by cropping out all data
pertaining to more than one location. Error Code 1007 (7th
rank) is generated when it fails to obtain start and end time
of the input RINEX data. This error is usually caused by a
wrong-formatted RINEX, however, it has occasionally been
caused along with a hardware problem such as disk failure.
102 CORS AND OPUS FOR ENGINEERS
Group 3
Fig. 5. Time history of the occurrence rate of the Error
Codes related to the CORS data including data availability,
quality and geometry (Group 3).
Group 4
Fig. 6. Time history of the occurrence rate of the Error
Codes due to other causes such as antenna, orbit,
network/rover solution, and internal server errors (Group 4).
If the user specifies one or more reference stations to be
used, OPUS-RS will not attempt to use other sites when a
user-selected site is not available or fails the quality check.
The reference site will not be used when it has less than 90
% of data coverage for the duration of the input time span.
In this case, the user will receive Error Code 1026 (9th rank).
The solution errors included in 10th rank will be described in
a later section. Table 3 provides a brief description of all 31
error codes generated during the 30-month period considered
in this study.
Time series of each Error Code
Monthly averaged time history plots for each Error Code are
shown in Figure 3 through 6. Some highlights for each plot
will be briefly described in this section. Note that the
percent values on the Y-axis indicate percent of all OPUS-
 1014
RS submissions, not percent of submissions with an error
code.
Group 1:
In July 2009, Error Code 1010 (Single frequency) became
unusually high and about 230 errors were generated in 4
minutes (July 29, 2009). The main cause is not clear but
they were the RINEX files obtained in 1996 and 1997. If
this abnormality is removed, the monthly occurrence of
Error Code 1010 is fairly stable between 20 and 30 which is
~0.18 % of the total submissions. Error Code 1015
(GLONASS only data) is also occurring 10-20 times per
month although the OPUS Web clearly specifies that OPUS-
S and OPUS-RS do not currently process GLONASS data
(though plans are underway to change this). Error Code
1032 (Unable to read RINEX) has never showed up since
June 2009.
Group 2:
The most noticeable time series in this group is Error Code
6007 (data spans too much time). Before May 2009, its
occurrence was about 300 times per month, but after June
2009, the number of occurrences has more than doubled.
This is when NGS changed the limit from 4 hours to 2 hours
due to the occasional processing backlog. Also, Soler et al.
(2010) confirmed that 4-hour datasets do not improve the
standard error significantly when compared to shorter ones.
Other than that, in terms of Group 2 errors, OPUS-RS has
been very stable since Aug 2009.
Group 3:
The peak of Error Code 1026 in May-June 2010 was due to
hardware and an unexpected database failure. It is believed
that this failure also contributed to the abnormal increase of
Error Code 6014. Error Code 1025 is triggered when the
data availability of the selected reference site for the given
time span is less than 90 %. This quality check is performed
for all the candidate reference sites. Therefore, this check
can also trigger Error Code 6014 when there is no user
specified reference site AND there are only 3 candidates
available. The reasons for two peaks of Error Code 6014 in
2008 are unknown. Error Code 1031 has been deleted as a
potential error message since September 2008 because the
cooperative CORS network merged with National CORS at
that time.
Group 4:
Some modifications/enhancements were made to the
network solution routines in early 2010. Error Code 6005
had been fluctuating month by month during 2008 and 2009,
and it became more stable recently, due to the software
enhancements. In late May 2010, NGS experienced a couple
of hardware failures that caused an increased number of
Error Code 9009. Most of the errors in Group 4 occurred
less than 1 % among all total submission for each month
except for the Error Code 6005, which is an unspecified
error in the network process. This also has dropped below
0.5 % for the last 6 months of the study because OPUS-RS
scripts have been fixed to reduce the occurrence of this error.
CORS AND OPUS FOR ENGINEERS
6034
6029
6029
6019
6015
6015
6014
6014 6014
6007
6007
6005
1026
1014
1025
1020 1020
1025 1014 1007 1014
1010
1000
Fig. 7. Time history of total abort rate with breakdown of
each Error Code.
Discussion
Most of the errors in OPUS-RS that occurred during the 2.5
years of this study were due to user violations of pre-
specified OPUS-RS requirements (Group 2). The CORS
related errors (Group 3) can be considered as a subset of
Group 2 in a broad sense, because the number of reference
sites and geometry constraints are also a part of OPUS-RS
requirements.
There are two ways to improve the success rate of OPUS-
RS: the first approach is for NGS to make better efforts to
educate users on how to avoid the potential unchecked
uploading restrictions. Figure 7 shows a big picture of the
total errors and the rate of occurrence for each Error Code.
Until May 2009, Error Code 6014 has been the main source
of failure of OPUS-RS and then the rate decreased and
stabilized except for a few peaks due to impromptu hardware
failures. Since November 2009, the occurrence rate of Error
Code 6014 dropped below 2 % (Figure 5) and it is believed
to be correlated with the availability of the weekly OPUS-
RS map (Soler et al., 2010). Error Code 6007 has become
more prominent since May 2009 when NGS changed the
data length requirement from four to two hours. NGS is
engaged in many new efforts to get the word out to its user
base (aside from the weekly CORS email), such as
improving the NGS web page, and starting an electronic
mailing list. It is hoped through these efforts that user error
in OPUS-RS will be reduced.
The second approach for decreasing the number of errors
is to make the software more robust. For example, if OPUS-
RS can automatically crop the input data to meet the current
requirement, Error Code 6007 will become eventually
obsolete. Also Error Code 6014 can be reduced if we design
a better algorithm to cover a larger area. If we could
eliminate these top two Error Codes, the number of aborted
solutions could be reduced by 38 % resulting in dropping the
total failure rate from 22 % to 13 %.
103
 Table 3. Error codes generated for 2.5 years and the description for each code.
Error Occurr Problems
Error messages
Code -ences (Group)
You do not have access to use OPUS globally...
The OPUS positioning software is only available for use for datasets taken/recorded in one
of the areas determined to be valid for OPUS and described in
http://www.ngs.noaa.gov/OPUS/Areas.html. A solution will not be performed on the OPUS-RS
1000 731 dataset submitted. requirements
Another possible suggestion is to check the XYZ position in the RINEX header file - it (2)
should be within 1 kilometer of the true position. Also, we could be experiencing network
problems - try resubmitting your data on the next business day after checking the
possibilities above.
The RINEX dataset submitted to OPUS failed to pass an initial test for one or more of the
following reasons. OPUS-RS
1007 4150 1. The data only contained values for a single frequency. requirements
2. RINEX file not formatted correctly. (2)
3. One of the lines in the RINEX file is over 80 characters in length.
The RINEX dataset submitted to OPUS only contained data for a single frequency. Dual RINEX
1010 847
frequency data is needed for processing. (TEQC) (1)
The RINEX data submitted to OPUS may have been recorded in kinematic mode. OPUS RINEX
1013 33
cannot process this data set or datasets that behave like those recorded in kinematic mode. (TEQC) (1)
The RINEX data submitted to OPUS contains data taken from more than one location.
OPUS-RS
This can be verified by opening up your RINEX file and searching for "MARKER".
1014 4876 requirements
OPUS will only process data taken from one location. Try separating the data into
(2)
individual files and then re-submit the data.
The RINEX data file that was submitted contained GLONASS observables. Currently
OPUS does not support datasets with GLONASS data. Please re-submit the dataset RINEX
1015 236
without the GLONASS data. See line 1 of the RINEX version of your file to see if the (TEQC) (1)
constellation type is correct.
OPUS aborted on the submitted data file for one or more of the following reasons. OPUS
cannot process the data file.
1. Collection interval of the data file was not one of the allowed rates. The intervals that
are accepted are 1,2,3,5,10,15,30 seconds.
2. The time of each epoch is offset from one of the above intervals. The seconds epoch
OPUS-RS
field must coincide with one of the above rates.
1020 2060 requirements
3. The data file may have been collected in kinematic mode. OPUS does not process
(2)
kinematic data files.
4. Note: OPUS processes data every 30 seconds, and 2+ hour files collected at the 1
second rate should be changed to 30 seconds.
5. If your data were collected today or yesterday, we may not have sufficient CORS data -
try resubmitting your file tomorrow.
OPUS-RS
The year and day-of-year could not be determined from the submitted data set. The data
1021 255 requirements
set may be corrupt. OPUS cannot continue the processing.
(2)
OPUS-RS
The time span of the submitted dataset spans more than two days. OPUS will only process
1022 1 requirements
data taken within two consecutive days.
(2)
WARNING! You have selected an antenna for which NGS does not have calibration
Antenna
1024 19 information. Your file will be processed as if you had selected NONE from the antenna
model (4)
drop down box.
One of the CORS sites that was selected from the pull-down menu is not available for the
User selected
1025 3891 day in question or it did not meet the quality control requirements. Please select another
CORS site (3)
CORS site to be included in the processing and re-submit the data.
Data from the three National CORS or IGS sites used to process your submitted dataset
CORS data
1026 3523 have not been collected from the field or are currently not available. Please re-submit
delay (3)
your RINEX data again after 24 hours.
(Table continued on next page)

104 CORS AND OPUS FOR ENGINEERS

(Continued from previous page)
Error Occurr Problems
Error messages
Code -ences (Group)
OPUS cannot retrieve information about one or more user selected cooperative CORS
sites from the NGS data base. The data base server may be down, the information stored User selected
1031 28
there may be incorrect, or it may not contain a position for the selected cooperative CORS CORS site (3)
stations which is valid for the date of your data.
OPUS could not read your RINEX file correctly. Please correct the error(s) on the line
below and re-submit your RINEX file to OPUS. Most errors are due to the format of the
line. Try submitting raw data if you submitted RINEX data on your previous submission, RINEX
1032 754
and if your files are Trimble files, try using the latest version of DAT2RIN(W), 3.5, which (TEQC) (1)
can be downloaded from the Trimble page
http://www.trimble.com/support_trl.asp?Nav=Collection-3621 .
An IGS orbit (precise, rapid or ultra-rapid) was not available at the time of data
3003 612 Orbit (4)
submission. Please re-submit the data in a day or two.
Network
6005 2934 OPUS-RS has stopped with an unspecified error in RSGPS network solution.
solution (4)
Your RINEX file is too long for OPUS-RS. Because of the troposphere model used, the
OPUS-RS
current version of OPUS-RS is limited to MAX_TIME hours. In most cases, the ultimate
6007 14186 requirements
accuracy can be obtained with data sets of 15 to 30 minutes. You may use a utility such as
(2)
TEQC to trim your data set or you may use the original OPUS.
The OPUS-RS solution for the position of the rover has failed to converge after 5 Solution
6009 597 iterations. This could be due to especially noisy data (among other reasons). If you really quality check
need a position for this station, you might try another data set. (4)
OPUS-RS is not able to find a solution for your data set. OPUS-RS has stopped with the Rover
6013 218
following message(s) in RSGPS rover solution: solution (4)
OPUS-RS cannot find three reference stations within 250 km of your position and with
suitable data for use with your dataset. OPUS-RS requires at least three reference stations
CORS
6014 13664 and is currently limited to a maximum distance of 250 km. If you wish to use reference
geometry (3)
stations more than 250 km from your rover station, you may use the User Selected Base
Station feature on the OPUS Options page.
OPUS-RS will not attempt a solution because the submitted data was collected at a
CORS
6015 5053 location that is more than 50 km outside of the area spanned by the set of CORS sites
geometry (3)
whose GPS data OPUS-RS would use in processing the submitted data.
OPUS-RS
Your input dataset is too short. OPUS-RS will not attempt a solution with less than 15
6019 5399 requirements
minutes of data.
(2)
OPUS-RS has stopped with an unexplained computer failure. Please try submitting your Network
6022 288
file again. If the problem persists, please notify the NGS staff at ngs.opus@noaa.gov. solution (4)
After the single baseline analysis, fewer than 3 useable reference stations remain. CORS data
6029 5454
Aborting. quality (3)
User selected
6032 330 User selected station SSSS fails the tropo test and cannot be used. Aborting.
CORS site (3)
User selected
6033 611 User selected station SSSS fails the single baseline test and cannot be used. Aborting.
CORS site (3)
ATTENTION!! The quality of the GPS data from the rover or nearby CORS sites was too
Solution
noisy and below minimum standards to attain a meaningful solution. To avoid this
6034 2192 quality check
unexpected inconvenience the user may want to re-observe at a different hour of the day
(4)
and for a longer period of time.
OPUS-RS has stopped for unexplained reasons in the analysis of the single baselines. The Rover
6035 92
average X and Y coordinates are both zero and the solution cannot proceed. solution (4)
Rover
6037 2 OPUS-RS has stopped for unexplained reasons in the multi-station rover solution.
solution (4)
ERROR! OPUS terminated abnormally in one of the processing modules. PPS - zero Internal
9009 288
coordinates for initial point. OPUS cannot process this dataset. Server (4)
ERROR! OPUS terminated abnormally in one of the processing modules. OPUS.pm Internal
9012 10
cannot connect to NGS Integrated Data Base. server (4)

CORS AND OPUS FOR ENGINEERS 105

References

Estey, L.H., and Meertens, C. (2001) “TEQC: The multi-

purpose toolkit for GPS/GLONASS data.” GPS
Solutions, 3(1), 42-49.
Schwarz, C.R. (2008). “Heuristic weighting and data
conditioning in the National Geodetic Survey Rapid
Static GPS software.” J. Surv. Eng,. 134(3), 76-82.
Schwarz, C.R., Snay, R.A., and Soler, T. (2009). “Accuracy
assessment of the National Geodetic Survey’s OPUS-RS
utility.” GPS Solutions., 13(2), 119-132.
Soler, T., Snay, R. A., Schwarz, C. R., and Choi, K.K.
(2010) “Accuracy of Rapid Static Online Positioning
User Service (OPUS-RS) revisited.” Article published in
this Monograph.

106 CORS AND OPUS FOR ENGINEERS

 14
Editing RINEX Observation Files for OPUS-RS
Peter Lazio, M.ASCE1

Abstract: Using OPUS-RS one can obtain geodetic coordinates from GPS observation sessions as short as five minutes. With
short observation sessions however, the quality of the observations becomes more critical. It is not unusual for OPUS-RS to fail
“due to especially noisy data (among other reasons).” The recommendation included in the email announcing a failed OPUS-RS
run is to try another data set. This is not always a practical solution. Using TEQC from UNAVCO one can review and edit RINEX
observation files that fail to process using OPUS-RS.

In this paper three RINEX observation files that failed to process using OPUS-RS will be reviewed using the quality control
functions of TEQC. Incidents indicated in the QC report will be examined in the RINEX observation file. Using information
gleaned from the QC report, the RINEX observation files will be edited using TEQC and resubmitted to OPUS-RS.

Author keywords: OPUS; OPUS-RS; TEQC; GPS positioning; surveys

Introduction
GPS vectors radiating from a hub station is a typical
observation scheme for photocontrol using GPS. A hub
station is occupied for an extended session while satellite
stations are occupied for short sessions. The GPS
observations from these short sessions can be submitted to
OPUS Rapid Static (OPUS-RS) to obtain geodetic coordinates
of the radial stations. Using OPUS-RS one can obtain
geodetic coordinates from GPS observation sessions as short
as five minutes. With short sessions the quality of the
observation sets becomes more critical.
On an actual photocontrol survey campaign eight radial
stations were observed. Each radial station was occupied
twice using Trimble FastStatic™ observation methods. Using
Trimble FastStatic™ methods the session length is determined
by the number of continuously observed satellites and a PDOP
mask. Table 1 lists the default observation session lengths for
dual frequency receivers as a function of the number of
continuously observed GPS satellites.
The default PDOP mask is six. If PDOP is six or greater at
the end of the default observation session the session is
extended until PDOP drops below 6.
Sixteen RINEX (Gurtner and Estey 2007) observation files
were submitted to OPUS-RS. OPUS-RS failed to process
three RINEX observation files. Figure 1 is typical of the error
message returned by the three unsuccessful runs. The failed
sessions varied in length from 13 minutes 30 seconds to 19
minutes 45 seconds. Longer FastStatic™ sessions are
indicative of fewer continuously observed satellites, loss of
lock on satellites or high PDOP. For these reasons longer
FastStatic™ observation sessions can be more difficult to
process with OPUS-RS than shorter sessions. The remedy
suggested in the OPUS-RS email was not impractical; it was
not possible to return to the project site to reobserve the three
Table 1. Default FastStatic session lengths for dual frequency
GPS receivers
Number of Continuously Default Session Length
Observed GPS Satellites
6+ 8 minutes
5 15 minutes
4 20 minutes
failed sessions. Using the quality control functions of TEQC
(Translate Edit Quality Control) (Estey and Meertens 1999)
from UNAVCO <http://www.unavco.org> the RINEX
observation files that OPUS-RS could not process were
examined. After locating the problem segments of the RINEX
observation file the file was edited using TEQC. OPUS-RS
was then able to process the edited RINEX observation files.
RINEX and TEQC
Figure 2 illustrates a typical RINEX observation file header.
For the purposes at hand the most important information in the
header are the observation types and the sampling interval.
This information is highlighted in Figure 2. The observables
in these RINEX observation files are, in order:
L1 - phase measurement on L1 frequency
C1 - pseudorange using C/A on L1 frequency
L2 - phase measurement on L2 frequency
P2 - pseudorange using P-Code on L2 frequency
D1 - Doppler shift on L1 frequency.
The sampling interval is 15 seconds. OPUS-RS decimates
data to a 30 second sampling interval for processing

1
GPS Survey Manager, Sidney B. Bowne & Son, LLP, 235 East Jericho Turnpike, Mineola, New York 11501. E-Mail:
plazio@bownegroup.com; plazio@optonline.net

CORS AND OPUS FOR ENGINEERS 107

 Fig. 1. Typical OPUS-RS error message

Fig. 2. Typical RINEX header

TEQC is a command line utility program. Typing
TEQC +QC filenm.06o
at a command prompt, where filenm.06o is the name of the
RINEX observation file, results in several files being created.
The most useful file for diagnosing a problem OPUS-RS run
is named filenm.06S. A complete sample of a 06S quality
control file can be found at the end of the paper. In this paper
only use the ASCII plot included in the QC report will be used
to analyze the observation file.
Figure 3 illustrates a typical ASCII plot for a RINEX
observation file. The numbers on the left are the PRN
numbers for the satellite. The number of observed satellites
for each epoch is listed below the observation symbols. Time
is ticked off along the bottom of the plot. For short
observation files each symbol in the ASCII plot represents one
epoch of data. In longer observation files, each symbol may
represent several epochs.
Table 2 contains the symbols used in the ASCII plots
examined in this article. These symbols are presented in
hierarchal order. A complete list of the symbols used by
TEQC can be found using the command line TEQC ++sym.

Fig. 3. Typical QC ASCII plot

108 CORS AND OPUS FOR ENGINEERS

 Table 2. Symbols used in QC summary

Symbol Representation
 
I Ionospheric phase slip
. A/S off; L1 C/A
o A/S on; L1 C/A L2 P2

Table 3. LLI bit codes

Bit 0 Lost lock between previous and
set current observation: cycle slip
possible (phase only)
Bit 1 Opposite wavelength factor to the
set one defined for the satellite by the
previous WAVELENGTH FACT
L1/2 line. Valid for the current
epoch only (phase only)
Bit 2 Observations under Antispoofing
set (may suffer from increased noise)

Fig. 4. ASCI Plot for RINEX file ph02348a.06o
on G11 and G13 indicates loss of lock and the L2 and P2
observables are zero. At epoch 14:42:45 the receiver is once
again locked onto the L1 observable for G11 and G13 but, L2
and P2 observables continue to be zero. Although
antispoofing (A/S) is on, the zero in the LLI of the of the L2
and P2 observables fools TEQC into reporting that the L1 and
C1 observables are collected with A/S off. These three
epochs correspond to the three “.” in the TEQC ASCII plot.
At epoch 14:43:15 the sudden jump from zero in L2 and P2
observable is interpreted by TEQC as an ionospheric slip and
shows up in the TEQC ASCII plot as an “I”. From this epoch
CORS AND OPUS FOR ENGINEERS
The RINEX standard specifies a F14.3 format for all
observables. An F14.3 format indicates floating point number
occupying 14-character field width with 3 decimal places.
What appears to be a fourth decimal place in the phase and
pseudorange observables is the Loss of Lock Indicator (LLI).
This is a bit coded integer in the range of 0 to 7. A blank or
zero value indicates OK or unknown status. LLI Bit codes are
listed in Table 3. The fourth decimal place indicates the
signal strength.
Review and Edit RINEX Observation Files
RINEX file ph02348a.06o
This session begins at 14:37:30 with observations on seven
GPS satellites and runs for 13 minutes 30 seconds or 54
epochs of observations. Figure 4 is the TEQC ASCII plot for
this session file. In this plot each symbol represents one
epoch. The problem areas are highlighted.
The section of RINEX file shown in Figure 5 starts at epoch
14:42:15. Five epochs of data for GPS satellites G11 and G13
are highlighted. At the start of this segment of RINEX file,
the receiver is locked onto and recording observations from
seven satellites. The following epoch, at 14:42:30, the L1 LLI
on the observations are recorded normally. The last four
epochs highlighted in the RINEX observation file in Figure 5
correspond to the highlighted sections in the TEQC ASCII
plot in Figure 4. Using the TEQC command line:
TEQC –G11 –G13 ph02348a.06o>ph02348ax.06o
removes all observations for GPS satellites G11 and G13 from
RINEX observation file ph02348a.06o and redirects the
output from TEQC to a new RINEX observation file
named ph02348ax.06o. When RINEX observation file
ph02348ax.06o is submitted to OPUS-RS it processes
successfully with the results shown in Figure 6.
109
 Fig. 5. Clip from RINEX file ph02348a.06o

Fig. 6. Successful OPUS-RS run for RINEX file ph02348ax.06o

110 CORS AND OPUS FOR ENGINEERS

 Fig. 7. ASCII plot for RINEX file ph01348b.06o

RINEX file ph01348b.06o
This session starts at 18:39:15 with observations on six
satellites and runs for 14 minutes 45 seconds or 59 epochs of
data. Figure 7 is the TEQC ASCII plot for this session. In
this plot each symbol represents one epoch. Twenty seven
epochs of data for GPS satellite G9 are highlighted in the
ASCII Plot. At 18:41:45 GPS satellite G9 is dropped for six
epochs while five GPS satellites continue to be observed.
This corresponds to the blank area for G9 in figure 7.
The section of RINEX observation file shown in figure 8
begins at 18:42:45. Two epochs of data for GPS satellite G9
are highlighted. At the start of this segment the receiver is
locked onto and recording data from five satellites. The
following epoch GPS satellite G9 reappears on the list of
observed satellites. The only valid observable for this epoch
is C1. At epoch 18:43:15 the receiver locks onto the L1 phase
observable, the L2 and P2 observables remain zero. As in the
previous example, although antispoofing (A/S) is on, the zero
in the LLI of the of the L2 and P2 observables fools TEQC
into reporting that the L1 and C1 observables are collected
with A/S off. This event corresponds to the first “.” in the
ASCII plot for G9 in Figure 7.
Figure 9 picks up the RINEX observation file at epoch
18:46:30. At this time the receiver is still locked onto the L1
and C1 observables but with zeros for the L2 and P2
observables. The following epoch the sudden change in the
L2 and P2 observables is interpreted as an ionospheric slip by
TEQC. This corresponds to the first “I” in the ASCII plot for
G9 in Figure 7. At epoch 18:47:00 the L2 and P2 observables
are once again zeros and the ASCII plot again symbolizes
these epochs with “.”. At 18:48:15 the receiver once again
starts recording L2 and P2 observables for GPS satellite G9.
The sudden change in value is again interpreted by TEQC as
an ionospheric slip and plotted as an “I” in the ASCII plot.
The section of RINEX observation file where this second
ionospheric slip take place is not included.
Using the TEQC command line:
TEQC –G9 ph01348b.06o>ph01348bx.06o
removes all observations for GPS satellite G9 from RINEX

Figure 8. Clip from RINEX file ph01348b.06o

CORS AND OPUS FOR ENGINEERS 111

 Fig. 9. Continuing RINEX file ph01348b.06o

Fig. 10. Successful OPUS-RS run for RINEX file ph01348bx.06o

observation file ph01348b.06o and redirects the output from
TEQC to a new RINEX observation file named
ph01348bx.06o. When RINEX observation file
ph01348bx.06o is submitted to OPUS-RS it processes
successfully with the results shown in Figure 10.
The W statistic of 0.22 for the rover mode processing is less
than the desired minimum value of three. The coordinates for
this solution differs from the A session OPUS-RS solution for
this station by -1.2 cm, -7.7 cm and -29.4 cm in latitude,
longitude and ellipsoid height respectively. The OPUS-RS
run from the A session on this station has a W statistic of
21.21 for network mode and 4.75 for rover solution. It is
likely that the OPUS-RS solution for ph01348bx.06o contains
a bad integer fix. Further investigation is warranted.
RINEX file ph03348b.06o
This session starts at 18:11:45 with observations on six
satellites and runs for 19 minutes 45 seconds or 79 epochs of
data. Figure 11 is the TEQC ASCII plot for this RINEX
observation file. Problems sections for data for GPS satellites
G8, G4 and G9 are highlighted. In this plot 72 symbols
represent 79 epochs so each symbol may represent more than
one epoch in some areas.

112 CORS AND OPUS FOR ENGINEERS

 Fig. 11. ASCII plot for RINEX file ph03348b.06o

Figure 12 is a clip of this RINEX file starting at epoch
18:15:15. Five epochs of data for GPS satellites G4 and G8
are highlighted. At the start of this segment six satellites are
being tracked cleanly including G4 and G8. The following
epoch, at 18:15:30, the L1 LLI flag for G8 indicates a loss of
lock and there is an abrupt change in the L1 observable. This
abrupt change is interpreted by TEQC as an ionospheric slip
which corresponds to the first “I” in the highlighted section of
the ASCII plot for G8 in Figure 11. At epoch 18:15:45 the L1
LLI flag for G4 indicates loss of lock, the L1 observable for
G8 is zero and the L2 and P2 observables for both G4 and G8
are zero. This event corresponds to the first “.” in the
highlighted area for G4 in Figure 11. As in the previous
examples, although antispoofing (A/S) is on, the zero in the
LLI of the L2 and P2 observables fools TEQC into reporting
that the L1 and C1 observables are collected with A/S off.

Fig. 12. Clip illustrating first event from ASCII plot in RINEX file ph03348b.06o

Figure 13 picks up the RINEX file at epoch 18:22:45. Two being tracked including GPS satellite G9. However, the L1
epochs of data for GPS satellite G9 are highlighted in Figure LLI flag indicates loss of lock on the L1 observable and the
13. At the start of this segment five satellites are tracking L2 and P2 observable for G9 are zero. This corresponds to
normally. The following epoch, at 18:23:00, six satellites are the first “.” in the TEQC ASCII plot for G9 in Figure 11.

CORS AND OPUS FOR ENGINEERS 113

 Fig. 13. Clip illustrating second event in RINEX file ph03348b.06o
This condition continues for five epochs of data. Figure 14
picks up the RINEX file again at epoch 18:24:30 when both
G4 and G9 are again tracked normally. This epoch
corresponds to the second “o” in the TEQC ASCII plot for G9
in Figure 11. Eight epochs of data are highlighted for GPS
satellites G4 and G9 are highlighted. The following epoch, at
18:24:45, the L1 LLI for G4 and G9 indicates loss of lock and
the L2 and P2 observables are zero. This condition continues
for four epochs for both satellites. On the fifth epoch, at
18:25:45 the L2 and P2 observables jump from zero. As in
previous examples, sudden change is interpreted by TEQC as
an ionspheric slip and plotted as an “I” in the ASCII plot. G4
continues to be tracked normally while G9 is lost and its L1
and P2 observables are recorded as zeros. When tracking on
G9 resumes the sudden jump is again interpreted by TEQC as
an ionspheric slip.
These conditions suggest three candidates for elimination,
namely G8, G4 and G9. Table 4 lists the combinations of
GPS satellites removed with the results. Removing every
obvious combination of GPS satellite with flawed date did not
result in a successful OPUS-RS run.
Table 4. Satellites removed and results

Removed OPUS-RS Result
SVs ----------------------------------------------
--------------
-----
G9 Failed to converge after 5 iterations
G4 Failed to converge after 5 iterations
G8 Failed to converge after 5 iterations
G4, G8 Failed to converge after 5 iterations
G4, G9 Failed to converge after 5 iterations
G8, G9 Failed to converge after 5 iterations
G4, G8, Terminated abnormally in one of the
G9 processing modules.
PPS - zero coordinates for initial point

114 CORS AND OPUS FOR ENGINEERS
Looking back at the ASCII plot in Figure 11, satellite G28
has a single ionospheric cycle slip. This single cycle slip
occurs at epoch 18:24:45 and is highlighted in Figure 15. It is
easy to overlook this slip alongside the much more obvious
loss of data from G4 and G9 in the same epochs. After
exhausting the obvious fixes, G28 was removed from the
RINEX observation file, more as an act of desperation than as
a logical selection. This OPUS-RS run completed
successfully with acceptable statistics as illustrated in Figure
16. This exercise highlights the sensitivity of OPUS-RS to
data submitted. For completeness the Appendix contains a
typical TEQC quality control report (filenm.06o)
Conclusions
The success of an OPUS-RS run is dependent on the quality
of the data submitted. Editing a RINEX observation file to
remove satellites with excessive cycle slips or missing
observables can cause an OPUS-RS run to succeed when the
unedited RINEX observation file failed. Sometimes the
satellite observations causing the OPUS-RS run to fail is not
obvious. All combinations of satellites with flawed
observables should be tried before giving up.
The large differences in coordinates between the two OPUS-
RS runs for session A and session B at station ph01 stands as
a warning against relying too heavily on a single OPUS-RS
solution.
References
Estey, L H., and Meertens, C. M. (1999). “TEQC: The Multi-
Purpose Toolkit for GPS/GLONASS Data.” GPS
Solutions, 3(1), 42-49
Gurtner, W., and Estey, L.H. (2007). “RINEX The Receiver
Independent Exchange Format Version 2.11.” Consult
<ftp://igscb.jpl.nasa.gov/igscb/data/format/rinex211.txt>
(July 23, 2010)
Fig. 14. Clip GPS satellites G4 and G9 in RINEX file h03348b.06o

Fig. 15. Ionospheric slip for G28

CORS AND OPUS FOR ENGINEERS 115

 Fig. 16. Successful OPUS-RS run after removing G28 from RINEX file

Appendix

Typical Complete TEQC Quality Control Report (filenm.06o)

SV+------------------------------------------------------------------------+ SV
3| ooo ooo ooo ooo oo oooo oo oooo oo ooo ooo oooo ooo oo ooo oooo ooo ooo| 3
8| ooo ooo ooo ooo oo oooo oo oooo oo ooo ooo oooo ooo oo ooo oooo ooo ooo| 8
11| ooo ooo ooo ooo oo oooo o. ..Io oo ooo ooo oooo ooo oo ooo oooo ooo ooo| 11
13| ooo ooo ooo ooo oo oooo o. ..Io oo ooo ooo oooo ooo oo ooo oooo ooo ooo| 13
19| ooo ooo ooo ooo oo oooo oo oooo oo ooo ooo oooo ooo oo ooo oooo ooo ooo| 19
27| ooo ooo ooo ooo oo oooo oo oooo oo ooo ooo oooo ooo oo ooo oooo ooo ooo| 27
28| ooo ooo ooo ooo oo oooo oo oooo oo ooo ooo oooo ooo oo ooo oooo ooo ooo| 28
Obs| 777 777 777 777 77 7777 77 7777 77 777 777 7777 777 77 777 7777 777 777|Obs
Clk| |Clk
+-------------|--------------------------|-------------------------|-----+
14:37:30.000 14:51:00.000
2006 Dec 14 2006 Dec 14

*********************
QC of RINEX file(s) : ph02348a.06o
*********************

Time of start of window : 2006 Dec 14 14:37:30.000

Time of end of window : 2006 Dec 14 14:51:00.000
Time line window length : 13.50 minute(s), ticked every 5.0 minute(s)
Observation interval : 15.0000 seconds
Total satellites w/ obs : 7
NAVSTAR GPS SVs w/o OBS : 1 2 4 5 6 7 9 10 12 14 15 16
17 18 20 21 22 23 24 25 26 29 30 31 32
Rx tracking capability : 12 SVs
Poss. # of obs epochs : 55
Epochs w/ observations : 55
Complete observations : 372
Deleted observations : 6
Moving average MP1 : 0.267850 m
Moving average MP2 : 0.733408 m
Points in MP moving avg : 50
No. of Rx clock offsets : 0
Total Rx clock drift : 0.000000 ms
Rate of Rx clock drift : 0.000 ms/hr
Report gap > than : 10.00 minute(s)
but < than : 90.00 minute(s)
epochs w/ msec clk slip : 0
other msec mp events : 0 (: 4) {expect <= 1:50}
IOD signifying a slip : >400.0 cm/minute

116 CORS AND OPUS FOR ENGINEERS

IOD slips : 2
IOD or MP slips : 2
first epoch last epoch hrs dt #expt #have % mp1 mp2 o/slps
SUM 06 12 14 14:37 06 12 14 14:51 .2250 15 n/a 372 n/a 0.27 0.73 186

Processing parameters are:

Receiver tracking capability : 12 SVs
Maximum ionospheric rate (L1) : 400.00 cm/min
Report data gap greater than : 10.00 min
but less than : 90.00 min
Expected rms level of P1 multipath : 50.00 cm
Expected rms level of P2 multipath : 65.00 cm
Multipath slip sigma threshold : 4.00 cm
% increase in MP rms for C/A | A/S : 100.00 %
Points in MP moving averages : 50
Minimum signal to noise for L1 : 0
Minimum signal to noise for L2 : 0
Width of ASCII summary plot : 72
Data indicators on summary plot : yes
Do ionospheric observable : yes
Do ionospheric derivative : yes
Do high-pass ionosphere observable : no
Do multipath observables : yes
Do 1-ms receiver clock slips : yes
Tolerance for 1-ms clock slips : 1.00e-02 ms
Do receiver LLI slips : yes
Do plot file(s) : yes

Observations start : 2006 Dec 14 14:37:30.000

Observations end : 2006 Dec 14 14:51:00.000
Observation interval : 15.0000 second(s)

SV #+hor <ele> #+mask <ele> #reprt #compl L1 L2 P1 P2 CA

--- ------ ----- ------ ----- ------ ------ ------ ------ ------ ------ ------
G 3* 0 0.00 0 0.00 54 54 54 54 0 54 54
G 8* 0 0.00 0 0.00 54 54 54 54 0 54 54
G11* 0 0.00 0 0.00 54 51 54 51 0 51 54
G13* 0 0.00 0 0.00 54 51 54 51 0 51 54
G19* 0 0.00 0 0.00 54 54 54 54 0 54 54
G27* 0 0.00 0 0.00 54 54 54 54 0 54 54
G28* 0 0.00 0 0.00 54 54 54 54 0 54 54
* = SV with no NAV info
Obs w/ no L1 : 0
Obs w/ no L2 : 6
Obs w/ no P1 | CA : 0
Obs w/ no P2 : 6
Obs w/ low L1 S/N : 0
Obs w/ low L2 S/N : 0

Obs reported w/ code | phase : 378

Obs deleted (any reason) : 6
Obs complete : 372

No. of Rx clock offsets : 0

Total Rx clock drift : 0.000000 ms
Rate of Rx clock drift : 0.000000 ms/hr

MP1 RMS summary (per SV):

slips L1 rx L2 rx
SV obs # del <elev> MP1 rms [m] all all all
G 3* 54 0 0.00 0.268729 0 0 0
G 8* 54 0 0.00 0.180273 0 0 0
G11* 54 3 0.00 0.345350 1 1 1
G13* 54 3 0.00 0.447755 1 1 1
G19* 54 0 0.00 0.120844 0 0 0
G27* 54 0 0.00 0.112089 0 0 0
G28* 54 0 0.00 0.414209 0 0 0
* = SV with no NAV info

mean MP1 rms : 0.267850 m

# MP1 obs : 372

CORS AND OPUS FOR ENGINEERS 117

 # MP1 slips : 2
# Rvr L1 slips : 2
# Rvr L2 slips : 2

MP2 RMS summary (per SV):

slips L1 rx L2 rx
SV obs # del <elev> MP2 rms [m] all all all
G 3* 54 0 0.00 0.516580 0 0 0
G 8* 54 0 0.00 0.576035 0 0 0
G11* 54 3 0.00 0.704368 1 1 1
G13* 54 3 0.00 0.934401 1 1 1
G19* 54 0 0.00 0.275913 0 0 0
G27* 54 0 0.00 0.304463 0 0 0
G28* 54 0 0.00 1.831645 0 0 0
* = SV with no NAV info

mean MP2 rms : 0.733408 m

# MP2 obs : 372
# MP2 slips : 2
# Rvr L1 slips : 2
# Rvr L2 slips : 2

118 CORS AND OPUS FOR ENGINEERS

 15
GPS Vectors, OPUS-S and OPUS-RS Observations in a Unified
Adjustment
Peter Lazio, M.ASCE1

Abstract: Combining OPUS-S and OPUS-RS solutions as stochastic quantities in a least squares adjustment along with GPS
vectors offers several advantages over using the OPUS coordinates as fixed quantities. Both the GPS vectors and the OPUS
coordinates contribute to the final coordinate solution in the least squares adjustment. This is true even when the GPS vectors
connect stations with OPUS solutions. In addition treating the OPUS coordinates as observations provides a more realistic estimate
of the external network accuracy with regard to the National Spatial Reference System.

Author keywords: OPUS; OPUS-RS; GPS vectors; adjustments; GPS positioning; geodetic networks

Introduction OPUS-RS coordinates in a least squares adjustment is the

A small three station network that included both GPS vectors
and coordinate observations illustrates the utility of combining
each measurement type in a unified adjustment. Each station
in the network has at least one set of observed coordinates,
either from OPUS Static (OPUS-S) (Mader et al. 2003) or
OPUS Rapid Static (OPUS-RS) (Martin 2007) and was
connected to the other two stations by GPS vectors. No
individual station is held fixed. Coordinate observations
provided the ties to the national network. The adjustment
process for this network highlights the advantages of
including coordinates as observed variables rather than as
fixed quantities. At the time of this engineering survey
(October 2006) OPUS-RS was still considered an operational
prototype. This network marked the author’s first production
use of OPUS-RS.
Most commercial least squares adjustment software uses a
mathematical model known as the “observation model.” In
the observation model the adjusted observations are functions
of parameters which, are varied as part of the adjustment
computation. In most cases involving surveying adjustments
the parameters are coordinates. Because of that, the
observation model is sometimes referred to as “variation of
coordinates.” This is a misnomer as the parameters to be
varied in a least squares adjustment are not limited to
coordinates. Other parameters could include scale and
orientation parameters.
In adjustment notation the observation model is
written, La = F ( X a ) . Where La is a vector of adjusted
observations and X a are the adjusted parameters. When
coordinates are used as observations F ( X a ) = X a and the
observations, Lb are written as Lb = X i with X i being the
individual observed coordinates. In the case of this network
the observed coordinates are OPUS-S and OPUS-RS results.
The key component that makes it possible to use OPUS and
inclusion of the covariance matrix in the OPUS / OPUS-RS
extended data report. (Lazio 2006; 2007)
GPS Observation Scheme
Two receivers were used to observe this network. Station 66
was occupied for two hours. During this time stations 79 and
90 were occupied for 45 minutes each, resulting in two GPS
vectors (6679 and 6690). Station 90 was then occupied
for two hours. During this time station 79 and 90 were
occupied a second time for 45 minutes each, resulting in two
more GPS vectors (9079 and 9066). Figure 1 shows a
schematic diagram of the network under discussion. Table 1
summarizes the observation scheme.
Table 1. Network observation scheme
From Occupation To Occupation Session Distance
66 45 minutes A 1.6
90 2 hours
79 45 minutes B 2.9
79 45 minutes C 1.5
66 2 hours
90 45 minutes D 2.9

The 45-minute sessions are much longer than required for
these short baselines however; the two-hour occupations at
stations 66 and 90 are minimum recommend session length
for submitting the GPS observations to OPUS-S. The 45
minute sessions ensure that the vectors would be well
determined. The closed loop and the repeat vector from
station 66 to 90 provide adequate redundancy.
Processing the GPS Data
After waiting for the release of the rapid ephemeris, the two
hour data files for stations 66 and 90 were submitted to
OPUS-S. The GPS observations for sessions A and C at
station 79 were windowed using TEQC (Estey and Meertens

1
GPS Survey Manager, Sidney B. Bowne & Son LLP, 235 East Jericho Turnpike, Mineola, NY 11501 E-Mail:
plazio@bownegroup.com; plazio@optonline.net
CORS AND OPUS FOR ENGINEERS 119
1999) from UNAVCO (<http://www.unavco.org/>) into six minute observation sessions were used to process the
15-minute data-sets. The 15-minute data-sets were submitted baselines. Although the reference variance ( a posteriori
to OPUS-RS; the two 2-hour data-sets were submitted to variance of unit weight) values are a bit larger than ideal, the
OPUS-S. Using the criteria outlined on the OPUS website ratio and RMS values are very good. The difference in
(<http://www.ngs.noaa. gov/OPUS/about.html>) six accepta- magnitude between the repeated vectors is only 3 millimeters.
ble OPUS-RS and two acceptable OPUS-S solutions were Table 2 summarizes the baseline processing statistics. The
returned. vectors along with their covariance matrices were exported
OPUS-RS solutions derived from GPS observations windo- from TGO to be adjusted using Columbus Network
wed from the same occupation are, strictly speaking, not Adjustment Software (Columbus) (Beaverton, OR).
independent results. They share a common setup and very
similar satellite constellation. The three data-sets windowed
Table 2. Baseline processing summary. All linear units are
from the same session at station 79 are not independent
given in meters
sessions. The three data-sets windowed from session B at
station 79 are independent of the three data-sets windowed From To Baseline Solution Ratio Reference RMS
from session C at station 79. The end of the third data-set Length Type Variance
windowed from session B is separated by 36 minutes from the (Fixed)
start of the first data-set windowed from session C. The two 90 66 2,910.556 L1 12.4 4.586 0.007
occupations of station 79 use different antennas and setups. 90 79 1,529.367 L1 44.9 4.589 0.007
The coordinates reported in the OPUS solutions were used 66 79 1,623.518 L1 10.2 4.058 0.007
as seed coordinates to process GPS vectors using the WAVE 66 90 2,910.553 L1 14.4 4.929 0.007
processor in Trimble Geomatics Office (TGO). The entire 45-

Fig. 1. Schematic network diagram

GPS Vector Network Adjustment
A minimally constrained adjustment of the four GPS vector
network was performed using Columbus. Setup errors were
modeled at 1.5 millimeters horizontally and vertically. This
adjustment passed the chi square test without scaling the
adjustment covariance matrix. It is well-known that the
covariance matrix resulting from GPS baseline processing is
often optimistic (Kashani et al. 2004). That is not the case in
this adjustment. The long sessions for such short baselines
provide more than enough data to compute the baselines to a
high degree of certainty. In addition the 3 mm difference
between repeated baselines is largely absorbed in the setup
errors used in the adjustment. Passing the chi square test on
the a posteriori variance of unit weight without any scaling of
the covariance matrix is also due, in part, to the low number
of degrees of freedom. In an adjustment with a low degree of
freedom there is more uncertainty in the a posteriori variance
of unit weight. This greater uncertainty is reflected in a larger
range in the value of the a posteriori variance of unit weight
that will pass the chi square test. The Columbus processing
summary is included in Figure 2.
OPUS Coordinate Observations
The next step is to add the coordinate observations from the
two OPUS results. Columbus supports coordinate
observations and will read an OPUS or OPUS-RS report and
convert the data into Columbus format. In commercial
software that does not support coordinate observations the
methods published in Lazio (2006) may be used to include the
OPUS-S or OPUS-RS coordinates as observations in a least
squares adjustment. After importing the OPUS report the
coordinates from the OPUS-S results and the covariance
matrix are included as observations in the least squares
adjustment.

120 CORS AND OPUS FOR ENGINEERS

 Including the OPUS coordinate observations in the
adjustment causes the chi square test to fail with an a
posteriori variance of unit weight of 4.30. No stations are
held fixed in this adjustment. The coordinate observations
provide the connections to the National Spatial Reference
System (NSRS) and remove the rank deficiency from the
normal matrix. Figure 3 shows the network processing
summary after including OPUS-S coordinate observations
into the adjustment.

Fig. 2. Network adjustment summary for GPS vectors alone

Fig. 3. Network processing summary after adding OPUS-S coordinate observations

The addition of the OPUS-S coordinate observations
increases the degrees of freedom of this adjustment from six
to nine. Failing the chi square test on the a posteriori variance
on the high side is indicative of an optimistic covariance
matrix. Since the minimally constrained adjustment passed
the chi square test, the OPUS coordinate observations are the
cause of the adjustment failing the chi square test. The
preferred method to objectively determine the scale factor for
an OPUS covariance matrix is to combine multiple OPUS
solutions, for the same station, in a least squares adjustment
and use the a posteriori variance of unit weight from the least
squares adjustment as the scale factor. In this case there is
only one OPUS solution at each station so an alternate method
is used. Columbus tabulates the residuals, degrees of freedom
and a posteriori variance of unit weight by observation type.
Looking at the geodetic coordinate observations the a
posteriori variance of unit weight is 7.98. Based on
experience, this is not an unreasonable scale factor. Scaling

CORS AND OPUS FOR ENGINEERS 121

the two OPUS coordinate covariance matrices by the same
scale factor is also reasonable. Both stations were observed
under similar conditions for the same session length and tied
to the same CORS. After scaling the covariance matrices of
the coordinate observations by 7.98 and readjusting the
summary is shown in Figure 4.
The adjustment now passes the chi square test. The sum of
Fig. 4. Network processing summary after scaling OPUS-S covariance matrix
Advantages of Coordinate Observations
If the OPUS coordinates for stations 66 and 90 were held as
fixed values, rather than as observations subject to
adjustment, the two vectors from station 66 to station 90
would be redundant. Being constrained between two fixed
coordinates, the GPS vectors between stations 66 and 90
would have adjusted to conform to the inverse between the
fixed coordinates. Under these conditions the two GPS
vectors between stations 66 and 90 would not have
contributed to the network and rightly should be removed
from the adjustment. Treating the OPUS coordinates as
observations allows the two GPS vectors to contribute to the
determination of the coordinates for stations 66 and 90.
In addition, using the OPUS coordinates as observations,
allows for a more accurate estimate of the external accuracy
of the network with reference to the national network. All
coordinates have some associated error. Treating the OPUS
coordinates as observations rather than fixed values reflects
that reality.
OPUS-RS Coordinate Observations
There still remain the six OPUS-RS solutions for station 79.
Since there are six solutions we can combine them into a
single solution in a least squares adjustment using the
coordinates as observations. The a posteriori variance of
122 CORS AND OPUS FOR ENGINEERS
the square of the weighted residuals for the GPS observations
is 8.9. This is slightly larger than the value for the GPS only
observations in the minimally constrained GPS only
adjustment. This indicates that the GPS vectors are absorbing
slightly more of the residuals than in the GPS only
adjustment. The coordinate observations are exerting an
influence in the estimation of the adjusted coordinates. .
unit weight of that adjustment can then be used to objectively
scale the OPUS-RS covariance matrices to more realistically
estimate the observation errors. The network processing
summary for the adjustment of the six OPUS-RS coordinate
solutions is shown in figure 5.
There are 18 coordinate observations included in this
adjustment, three for each OPUS-RS solution. One OPUS-RS
solution provides sufficient observations to uniquely define
the coordinates of station 79 in three dimensions. The other
five OPUS-RS solutions provide the 15 degrees of freedom.
After scaling the covariance matrix by 4.58 the adjustment
passes the chi square test with an a posteriori variance of unit
weight of 1.000.
Final Combined Adjustment
The OPUS-RS coordinate observations can now be included
in a least squares adjustment along with the OPUS coordinate
observations and GPS vectors. In this unified adjustment the
covariance matrix for the GPS vectors is the unscaled
covariance matrix used in the original minimally constrained
adjustment; the covariance matrix for the OPUS coordinate
observations is scaled by 7.98; the covariance matrix for the
OPUS-RS observations will be scaled by 4.58. No stations
are held fixed. The OPUS-S coordinate observations at
stations 66 and 90 and the OPUS-RS coordinate observations
at station 79 provide the connection to the NSRS and remove
the rank deficiency from the normal matrix. The network
processing summary for the final adjustment is shown in
Figure 6.
This adjustment passes the chi square test indicating that
the residuals are consistent with the assumptions made. In
this adjustment the sum of the squares of the weighted
residuals for the GPS observations is 9.9. This is greater
than either of the two previous adjustments that include GPS
vectors. The GPS vectors are again absorbing a still greater
share of the adjustment than before. The coordinate
observations are exerting greater influence on the adjusted
coordinates for the network stations.
The final adjusted coordinates with standard deviations are
summarized in Table 3.

Fig. 5. Network processing summary for adjustment of OPUS-RS coordinate observations

Fig. 6. Network processing summary for final adjustment

Table 3. Final adjusted coordinates with standard deviations

Station Latitude Longitude Ellipsoid Lat. Std. Lon. Std. Ht. Std.
Ht. Dev. Dev Dev.
66 N40°33’22.14954” W74°12’12.10793” -28.068m 0.003m 0.002m 0.007m
79 N40°33’50.37236” W74°11’13.85774” -21.688m 0.002m 0.002m 0.007m
90 N40°33’39.36810” W74°10’10.46871” -28.843m 0.003m 0.002m 0.007m

CORS AND OPUS FOR ENGINEERS 123

Conclusions
OPUS-RS allows centimeter level accuracy with observation
spans as short as 15 to 20 minutes (Kashani et al 2005;
Schwarz et al 2009). With repeat occupations, as part of a
normal network observation scheme, multiple OPUS-RS
solutions can be included in a network adjustment to add
strength to the adjustment. Using OPUS-S and OPUS-RS
coordinate observations rather than fixed coordinates allows
GPS vectors connecting these stations to contribute to the
least squares adjustment. If these stations were fixed the GPS
vectors would simply adjust to match the inverse between the
fixed stations. The GPS vectors would not contribute to the
adjustment and should be removed. Using OPUS-S and
OPUS-RS coordinate observations to constrain a network
adjustment to the NSRS provides a more realistic estimate
external precision of the network with regard to the NSRS
than fixed coordinates.
References
Estey, L. H., and Meertens, C. M. (1999). “TEQC: The
multipurpose toolkit for GPS/GLONASS data.” GPS
124 CORS AND OPUS FOR ENGINEERS
Solutions, 3(1), 42–49.
Kashani, I., Pawel, W., and Grejner-Brzezinska, D. A. (2004).
“On the reliability of the VCV matrix: A case study based
on GAMIT and Bernese GPS software.” GPS Solutions,
8(4), 193–199.
Kashani, Wielgosz, Grejner-Brzezinska, Mader (2005). “A
new network-based rapid-static module for the NGS
Online Positioning User Service – OPUS-RS.” ION 61st
Annual Meeting, Institute of Navigation, pp. 928-936.
Lazio, P. (2006). “OPUS observations.” Surv. Land Inf. Sys.,
66(3), 185–194.
Lazio, P (2007) “Constraining network adjustments to OPUS-
RS coordinate observations.” J. Surv. Eng., 133(3), 106-
113
Mader, G. L., Weston, N. D., Morrison, M. L., and Milbert, D.
G. (2003). “The On-line Positioning User Service
(OPUS).” Prof. Surveyor, 23(5), 26, 28, 30.
Martin, D. (2007) “Geodetic connections. OPUS Rapid
Static.” The American Surveyor, 4(3), 44, 46-48.
Schwarz, C.R., Snay, R.A., and Soler, T. (2009) “Accuracy
assessment of the National Geodetic Survey’s OPUS-RS
utility.” GPS Solutions, 13(2), 119-132.
 16
Constraining Network Adjustments to OPUS-RS
Coordinate Observations
Peter Lazio, M.ASCE1

Abstract: OPUS rapid static 共OPUS-RS兲 was introduced to the public in August 2005 as an operational prototype. Allowing centimeter
accuracy with 10–15-min observation sessions, OPUS-RS holds the promise of dramatically lessening the time needed to reference a
survey to the National Spatial Reference System. 共NSRS兲. The purpose of this paper is to compare results between networks constrained
to the NSRS using multiple short OPUS-RS observation sessions and much longer OPUS observation sessions. The results of this
comparison demonstrate that multiple short OPUS-RS sessions provide for significant time savings with results that agree within a
centimeter of the longer OPUS sessions.
DOI: 10.1061/共ASCE兲0733-9453共2007兲133:3共106兲
CE Database subject headings: Global positioning; Least squares method; Control surveys.

Introduction
The National Geodetic Survey 共NGS兲 launched the web-based
online positioning user service 共OPUS兲 in March of 2001 to pro-
vide easier access to the National Spatial Reference System
共NSRS兲. NGS intended OPUS as a source of accurate, consistent,
reliable, and timely geodetic positions 共Mader et al. 2003兲. OPUS
provides coordinates referenced to the North American Datum of
1983 共NAD83兲 and the International Terrestrial Reference Frame
of 2000 共ITRF00兲.
Soler et al. 共2006a兲 caution “Among the limitations for using
OPUS, the time duration of the GPS data set was always empha-
sized. A minimum of 2 h of data is recommended to obtain results
sufficiently accurate for surveying applications” 共Soler et al.
2006a兲. Decreasing an OPUS observation time span to less than
2 h “drastically increases uncertainties due to difficulty in fixing
integer ambiguities as consequence of poor geometry and local
atmospheric disturbances” 共Soler et al. 2006a兲. In addition to the
problem of fixing integer ambiguities, short OPUS sessions
present difficulties modeling the tropospheric delays to GPS sig-
nals. OPUS uses the NGS baseline reduction software program
for adjustment of GPS ephemerides 共PAGES兲. Using PAGES, a
2 h session was deemed sufficient to adequately model the neutral
atmospheric delay for geodetic purposes using a relatively crude
seasonal meteorological model 共Marshall et al. 2001兲.
True to its intent, OPUS is rapidly becoming a primary means
of connecting surveys to the NSRS. OPUS lends itself well to
radial surveys. With multiple short occupations of the radial sta-
1
GPS Survey Manager, Sidney B. Bowne & Son LLP, 235 East
Jericho Turnpike, Mineola, New York 11501. E-mail: plazio@
bownegroup.com; plazio@optonline.net
Note. Discussion open until January 1, 2008. Separate discussions
must be submitted for individual papers. To extend the closing date by
one month, a written request must be filed with the ASCE Managing
Editor. The manuscript for this paper was submitted for review and pos-
sible publication on December 13, 2006; approved on January 26, 2007.
This paper is part of the Journal of Surveying Engineering, Vol. 133,
No. 3, August 1, 2007. ©ASCE, ISSN 0733-9453/2007/3-106–113/
$25.00.
tions around a hub station, only the occupation at the hub will be
of sufficient duration for a reliable OPUS determination. The GPS
observations recorded at the hub station serve two purposes. Sub-
mission of the GPS observations to OPUS references the hub
station to the NSRS and they are also used to postprocess the
radiating GPS vectors. If there are redundant observations in the
network, the coordinates of the hub station obtained from OPUS
provide the minimal constraints for the network.
At the same time that Soler et al. 共2006a兲 cautioned against
using OPUS sessions of less than 2 h, the hope was presented that
“NGS is currently trying to develop alternative software capable
of reliably fixing integer ambiguities for time periods of 15 min
and less” 共Soler et al. 2006a兲. The alternative software is OPUS
rapid static 共OPUS-RS兲. OPUS-RS was released for public use as
an operational prototype in August 2005 共http://www.ngs.
noaa.gov/OPUS/OPUS-RS.html兲. The reason for the dramatic de-
crease in session duration required for reliable geodetic positions
is the new baseline reduction software behind OPUS-RS. Instead
of PAGES, the software behind OPUS-RS is “based on the Wide
Area Rapid-Static 共WARS兲 module of the Multi Purpose GPS
Processing Software 共MPGPS™兲, and it is an implementation of
the Network RTK algorithm applied in the software” 共Kashani
et al. 2005兲.
Where OPUS independently computes three baseline solutions
to determine the position of the rover antenna, OPUS-RS uses a
network approach. To determine the coordinates of a point
OPUS-RS computes two solutions. The first solution, or network
solution does not include the station whose coordinates are to be
determined. Instead, OPUS-RS chooses up to six continuously
operating reference stations 共CORS兲 and uses the GPS observa-
tions at the CORS to estimate ionospheric and tropospheric de-
lays. Since the coordinates at the CORS are known quantities, the
integer ambiguities for the baselines between the CORS are easier
to resolve. In the second solution, or rover solution, the topo-
spheric and ionospheric delays estimated in the network solution
are used to interpolate or extrapolate these delays at the rover
stations. In addition, using the linear dependence of the double
difference observable, the resolved integer ambiguities from the
network solution aids the resolution of integer ambiguities at the
rover 共Kashani et al. 2005兲.

CORS AND OPUS FOR ENGINEERS 125

 Table 1. Trimble Recommended FastStatic Session Lengths
Recommended
trimble FastStatic
Continuously observation session
observed GPS satellites 共min兲
6 8
5 15
4 20

A session is extended, beyond the recommended minimum time,

if the PDOP value is above 6 at the completion of the recom-
mended session length until the PDOP falls below 6.
In the case of this survey, every session was observed for the
longer of 15 min or the recommended Trimble FastStatic session
length. During the occupation a note was made of when the ses-
sion would end if the Trimble FastStatic session length was used.
Table 2 lists the actual occupation times and the corresponding
recommended Trimble FastStatic session length.
The hub station was occupied for 3 h 53 min. The additional
time was spent traveling between stations and consulting with the
field crew on the survey requirements.

Radial Fast Static Network with OPUS

The GPS observations at the hub station were submitted to OPUS

共http://www.ngs.noaa.gov/OPUS/兲. The OPUS solution used 96%
of the observations with 100% of the integer ambiguities fixed
and an overall RMS of 1.5 cm. The peak to peak errors were 1.1,
Fig. 1. Radial GPS network 1.2, and 3.0 cm in latitude, longitude, and ellipsoid height, re-
spectively. The NGS guidelines for a quality OPUS solution are
90% or more observations used, at least 50% ambiguities fixed,
With the short occupation times allowed with dual frequency RMS seldom exceeding 3 cm and peak-to-peak errors seldom ex-
GPS, the 2-h-plus recommended occupation time for OPUS may ceeding 5 cm 共Soler et al. 2006b兲. Given the above NGS guide-
become the most time-consuming component, particularly for lines, this OPUS run qualifies as a quality solution. The shortest
small radial surveys. However, if the short fast-static occupations baseline computed by OPUS was 12.5 km; the longest baseline
of the radial stations can themselves provide the ties to the NSRS, was 37.6 km with an average baseline length of 29.2 km.
then there is no need for the long occupations required for accu- The baselines radiating from the hub station were reduced
rate OPUS solutions. In addition the multiple ties to the NSRS using the weighted ambiguity vector estimator 共WAVE兲 processor
provided by the multiple occupations of the radial stations pro- in Trimble Geomatics Office 共TGO兲 version 1.63 using the obser-
vide more robust connection to the NSRS than a single OPUS tie. vation session for each radial station. All baselines were success-
OPUS-RS with its short occupation times can provide these mul- fully resolved with fixed solutions.
tiple ties to the NSRS.
To demonstrate this concept this paper will examine two GPS
networks that were constrained to the NSRS using OPUS. These
Table 2. Actual Session Lengths
same networks will then be constrained to the NSRS using mul-
tiple OPUS-RS ties. Comparing the results will demonstrate that Trimble
multiple OPUS-RS ties combined with fast static vectors can pro- Station Session FastStatic
vide coordinates consistent with longer OPUS solutions at the Id duration duration Comments
centimeter level with much less observation time. 2 15 min 8 min 6 SV
3 15 min 8 min 6 SV
4 15 min 8 min 6 SV
Radial Fast Static GPS Network 5 15 min 8 min 6 SV
6 15 min 13 min Briefly dropped below 6 SV
Fig. 1 illustrates a radial survey with five outer stations. This 2 15 min 8 min 6 SV
network is approximately 490 m in extent north–south and 124 m 3 15 min 8 min 6 SV
east–west. Each radial station was occupied twice using Trimble 4 21 min 30 s 21 min 30 s PDOP⬎ 6
FastStatic methods. Recommended occupation times for Trimble
5 15 min 10 min Briefly dropped below 6 SV
FastStatic depend on the number of GPS satellites continuously
6 15 min 15 min 5 SV
observed and the specified PDOP mask 共Trimble 2001兲. Table 1
Total Time 2 h 36 min 30 s
summarizes the recommended Trimble FastStatic session lengths.

126 CORS AND OPUS FOR ENGINEERS

Table 3. Summary of Adjustment of Individual GPS Baselines
Reference Chi square Reference Chi square
Length variance test variance test
Baseline 共m兲 共first iteration兲 共first iteration兲 共second iteration兲 共second iteration兲
1-2 304 0.443 Pass 0.654 Pass
1-3 305 111.873 Fail 2.669 Pass
1-4 416 2.092 Pass 1.115 Pass
1-5 448 10.760 Fail 1.372 Pass
1-6 93 1.865 Pass 1.224 Pass

A least-squares adjustment was performed on the GPS vectors. The extended data section of an OPUS-RS report includes the
Since each vector was individually observed there were no corre- covariance matrix of the point solution. Fig. 2 depicts a typical
lations between the individual vectors. Because of this, the adjust- covariance for a point solution in the OPUS-RS extended data
ment of the GPS baselines consists of five adjustments each with section. This covariance matrix is identical in appearance to the
a degree of freedom of 3 rather than a single adjustment with a covariance matrix in the OPUS extended data section, however,
degree of freedom of 15. In each case estimated centering errors they are derived differently. The point covariance matrix in an
of 1.0 mm, horizontally and vertically, were modeled in the ad- OPUS-RS solution is the result of a network solution that in-
justment. A second iteration was performed even if the first ad- cludes both the reference stations and the rover station; it is a
justment passed the chi square test to more accurately scale the submatrix of a larger covariance matrix that includes the vari-
covariance matrix of the adjustment. The results of the adjustment ances and covariances for all the stations in the network solution.
are summarized in Table 3. The covariance matrix from an OPUS point solution is derived
Using the tau statistic 共Pope 1976兲 as the criteria, there were using linear error propagation and some empirical determination
no outliers in these adjustments. from the three vectors used to establish the OPUS point solution.
The linear error propagation used by OPUS to form the covari-
ance matrix is formally correct but easily contaminated by blun-
Radial Fast Static Network with OPUS-RS ders. The primary quality control statistic for OPUS is the
peak-to-peak errors for each coordinate as the peak-to-peak errors
When performing Trimble FastStatic surveys, unless the survey is more clearly reveal the presence of a blunder than a propagated
started and ended for each occupation, the GPS observations are variance 共Schwarz 2006兲.
all stored in a single file. In order to submit the GPS observations The inclusion of the covariance matrix in an OPUS solution
at the radial stations to OPUS-RS this file must be broken up into makes it possible to include coordinates as observations in a least
individual RINEX observation files. The combined Trimble ob- squares adjustment 共Lazio 2006兲. The same principle applies to
servation file was converted to RINEX format using the Trimble the covariance matrix included with the extended data of OPUS-
Dat2Rin utility. Each session was then manually parsed into indi- RS. Five individual least squares adjustments, each with a degree
vidual RINEX files. These individual RINEX files were then sub- of freedom of 3, were performed using the two OPUS-RS coor-
mitted to OPUS-RS. Every file submitted was successfully dinate observations on each radial station. After the first iteration
resolved by OPUS-RS. The six CORS used as reference stations of the adjustment, the coordinate observation covariance matrices
by OPUS-RS included the CORS used by OPUS. The shortest were scaled by the reference variance and the adjustment was
baseline computed by OPUS-RS was 12.5 km; the longest base- rerun. The reference variances for each adjustment are tabulated
line was 56.1 km with an average of 39.0 km. The three CORS in Table 5.
used by OPUS were the closest of the six CORS used by OPUS- In the case of Stations 4 and 5, the outlier observations were
RS. Table 4 lists the coordinate differences between the two retained in the adjustment as the residuals were within the hori-
OPUS-RS submissions at each station. zontal network accuracy listed with the covariance matrix of the
Station 6 is approximately 4 m from a 6-ft chain link fence. two OPUS-RS solutions.
However, the individual baselines from the hub station were well Once the covariance matrices for the GPS vectors and the
resolved with no outliers in the least-squares adjustment. OPUS-RS coordinate observations were properly scaled, the GPS
vectors and the OPUS-RS coordinate observations were included
in a unified adjustment. For this adjustment, no station was held
Table 4. Differences between OPUS-RS Coordinates 共15 min兲 Sessions fixed. The OPUS-RS coordinate observations provide ties to the
Session B–Session A
dN dE dh
Station 共m兲 共m兲 共m兲
2 −0.001 −0.013 0.044
3 −0.030 0.016 0.003
4 −0.001 −0.012 −0.068
5 0.003 −0.004 −0.058
6 −0.129 −2.752 −0.406
RMS 0.059 1.231 0.187
Excluding 6 0.013 0.012 0.046 Fig. 2. Typical OPUS-RS covariance matrix for point solution

CORS AND OPUS FOR ENGINEERS 127

Table 5. Summary of Adjustment of OPUS-RS Coordinates
Reference Reference
variance variance
Station 共first iteration兲 共second iteration兲 Comments
2 11.049 1.0 —
3 52.556 1.0 —
4 5.314 1.0 One longitude outlier with 4.8 mm residual
5 3.544 1.0 One longitude outlier with 2.5 mm residual
6 268,928.348 — No second adjustment

NSRS. The OPUS solution was not considered in this adjustment. values determined during the network solution. With one excep-
The coordinates of every station including the hub were allowed tion all the network coordinates constrained to the OPUS-RS so-
to vary in the adjustment. lutions are within one centimeter horizontally of the network
The OPUS-RS solutions on Station 6 resulted in two signifi- fixed to the OPUS solution.
cantly different coordinates. One of the goals of unified adjust-
ment was to determine which OPUS-RS determination of Station
6 was most consistent with the GPS vectors and the other Shorten the OPUS-RS Sessions
OPUS-RS determinations. Three individual adjustments were per-
formed. The reference variance for each of these adjustments is Looking again at the FastStatic session lengths, the difference
summarized in Table 6. between the observed sessions and the recommended minimum
Based on the reference variance of the least-squares adjust- Trimble FastStatic sessions is 1-h 4-min for 10 sessions. The po-
ment that included the OPUS-RS coordinate observations for Sta- tential for time savings using the minimum Trimble FastStatic
tion 6 from Session A, the OPUS-RS coordinate observations session lengths is evident. Using the FastStatic session lengths
from Session A were rejected. with no delays traveling between radial stations, the survey could
potentially have been completed before the 2-h recommended
OPUS session duration.
Coordinate Comparison of OPUS and OPUS-RS To see how the shorter observation sessions affect the adjust-
Derived Coordinates ment, the RINEX files for the individual radial stations were win-
dowed, using TEQC from UNAVCO 共http://facility.unavco.org/
Table 7 lists the difference between the coordinates determined in software/teqc/teqc.html兲, to the Trimble FastStatic session length.
the least-squares adjustment using OPUS-RS coordinate observa- These RINEX files were submitted to OPUS-RS. Every
tions and the adjustment that fixed the coordinate of the 3-h 53- OPUS-RS submission was successfully resolved. Table 8 lists the
min OPUS session. differences between OPUS-RS coordinate solutions.
Although slightly biased in the easting and ellipsoid height, Comparing Tables 4 and 8, the difference between coordinates
the differences between the network coordinates constrained to determined using the shorter sessions is greater than the differ-
the 15-min OPUS-RS solutions and the network fixed to the 3-h ence between coordinates determined using the longer sessions.
53-min OPUS solution are well within the peak-to-peak errors for The estimated errors for the coordinates, as indicated by the hori-
the OPUS solution. One possible explanation for the vertical bias zontal and vertical network accuracies, are also larger.
is the different way OPUS and OPUS-RS model atmospheric de-
lays with OPUS using a seasonal model and OPUS-RS using
Least-Squares Adjustment Using Shortened
OPUS-RS Sessions
Table 6. Reference Variance for Adjustments Including OPUS-RS
Coordinates at Station 6
Following the previously used methodology, the OPUS-RS coor-
Reference dinate observations were adjusted individually in a least-squares
Comments variance adjustment. Each least-squares adjustment had a degree of free-
No coordinate observation at Station 6 1.131
OPUS-RS Session A coordinate observation 19,122.570
OPUS-RS Session B coordinate observation 1.130
Table 8. Differences between OPUS-RS Coordinates 共Trimble FastStatic
Sessions兲
Table 7. Comparison of Adjusted Coordinates 共15 min OPUS-RS Minus
OPUS兲 Session B–Session A
dN dE dh dN dE dh
Station 共m兲 共m兲 共m兲 Station 共m兲 共m兲 共m兲
1 0.001 0.007 0.007 2 −0.002 −0.016 0.073
2 0.000 0.007 0.008 3 −0.160 0.101 −0.068
3 −0.002 0.010 0.004 4 0.003 0.013 0.079
4 0.001 0.007 0.007 5 −0.014 −0.014 −0.095
5 0.003 0.007 0.004 6 −0.460 0.040 −0.649
6 0.000 0.005 0.008 RMS 0.218 0.050 0.299

128 CORS AND OPUS FOR ENGINEERS

Table 9. Summary of Adjustment of OPUS-RS Coordinates Table 12. Standard Deviations of Inverse between Stations 5 and 6
Reference Reference Inversed quantity Standard deviation
variance variance
Grid distance 0.031 m
Station 共first iteration兲 共second iteration兲 Comments
Grid azimuth 10⬙
2 11.117 1.0 No outliers Height difference 0.344 m
3 859.775 1.0 No outliers
4 4.903 1.0 No outliers
5 11.791 1.0 No outliers bias of 3 cm matches the peak-to-peak errors in the OPUS
6 198.516 1.0 No outliers solution.
The near-uniform translation between the network fixed to the
OPUS solution and the network constrained to the OPUS-RS co-
ordinate observations reflects the contribution of the GPS vectors
dom of three. The coordinate covariance matrices were scaled by
to the scale and orientation of the network. When combining
the reference variance and adjusted a second time and results
OPUS-RS coordinate observations with GPS vectors, the GPS
tabulated in Table 9.
vectors provide the scale and orientation of the network while the
The larger reference variances for the adjustments of Stations
OPUS-RS coordinate observations provide the location. As an
3 and 6 reflect the large coordinate differences between Sessions
illustration, Table 11 contains the NAD83关CORS96兴 New York
A and B at those stations. There were, however, no outliers and
State Plane Coordinates, Eastern Zone and covariance matrices
the adjustment results were accepted.
for Stations 5 and 6, after adjusting the OPUS-RS coordinate
The original GPS vectors were now combined with the
observations alone.
OPUS-RS coordinate observations from the shorter sessions. The
Using standard error propagation methods, the standard devia-
original vectors were used so that the only difference in this ad-
tion for the grid distance, azimuth and difference in elevation
justment when compared to the 15 min OPUS-RS adjustment
between Stations 5 and 6 is shown in Table 12. Table 13 contains
would be the result of using the shorter OPUS-RS coordinate
the NAD 83关CORS96兴 New York State Plane Coordinates, East-
observations. With 10 GPS vectors and 10 coordinate observa-
ern Zone and covariance matrix of Stations 5 and 6 from the
tions and six three-dimensional 共3D兲 coordinates to determine,
adjustment that included both OPUS-RS coordinate observations
this adjustment had a degree of freedom of 42. The adjustment
and GPS vectors. The standard deviations for the grid distance,
passed the chi square test with a reference variance of 1.037.
azimuth and difference in elevation between Stations 5 and 6 are
Table 10 contains the coordinated differences between the ad-
tabulated in Table 14. The smaller standard deviations reflect the
justed network coordinates in the network containing multiple
contribution of the GPS vectors to the network.
short OPUS-RS sessions and the adjusted network coordinates
determined by fixing the 3-h 53-min OPUS session.
Horizontally, the results are virtually identical compared to the
Fewer Network Stations
longer OPUS-RS observation session. With respect to horizontal
location even with short observation sessions, the combination of
Smaller networks would benefit even more from the time savings
OPUS-RS coordinate observations and GPS vectors can repro-
of short OPUS-RS observations than larger networks. That is be-
duce a 3 h 53 min OPUS session within a centimeter. The vertical
cause in large networks the hub receiver is able to log more data
while the rover travels to and occupies more stations. The net-
work in Fig. 3 has only three stations.
Table 10. Comparison of Adjusted Coordinates 共Shortened OPUS-RS This network, approximately 0.9 km in extent north–south and
Minus OPUS兲 2.9 km in extent east–west, was originally constrained to the
dN dE dh NSRS by two, approximately 2 h, OPUS sessions at Stations 90
Station 共m兲 共m兲 共m兲 and 66. While the base receiver occupied Station 90 for 2 h
1 0.001 0.006 0.031 11 min, the rover occupied Stations 66 and 79 for 45 min each. At
2 0.000 0.006 0.031
the end of the session on Station 90, the receiver that was previ-
ously the rover occupied Station 66 for 2 h 7 min while the other
3 −0.001 0.007 0.029
receiver occupied Stations 79 and 90 for 45 min each.
4 0.001 0.006 0.030
The GPS observations from the 2 h 11 min session at Station
5 0.002 0.006 0.030
90 and the 2 h 7 min session at Station 66 were submitted to
6 0.001 0.006 0.031

Table 11. Coordinates and Covariance Matrices of Stations 5 and 6 Using OPUS-RS Alone
Covariance matrix
Coordinate N E h
Station 共m兲 共m2兲 共m2兲 共m2兲
5 N 243,955.1663 0.0000566879 0.0000062649 −0.0000113019
E 196,107.2521 0.0000308013 −0.0001121349
h −1.5302 0.0030321738
6 N 244,445.0726 0.0009345588 0.0001591841 0.0015030975
E 196,044.2583 0.0005016606 −0.0013233095
h 4.9015 0.1150251696

CORS AND OPUS FOR ENGINEERS 129

Table 13. Coordinates and Covariance Matrices of Stations 5 and 6 Using GPS Vectors and OPUS-RS
Covariance matrix

Coordinate N E h
Station 共m兲 共m2兲 共m2兲 共m2兲
5 N 243,955.1606 0.0000152205 0.0000000133 0.0000002572
E 196,107.2482 0.0000095293 −0.0000082890
h −1.4853 0.0005944124
6 N 244,445.0771 0.0000122845 0.0000001979 −0.0000005185
E 196,044.2796 0.0000087511 −0.0000033549
h 4.9177 0.0005836801

OPUS. The results of both OPUS runs met the criteria for a qual-
ity OPUS solution. For the six baselines computed for two OPUS
sessions, the shortest baseline computed by OPUS was 16.7 km;
the longest baseline was 32.16 km with an average baseline
length of 23.0 km.
The four GPS vectors were adjusted in a minimally con-
strained adjustment and the covariance matrix scaled by the ref-
erence variance. There were no outlier observations among the
GPS vectors. After the minimally constrained GPS vector net-
work passed the chi square test, the OPUS coordinate observa-
tions were added to the network. When adjusted, this network
failed the chi square test with a reference variance of 3.439. The
reference variance of the coordinate observations alone was
8.337. The covariance matrices of OPUS coordinate observations
were scaled by 8.337 and the adjustment run again. The second
adjustment passed the chi square test with a reference variance of
1.246. The coordinates resulting from this network adjustment
will later be compared in Table 18 to those derived from the same
network using shorter observation sessions and constrained to
OPUS-RS coordinate observations.
To simulate a FastStatic network using OPUS-RS observations
the GPS observation files were windowed using TEQC. Two 10-
min RINEX observation files were windowed from each of the
2-h observation sessions at Stations 66 and 90. These 10-min
sessions correspond to the start of the 45-min sessions by the
rover stations. The first 10 min of the 45-min observation sessions
were also windowed using TEQC. This created four 10-min ses-
sions as depicted in Table 15.
Four vectors were processed using the WAVE processor in
TGO. Eight GPS observation files were submitted to OPUS-RS,
three each at Stations 66 and 90 and two at Station 79. All
Table 14. Standard Deviation of Inverse between Stations 5 and 6
Inversed quantity Standard deviation
OPUS-RS files were successfully solved. The shortest baseline
computed by OPUS-RS was 16.7 km; the longest baseline was
63.0 km with an average of 34.9 km. As in the radial network, the
three CORS used by OPUS were the closest of the six CORS
used by OPUS-RS.
Submitting data to OPUS-RS for both ends of a GPS vector in
a single session raises questions of redundancy and dependent
vectors. Between the six CORS used by OPUS-RS and the two
receivers observing in the field, it is possible to compute 28 vec-
tors, only seven of which are independent vectors. Two OPUS-RS
sessions plus the network vector yield 13 vectors. However, the
vectors computed by OPUS-RS are not treated as vectors in the
local network but rather as coordinate observations. These coor-
dinate observations are so-called derived observations 共Leick
2004, p. 96兲, which are the result of an independent least-squares
adjustment of the six vectors computed by OPUS-RS. While it is
true that there is a dependency between the data used to compute
the network vector and the OPUS-RS solutions, treating the
OPUS-RS solution and the WAVE baseline processing as two
different observation types provides a degree of autonomy.
Greater observational redundancy would be achieved by submit-
ting GPS observations from only one end of the local network
vector to OPUS-RS at the loss of redundancy for the coordinate
observations. As demonstrated by the large differences in coordi-
nates between sessions at Station 6 in the original radial network,
a single OPUS-RS observation is not a reliable constraint.
Table 16 shows the OPUS-RS coordinate differences for each
station using the results from the last submitted file as the bench-
mark. For example, for Station 66, the coordinates from
Table 15. Ten Minute Sessions
Time
Session 共local兲 Baseline

Grid distance 0.005 m A 9:30—9:40 90-66

Grid azimuth 2⬙ B 10:30—10:40 90-79
Height difference 0.0343 m C 11:30—11:40 66-79
D 13:30—13:40 66-90

Table 16. Differences between OPUS-RS Coordinates 共10 min Sessions兲

dN dE dh
Station 共m兲 共m兲 共m兲 Session
66 −0.007 −0.004 0.054 D-A
66 −0.001 0.004 0.050 D-C
79 0.001 0.006 −0.020 C-B
90 −0.004 0.000 −0.003 D-A
Fig. 3. Smaller network 90 −0.006 −0.001 −0.056 D-B

130 CORS AND OPUS FOR ENGINEERS

Table 17. Summary of Adjustment of OPUS-RS Coordinates
Reference Reference
Degrees variance variance
Station of freedom 共first iteration兲 共second iteration兲
66 6 2.572 1.000
79 3 2.014 1.000
90 6 4.090 1.000
OPUS-RS Session A and OPUS-RS Session C were subtracted
from the coordinates derived in OPUS-RS Session D.
The four GPS vectors were adjusted in a minimally con-
strained network. This adjustment had a degree of freedom of 6.
The covariance matrix was scaled by the reference variance and
the adjustment run again. There were no outlier observations and
the adjustment passed the chi square test.
Following the pattern in the radial network the OPUS-RS co-
ordinate observations were adjusted individually in a least-
squares adjustment. The least-squares adjustments at Stations 66
and 90 had a degree of freedom of 6. The least-squares adjust-
ment at Station 79 had a degree of freedom of 3. The coordinate
covariance matrices were scaled by the reference variance and
adjusted a second time. There were no outliers in any of the
adjustments. The results are summarized in Table 17.
The GPS vectors and the OPUS-RS coordinate observations
were then combined into a single network adjustment. This ad-
justment consisted of four GPS vectors and eight OPUS-RS
coordinate observations. With three 3D coordinates to be deter-
mined the adjustment has a degree of freedom of 27. The refer-
ence variance for this adjustment was 1.866, which failed the chi
square test. The maximum reference variance that will pass the
chi square test with 27 degrees of freedom is 1.600. No observa-
tions were flagged as outliers.
The reference variance of the minimally constrained adjust-
ment that was performed on the four GPS vectors passed the chi
square test, and the reference variance of individual adjustments
for the coordinate observations passed the chi square test. This
implies an inconsistency between the OPUS-RS coordinate obser-
vations and the GPS vectors. Eliminating all OPUS-RS coordi-
nate observations at Stations 66 and 79 actually resulted in a
higher reference variance. After eliminating the OPUS-RS coor-
dinate observations at Station 90, the reference variance was
1.038 with a degree of freedom of 18. By reintroducing the
OPUS-RS coordinate observations at Station 90 back into the
adjustment, one by one, it was determined that the OPUS-RS
coordinate observations from Session A caused the chi square test
on the reference variance to fail.
In a least-squares adjustment, blind rejection of an observation
based on a statistical test is not recommended 共Leick 2004,
p 160兲. At the 95% confidence level there is a 5% chance of
committing a Type I error. Stated another way, there is a one in 20
chance of rejecting a valid observation. In this case, the coordi-
nate observations at Station 90 during Session A differed from the
same observations during Session D by only 4, 0, and −3 mm in
N, E, and h, respectively. The coordinate observations for Session
D were not flagged as outliers in the individual adjustment of
OPUS-RS coordinate observations at Station 90. In other words,
the coordinate observations for Session A were consistent with the
coordinate observations for the other two sessions. It was decided
to leave the coordinate observations for Station 90 from Session
A in the adjustment based on the conclusion that rejecting these
coordinate observations would likely commit a Type I error.
CORS AND OPUS FOR ENGINEERS
Table 18. Comparison of Adjusted Coordinates Using OPUS-RS
Coordinate Observations and OPUS Coordinate Observations
dN dE dh
Station 共m兲 共m兲 共m兲
66 0.007 0.004 0.021
79 0.007 0.003 0.016
79 −0.006 −0.006 −0.019
The resulting coordinates for the adjustments constrained to
OPUS versus OPUS-RS are compiled in Table 18.
No horizontal coordinate differs by more than 9 mm. The
maximum difference vertically is 21 mm. The total observation
time for the network using OPUS-RS constraints is 40 min. The
total observation time for the network using OPUS constraints is
4 h 18 min. This constitutes a time savings of 3 h 38 min or 84%.
Conclusion
While not enough data was presented in this paper to support firm
conclusions, it appears that in aggregate, the combination of short
OPUS-RS coordinate observations and GPS vectors can repro-
duce the results of much longer OPUS observation sessions at the
centimeter level. The longer average and maximum baselines
computed in the OPUS-RS solutions did not seem to impact these
results.
A single OPUS-RS observation session is not as reliable as a
single long OPUS observation session. This is particularly illus-
trated by the 2.752 m difference between the two OPUS-RS de-
terminations for the longitude of Station 6 in the radial network.
In addition to providing blunder detection, the second OPUS-RS
coordinate and covariance matrix provides an objective means of
scaling the covariance matrices of the coordinate observations. As
seen in the adjustment of the OPUS-RS coordinate observations
from the shorter sessions of the radial network, the reference vari-
ance can vary considerably. Without the second OPUS-RS obser-
vation, there is no objective means to establish the reference
variance for the covariance matrix.
For networks of limited extent, using OPUS-RS coordinate
observations with FastStatic GPS vectors may provide significant
time savings while maintaining results comparable to much
longer OPUS observation sessions. A blunder in a single OPUS
coordinate is not detectable in a network that is minimally con-
strained to a single OPUS solution. Multiple OPUS-RS coordi-
nate observations provide more robust ties to the NSRS than a
single OPUS coordinate.
Further research is needed to confirm the reliability of
OPUS-RS as a means of constraining networks to the National
Spatial Reference System. This research should include the effect
of distance from the CORS used in OPUS and OPUS-RS solu-
tions. Other possible avenues of research are the possibilities of
biases between OPUS and OPUS-RS solutions especially with
regard to neutral atmospheric delays.
Acknowledgments
The writer gratefully acknowledges comments and suggestions of
the three anonymous reviewers whose constructive criticisms
have improved the content and presentation of this paper.
131
References
Kashani, I., Wielgosz, P., Grejner-Brezinska, D. A., and Mader, G. L.
共2005兲. “A new network-based rapid-static module for the NGS online
positioning user service—OPUS-RS.” Proc., ION 61st Annual Meet-
ing, Cambridge, Mass., 928–936.
Lazio, P. 共2006兲. “OPUS observations.” Surv. Land Inf. Sys., 66共3兲, 185–
194.
Leick, A. 共2004兲. GPS satellite surveying, 3rd Ed., Wiley, Hoboken, N.J.
Mader, G. L. Weston, N. D., Morrison, M. L., and Milbert, D. G. 共2003兲.
“The online positioning user service 共OPUS兲.” Prof. Surveyor, 23共5兲,
26–30.
Marshall, J., Schenwerk, M., Snay, R., and Gutman, S. 共2001兲. “The
effect of the MAPS weather model on GPS-determined ellipsoidal
132 CORS AND OPUS FOR ENGINEERS
heights.” GPS Solutions, 10共1兲, 1–14.
Pope, A. J. 共1976兲. “The statistics of residuals and the detection of out-
liers.” NOAA Technical Rep. NOS 65 NGS 1, U.S. Dept. of Com-
merce, Rockville.
Schwarz, C. R. 共2006兲. “Statistics of range of a set of normally distrib-
uted numbers.” J. Surv. Eng., 132共4兲, 155–159.
Soler, T., Michalak, P., Weston, N. D., Snay, R. A., and Foote, R. H.
共2006a兲. “Accuracy of OPUS solutions for 1- to 4-h observing ses-
sions.” GPS Solutions, 10共1兲, 45–55.
Soler, T., Weston, N. D., Snay, R. A., Mader, G. L., and Foote, R. H.
共2006b兲. “Precise georeferencing using the on-line positioning user
service 共OPUS兲.” Proc., XXIII Int. FIG Congress, Munich, Germany.
Trimble Navigation Ltd Documentation Group 共Trimble兲. 共2001兲. Trimble
survey controller reference manual, Vol. 2, Trimble Navigation Lim-
ited, Sunnyvale, Calif.
 17
Efficiency and Reliability of Ambiguity Resolution
in Network-Based Real-Time Kinematic GPS
Dorota A. Grejner-Brzezinska1; Israel Kashani2; Pawel Wielgosz3; Dru A. Smith4; Paul S. J. Spencer5;
Douglas S. Robertson6; and Gerald L. Mader7

Abstract: Fast and reliable ambiguity resolution 共AR兲 is particularly challenging in long-range real-time kinematic 共RTK兲 global
positioning system 共GPS兲, since the atmospheric errors decorrelate with the increasing base-rover separation, effectively reducing the
success rate of integer fixing. In order to improve the speed and the success rate of AR, external atmospheric corrections are required. In
this paper, four different methods of ionosphere modeling are used as a source of external information, and their impact on the speed and
reliability of AR and the rover positioning accuracy is discussed. An example data set, collected by the Ohio Continuously Operating
Reference Stations on August 31, 2003, is analyzed, with special emphasis on varying ionospheric conditions during the course of the day
in order to study the applicability of these ionospheric models to high-accuracy RTK GPS. In particular, the time-to-fix, the level of AR
success, and the accuracy of the resulting rover coordinates are analyzed. Each method displays a different level of accuracy, and thus
varying applicability to support AR under changing ionospheric conditions.
DOI: 10.1061/共ASCE兲0733-9453共2007兲133:2共56兲
CE Database subject headings: Global positioning; Errors; Networks; Reliability.

Introduction the resulting position coordinates. Traditional AR algorithms, de-

In precise relative global positioning system 共GPS兲 positioning
based on double-differenced 共DD兲 carrier phase measurements,
the key issue is to resolve the ambiguities to their integer values,
and subsequently, to derive an improved estimator of the baseline
components 共i.e., fixed solution兲. Therefore, the success of the
ambiguity resolution 共AR兲 effectively determines the quality of
1
Associate Professor, Satellite Positioning and Inertial Navigation
共SPIN兲 Laboratory, Dept. of Civil and Environmental Engineering and
Geodetic Science, The Ohio State Univ., 470 Hitchcock Hall, Columbus,
OH 43210-1275. E-mail: dbrzezinska@osu.edu
2
Postdoctoral Researcher, Satellite Positioning and Inertial Navigation
共SPIN兲 Laboratory, Dept. of Civil and Environmental Engineering and
Geodetic Science, The Ohio State Univ., 470 Hitchcock Hall, Columbus,
OH 43210-1275.
3
Postdoctoral Researcher, Satellite Positioning and Inertial Navigation
共SPIN兲 Laboratory, Dept. of Civil and Environmental Engineering and
Geodetic Science, The Ohio State Univ., 470 Hitchcock Hall, Columbus,
OH 43210-1275.
4
Chief Geodesist, NOAA National Geodetic Survey, 1315 East-West
Hwy., Silver Spring, MD 20910.
5 al. 2001; Fotopoulos and Cannon 2001; Rizos 2002; Jensen 2002;
Visiting Research Physicist, National Geodetic Survey, NOS/NOAA
and Cooperative Institute for Research in Environmental Sciences
共CIRES兲, Univ. of Colorado/NOAA, Boulder, CO 80309-0216.
6
Geodesist, National Geodetic Survey, NOS/NOAA and Cooperative
Institute for Research in Environmental Sciences 共CIRES兲, Univ. of
Colorado/NOAA, Boulder, CO 80309-0216.
7
Chief of the Geosciences Research Division, NOAA National
Geodetic Survey, 1315 East-West Hwy., Silver Spring, MD 20910.
Note. Discussion open until October 1, 2007. Separate discussions
must be submitted for individual papers. To extend the closing date by
one month, a written request must be filed with the ASCE Managing
Editor. The manuscript for this paper was submitted for review and pos-
sible publication on May 11, 2006; approved on June 30, 2006. This
paper is part of the Journal of Surveying Engineering, Vol. 133, No. 2,
May 1, 2007. ©ASCE, ISSN 0733-9453/2007/2-56–65/$25.00.
veloped for static applications, may take the advantage of several
hours of continuous tracking and varying GPS geometry, allowing
usually for reliable AR, even with a substantial base-rover sepa-
ration. The redundancy in the system normally allows for an ex-
tended mathematical model, where the remaining differential
effects, such as atmospheric errors, could be estimated, and thus
removed from the final positioning solution. On the other hand,
methods for rapid-static and kinematic applications have been
developed, where the occupation times are usually at the order of
seconds to minutes, and the distances between the reference and
the rover stations are usually no longer than 10– 20 km. Several
new techniques were recently proposed, where networks of Con-
tinuously Operating Reference Stations 共CORS兲 were used to
derive external information supporting kinematic 共and static兲 po-
sitioning, resulting in efficient algorithms virtually independent
from the base-rover separation. The two most commonly used
methods are network-based estimation of atmospheric 共iono-
spheric and tropospheric兲 corrections that can be broadcast to the
user, or mathematical creation of virtual reference stations 共VRS兲
共Raquet 1998; Vollath et al. 2000, 2002; Fortes et al. 2000; Dai et
Mader and Morrison 2002; Fortes 2002; Wanninger 2002; Bock
et al. 2003; Euler et al. 2001, 2004; Kashani et al. 2004, 2005兲.
These methods, by providing either corrected observables using
atmospheric corrections derived from the reference network, or
by forming synthetic data for a mathematically defined reference
station close to the approximate location, facilitate the reduction
of a long-range kinematic 共or static兲 baseline to a short-range case
共i.e., the atmospheric errors are reduced to a negligible level兲.
This, in theory, should increase the computational efficiency of
the ambiguity search process and allow fast and accurate position
estimation.
In kinematic positioning, AR may be performed on-the-fly
共OTF兲 or instantaneously 共single-epoch solution兲. OTF requires

CORS AND OPUS FOR ENGINEERS 133

information accumulation over several epochs of data, while the
instantaneous solution treats every epoch independently. Clearly,
the later approach is much more challenging 共Kim and Langley
2000兲. The advantage of this method is, however, that any incor-
rectly resolved ambiguities or cycle slips do not affect subsequent
epochs. Still, in order to resolve the ambiguities instantaneously
over long baselines, very accurate atmospheric corrections must
be available, which is not always possible 共Odijk 2001; Kashani
et al. 2004兲. An additional challenge is the ambiguity validation
that is hard to accomplish due to low redundancy in the system
共Grejner-Brzezinska et al. 2005c兲.
This paper presents the analysis of the speed and reliability of
the OTF AR process in a long-baseline real-time kinematic 共RTK兲
scenario, with the externally provided ionospheric models and
rapid International GNSS Service 共IGS兲 orbits. Four GPS
network-based ionospheric models with different temporal and
spatial resolutions are considered. These models are tested under
varying ionospheric conditions in order to determine their suit-
ability to support OTF AR, and subsequently, precise kinematic
positioning. The results presented in this paper are direct continu-
ation of an earlier work presented in Grejner-Brzezinska et al.
共2004兲, where the first test analyses of the ionospheric models
were presented. In Grejner-Brzezinska et al. 共2004兲, the emphasis
was on the comparison of the quality of the ionospheric models
considered with respect to the reference DD ionospheric delays,
derived from the L4 共geometry-free兲 carrier phase linear combi-
nation with fixed integer ambiguities. All analyses were per-
formed using the Multi-Purpose GPS Processing Software
共MPGPS兲, developed by the Satellite Positioning and Inertial
Navigation 共SPIN兲 Laboratory at The Ohio State University. It
was also demonstrated that the MPGPS-derived ionospheric cor-
rections may be suitable for instantaneous AR, while the other
investigated methods could not support the single-epoch solution.
In this paper, the primary focus is on the OTF AR supported by
the selected ionospheric models. The time needed to fix the am-
biguities to their integer values, the AR success rate, and the
accuracy of the resulting kinematic positioning are tested and
analyzed.
Methodology: Ionospheric Models
and Positioning Algorithm
While more details on the ionospheric models tested are presented
in Grejner-Brzezinska et al. 共2004兲 and in the references listed
here, a brief description of each model is included below for
completeness.
• MPGPS-NR: Network RTK 共NR兲 carrier phase-based model,
decomposed from DD ionospheric delays 共Kashani et al.
2004兲, interpolated to the rover location. It is a local model,
with high temporal resolution, equivalent to the GPS data rate.
In this case, the single-layer ionospheric model is assumed
with an ellipsoidal height of 400 km. MPGPS-NR is derived
here from a subnetwork of four stations of the Ohio CORS
network 共see Fig. 1兲; in general, three or more reference sta-
tions can be used. The decomposed, zero-difference 共ZD兲
ionospheric delays 共slant兲 are interpolated for the user location
on the satellite-by-satellite basis 关vertical delays, referred to
the ionosphere pierce points 共IPP兲 can also be used兴. Once the
ZD ionospheric delays are interpolated to the approximate user
location, the DD delays between reference station共s兲 and the
rover can be constructed.
• ICON: Regional, absolute model based on undifferenced dual-
134 CORS AND OPUS FOR ENGINEERS
Fig. 1. CORS subnetwork used in the experiments
frequency ambiguous carrier phase data 共Smith 2004兲. The
ionosphere is assumed to be a single layer of an ellipsoidal
height of 300 km, and the geographic locations of the GPS
ground stations must allow simultaneous observation of satel-
lites by a number of stations. In this study, the ionospheric
delay values were computed using around 350 U.S. CORS
stations, including 16 primary Ohio CORS stations. The cor-
rections are represented as a slant delay along the reference
receiver–satellite path, and referred to the ionospheric pierce
points. To support rover positioning, these corrections are in-
terpolated for the user/satellite pair using linear interpolation.
The temporal resolution of this model is equivalent to the data
sampling rate.
• MAGIC: Regional tomographic model using pseudorange-
leveled phase data 共Spencer et al. 2004兲. In this study, about
150 U.S. CORS and IGS stations, including one Ohio CORS
station 共Akron, which is not used in this study兲, were used to
derive ionospheric delays for the continental United States.
This model estimates coefficients of empirical orthogonal
functions 共EOFs兲 that represent vertical variation of electron
density 共Ne兲 at a selected grid 共1.5° ⫻ 4.0° spacing in latitude
and longitude, respectively兲. The solution is quantized with
15 min time-steps. The gridded Ne values are then used to
interpolate the Ne at any point in the ionosphere within the
defined grid 共i.e., the satellite location, as observed by the user,
must be within the grid coverage兲, which is then integrated to
obtain the total electron content 共TEC兲 that can be converted
to the ionospheric delay, used directly to correct base and
rover data in the rover position estimation procedure.
• IGS GIM 共Global Ionosphere Map兲: A weighted combination
of several global models developed independently by the IGS
Ionosphere Associate Analysis Centers 共IAACs兲. The com-
bined maps have a spatial resolution of 2.5° and 5.0° in lati-
tude and longitude, respectively, and a 2-h temporal resolution
共Feltens and Jakowski 2002兲. IGS GIM assumes a single-layer
ionosphere at an ellipsoidal height of 450 km. To convert ver-
tical TEC 共VTEC兲 from GIMs into line-of-sight slant TEC, a
modified single-layer model 共MSLM兲 mapping function is

Fig. 2. Baselines analyzed in the experiments
adopted 共Schaer et al. 1998兲. GIMs provide absolute TEC in
the ionosphere map exchange format 共IONEX兲 共Schaer et al.
1998兲. In this study, the ionospheric delays were interpolated
for the rover and base receiver locations using Kriging, and
were subsequently used to form DD corrections in the rover-
positioning step.
ICON and MAGIC are two National Geodetic Survey 共NGS兲
ionospheric products, developed for the continental United States.
Both models are prototypes, part of the ongoing research
projects, and are currently available to the general public for test-
ing and evaluation purposes 具http://www.noaanews.noaa.gov/
stories2004/s2333.htm典. It should be pointed out that only
four example models were selected for testing in this paper,
while vast literature exists on the topic of ionosphere modeling
with GPS 共El-Arini et al. 1994; Komjathy and Langley 1996;
Komjathy 1997; Sardon and Zarraoa 1997; Skone 1998; Schaer
1999; Mannucci et al. 1999; Hansen et al. 2000a,b; Skone 2000;
Liao and Gao 2000; Komjathy et al. 2002; Leandro 2004; Rho
et al. 2004; Kolb et al. 2005; Rideout and Coster 2006兲.
Reference Ionosphere
The reference ionosphere is derived as DD ionospheric delays
from a network solution, using dual-frequency carrier phase and
pseudorange data 共Kashani et al. 2005兲. In the network solution,
the following parameters are estimated: undifferenced tropo-
spheric total zenith delay 共TZD兲, estimated for each station every
two hours; DD ionospheric delays, estimated every epoch; and
DD ambiguities on L1 and L2. The coordinates of the CORS
stations are considered known, which makes the AR for the ref-
erence network much easier to perform, even for long baselines
共i.e., ⬃200 km between the CORS stations兲. The least-squares
ambiguity decorrelation adjustment 共LAMBDA兲 method is used
to fix the ambiguities to their integer values 共Teunissen 1994; de
Jonge and Tiberius 1996兲, and the W-ratio test 共Wang et al. 1998兲
is used for AR validation. Once the ambiguities are resolved, the
L4 linear combination is used to estimate the final reference DD
ionosphere. When the reference ionosphere is formed, the simu-
CORS AND OPUS FOR ENGINEERS
Table 1. Statistics of the Ionospheric Delay Residuals with respect to the
Reference Ionosphere within ±5 cm Limit 共24-h Data Set兲
Residuals in 关%兴 within the ±5 cm limit
63-km 98-km
baseline baseline
MPGPS-NR 94.2 94.2
ICON 31.9 32.5
MAGIC 83.3 67.1
IGS GIM 71.4 54.3
lated rover station 共here, KNTN兲 is included in the network solu-
tion. The same method, but excluding KNTN, is used to form the
DD ionospheric model that is subsequently decomposed to the
biased undifferenced corrections 共MPGPS-NR model兲 and inter-
polated for KNTN location. In the analyses presented here, the
Ohio CORS subnetwork 共KNTN, COLB, SIDN, DEFI, TIFF sta-
tions兲 illustrated in Fig. 1 was used.
RTK Positioning Algorithm
The rover positioning algorithm in MPGPS is based on the same
functional model as the network solution, with TZD supplied by
the MPGPS network solution and the ionospheric corrections pro-
vided externally by each tested model. Both network and single-
baseline modes can be applied to estimate the rover location;
however, only a baseline solution is presented here. A
comparison between the single-baseline and the network solutions
for rover coordinates is presented in Kashani et al. 共2003兲. The
suitability of the external ionospheric corrections to support OTF
AR was tested using different stochastic constraints, ranging from
1 to 20 cm. It should be mentioned that the OTF method is used
to establish the ambiguities at the beginning of the kinematic
track, and then the positioning algorithm may switch to the in-
stantaneous 共single-epoch兲 mode, using the ionospheric correction
prediction, based on the previous epoch of data. The detailed
algorithms and software implementation of the MPGPS software
are presented in Kashani et al. 共2004兲, Wielgosz et al. 共2004兲, and
Grejner-Brzezinkska et al. 共2005c兲.
Test Data and Experimental Results
Test Data Set
A 24-h GPS data set collected by the Ohio CORS stations on
August 31, 2003 at a 30-s sampling rate was used in the experi-
ments, which are described in the following sections. This span
of the selected data set allowed for a comparison of time windows
with different ionospheric TEC levels and varying GPS constel-
lation, and their impact on the AR and kinematic positioning
results. Fig. 1 illustrates the selected reference subnetwork, and
Fig. 2 shows the two baselines processed and analyzed here:
SIDN-KNTN 共63 km兲 and DEFI-KNTN 共98 km兲. Station KNTN
was selected as a simulated rover, whose “true” coordinates were
obtained from a 24-h static solution of the Ohio CORS network
using the Bernese software 共Hugentobler et al. 2001兲.
Experimental Results
The entire 24-h data set was first processed to derive the DD
ionospheric reference 共Grejner-Brzezinska et al. 2004兲. Subse-
135
Table 2. Number of Epochs Needed to Resolve Integer Ambiguities Using the Tested Models for KNTN-DEFI Baseline 共63 km兲 at the Highest
Ionospheric Variability
Time windows
Constraint
Model 共cm兲 0400 0410 0420 0430 0440 0450 0500 0510 0520 0530 0540 0550 Average
a a a a a a
MPGPS 1 3 3 5 3 3 3 33 9 10 3 3 14 7.7
5 3a 3a 4 3a 3a 3a 30 10 10 3 3a 14 7.4
ICON 5 ⬎100 60 ⬎100 ⬎100 ⬎100 ⬎100 ⬎100 ⬎100 ⬎100 ⬎100 ⬎100 ⬎100 ⬎97.0
20 3a 10 3 3a 84 58 3 38 9 3a 44 27 23.8
a a a
MAGIC 5 3 3 31 22 3 3 29 6 10 3a 16 15 12.0
10 3a 5 3a 22 3a 3 11 6 10 3a 18 14 8.4
IGS GIM 5 33 19 3a 28 31 24 28 3 13 3a 15 14 17.8
10 9 8 3a 45 20 22 22 4 13 3a 17 14 15.0
Note: Shown are different solutions with varying stochastic constraints applied to the externally provided ionosphere in the rover positioning solution.
a
Ambiguity found at the first epoch; however, the method requires a minimum of three epochs to validate the choice.
Table 3. Number of Epochs Needed to Resolve Integer Ambiguities Using the Tested Models for KNTN-DEFI Baseline 共63 km兲 at the Lowest
Ionospheric Variability
Time windows
Constraint
Model 共cm兲 1800 1810 1820 1830 1840 1850 1900 1910 1920 1930 1940 1950 Average
a a a a a a a a a a a a
MPGPS 1 3 3 3 3 3 3 3 3 3 3 3 3 3.0
5 3a 3a 3a 3a 3a 3a 3a 3a 3a 3a 3a 3a 3.0
ICON 5 ⬎100 92 72 ⬎100 95 75 ⬎100 ⬎100 ⬎100 ⬎100 ⬎100 ⬎100 ⬎94.5
20 85 30 8 3 3 3a 3a 3a 82 16 20 3a 21.6
a a a
MAGIC 5 15 3 3 3 3 3a 3 a
3a
3 a
3 a
3a
3a 4.0
10 3a 3a 21 3 3 3a 3a 3a 3a 3a 3a 3a 4.5
IGS GIM 5 3a 16 5 3a 3a 3a ⬎100 19 50 3a 3a ⬎100 ⬎25.7
a a a
10 3 9 3 3 3 3a 39 14 42 3a 3 85 17.5
Note: Shown are different solutions with varying stochastic constraints applied to the externally provided ionosphere in the rover positioning solution.
a
Ambiguity found at the first epoch; however, the method requires a minimum of three epochs to validate the choice.

Table 4. Number of Epochs Needed to Resolve Integer Ambiguities Using the Tested Models for KNTN-SIDN Baseline 共98 km兲 at the Highest
Ionospheric Variability
Time windows
Constraint
Model 共cm兲 0400 0410 0420 0430 0440 0450 0500 0510 0520 0530 0540 0550 Average
a a a a a a
MPGPS 1 3 3 10 3 3 3 33 8 11 3 3 14 8.1
5 21 6 7 3a 3a 3a 3a 6 10 3 3a 10 6.5
ICON 5 ⬎100 ⬎100 ⬎100 ⬎100 ⬎100 ⬎100 ⬎100 ⬎100 ⬎100 ⬎100 ⬎100 ⬎100 ⬎100
20 ⬎100 ⬎100 ⬎100 ⬎100 86 83 67 51 31 87 3a 5 ⬎67.8
a a a
MAGIC 5 20 40 14 3 3 3 6 3 11 5 3a 3a 9.5
10 79 56 20 3 3 3a 6 3a 11 10 15 3a 17.7
IGS GIM 5 ⬎100 99 40 26 25 3 51 33 13 4 43 22 ⬎38.2
10 ⬎100 ⬎100 25 3 3a 3a 11 3a 11 14 25 3 ⬎25.1
Note: Shown are different solutions with varying stochastic constraints applied to the externally provided ionosphere in the rover positioning solution.
a
Ambiguity found at the first epoch; however, the method requires a minimum of three epochs to validate the choice.

Table 5. Number of Epochs Needed to Resolve Integer Ambiguities Using the Tested Models for KNTN-SIDN Baseline 共98 km兲 at the Lowest
Ionospheric Variability
Time windows
Constraint
Model 共cm兲 1800 1810 1820 1830 1840 1850 1900 1910 1920 1930 1940 1950 Average
a a a a a a a a a a a a
MPGPS 1 3 3 3 3 3 3 3 3 3 3 3 3 3.0
5 3a 3a 3a 3 3a 3a 3a 3a 3a 3a 3a 3a 3.0
ICON 5 ⬎100 88 68 3 3a 3a 3a 3a 3a 3a 22 3a ⬎25.2
a a a a
20 ⬎100 3 7 3 3 3 3 3 3 3a 3 a
3a ⬎11.4
a a a a a a a a
MAGIC 5 3 3 3 3 3 3 3 3 3 3a 3 a
3a 3.0
a a a a a a a a
10 3 3 3 3 3 3 3 3 3 3a 3 a
3a 3.0
IGS GIM 5 ⬎100 ⬎100 ⬎100 ⬎100 7 49 8 3 3a 9 3a 3a ⬎40.4
10 6 88 68 43 3 41 3a 3a 3a 3a 3 a
3a 22.2
Note: Shown are different solutions with varying stochastic constraints applied to the externally provided ionosphere in the rover positioning solution.
a
Ambiguity found at the first epoch; however, the method requires a minimum of three epochs to validate the choice.

136 CORS AND OPUS FOR ENGINEERS

Fig. 3. MPGPS-NR model n,e,u residuals with respect to the reference coordinates for the 63-km baseline, with initial epoch at 1820 UT 共a兲;
stochastic constraints of 5 cm; corresponding W-ratio 共b兲
quently, the ionospheric corrections were estimated using the four
models, and compared to the reference ionosphere. The figures
showing detailed plots of the ionospheric signature and the re-
siduals of each solution with respect to the reference are shown in
Grejner-Brzezinska et al. 共2004兲. As Grejner-Brzezinska et al.
共2004兲 show, the ionospheric activity changed during the course
of the day, with the highest variability before the local sunrise; the
average Kp index for that day was around 2o, indicating very
mild overall ionospheric activity. The amount of the estimated
DD ionospheric delays ranged from ±5 to ±25 cm, depending on
the local time and the satellite elevation angle.
As discussed in detail in Grejner-Brzezinska et al. 共2004兲, and
summarized in Table 1, MPGPS-NR shows a good fit to the ref-
erence ionosphere, with 94.2% of the residuals within the ±5 cm
boundary 共i.e., around one quarter of the L1 cycle兲, which en-
abled instantaneous AR in the rover positioning step 共Grejner-
Brzezinska et al. 2004兲. Note that residual is defined here as the
difference between the model under consideration and the refer-
ence DD ionosphere. The NGS ICON model displays a rather flat
spectrum of differences with respect to the reference; however,
biases are visible in this solution 共Grejner-Brzezinska et al. 2004兲.
The ICON solution may be subject to incorrectly resolved biases
共absolute TEC兲, primarily due to the fact that the method uses a
simple cosine mapping function at the satellite track crossovers,
which are fundamental to the bias resolution 共Smith 2004兲.
MAGIC is subject to smoothing due to the time quantization
共15 min兲 of the final output; however, its fit to the reference
ionosphere is good, reaching a maximum of around one L1 cycle.
Fig. 4. MAGIC model n,e,u residuals with respect to the reference coordinates for 98-km baseline, with initial epoch at 0500 UT 共a兲; stochastic
constraints of 10 cm; corresponding W-ratio 共b兲
CORS AND OPUS FOR ENGINEERS
IGS GIM presents residuals higher than MAGIC by about 30%.
Since the suitability of these models for instantaneous AR was
rather low, except for MPGPS-NR 共Grejner-Brzezinska et al.
2004兲, in this paper, the focus is on their applicability to OTF AR.
A complete analysis of the AR speed and reliability is presented
next, as a function of the ionospheric model used and the iono-
spheric activity during the course of the day. Some preliminary
results of these tests were presented by Grejner-Brzezinska et al.
共2005a兲.
Tables 2–5 present detailed statistics of the AR time-to-fix—
that is, the number of epochs needed to find integers for both
tested baselines. Two representative 2-h windows were selected;
the first one, 0400–0600 UT, corresponds to the highest iono-
spheric variability 共before local sunrise兲, and the second window,
1800–2000 UT corresponds to the lowest ionospheric variability
共local afternoon兲 during the 24-h period. The AR process was
restarted every 10 min during the analyzed windows, and the
number of epochs needed to resolve the integers was counted, as
shown in Tables 2–5. In each case, the data processing continued
for the remaining epochs of the predefined 100-epoch test win-
dow, after the integers were selected. It should be noted that even
though the number of epochs needed to fix integers is counted
here as the measure of success, the time span, not just the epoch
number, has a significant impact on the AR process. The 30-s
sampling rate used here allows for a rather substantial geometry
change over a few epochs, enabling fast AR, if the external iono-
spheric information is of sufficient quality. For a higher sampling
rate, more epochs of data would be needed to achieve the neces-
137
Table 6. Position Residuals with respect to the Known Reference
Coordinates after Ambiguity Fixing
Position residuals in 关mm兴
Standard
Mean deviation
n e u n e u
KNTN-SIDN 共63 km兲 04–06 UT 2 2 −34 9 7 25
KNTN-SIDN 共63 km兲 18–20 UT 0 1 −4 8 6 24
KNTN-DEFI 共98 km兲 04–06 UT 13 7 −48 14 8 27
KNTN-DEFI 共98 km兲 18–20 UT 5 0 −3 7 7 22
sary geometry change, even if the same ionospheric model was
used. Table 2 summarizes the worst window for the shorter base-
line, and Table 3 refers to the best window for the same baseline.
Tables 4 and 5 present similar statistics for the longer baseline.
All tables include the statistics for several rover positioning solu-
tions, where varying stochastic constraints of 1, 5, 10, and 20 cm
共1 sigma兲, were applied to the ionospheric corrections tested. It
should be emphasized that ionospheric delays must be treated as
stochastic parameters in the rover positioning solution, where the
tightness of the stochastic constraints is a function of the esti-
mated quality of the external corrections.
MPGPS-NR and MAGIC support fast OTF AR with the iono-
sphere constrained to ±5 cm 共time-to-fix reaches 3.0–12.0 epochs
for MAGIC and 3.0–7.4 for MPGPS-NR兲. Furthermore,
MPGPS-NR provides AR within 3.0–7.7 epochs even if the
ionosphere is tightly constrained to ±1 cm. Releasing the con-
straints to ±10 cm for MAGIC may improve the speed of AR
under more varying ionospheric conditions, as seen in Table 2.
ICON and IGS GIM work better if the stochastic constraints are
more released 共i.e., ±10 and ±20 cm, respectively兲. In summary,
MPGS-NR needs on average only 7.4 共6.5兲 epochs during the
highest ionospheric variability and 3.0 共3.0兲 epochs during the
period of lowest ionospheric variability to fix the ambiguities to
their integer values, using ±5 cm constraints on the external iono-
sphere 共the numbers in parenthesis correspond to the longer base-
line兲. Under the same conditions, MAGIC requires 12.0 共10.0兲
and 4.0 共3.0兲 epochs, respectively; IGS GIM requires 17.8 共38.2兲
and 25.7 共40.4兲 epochs, respectively; and ICON needs more than
97.0 共⬎100兲 and 94.5 共⬎25.2兲, respectively. Releasing the sto-
chastic constraints to 10 cm for MAGIC and IGS GIM, and to
20 cm for ICON, results in the average number of epochs needed
to fix the ambiguities equal to 8.4 共17.7兲 and 4.5 共3.0兲 for
MAGIC, 15 共25.1兲 and 17.5 共22.2兲 for IGS GIM, and 23.8 共67.8兲
and 21.6 共11.4兲 for ICON, respectively. These results are consis-
tent with the ionospheric delay residual statistics with ±5 cm cut-
off, presented in Table 1.
In the standard MPGPS processing, once the initial ambigu-
ities are resolved using the OTF technique and the external
ionospheric corrections with stochastic constraints, the rover po-
sitioning continues in the instantaneous mode 共Kashani et al.
2004兲. In the case presented here, however, the OTF method was
used for the entire test duration. The selected examples of the
position coordinate residuals with respect to the reference known
coordinates as well as the corresponding W-ratio test results are
presented in Figs. 3 and 4. It is important to point out that the bias
visible in the vertical coordinate in Fig. 4 is caused by the bias in
the network-derived tropospheric corrections. The statistics of the
residuals are shown in Table 6. It should also be mentioned that
according to Verhagen 共2004兲, the W-ratio, similarly to all statis-
tical tests commonly used to test the integer selection, lacks a
correct theoretical basis; in essence, the assumption that the test
statistic follows the t-distribution is incorrect. However, it still
gives satisfactory results, and is, therefore, used here. Verhagen
共2005兲 indicates that there is no single test that performs best
in all possible scenarios; each one of the commonly used tests has
its pros and cons. The W-ratio seems to be too conservative—it
offers a relatively low probability of correct acceptance, which is
a function of the choice of the critical value, according to Ver-
hagen 共2005兲; therefore, an alternative statistical test might be
considered for our future analysis.
Recent Updates to MAGIC and ICON
A careful analysis of ICON and MAGIC, as presented in Grejner-
Brzezinska et al. 共2004兲, indicates that while ICON is capable of
capturing local features of the ionosphere, it may fail in finding
correct biases. MAGIC, to the contrary, provides correct biases,
while the time/space resolution of the model may have a smooth-
ing impact on the resulting ionospheric corrections. Therefore,
combining the advantages of both methods should lead to a su-
perior solution. Consequently, the ICON solution was fitted to the
MAGIC solution to provide the best of both methods: correct

Table 7. Statistics of DD Ionospheric Delay Residuals with respect to the Reference for 24-h Data Set, 63-km Baseline
Modified Modified Modified
ICON ICON MAGIC MAGIC MAGIC
Model/statistics MPGPS 共no KNTN兲 共no KNTN兲 共no KNTN兲 共no KNTN兲 共w/KNTN兲
Mean 关mm兴 −0.2 −25.9 0.3 11.9 −1.4 −1.8
Standard deviation 关mm兴 27.0 28.3 28.3 55.7 27.9 0.3
Note: Last column shows the solution including the KNTN L4 fit to MAGIC ionospheric corrections.

Table 8. Statistics of the Ionospheric Delay Residuals with respect to the Reference Ionosphere for 24-h Data Set, 98-km Baseline
Modified Modified Modified
ICON ICON MAGIC MAGIC MAGIC
Model/statistics MPGPS 共no KNTN兲 共no KNTN兲 共no KNTN兲 共no KNTN兲 共w/KNTN兲
Mean 关mm兴 −2.7 6.3 −4.9 12.0 −4.9 −5.4
Standard deviation 关mm兴 27.0 31.1 31.1 52.4 27.9 0.3
Note: Last column shows the solution including the KNTN L4 fit to MAGIC ionospheric corrections.

138 CORS AND OPUS FOR ENGINEERS

Table 9. DD Ionospheric Delay Residual Summary Statistics 共±5 and AR. Examples of the DD ionospheric residuals with respect to the
±10 cm Cutoffs for 24 h兲 reference for the original and modified ICON and MAGIC solu-
Residuals in % within predefined limits, 24 h tions are displayed in Figs. 5 and 6.
In addition, the rover observations may be fitted to the modi-
KNTN-SIDN KNTN-DEFI fied MAGIC or ICON and used in the postprocessing mode to
共63 km兲 共98 km兲
remove the ionospheric biases 共this concept also applies to
±10 cm ±5 cm ±10 cm ±5 cm MPGPS-NR and IGS GIM兲. Fig. 7 displays an example of DD
MPGPS-NR 99.3 94.2 99.3 94.2
ionosphere residuals of the modified MAGIC solution, where
共no KNTN data兲 rover observations were fitted to the interpolated corrections from
Modified ICON 97.3 88.6 95.8 81.4
the model, and as a result, the ionospheric bias was removed.
共no KNTN data兲
Modified MAGIC 97.6 87.4 97.1 85.2
共no KNTN data兲 Discussion and Conclusions
Modified MAGIC 100.0 100.0 99.6 99.6
共KNTN data included兲 The impact of the external ionospheric models on the OTF AR
and the final kinematic positioning accuracy were studied in this
paper. A 24-h data set from the Ohio CORS network was pro-
cessed and analyzed, using four different ionospheric models and
biases from MAGIC and the local ionospheric signature from the recent updates to two of them—ICON and MAGIC. To dem-
ICON. This model is referred to as “modified ICON.” onstrate the effect of these models on the OTF RTK solution
Alternatively, MAGIC solution can be directly modified to use under different ionospheric conditions, two 2-h windows were
the carrier phase data fit after the biases have been properly cap- selected 共daytime and nighttime兲 and discussed in detail. The
tured by the model. Namely, L4 observables can be fitted to the number of epochs needed to accomplish the OTF AR varied with
MAGIC-estimated ionospheric delays; this way the constant the type of ionospheric model and the level of stochastic con-
mean difference 共bias兲 in L4 along the satellite arc is removed. straints 共that correspond to the accuracy of the model兲 applied to
This model is referred to as “modified MAGIC.” the external ionosphere in the final rover positioning solution.
As a result of these revisions, high accuracy ionospheric cor- Based on the statistics shown in Tables 2–5 it can be con-
rections that match the DD reference ionosphere with the cluded that under the described conditions, the local model,
5 – 10 cm level of accuracy more than 90% of the time are MPGPS-NR, needs 3–7 epochs to fix the ambiguities with the
achieved for both modified models, as shown in Tables 7–9. Thus, 5-cm stochastic constraint on the ionosphere. Of the two regional
both modified models are suitable for instantaneous and fast OTF models, MAGIC needs 3–12 epochs and 3–18 epochs for 5-cm

Fig. 5. Residuals with respect to the reference ionosphere 共August 31, 2006; 98-km baseline兲: original ICON solution 共a兲; modified ICON
solution 共b兲

CORS AND OPUS FOR ENGINEERS 139

Fig. 6. Residuals with respect to the reference ionosphere 共August 31, 2006; 98-km baseline兲: original MAGIC solution 共a兲; modified MAGIC
solution 共b兲

Fig. 7. Modified MAGIC solution including L4 fit to the rover 共KNTN兲 data; residuals with respect to the reference ionosphere: 63-km baseline
共a兲; 98-km baseline 共b兲

140 CORS AND OPUS FOR ENGINEERS

and 10-cm constraints, respectively, and ICON requires 11–68
epochs with the constraint of 20 cm. ICON requires longer times
with tighter constraints. IGS GIM needs on average 18–38 epochs
with the 5-cm constraint and 15–25 epochs if the level of con-
straint is released to 10 cm. Once the ambiguities are fixed to
their integer values, the rover positioning algorithm provides
centimeter-level accuracy for the horizontal and vertical coordi-
nates, as shown in Table 6.
It should be emphasized that the nature of the MPGPS-NR
model, in the context used here, is rather local, with the spacing
among stations of around 100 km and only four stations used to
derive it. Its high accuracy and reliability demonstrated in the
examples presented here arise from the high temporal and spatial
resolutions of the model, and careful network data processing
regimen, including AR and stochastic constraint selection.
MAGIC is clearly characterized by the largest relative spacing
among the reference stations, and as a regional model, it uses
roughly half of the stations needed by another regional model,
ICON. Still, the accuracy of MAGIC is high, leading to a reliable
support of OTF AR and the positioning solution. The clear advan-
tage of ICON is its reliance on high-accuracy carrier phase data,
and direct solution of undifferenced ionospheric corrections.
While the mathematics of ICON are internally consistent, its ac-
curacy is modest for some parts of the analyzed data sets because
the method relies at this point on a simple cosine mapping at the
satellite track crossovers, which are fundamental to the ambiguity
resolution 共Smith 2004兲. By combining the advantages of both
methods, high-accuracy ionospheric corrections, supporting fast
and reliable AR, can be derived.
The next step in our analyses is to consider a time period of
very active 共stormy兲 ionosphere, and test the applicability of these
ionospheric models to AR and rover positioning under those con-
ditions 共Wielgosz et al. 2005; Grejner-Brzezinska et al. 2005b兲. In
order to support routine user applications, it is necessary to deter-
mine the optimal number of stations needed to derive the iono-
spheric corrections in each tested model. Thus, the minimum con-
figuration with still sufficient accuracy, suitable for real-time
applications, needs to be determined, as an arbitrarily large num-
ber of data sets to transfer and process in real-time may hinder the
efficiency of the process.
Acknowledgments
This project is supported by the National Geodetic Survey,
NOAA/NGS Grant.
References
Bock, Y., de Jonge, P., Honcik, D., and Fayman, J. 共2003兲. “Wireless
instantaneous network RTK: Positioning and navigation.” Proc., ION
GPS/GNSS, 1397–1405.
Dai, L., Han, S. W., Wang, J. L., and Rizos, C. 共2001兲. “A study on
GPS/GLONASS multiple reference station technique for precise real-
time carrier phase-based positioning.” Proc., ION GPS, 392–403.
de Jonge, P. J., and Tiberius, C. 共1996兲. “The lambda method for integer
ambiguity estimation: Implementation aspects.” LGR Publication No.
12, August, 1–49.
El-Arini, M. B., Conker, R., Albertson, T., Reegan, J. K., Klobuchar, J.
A., and Doherty, P. 共1994兲. “Comparison of real-time ionospheric
algorithms for a GPS wide-area augmentation system 共WAAS兲.”
Navigation, 41共4兲, 393–413.
CORS AND OPUS FOR ENGINEERS
Euler, H.-J., Keenan, C. R., Zebhauser, B. E., and Wübbena, G. 共2001兲.
“Study of a simplified approach in utilizing information from perma-
nent reference station arrays.” Proc., ION GPS, 379–391.
Euler, H.-J., Seeger, S., Zelzer, O., Takac, F., and Zebhauser, B. E.
共2004兲. “Improvement of positioning performance using standardized
network RTK messages.” Proc., ION National Technical Meeting,
453–461.
Feltens, J., and Jakowski, N. 共2002兲. “The International GPS Service
共IGS兲 ionosphere working activity.” SCAR Report No. 21.
Fortes, L. P. 共2002兲. “Optimizing the use of GPS multi-reference stations
for kinematic positioning.” Proc., ION GPS, 2359–2372.
Fortes, L. P., Cannon, M. E., and Lachapelle, G. 共2000兲. “Testing a multi-
reference GPS station network for OTF positioning in Brazil.” Proc.,
ION GPS, 1133–1142.
Fotopoulos, G., and Cannon, M. E. 共2001兲. “An overview of multi-
reference station methods for cm-level positioning.” GPS Solutions,
4共3兲, 1–10.
Grejner-Brzezinska, D. A., et al. 共2004兲. “An analysis of the effects of
different network-based ionosphere estimation models on rover posi-
tioning accuracy.” J. GPS, 3共1-2兲, 115–131.
Grejner-Brzezinska, D. A., et al. 共2005a兲. “The impact of the external
ionospheric models on the accuracy of RTK position.” Proc., ION
National Technical Meeting, 462–470.
Grejner-Brzezinska, D. A., et al. 共2005b兲. “The impact of severe iono-
spheric conditions on the accuracy of RTK position estimation: Per-
formance analysis of various ionospheric modeling techniques.”
Proc., ION Annual Meeting, 887–901.
Grejner-Brzezinska, D. A., Kashani, I., and Wielgosz, P. 共2005c兲. “On
accuracy and reliability of instantaneous network RTK as a function
of network geometry, station separation, and data processing strat-
egy.” GPS Solutions, 9共3兲, 179–193.
Hansen, A., Peterson, E., Walter, T., and Enge, P. 共2000a兲. “Correlation
structure of ionospheric estimation and correction for WAAS.” Proc.,
ION National Technical Meeting, 454–463.
Hansen, A., Walter, T., Blanch, J., and Enge, P. 共2000b兲. “Ionospheric
spatial and temporal correlation analysis for WAAS: Quiet and
stormy.” Proc., ION GPS, 634–642.
Hugentobler, U., Schaer, S., and Fridez, P. 共2001兲. Bernese GPS soft-
ware version 4.2, Astronomical Institute, Univ. of Berne, Berne,
Switzerland.
Jensen, A. B. O. 共2002兲. “Investigations on the use of numerical weather
predictions, ray tracing, and tropospheric mapping functions for net-
work RTK.” Proc., ION GPS, 2324–2333.
Kashani, I., Wielgosz, P., and Grejner-Brzezinska, D. A. 共2003兲. “Free net
adjustment in multireference stations approach for instantaneous
RTK.” Proc., ION GPS/GNSS, 1390–1396.
Kashani, I., Grejner-Brzezinska, D. A., and Wielgosz, P. 共2004兲. “To-
wards instantaneous RTK GPS over 100 km distances.” Proc., ION
Annual Meeting, 679–685.
Kashani, I., Wielgosz, P., and Grejner-Brzezinska, D. A. 共2005兲. “The
impact of the ionospheric correction latency on long-baseline instan-
taneous kinematic GPS positioning.” Surv. Rev. 共accepted February
2005兲.
Kim, D., and Langley, R. B. 共2000兲. “GPS ambiguity resolution and
validation: Methodologies, trends, and issues.” Proc., 7th GNSS Work-
shop and Int. Symp. on GPS/GNSS, 213–221.
Kolb, P. F., Chen, X., and Vollath, U. 共2005兲. “A new method to model
the ionosphere across local area networks.” Proc., ION GNSS,
705–711.
Komjathy, A., and Langley, R. B. 共1996兲. “The effect of shell height on
high precision ionospheric modelling using GPS.” Proc., IGS Work-
shop, 193–203.
Komjathy, A. 共1997兲. “Global ionospheric total electron content mapping
using the global positioning system.” Ph.D. thesis, Dept. of Geodesy
and Geomatics Engineering, Technical Report No. 188, Univ. of New
Brunswick, Fredericton, Canada.
141
Komjathy, A., et al. 共2002兲. “A new ionospheric model for wide area
differential GPS: Multiple shell approach.” Proc., ION National Tech-
nical Meeting, 460–466.
Leandro, R. F. 共2004兲. “A new technique to TEC regional modeling using
a neural network.” Proc., ION GNSS, 354–365.
Liao, X., and Gao, Y. 共2000兲. “Carrier-based ionosphere recovery using a
regional area GPS network: Preliminary results.” Proc., ION National
Technical Meeting, 474–480.
Mader, G. L., and Morrison, M. L. 共2002兲. “Using interpolation and
extrapolation techniques to yield high data rates and ionosphere delay
estimates from continuously operating GPS networks.” Proc., ION
GPS, 2342–2348.
Mannucci, A. J., Iijima, B., Sparks, L., Pi, X., Wilson, B., and
Lindqwister, U. 共1999兲. “Assessment of global TEC mapping using a
three dimensional electron density model.” J. Atmos. Sol.-Terr. Phys.,
61, 1227–1236.
Odijk, D. 共2001兲. “Instantaneous GPS positioning under geomagnetic
storm conditions.” GPS Solutions, 5共2兲, 29–42.
Raquet, J. 共1998兲. “Development of a method for kinematic GPS carrier-
phase ambiguity resolution using multiple reference stations.” Ph.D.
thesis, The Univ. of Calgary, UCGE Rep. 20116, Univ of Calgary,
Alberta, Canada.
Rho, H., Langley, R. B., and Komjathy, A. 共2004兲. “An enhanced UNB
ionospheric modeling technique for SBAS: The quadratic approach.”
Proc., ION GPS, 354–365.
Rideout, W., and Coster, A. 共2006兲. “Automated GPS processing for glo-
bal total electron content data.” GPS Solutions, 10共3兲, 219–228.
Rizos, C. 共2002兲. “Network RTK research and implementation: A geo-
detic perspective.” J. GPS, 1共2兲, 144–150.
Sardon, E., and Zarraoa, N. 共1997兲. “Estimation of total electron content
using GPS Data: How stable are the differential satellite and receiver
instrumental biases?” Radio Sci., 32共5兲, 1899–1910.
Schaer, S. 共1999兲. “Mapping and predicting the Earth’s ionosphere using
the Global Positioning System.” Ph.D. thesis, Astronomical Institute,
Univ. of Berne.
Schaer, S., Gurtner, W., and Feltens, J. 共1998兲. “IONEX: The ionosphere
map exchange format version 1.” Proc., IGS Analysis Center Work-
142 CORS AND OPUS FOR ENGINEERS
shop, J. M. Dow, ed., ESA/ESOC, 233–247.
Skone, S. 共1998兲. “Wide area ionospheric grid modelling in the auroral
region.” Ph.D. thesis, Dept. of Geomatics Engineering, UCGE Re-
ports No. 20123, Univ. of Calgary, Alberta, Canada.
Skone, S. 共2000兲. “Wide area ionosphere modeling at low latitudes:
Specifications and limitations.” Proc., ION GPS, 643–652.
Smith, D. A. 共2004兲. “Computing unambiguous TEC and ionospheric
delays using only carrier phase data from NOAA’s CORS network.”
Proc., IEEE PLANS, 527–537.
Spencer, P. S. J., Robertson, D. S., and Mader, G. L. 共2004兲. “Ionospheric
data assimilation methods for geodetic applications.” Proc., IEEE
PLANS, 510–517.
Teunissen, P. J. G. 共1994兲. “A new method for fast carrier phase ambigu-
ity estimation.” Proc., IEEE PLANS, 562–573.
Verhagen, S. 共2004兲. “Integer ambiguity validation: An open problem?”
GPS Solutions, 8共1兲, 36–43.
Verhagen, S. 共2005兲. “On reliability of integer ambiguity resolution.”
Navigation, 52共2兲, 99–110.
Vollath, U., Buecherl, A., Landau, H., Pagels, C., and Wagner, B. 共2000兲.
“Multi-base RTK positioning using virtual reference stations.” Proc.,
ION GPS, 123–131.
Vollath, U., Landau, H., Chen, X., Doucet, K., and Pagels, C. 共2002兲.
“Network RTK versus single base RTK: Understanding the error char-
acteristics.” Proc., ION GPS, 2774–2781.
Wang, J., Stewart, M., and Tsakiri, M. 共1998兲. “A discrimination test
procedure for ambiguity resolution on-the-fly.” J. Geodesy, Berlin,
72, 644–653.
Wanninger, L. 共2002兲. “Virtual reference stations for centimeter-level ki-
nematic positioning.” Proc., ION GPS, 1400–1407.
Wielgosz, P., Grejner-Brzezinska, D. A., and Kashani, I. 共2004兲.
“Network approach to precise medium range GPS navigation.” Navi-
gation, 51共3兲, 213–220.
Wielgosz, P., Kashani, I., and Grejner-Brzezinska, D. A. 共2005兲. “Analy-
sis of long-range network RTK during severe ionospheric storm.”
J. Geodesy, Berlin, 79共9兲, 524–531.
 18
Network Calibration for Unfavorable Reference-Rover
Geometry in Network-Based RTK: Ohio CORS Case Study
Dorota A. Grejner-Brzezinska, M.ASCE1; Niyazi Arslan2; Pawel Wielgosz3; and Chang-Ki Hong4

Abstract: In the network-based real-time kinematic 共RTK兲 global positioning system approach, the rover positioning accuracy and
reliability depends on the quality of the atmospheric corrections, which is largely a function of spatial and temporal variability of
ionospheric and tropospheric parameters. The location of the rover receiver with respect to the reference network receivers is also a very
important factor, especially for applications such as off-shore navigation, where favorable geometry cannot always be assured. The
primary goal of this paper is to describe tests of the speed and reliability of the ambiguity resolution and the ultimate accuracy of
kinematic positioning for two representative reference receiver geometries: 共1兲 pentagonal reference receiver geometry, with network-
rover separation up to 131 km, which represents a typical reference scenario where the rover is located inside the reference network; and
共2兲 irregular geometry, simulating a shore-bound scenario where the reference network can support only extrapolation of the atmospheric
corrections to an off-shore rover 共outside the reference network兲, with network–rover separation up to 200 km. The latter scenario is of
special interest here, as the objective is to investigate the maximum acceptable separation of the rover receiver from the shore-bound
reference stations. The Ohio Continuously Operating Reference Stations 共CORS兲 network is used to simulate both scenarios, and the
MPGPS software developed at The Ohio State University Satellite Positioning and Inertial Navigation Laboratory is used to carry out the
analyses over a 24-h period of varying ionospheric activity. As a result of this study, the error budget associated with both network
geometries is obtained, and the limitations of the network approach as a function of the network-rover geometry can be ascertained.
DOI: 10.1061/共ASCE兲0733-9453共2009兲135:3共90兲
CE Database subject headings: Global positioning; Geodetic surveys; Accuracy; Statistics; Geometry; Ohio; Kinematics.

Introduction corrections 共Rizos 2002; Vollath et al. 2002兲. Consequently, if the

The key to successful ambiguity resolution 共AR兲 in long-range
kinematic positioning is to mitigate the errors due to ionospheric
and tropospheric delays 共Vollath et al. 2000, 2002; Rizos 2002;
Kashani et al. 2005兲. Of the two delay measurement biases, the
former has the greatest impact on AR because reliable ambiguity
resolution is only possible in the absence of large phase biases.
The use of the multireference station approach for global posi-
tioning system 共GPS兲 kinematic positioning significantly in-
creases the distance over which kinematic carrier-phase AR can
be performed by reducing the ionospheric residual errors. This
can be achieved either by imposing some geometric conditions
based on fixed reference locations, and/or through the use of ref-
erence network data to estimate the ionospheric and tropospheric
1
Satellite Positioning and Inertial Navigation 共SPIN兲 Laboratory,
Dept. of Civil and Environmental Engineering and Geodetic Science, The
Ohio State Univ., Columbus, OH 43210. E-mail: dbrzezinska@osu.edu
2 共Wielgosz et al. 2005兲.
Satellite Positioning and Inertial Navigation 共SPIN兲 Laboratory,
Dept. of Civil and Environmental Engineering and Geodetic Science, The
Ohio State Univ., Columbus, OH 43210; and, Geodesy and Photogram-
metry Engineering Dept., Yildiz Technical Univ., Turkey.
3
Univ. of Warmia and Mazury, Olsztyn, Poland.
4
Satellite Positioning and Inertial Navigation 共SPIN兲 Laboratory,
Dept. of Civil and Environmental Engineering and Geodetic Science, The
Ohio State Univ., Columbus, OH 43210.
Note. This manuscript was submitted on March 10, 2008; approved
on September 26, 2008; published online on July 15, 2009. Discussion
period open until January 1, 2010; separate discussions must be submitted
for individual papers. This paper is part of the Journal of Surveying
Engineering, Vol. 135, No. 3, August 1, 2009. ©ASCE, ISSN 0733-
9453/2009/3-90–100/$25.00.
carrier-phase observable errors are corrected or minimized, it is
generally possible to resolve integer ambiguities over longer in-
terreceiver distances, and thus to increase the accuracy and reli-
ability of the resultant rover coordinates. In the network-based
real-time kinematic 共RTK兲 approach, the quality of the rover po-
sition coordinates depends on the accuracy of the network-
derived atmospheric corrections, as well as the mechanisms for
delivering these corrections to users via wireless communications
links 共this paper will not deal with the latter.兲 The accuracy of the
network-derived corrections is a function of the spatial and tem-
poral resolutions of the GPS reference receiver data used to esti-
mate these corrections, and the rover location with respect to the
reference network. If the spatiotemporal resolution or the rover–
network geometry is weak, the corrections may not be able to
properly capture the ionospheric 共and tropospheric兲 variability,
resulting in a lowered quality of the corrections interpolated to the
rover location, and, ultimately, in a decreased reliability of AR
In some applications however, such as off-shore navigation,
favorable reference network geometry cannot be accomplished, as
no reference stations are available off-shore. Thus, this class of
applications requires an assessment of the limiting factors of the
network-based solution. This is attempted in this paper. The pri-
mary focus of the study presented here is the performance analy-
sis of two representative reference receiver geometries:
1. Reference geometry with five stations separated by
105– 171 km, with the reference station–rover separation of
65 and 131 km, and rover location inside the network; and
2. Irregular geometry, simulating a shore-bound scenario, with
reference stations separated by 85– 171 km, and reference

CORS AND OPUS FOR ENGINEERS 143

 station–rover separation of 65, 131, and 202 km, with the
rover location outside the network 共see the next section for
more details兲.
The goal is to determine the accuracy limits of the corrections
derived from the network geometry, and to ascertain the maxi-
mum acceptable separation of the rover receiver from the linearly
distributed reference stations. This scenario is of special interest,
as it simulates shore-bound reference station geometry, where the
reference network can only support extrapolation of the atmo-
spheric corrections. It should be emphasized that this scenario is
simulated through a selection of the Ohio Continuously Operating
Reference Stations 共CORS兲 that form this geometry. No shore or
off-shore stations/data were used. This does not have any major
impact on the ionospheric correction quality and the AR process,
however, some impact might be observed on a real off-shore rov-
er’s height solution, as the troposphere differs over the land and
the sea 共e.g., due to the existence of horizontal tropospheric gra-
dients兲. In this solution, the double difference 共DD兲 ionospheric
delays are estimated using the geometry-free, L4 共L1–L2兲, linear
combination with fixed ambiguities, which assures no contamina-
Fig. 1. Experimental data: Case 1, simulated rovers: MTVR and
tion by unmodeled geometric terms, such as residual tropospheric COLB
errors 共Schaer 1999兲.
In this study, the success rate of the on-the-fly 共OTF兲 AR for
varying ionospheric conditions 共Kp index ranging from 2o to
6+兲, two different network geometries and different separa- considered, under the assumption that a reference network with a
tions between the rover and the reference station in the baseline local/regional coverage is used 共i.e., station separation of
solution are used, together with the accuracy of the resulting co- 100– 200 km兲. The following network–rover geometries were
ordinates and time-to-fix, as the quality measures of the network- considered 共Figs. 1 and 2兲:
based RTK performance. This research is a continuation of an 1. Pentagonal, uniform reference receiver geometry 共Case 1兲,
earlier study 共Grejner-Brzezinska et al. 2005兲, where the effects and the rover 共COLB, MTVR兲 inside the network, represent-
of network geometry, station separation, and the data reduction ing the typical reference/benchmark scenario. This scenario
technique on the final quality and reliability of the rover position- will be used to assess the loss of speed and reliability of the
ing solution were investigated. In 共Grejner-Brzezinska et al. AR process, and ultimately the loss of continuity and accu-
2005兲, the emphasis was on instantaneous ambiguity resolution, racy of the rover position estimation for situations where the
and the algorithm presented there used a single-step approach, rover moves along or away from the shoreline, and the ref-
where the rover data were reduced together with the network data erence network is shore bound.
in a single least-squares adjustment using the weighted free-net 2. Shore-bound reference receiver geometry that simulates the
approach. However, in the study presented here, a single-baseline shore line geometry 共shore-bound range兲 with the simulated
solution is used in the kinematic processor, and the OTF ambigu-
ity resolution method is implemented using epoch-by-epoch iono-
spheric corrections from the network. Hence, the network
solution is separated from the rover positioning algorithm. It
should be mentioned here that there have been numerous case
studies on the performance of network RTK over varying geom-
etries. However, most of them are based on proprietary software/
algorithms, varying models, assumptions, and goals, hence, it is
difficult to compare them directly; the reader is referred to several
example studies 共Alves et al. 2003; Diep Dao et al. 2004; Feng
and Rizos 2005; Grejner-Brzezinska et al. 2005; Ahn et al. 2006;
Zhang et al. 2006兲. Recently, Schwarz et al. 共2009兲 investigated
the effects of the geometry of the selected CORS stations on
rapid-static solutions, quantifying them by a parameter named
interpolative dilution of precision 共IDOP兲.

Experimental Scenarios

Twenty-four hours of dual frequency, 30-s sampling rate data in

RINEX format, from the selected Ohio CORS stations were used
in this experiment. The primary objective of this experiment was
to assess the impact of the reference network–rover geometry on
kinematic rover coordinate solutions derived using the network-
generated atmospheric corrections. Two different geometries were
Fig. 2. Experimental data: Case 2, MTVR, WOOS, and GARF are
the rovers, simulating the shore-bound geometry with rover moving
away from the network

144 CORS AND OPUS FOR ENGINEERS

 rover, whose locations are represented by stations MTVR,
WOOS, and GARF, to simulate a trajectory moving away
from the network 共Case 2兲.
Case 2 is of primary interest here, whereas Case 1 is presented
as a benchmark to demonstrate the impact of the weak network–
rover geometry in Case 2.
Approach and Methodology
The Multi-Purpose GPS Processing Software 共MPGPS兲 imple-
ments a network-based positioning approach, and was developed
at The Ohio State University 共Wielgosz et al. 2004; Kashani et al.
2004; Grejner-Brzezinska et al. 2005兲. The algorithm consists of
two primary modules:
1. Reference network solution, which generates atmospheric
corrections; and
2. Rover positioning solution, which uses the corrections gen-
erated in Step 1.
The software operates in the static, rapid-static, OTF kinematic,
and instantaneous modes, and supports single- and multibaseline
rover solutions. The primary processing engine for both network
and the rover positioning modules is based on the generalized
least squares 共GLS兲 approach 共Uotila 1986兲. The GLS approach is
known for its flexibility, offering an easy implementation of dif-
ferent stochastic constraints and weighted parameters. The pri-
mary unknowns in the reference network solution 共Step 1兲 are DD
carrier phase ambiguities, DD ionospheric delays, and tropo-
spheric total zenith delays 共TZD兲, whereas the reference network
coordinates are tightly constrained. The AR technique is based on
the LAMBDA method 共Teunissen 1994; Joosten 2001兲 with the
W-test applied for validation 共Wang et al. 1998兲. As the station
coordinates are known, it usually takes 1–5 observational epochs
to fix the ambiguities in the network. According to Verhagen
共2004, 2005兲, all statistical tests 共including the W-test兲 commonly
used to verify the integer selection, are based on the incorrect
assumption that the test statistic follows the t-distribution. The
W-test seems to be too conservative, resulting in a relatively low
probability of correct acceptance, which is a function of the
choice of the critical value. In our work to date, the W-test test
provided satisfactory results; however, an alternative statistical
test might be considered in a future upgrade of the MPGPS.
The network ambiguity resolution step is followed by the es-
timation of the final DD ionospheric delays using the carrier
phase geometry-free 共L4兲 linear combination. The DD iono-
spheric delays are subsequently decomposed to biased zero dif-
ference 共ZD兲 delays. The ZD ionospheric delays may be applied
in the rover positioning procedure regardless of the scheme used
to form the DD, whereas the original DD delays are associated
with a particular reference satellite used in the network solution,
which may complicate the correction propagation and their appli-
cation in the rover solution. The approach used in DD decompo-
sition is based on introducing loose constraints to the diagonal
entries of the normal matrix 共i.e., matrix regularization兲 in order
to remove the singularity. The details on matrix regularization can
be found in Koch and Kusche 共2002兲. This decomposition ap-
proach leads to the biased estimates of ZD in the least squares
sense. However, as the rover positioning procedure uses the DD
measurement model, the biases cancel out when the DD correc-
tions are formed. It should be mentioned that an alternative
method of obtaining single-path phase delays from GPS double
differences using independent constraints on zero differences was
proposed by Alber et al. 共2000兲.
CORS AND OPUS FOR ENGINEERS
The MPGPS ionospheric model is a local model with a spatial
resolution reflecting the reference station separation, and temporal
resolution equal to the data sampling rate. It normally uses three
to five reference stations within 100– 200 km from the rover lo-
cation. In this model, the decomposed slant ZD ionospheric de-
lays are interpolated 共extrapolated兲 to the rover’s location on a
satellite-by-satellite basis using ordinary Kriging. More details on
the actual algorithms used for ionosphere modeling and, in gen-
eral, for the network solution, can be found in, e.g., Kashani et al.
共2005兲 and Grejner-Brzezinska et al. 共2005兲.
The accuracy of the interpolated ionospheric corrections is pri-
marily a function of the state of the ionosphere, i.e., more variable
and active conditions will normally lead to larger errors in the
empirically derived model. Thus, the actual accuracy of the cor-
rections used in the rover positioning procedure must be properly
accounted for by using variable stochastic constraints. In general,
the level of stochastic constraints depends on the network–rover
separation, the spatial resolution of the network, and the state of
the ionosphere.
The efficiency of the AR process and the convergence speed of
the positioning algorithm depend on the selection of adequate
stochastic constraints for the ionospheric corrections. Grejner-
Brzezinska et al. 共2004兲 and Wielgosz et al. 共2005兲 demonstrate
that adaptive constraints are necessary to account for variable
levels of correction accuracy. It was verified in Wielgosz et al.
共2005兲 that constraints ranging from 1 to 40 cm have to be used
to accommodate varying baseline lengths 共60– 120 km兲 and
changing ionospheric conditions. In general, constraints that are
too tight or too loose may lead to incorrect integer ambiguities.
Additional extended discussions on the selection of the level of
stochastic constraint in the baseline solution can be found in
Schwarz 共2008兲.
The tropospheric refraction term, in a form of undifferenced
tropospheric TZD, is estimated every 1 – 2 h for each reference
station in the network. Then the TZD values are interpolated to
the approximated rover position using a planar interpolation,
when three reference stations are used, or the Kriging method,
when more than three reference stations are used. The tropo-
spheric delays are mapped using the UNBabc mapping function
共Guo and Langley 2003兲. It should be noted that the ellipsoidal
height differences among the reference stations and the rover are
accounted for in the interpolation procedure. No tropospheric gra-
dient is estimated at this stage. For more information on interpo-
lation algorithms commonly used in the network-based GPS
algorithms, the reader is referred to Dai et al. 共2004兲.
AR Test Criteria
In order to validate the accuracy of the ionospheric corrections, a
high-resolution reference ionospheric model 共actual DD iono-
spheric delays兲 was derived using MPGPS, based on the reference
stations and the 共simulated兲 rover data. Next, high resolution
ionospheric corrections were computed based only on the refer-
ence network data, and the corrections were interpolated 共extrapo-
lated兲 for the rover’s location. The difference between the
reference DD ionospheric delays and the interpolated 共extrapo-
lated兲 corrections, referred to as DD ionospheric correction re-
siduals, provides a measure of quality of the network-based
ionospheric corrections.
To test the speed and reliability of ambiguity resolution, the
AR process was restarted every 20 epochs 共10 min兲, resulting in
144 sessions during the 24-h period. The AR statistics and the
145

Fig. 3. Kp index, 04-03-04 共ISGI 2008兲
positioning accuracy, presented in the next section, were derived
based on 144 samples for both network geometries tested. The
AR success rate is defined as the ratio of the number of sessions,
in which the ambiguities were successfully resolved and vali-
dated, to the total number of sessions processed 共W-test⬎ 4 vali-
dates the integer selection兲. An additional validation measure is
based on the known coordinates of the rover location, where the
rover position horizontal residuals dn and de, with respect to the
known reference coordinates, must meet the following empiri-
cally defined criterion: 冑dn2 + de2 艋 3 cm. Naturally, the second
criterion can only be used for performance testing, as no rover
coordinates are available under operational scenarios. An AR vali-
dation failure results when W-test⬎ 4, but 冑dn2 + de2 ⬎ 3 cm 共this
case is referred to as “validation failure” in the upcoming Tables
6 and 8兲. The geometric dilution of precision 共GDOP兲 threshold
of 7 was used 共i.e., the data are excluded from the solution if
GDOP⬎ 7 at any station兲.
Experimental Data Set Characteristics
A 24-h dual frequency, 30-s sampling rate data set collected on
April 3, 2004 by the selected CORS was used. A continuous 24-h
network calibration period is assumed, with the ionospheric and
tropospheric corrections derived from the network, and no meteo-
rological data used in the tropospheric correction estimation
共evaluated every 1 h兲. The International GNSS Service rapid or-
bits were used to process code and carrier phase data collected in
a low multipath environment. The a priori standard deviations
used were 0.6 m for pseudorange and 0.002 m for carrier phase;
and an elevation-dependent weighting scheme was applied 共a pro-
portionality factor, 1 / cos z, where z = elevation angle兲. In the
rover positioning solution, the stochastic constraints were im-
posed on the external ionospheric 共adaptive, ⬃30% of the correc-
tion’s magnitude, empirically determined兲 and tropospheric
corrections 共tight constraints of 1 cm兲. Varying levels of the geo-
magnetic Kp index were observed during the course of the day,
with the max Kp index= 6+, min Kp index= 2o and 兺Kp= 33o
共see Fig. 3兲. The ionospheric disturbances caused by geomagnetic
activity were observed during the period 21–24 UT. In the kine-
matic processor, 30-min 共60 epochs兲 processing intervals for co-
ordinate estimation were tested. The ITRF2000 共Altamimi et al.
2002兲 reference coordinates of the simulated rovers and the ref-
erence network stations were obtained from a 24-h BERNESE
solution 共Dach et al. 2007兲 with a millimeter-level standard de-
viations per coordinate. The processing was restarted every
10 min with a 20-min overlap between subsequent sessions.
Results and Discussion
Ionospheric Delay Analysis
Tables 1 and 2 show the statistics of the reference 共actual兲 DD
ionospheric delays within the predefined representative limits for
the 24-h period analyzed here, for both network geometries.
Tables 3 and 4 show the statistics of the DD ionospheric correc-
tion residuals, defined as the difference between the reference DD
ionospheric delays and the DD ionospheric correction interpo-
lated 共extrapolated兲 from the network. Two different ionospheric
conditions can be distinguished during the 24-h period:
• Quiet ionosphere between 0 UT and 21 UT 共7:00 p.m. to 4:00
p.m. next day local time兲; and
• Disturbed ionosphere between 21 UT and 24 UT 共4:00 p.m. to
7:00 p.m. local time兲.

Table 1. Reference DD Ionospheric Delays within the Indicated Limits 共Case 1兲 共%兲
04-03-04 共quiet, 0–21 UT兲 04-03-04 共active, 21–24 UT兲

Baseline 0 – 20 cm 20– 50 cm 50– 100 cm ⬎100 cm 0 – 20 cm 20– 50 cm 50– 100 cm ⬎100 cm

WOOS-MTVR
99.1 0.9 0.0 0.0 60.2 23.2 13.2 3.4
65 km
WOOS-COLB
96.4 3.5 0.1 0.0 51.4 23.3 17.3 8.0
131 km

Table 2. Reference DD Ionospheric Delays within the Indicated Limits 共Case 2兲 共%兲
04-03-04 共Quiet, 0–21 UT兲 04-03-04 共Active, 21–24 UT兲

Baseline 0 – 20 cm 20– 50 cm 50– 100 cm ⬎100 cm 0 – 20 cm 20– 50 cm 50– 100 cm ⬎100 cm

COLB-MTVR
99.7 0.3 0.0 0.0 69.1 22.4 7.2 1.3
65 km
COLB-WOOS
95.0 5.0 0.1 0.0 43.0 23.4 19.6 14.0
131 km
COLB-GARF
91.0 8.9 0.0 0.0 29.5 26.0 12.8 31.7
202 km

146 CORS AND OPUS FOR ENGINEERS

Table 3. DD Ionospheric Correction Residuals with respect to the Ref- Table 5. Reference DD Ionospheric Delay 共Absolute Values兲: Mean and
erence DD Ionospheric Delays from Table 1 within the Indicated Limits Standard Deviation 共Cases 1 and 2兲
共Case 1兲 共%兲
04-03-04 04-03-04
04-03-04 04-03-04 共quiet, 0-21 UT兲 共active, 21–24 UT兲
共quiet, 0–21 UT兲 共active, 21–24 UT兲
Standard Standard
Baseline ⫾5 cm ⫾10 cm ⫾20 cm ⫾5 cm ⫾10 cm ⫾20 cm Mean deviation Mean deviation
Case Baseline 共cm兲 共cm兲 共cm兲 共cm兲
WOOS-MTVR
95.5 99.9 100.0 56.2 72.4 91.9
65 km WOOS-MTVR
3.4 2.2 24.5 14.4
WOOS-COLB 65 km
95.4 99.7 100.0 62.6 77.5 93.1 1
131 km WOOS-COLB
6.0 3.6 37.6 25.4
131 km
COLB-MTVR
3.2 1.6 18.8 12.4
Consequently, in the following, the statistics are presented for 65 km
these two time windows separately. COLB-WOOS
2 6.2 3.6 45.5 26.8
Table 2 shows the statistics of the reference DD ionospheric 131 km
delays, and Table 4 shows the statistics of the DD ionospheric COLB-GARF
8.2 3.4 80.4 44.4
correction residuals, for Case 2. The reference DD ionospheric 202 km
delays exhibit characteristics similar to those presented in Table 1
for Case 1. However, the impact of network geometry can be
observed, e.g., by comparing the results in Tables 1 and 2 for the
should be noted that the reference DD ionospheric delays are
COLB-WOOS baseline. The DD ionospheric correction residuals
considered normally distributed. The primary conclusion that can
for COLB-WOOS, summarized in Table 4, show that when the
be drawn is that the variability of the ionosphere during the period
DD ionospheric corrections are extrapolated, significantly smaller
21–24 UT 共4:00 p.m.–7:00 p.m. local time兲 is up to 10 times
percentage of the ionospheric correction residuals, especially for
larger than that of the quiet period, based on the magnitude of the
the longer baselines, are of a magnitude lower than then L1 wave-
standard deviations. Note very significant means and standard de-
length, which would allow for fast AR. This is more pronounced
viations for COLB-WOOS 共130.9 km兲 and COLB-GARF
for the active ionospheric period.
共202 km兲 baselines 共Case 2兲.
As can be observed in Table 4, the accuracy of the DD iono-
Although the results for all baselines, even the longest ones,
spheric corrections 共indicated by the level of DD correction re-
are very similar in terms of their means and standard deviations
siduals兲 drops significantly with increasing distance between the
for the quiet ionospheric period, during the higher ionospheric
rover and the network. For example, baseline COLB-GARF
activity level, significant differences can be observed among the
共202 km兲, in comparison to COLB-WOOS 共130.9 km兲, displays a
baselines as a function of their lengths. In the postprocessing tests
significant drop in the ionospheric correction accuracy; now only
presented here, the magnitude of the standard deviation of the DD
56.5% of DD ionospheric correction residuals are good to 5 cm
ionospheric correction residual time series is a good indication of
共16% drop in comparison to the COLB-WOOS baseline兲, 81%
the level of the ionospheric stochastic constraints that could be
are within the 10 cm accuracy range 共10% drop in comparison to
used in the rover solution for a specific baseline length and iono-
the COLB-WOOS baseline兲, and 96.5% are good to 20 cm 共2.3%
spheric conditions. An example of the selection of stochastic con-
drop in comparison to the COLB-WOOS baseline兲. Conversely,
straints for the predicted ionospheric corrections in the rover
for the rover closer to the network 共e.g., MTVR兲, the ionospheric
solution is discussed in Schwarz 共2008兲.
corrections are extrapolated with the accuracy comparable to
Case 1, to within less than 3% for the quiet ionospheric period,
whereas for the more active period the difference between Case 1 Ambiguity Resolution Test
and Case 2 can reach up to 40% in terms of the percentage of DD In order to demonstrate the impact of the level of stochastic con-
ionospheric correction residuals falling within the selected accu- straints, Table 6 presents the AR statistics for Case 1, where ex-
racy ranges. ample 20- and 50-cm stochastic constraints 共labeled in Tables 6–9
Table 5 provides the statistics 共mean and standard deviation兲 as “DD iono correction standard”兲 were used for the ionospheric
of the reference DD ionospheric delays in the absolute sense. It corrections interpolated from the network solution to the rover
location 共MTVR, COLB兲. The AR success rate and time-to-fix, as
well as the percentage of AR validation failure, are listed as mea-
Table 4. DD Ionospheric Correction Residuals with respect to the Ref-
sures of the success of the ambiguity resolution process. The
erence DD Ionospheric Delays from Table 2 within the Indicated Limits
共Case 2兲 共%兲 20-cm constraint was selected here as an example only. Based on
the level of reference DD ionospheric delay standard deviations in
04-03-04 04-03-04 Table 5, much tighter constraints can be used for the quiet iono-
共quiet, 0–21 UT兲 共active, 21–24 UT兲 spheric period, e.g., Grejner-Brzezinska et al. 共2007兲. Relaxing
Baseline ⫾5 cm ⫾10 cm ⫾20 cm ⫾5 cm ⫾10 cm ⫾20 cm the constraint level far above the magnitude of the standard de-
viations listed in Table 5 leads to a longer time-to-fix 共more than
COLB-MTVR doubled, compared to the tighter constraint case兲.
92.7 99.4 100 60.8 85.7 96.3
65 km Table 7 lists the summary statistics of the positioning results
COLB-WOOS after the ambiguities have been fixed to their integer values 共Case
72.4 91.2 98.8 19.3 37.9 58.8
131 km
1兲, as shown in Table 6. Note that these results are compared to
COLB-GARF the 24-h reference solution, as mentioned earlier. Using the 20-cm
56.5 81.1 96.5 10.1 19.9 39.5
202 km
stochastic constraints, the example solutions presented in Table 7

CORS AND OPUS FOR ENGINEERS 147

Table 6. Single Baseline AR Statistics; Simulated Rovers: MTVR and COLB 共Case 1兲
04-03-04 04-03-04
共quiet ionosphere, 0–21 UT兲 共active ionosphere, 21–24 UT兲

DD iono AR Mean Validation AR Mean Validation

correction success time-to-fix failure success time-to-fix failure
Baseline standard 共cm兲 rate 共%兲 共epoch兲 共%兲 rate 共%兲 共epoch兲 共%兲
WOOS-MTVR 20 99.0 6 0.0 66.7 24 13.3
65 km 50 98.0 14 1.0 100.0 16 0.0
WOOS-COLB 20 96.0 8 3.0 64.3 22 14.3
131 km 50 91.9 18 3.0 100.0 21 0.0

show that centimeter-level accuracy can be achieved for each co-
ordinate component for the ionospherically quiet and active peri-
ods. This verifies the fact that once the ambiguities are fixed,
centimeter-level positioning results can be achieved. It should be
emphasized, however, that during the active period only 64.3–
66.7% of the epochs will have coordinate results based on fixed
ambiguities 共see Table 6兲. Table 8 presents similar statistics for
Case 2. It can be observed that centimeter-level positioning is
assured under quiet ionospheric conditions for the 65 and 131 km
baselines, whereas the 202 km baseline shows a lower accuracy.
Under active ionospheric conditions, all baselines processed with
the extrapolated DD ionospheric corrections display poor accu-
racy due to the AR failure 共see also Table 9兲. Note that these
statistics were obtained based on restarting the AR procedure to
test the effectiveness of the process, whereas in real operational
scenario the ambiguities would be retained if no cycle slip occurs.

Table 7. Mean and Standard Deviation of the n, e, and u Coordinate Residuals for Selected Time Windows; Simulated Rovers: MTVR and COLB
共Case 1兲
DD iono Mean 共cm兲 Standard deviation 共cm兲
Time Interval correction standard
Baseline 共h兲 共cm兲 n e u n e u
WOOS-MTVR 7:00–7:30 20 −0.1 −0.3 −0.8 0.4 0.4 1.0
65 km 22:10–22:40 20 0.3 −0.2 1.6 0.6 0.5 1.2
WOOS-COLB 7:00–7:30 20 −0.2 −0.4 −0.3 0.4 0.5 1.2
131 km 22:10–22:40 20 0.1 −0.3 0.6 0.6 0.5 1.1

Table 8. Mean and Standard Deviation of n, e, and u Coordinate Residuals for Selected Time Windows; Simulated Rovers: MTVR, WOOS, and GARF
共Case 2兲
Standard deviation
Mean 共cm兲 共cm兲
Time interval DD iono standard
Baseline 共h兲 共cm兲 n e u n e u
COLB-MTVR 7:00–7:30 20 0.1 0.2 −0.1 0.3 0.4 1.1
65 km 22:10–22:40 50 −0.6 2.2 2.0 3.3 6.5 3.4
COLB-WOOS 7:00–7:30 50 0.2 0.4 0.7 0.4 0.5 1.2
131 km 22:10–22:40 70 1.3 13.3 −14.3 10.9 16.5 29.4
COLB-GARF 7:00–7:30 50 2.5 0.9 −2.3 8.0 1.8 3.9
202 km 22:10–22:40 100 −12.2 50.6 25.2 16.2 23.7 26.1

Table 9. Single Baseline AR Statistics; Simulated Rovers: MTVR, WOOS, and GARF 共Case 2兲
04-03-04 共quiet, 0–21 UT兲 04-03-04 共active, 21–24 UT兲

DD iono AR success Mean Validation AR success Mean Validation

correction standard rate time-to-fix failure rate time-to-fix failure
Baseline 共cm兲 共%兲 共epoch兲 共%兲 共%兲 共epoch兲 共%兲
COLB-MTVR 20 99.0 4 1.0 73.3 11 20.0
65 km 30 95.1 6 4.9 93.3 9 6.7
50 93.2 7 10.0 100.0 16 0.0
COLB-WOOS 35 88.8 23 3.7 26.7 45 33.3
131 km 50 89.7 27 1.9 26.7 44 33.3
70 86.0 30 1.9 46.7 45 13.3
COLB-GARF 50 65.4 26 26.2 13.3 57 20.0
202 km 70 58.9 30 28.0 20.0 53 20.0
100 61.7 33 24.3 20.0 53 13.3

148 CORS AND OPUS FOR ENGINEERS

Fig. 4. W-test and coordinate residuals for COLB–MTVR 共65 km, Case 2兲 at 共a兲 07:00 UT with DD ionosphere stochastic constraint of 20 cm;
共b兲 22:10 UT with DD ionosphere stochastic constraint of 50 cm. Dashed lines in the W-test plots represent a threshold value of 4. Dash–dotted
lines in the coordinate residual plot indicate a threshold of ⫾0.03 m.
Table 9 summarizes the AR statistics for the case that simu-
lates the shore-bound geometry 共Case 2兲. The shortest network–
rover separation of ⬃65 km 共COLB-MTVR兲 assures 99–73% 共for
quiet and active periods, respectively兲 of AR success rate using a
20-cm DD ionosphere correction stochastic constraint. Releasing
the constraint to 50 cm for the active period increases the success
rate to 100% and reduces the validation failure from 20 to 0%, but
as a trade-off, it increases the average time-to-fix from 11 to 16
epochs. Notably, the results for the COLB-WOOS baseline, com-
mon to both network geometries, are degraded by ⬃10% 共over
50% for the active period兲 in terms of the AR success rate, as
compared to the same baseline in the better rover–network geom-
etry scenario 共Table 6兲. The statistics in Table 9 for the longest
共202 km兲 baseline, COLB-GARF, indicate that low AR success
rate 共maximum of only 65.4%兲 can be achieved under quiet iono-
spheric conditions.
Clearly, in the geometry scenario in which the rover is as-
sumed to be moving away from the network, not only does the
ionospheric variability have an impact on the level of suitable
stochastic constraints, but also the baseline length plays a more
significant role as the corrections are extrapolated rather than in-
terpolated. Thus, the stochastic constraints that provided the best
solution in this case are larger than the reference DD ionospheric
delay standard deviations listed in Table 5. From the practical
stand point, a network–rover separation of ⬃65 km seems to be
the largest acceptable distance that assures a quality rover solu-
tion under both quiet and active ionospheric conditions. Still, a
careful selection of the level of stochastic constraints for the ex-
trapolated DD ionospheric correction is necessary. Increasing the
CORS AND OPUS FOR ENGINEERS
separation to ⬃130 km lowers the AR success rate by ⬃10% with
respect to the ⬃65 km baseline under quiet ionospheric condi-
tions; moving the rover further away from the network to a dis-
tance of ⬃202 km lowers the success rate by 25%, as compared
to the 130-km separation for a quiet ionosphere. Baselines above
65 km in length cannot provide acceptable solutions for more
than 20–46.7% of the epochs. Note that this case refers to the
extrapolation rather than the interpolation mode, and cannot be
directly compared to the normal operational scenario using a
commercial product, when the rover is normally inside the net-
work and the reference station separation is much lower.
Example plots of the W-test and the corresponding positioning
residuals are presented in Figs. 4 and 5 for baselines COLB-
MTVR and COLB-GARF for Case 2. In general, the quality and
continuity of COLB-MTVR solution is comparable to that of
Table 7, whereas the example plots presented in Fig. 5 indicate
that during a quiet ionosphere period it is possible to obtain a
good solution for baselines up to 200 km in length, but the solu-
tion continuity is not assured 共see Tables 8 and 9兲. For active
ionosphere periods, however, the longer baselines can only assure
short periods of good quality positioning solution, and there may
be significant periods where no solution can be obtained 共i.e.,
nonzero validation failure percentage兲.
Properties of DD Ionosphere and Their Impact on the
Network Solution: Summary
Rapid change of the ionospheric conditions during active geo-
magnetic periods is a major factor for inadequate modeling that
149
Fig. 5. W-test and coordinate residuals for COLB–GARF 共202 km, Case 2兲 at 共a兲 07:00 UT with DD ionosphere stochastic constraint of 50 cm;
共b兲 22:10 UT with DD ionosphere stochastic constraint 70 cm

results in unreliable prediction in time and space 共especially in the

case of ionospheric correction extrapolation兲. The ionosphere, as
a spatially and temporarily correlated medium, displays different
correlation times as a function of baseline length, time of day, and
the level of ionospheric activity. Across the network, correlation
exists between the total electron content 共TEC兲 along the line of
sight to different satellites, as observed from different stations,
due to the proximity of the stations within the network.
One of the primary objectives of using network-based posi-
tioning algorithms is to reduce the temporal correlation of the DD
ionospheric correction residuals in order to reduce initialization
times and to increase the accuracy and reliability of the position-
ing results 共Vollath et al. 2002兲. In order to quantify the benefit of
the network approach, the empirical autocorrelation function for
the reference DD ionospheric delay and the correction residuals
can be analyzed. Testing temporal correlation using varying base-
line lengths may provide clues to the characteristics of spatial
correlation. A good understanding of the spatial correlation is im-
portant in order to properly interpret the DD ionospheric correc-
tions, as the existence of correlation affects the interpolated 共or
extrapolated兲 correction quality.
It should be noted, however, that the analysis of the autocor-
relation of the DD ionospheric delays and ionospheric correction
residuals in the tested data set did not lead to conclusive results,
as the ionospheric properties change with satellite elevation and
azimuth, as well as with the level of ionospheric activity. Thus, Fig. 6. DD ionospheric delays and their empirical autocorrelation
only a selected example is presented here. Fig. 6 illustrates an function for 130.9-km baseline WOOS–COLB 共Case 1兲; 共a兲 quiet
example of the reference DD ionospheric delays 共top兲 and their ionosphere 共PRNs 13-31兲; 共b兲 active ionosphere 共PRNs 18–21兲. The
empirical autocorrelation function 共bottom兲. Fig. 7 illustrates the correlation time is 6 epochs for quiet period and 5 epochs for active
corresponding DD ionospheric correction residuals 共top兲 and their period. One epoch⫽30 s.

150 CORS AND OPUS FOR ENGINEERS

 Table 10. VTEC Correlation Time in Minutes per PRN for Quiet and
Active Conditions for Stations COLB and GARF
COLB GARF

PRN 0–21 UT 21–24 UT 0–21 UT 21–24 UT

1 40.0 — 40.0 —
3 — 7.5 — —
4 40.5 — 40.5 —
5 41.0 — 41.0 —
6 26.0 — 26.0 —
7 41.0 — 41.0 —
8 38.5 — 38.5 —
9 34.5 15.5 34.5 9.5
10 24.0 — 24.0 —
11 38.0 — 38.0 —
13 30.0 — 30.0 —
14 39.0 — 39.0 —
15 23.5 13.0 23.5 7.0
16 35.0 — 35.0 —
17 16.5 — 16.5 —
18 14.5 11.5 14.5 19.0
20 24.5 — 24.5 —
Fig. 7. DD ionospheric correction residuals and their empirical au-
tocorrelation function for 130.9-km baseline WOOS–COLB 共Case 1兲: 21 8.5 20.0 8.5 16.0
共a兲 quiet ionosphere 共PRNs 13-31兲; 共b兲 active ionosphere 共PRNs 18– 22 30.0 14.0 30.0 14.0
21兲. The correlation time is 5 epochs for quiet period and 4 epochs 24 37.5 — 37.5 —
for active period. One epoch⫽30 s. 25 32.5 — 32.0 —
26 18.0 21.5 18.0 18.0
27 35.5 — 32.5 —
empirical autocorrelation functions 共bottom兲 for the 130.9-km
28 28.5 — 28.5 —
baseline, WOOS-COLB, during two 2-h 共quiet and active兲 peri-
29 22.0 17.5 22.0 15.0
ods, using the ionosphere solution from Case 1. Note that the
30 42.0 — 42.0 —
empirical autocorrelation functions are based on the detrended
time series. As can be seen in Fig. 6, the ionosphere decorrelates 31 35.0 — 35.0 —
faster under active conditions, which can be explained by, in gen- Mean 29.7 15.1 29.7 14.1
eral, a higher randomness and variability of the reference DD
ionospheric delays 共as well as their correction residuals, as seen in
Fig. 7兲 under active ionospheric conditions. Note that correlation period, which indicates that lower quality interpolated 共or ex-
time is shorter, as expected, for the DD ionospheric correction trapolated兲 correction should be expected due to high spatiotem-
residuals as compared to the reference DD ionospheric delays. poral variability of the DD ionosphere. Note that the means and
The correlation time is defined here as the time needed for the their standard deviations are very similar during the period of
autocorrelation function to drop to 0.5. quiet ionospheric conditions for baseline lengths ranging from
Table 10 provides the summary statistics for vertical TEC ⬃65 to ⬃ 124 km, i.e., 2 – 3 cm for both mean and the standard
共VTEC兲 correlation time for both quiet and active ionosphere deviation, and increase to ⬃10 cm 共mean兲 and ⬃5 cm 共standard
periods for all satellites that were observed for a minimum of 2 h.
“—” in Table 10 indicates that the satellite was observed for less
than 2 h. The VTEC values per satellite were obtained using the
carrier-smoothed pseudorange data. The correlation time is on
average two times higher for the quiet period than for the active
period. Note that the correlation time is virtually the same for the
quiet time for satellites observed from the two locations separated
by about 200 km, indicating spatial correlation between the iono-
sphere observed from COLB and GARF. The differences ob-
served in correlation time during the active period for the same
satellites observed by COLB and GARF indicates a more signifi-
cant spatial decorrelation.
To summarize, the ionospheric properties for the period stud-
ied here, Fig. 8 illustrates the mean and the standard deviation of
the DD ionospheric delays for selected reference baselines, as a
function of baseline length and varying levels of ionospheric ac-
tivity. Note significantly larger mean, and especially standard de-
viations, for the active period. The standard deviations increased Fig. 8. Mean and standard deviation of DD ionospheric delays as a
from a few centimeters up to 55 cm during the ionospheric storm function of baseline length

CORS AND OPUS FOR ENGINEERS 151


Fig. 9. Best achieved AR rate and the corresponding time-to-fix
共min兲 as a function of baseline length; data sampling rate: 30 s
deviation兲 for baseline lengths 170– 200 km. The distance depen-
dence is more pronounced during periods of active ionospheric
conditions.
Fig. 9 summarizes the best achieved AR success rate and the
corresponding time-to-fix for all baselines tested for Cases 1 and
2. Note the increased time-to-fix and lower AR success rate as a
function of increased baseline length and ionospheric activity. For
the more active ionosphere period, some of the baselines 共e.g.,
WOOS-MTVR or WOOS-COLB in Case 1兲 show longer time-to-
fix as compared to the quiet period, but a comparable AR success
rate. In the case of the long baselines, for which the ionospheric
corrections were extrapolated 共COLB-WOOS or COLB-GARF in
Case 2兲, the time-to-fix becomes significantly longer and the AR
success rate is low.
In general it is rather difficult to quantify the functional depen-
dency of the correlation time of the DD ionospheric correction
residuals and the AR time-to-fix. However, for quiet ionospheric
conditions, when the ionosphere behaves in a more predictable
manner, a clear relationship can be observed. For example, the
correlation times for DD ionospheric correction residuals and the
time-to-fix are seven and six epochs, respectively, for the WOOS-
MTVR baseline, four and seven epochs, respectively, for the
WOOS-COLB baseline, and five and four epochs, respectively,
for the COLB-MTVR baseline 共not all shown here兲. Clearly, these
two quantities have a close relationship.
Summary and Conclusions
In this paper, the impact of the reference network–rover geometry
on the GPS kinematic rover coordinate solution derived using the
network-generated atmospheric corrections was investigated. Two
different geometries were considered: 共1兲 pentagonal, uniform
reference receiver geometry, with the rover inside the network of
five reference stations 共Case 1兲 and 共2兲 simulated shore-bound
reference receiver geometry for a rover moving away from the
shore line 共Case 2兲. The latter case was of primary interest here.
The analysis of these two scenarios enabled the quantification of
the growth of the error in the generated ionospheric corrections,
resulting in the lower success rate and lower reliability of AR in
the case of rovers moving away from the network, in comparison
to the case of a rover located within the reference receiver net-
work.
The following are the conclusions that can be drawn in rela-
tion to Case 1:
152 CORS AND OPUS FOR ENGINEERS
• Centimeter-level kinematic positioning accuracy can be
achieved when the ionosphere is in a comparatively undis-
turbed 共quiet兲 state.
• The accuracy is only slightly worse under disturbed condi-
tions, with a few-centimeter accuracy still achievable as long
as the rover is located inside the perimeter of the reference
receiver network; however, a much lower number of observa-
tion sessions can provide fixed solutions, unless the level of
stochastic constraint is released, which results in a longer
time-to-fix.
• Time-to-fix ranges from 6 共with 20-cm stochastic constraint
for the ionospheric correction and for the shortest baseline兲 to
18 epochs 共50-cm stochastic constraint兲 during periods of un-
disturbed ionosphere.
The following are the conclusions that can be drawn in relation to
Case 2:
• AR success rate decreases from ⬃99 to ⬃65% with an in-
crease in rover–reference receiver distance from the network’s
edge 共from ⬃65 to ⬃ 202 km兲 during periods of quiet iono-
sphere, with ionospheric stochastic constraints of 20 and
50 cm, respectively;
• AR success rate ranges from ⬃73 to 100% for relaxed sto-
chastic constraints 共i.e., 50 cm兲 to only ⬃20% 共70-cm con-
straint level兲 with increasing rover–reference receiver distance
from the network’s edge during periods of disturbed iono-
sphere;
• Time-to-fix increases from ⬃10 to 11 epochs to over 50 ep-
ochs with increasing rover–reference receiver distance from
the network’s edge for periods of active ionosphere; and
• Time-to-fix ranges from 4 to 33 epochs for the quiet iono-
sphere period, with increasing distance from the network’s
edge.
It has been shown that decorrelation of the DD ionosphere can be
achieved using the network corrections, and the effect was quan-
tified using the example of an empirically derived autocorrelation
function of the reference DD ionospheric delays and the corre-
sponding DD correction residuals. For completeness, the correla-
tion time for VTEC was quantified for all satellites during
observation periods of 2 h or more, for two stations separated by
⬃200 km. In general, the correlation time was twice as long for
the quiet ionosphere period compared to the active period, and
was comparable for the same satellites observed by the two sta-
tions 共⬃200 km apart兲 for the quiet period. However, more dif-
ferences were observed during the active ionosphere period,
indicating more significant temporal and spatial decorrelation.
In the positioning step, the level of stochastic constraints must
be released during active ionosphere periods in order to achieve
more reliable AR. This, however, may cause longer time-to-fix. It
has been shown that by doing so the AR success rate is signifi-
cantly increased 共e.g., from 60–70 to ⬃100%兲. The simulated
shore-bound geometry indicates that the land-based networks can
reliably support the rover positioning in the near-shore zone of
50– 60 km, and a rover moving further away will result in a de-
crease in the chance of AR and, ultimately, the accuracy and
continuity of its position will suffer. Note that for an improved
operable solution, horizontal tropospheric gradients may need to
be estimated, especially for the case when the corrections are
extrapolated over water surfaces.
Acknowledgments
The writers would like to thank Dr. Gerry Mader of the National
Geodetic Survey for his insightful comments on the draft of this
paper, and Professor Chris Rizos of the University of New South
Wales, for revising the final version of this manuscript. They
would also like to thank Miss. Karla Edwards, a Ph.D. student at
The Ohio State University, for providing VTEC estimates. During
his stay at The Ohio State University, the second writer was sup-
ported by the Scientific and Technological Research Council of
Turkey 共TUBITAK兲. This support is gratefully acknowledged.
References
Ahn, Y. W., Lachapelle, G., Skone, S., Gutman, S., and Sahm, S. 共2006兲.
“Analysis of GPS RTK performance using external NOAA tropo-
spheric corrections integrated with a multiple reference station ap-
proach.” GPS Solutions, 10共3兲, 171–186.
Alber, C., Ware, R., Rocken, C., and Braun, J. 共2000兲. “Obtaining single
path phase delays from GPS double differences.” Geophys. Res. Lett.,
27共17兲, 2661–2664.
Altamimi, Z., Pillard, P., and Boucher, C. 共2002兲. “ITRF2000: A new
release of the international terrestrial reference Frame for earth sci-
ence applications.” J. Geophys. Res., 107共B10兲, 2214, 具http://www.
agu.org/pubs/crossref/2002/2001JB000561.shtml典.
Alves, P., Ahn, Y. W., and Lachapelle, G. 共2003兲. “The effects of network
geometry on network RTK using simulated GPS data.” Proc., Institute
of Navigation GPS/GNSS 2003, The Institute of Navigation, Manas-
sas, Va., 1417–1427.
Dach, R., Hugentobler, U., Fridez, P., and Meindl, M. 共2007兲. User’s
manual of the Bernese GPS software version 5.0, Astronomical Insti-
tute, University of Bern, Bern, Switzerland.
Dai, L., Han, S., Wang, J., and Rizos, C. 共2004兲. “Comparison of inter-
polation algorithms in network-based GPS techniques.” Navigation,
50共4兲, 277–293.
Diep Dao, T. H., Alves, P., and Lachapelle, G. 共2004兲. “Performance
evaluation of multiple reference station GPS RTK for a medium scale
network.” J. Glob. Positioning Syst., 3共1–2兲, 173–182.
Feng, Y., and Rizos, C. 共2005兲. “Global, regional and local GNSS ap-
proaches: Concept and performance perspectives.” Proc., Institute of
Navigation GNSS 2005, The Institute of Navigation, Manassas, Va.,
2277–2287.
Grejner-Brzezinska, D. A., et al. 共2004兲. “An analysis of the effects of
different network-based ionosphere estimation models on rover posi-
tioning accuracy.” J. GPS, 3共1–2兲, 115–131.
Grejner-Brzezinska, D. A., et al. 共2007兲. “On efficiency and reliability of
ambiguity resolution in network-based RTK GPS.” J. Surv. Eng.,
133共2兲, 56–65.
Grejner-Brzezinska, D. A., Kashani, I., and Wielgosz, P. 共2005兲. “On
accuracy and reliability of instantaneous network RTK as a function
of network geometry, station separation, and data processing strat-
egy.” GPS Solutions, 9共3兲, 179–193.
Guo, J., and Langley, R. B. 共2003兲. “A new tropospheric propagation
delay mapping function for elevation angles down to 2°.” Proc., In-
stitute of Navigation GPS/GNSS 2003, The Institute of Navigation,
Manassas, Va., 368–376.
The International Service of Geomagnetic Indices 共ISGI兲. 共2008兲. 具http://
isgi.cetp.ipsl.fr/source/indices/Kp/kp2004.wdc典 共Jan. 2, 2008兲.
CORS AND OPUS FOR ENGINEERS
Joosten, P. 共2001兲. “The LAMBDA method: Matlab™ implementation
version 2.1.” Mathematical geodesy and positioning civil engineering
and geosciences, Delft Univ. of Technology, Delft, The Netherlands.
Kashani, I., Grejner-Brzezinska, D. A., and Wielgosz, P. 共2005兲. “To-
wards instantaneous network-based RTK GPS over 100 km distance.”
Navigation, 52共4兲, 239–245.
Kashani, I., Wielgosz, P., and Grejner-Brzezinska, D. A. 共2004兲. “The
effect of double difference ionospheric corrections latency on instan-
taneous ambiguity resolution in long-range RTK.” Proc., Institute of
Navigation GNSS 2004, The Institute of Navigation, Manassas, Va.,
2881–2890.
Koch, K. R., and Kusche, J. 共2002兲. “Regularization of geopotential de-
termination from satellite data by variance components.” J. Geodyn.,
76共5兲, 259–268.
Rizos, C. 共2002兲. “Network RTK research and implementation: A geo-
detic perspective.” J. GPS, 1共2兲, 144–150.
Schaer, S. 共1999兲. “Mapping and predicting the earth’s ionosphere using
the global positioning system.” Ph.D. thesis, Univ. of Berne, Berne,
Switzerland.
Schwarz, C. R. 共2008兲. “Heuristic weighting and data conditioning in the
National Geodetic Survey rapid static GPS 共RSGPS兲 software.” J.
Surv. Eng., 134共3兲, 76–82.
Schwarz, C. R., Snay, R. A., and Soler, T. 共2009兲. “Accuracy assessment
of the National Geodetic Survey’s OPUS-RS utility.” GPS Solutions,
13共2兲, 119–132.
Teunissen, P. J. G. 共1994兲. “A new method for fast carrier phase ambigu-
ity estimation.” Proc., IEEE PLANS, IEEE, New York, 562–573.
Uotila, U. A. 共1986兲. “Notes on adjustment computation. Part I.” Dept. of
Geodetic Science and Surveying, The Ohio State Univ, Columbus,
Ohio.
Verhagen, S. 共2004兲. “Integer ambiguity validation: An open problem?”
GPS Solutions, 8共1兲, 36–43.
Verhagen, S. 共2005兲. “On reliability of integer ambiguity resolution.”
Navigation, 52共2兲, 99–10.
Vollath, U., Buecherl, A., Landau, H., Pagels, C., and Wagner, B. 共2000兲.
“Multi-base RTK positioning using virtual reference stations.” Proc.,
Institute of Navigation GPS 2000, The Institute of Navigation, Ma-
nassas, Va., 123–131.
Vollath, U., Landau, H., Chen, X., Doucet, K., and Pagels, C. 共2002兲.
“Network RTK versus single base RTK—Understanding the error
characteristics.” Proc., Institute of Navigation GPS 2002, The Institute
of Navigation, Manassas, Va., 2774–2781.
Wang, J., Stewart, M., and Tsakiri, M. 共1998兲. “A discrimination test
procedure for ambiguity resolution on-the-fly.” J. Geodyn., 72共11兲,
644–653.
Wielgosz, P., Grejner-Brzezinska, D. A., and Kashani, I. 共2004兲. “Net-
work approach to precise medium range GPS navigation.” Naviga-
tion, 51共3兲, 213–220.
Wielgosz, P., Kashani, I., and Grejner-Brzezinska, D. A. 共2005兲. “Analy-
sis of long-range network RTK during severe ionospheric storm.” J.
Geodyn., 79共9兲, 524–531.
Zhang, K., et al. 共2006兲. “Sparse or dense: Challenges of Australian net-
work RTK.” IGNSS Symp., International Global Navigation Satellite
Systems Society, Queensland, Australia.
153
 19
Transforming Positions and Velocities between the
International Terrestrial Reference Frame of 2000 and North
American Datum of 1983
Tomás Soler, M.ASCE,1 and Richard A. Snay2

Abstract: In December 2001, Natural Resources Canada and the U.S. National Geodetic Survey 共NGS兲 jointly adopted values for a set
of 14 parameters for transforming positional coordinates and velocities between the International Terrestrial Reference Frame of 2000
共ITRF00兲 and the North American Datum of 1983 共NAD 83兲. Seven of these parameters characterize the variation with respect to time of
the standard seven parameters 共three shifts, three rotations, and a differential scale兲. In March 2002, the NGS updated the NAD 83
positional coordinates for all continuously operating reference stations to be consistent with their corresponding ITRF00 coordinates at an
epoch date of 2002.00. Also, the NGS has incorporated these adopted values for the 14 transformation parameters into software packages,
such as HTDP 共horizontal time dependent positioning兲 for transforming positional coordinates across time and between reference frames,
and OPUS 共On-line Positioning User Service兲 for processing global positioning system data. Both HTDP and OPUS are available through
the NGS Tool Kit 共http://www.ngs.noaa.gov/TOOLS/兲.
DOI: 10.1061/共ASCE兲0733-9453共2004兲130:2共49兲
CE Database subject headings: Datum; North America; Global positioning; Geodetic surveys; Velocity.

Introduction represents a great improvement over the U.S. Department of De-

A significant breakthrough in the geosciences field was accom-
plished with the introduction, more than two decades ago, of the
Global Positioning System 共GPS兲. The GPS deserves credit for
substantially increasing our knowledge of geocentric terrestrial
coordinate systems. It represents a substantial leap forward from
the regionally defined coordinate systems of pre-GPS vintage, for
example, the North American Datum of 1927 共NAD 27兲 and the
South American Datum of 1956 共SAD 56兲. The accuracy cur-
rently available in geocentricity, orientation, and scale of terres-
trial coordinate frames will be difficult to improve significantly in
the foreseeable future.
This achievement has been made possible primarily by refine-
ments in the precise ephemerides 共orbits兲 disseminated by the
International GPS Service 共IGS兲. These IGS orbits have been de-
rived from the GPS data recorded at numerous ground-based sta-
tions, and they currently provide positions for the GPS satellites
at the 5 cm level 共Springer and Hugentobler 2001兲. Moreover, the
IGS supplies, via the Internet, predicted orbits, referred to as
‘‘ultra-rapid’’ orbits, that give 3D estimates of satellite positions
with a standard error in the 30- to 40-cm range. This precision
1
Chief, Global Positioning System Branch, National Geodetic Survey,
NOS, National Oceanic and Atmospheric Administration, 1315 East-West
Hwy., Silver Spring, MD 20910. E-mail: Tom.Soler@noaa.gov
2
CORS Program Manager, National Geodetic Survey, NOS, National
Oceanic and Atmospheric Administration, 1315 East-West Hwy., Silver
Spring, MD 20910. E-mail: Richard.Snay@noaa.gov
Note. Discussion open until October 1, 2004. Separate discussions
must be submitted for individual papers. To extend the closing date by
one month, a written request must be filed with the ASCE Managing
Editor. The manuscript for this paper was submitted for review and pos-
sible publication on August 29, 2002; approved on April 18, 2003. This
paper is part of the Journal of Surveying Engineering, Vol. 130, No. 2,
May 1, 2004. ©ASCE, ISSN 0733-9453/2004/2-49–55/$18.00.
fense 共DoD兲 broadcast orbits, the standard error for whose satel-
lite positions is about 2.7 m 共Springer and Hugentobler 2001兲.
A large amount of effort has been expended on exploiting the
advent of precise positioning. Several countries have readily de-
ployed permanent GPS satellite tracking networks to establish a
fundamental framework for differential GPS positioning at sub-
centimeter accuracies. GPS campaigns have proliferated in recent
years, and new, superior continental reference systems have
evolved around the globe. These include the European Terrestrial
Reference Frame of 1989 共ETRF89兲, the Geocentric Datum of
Australia 1994 共GDA94兲, the North American Datum of 1983
共NAD 83兲, and the South American Geocentric Reference System
共SIRGAS兲. More information about the frames used in these par-
ticular datums is given in Soler and Marshall 共2003兲. Subse-
quently, local networks have been densified and rigorous control
for mapping and surveying has been extended. Also, as a result of
more sophisticated national geoid height models—so critical for
GPS leveling—the GPS now affords a more economical alterna-
tive to differential leveling for many heighting applications.
GPS users can now determine the 3D positional coordinates of
a point with centimeter accuracy relative to a control station lo-
cated several hundred kilometers away 共Eckl et al. 2001兲. As an
added incentive, a profusion of continuously operating reference
stations 共CORS兲 exists today that are operated for various differ-
ent applications. Such is the case for the National CORS network,
which is managed by the National Geodetic Survey 共NGS兲 in
cooperation with more than 100 organizations, each of which op-
erates at least one CORS. The National CORS network as of
March 2004 contained 459 permanently monumented GPS base
stations, and it is growing at a rate of about 7 stations per month.
Positional coordinates of the National CORS sites form the foun-
dation for the National Spatial Reference System 共NSRS兲, the
backbone for all geodesy, surveying, and mapping applications in
the United States. Not only is the National CORS network be-

154 CORS AND OPUS FOR ENGINEERS

coming a natural tool for accurate 3D positioning in the country,
but its GPS data holdings are used by a plethora of investigators
interested in applications as diverse as ionospheric research,
crustal motion, water vapor studies, and aerial mapping 共Snay
et al. 2002兲. For more information about the CORS program, con-
sult the Web address http://www.ngs.noaa.gov/CORS/.
Positional coordinates for the stations defining the NSRS are
expressed relative to the North American Datum of 1983, NAD
83 for short. These NAD 83 coordinates are in turn defined
through a Helmert 共similarity兲 transformation from coordinates
expressed relative to the International Terrestrial Reference Frame
of 2000 共ITRF00兲, the most accurate geocentric reference frame
currently available.
It should be pointed out here that recent studies by Merrigan
et al. 共2002兲 indicate that ITRF00 and World Geodetic System of
1984 共WGS 84兲 共G1150兲 are essentially identical. ITRFxx frames,
where xx denotes the last two digits identifying the solution, are
created under international sponsorship and satisfy stringent ac-
curacy requirements for various modern space-based geodetic
techniques. Associated with each ITRFxx frame is a specified
epoch date to which the published positions correspond. The po-
sition for some other date might differ due to phenomena such as
crustal motion. The epoch associated with ITRF00 is t 0
⫽1997.00 共January 1, 1997兲. Every well-defined reference frame
must specify a velocity for each point to transform its positional
coordinates from epoch t 0 to any other arbitrary epoch t.
The U.S. National Geodetic Survey 共NGS兲 determines posi-
tional coordinates for CORS sites by exploiting the most up-to-
date and advanced GPS methodologies and software. Initially,
these coordinates are rigorously computed in ITRF00. Introduc-
tory information about ITRF frames can be found in Boucher and
Altamimi 共1996兲 and Snay and Soler 共2000b兲. The final step in
CORS processing is to transform the ITRF00 coordinates into
NAD 83 coordinates. This requires implementing a set of trans-
formation equations, as will be explained in the following section.
Transforming Positional Coordinates
Let x(t) NAD 83 , y(t) NAD 83 , and z(t) NAD 83 denote the NAD 83
positional coordinates for a point at time t as expressed in a 3D
Cartesian Earth-centered, Earth-fixed coordinate system. These
coordinates are expressed as a function of time to reflect the re-
ality of the crustal motion associated with plate tectonics, land
subsidence, volcanic activity, postglacial rebound, and so on.
Similarly, let x(t) ITRF , y(t) ITRF , and z(t) ITRF denote the ITRFxx
positional coordinates for this same point at time t. The given
ITRFxx coordinates are related to their corresponding NAD 83
coordinates by a Helmert transformation that is approximated by
the following equations:
x 共 t 兲 NAD 83⫽T x 共 t 兲 ⫹ 关 1⫹s 共 t 兲兴 •x 共 t 兲 ITRF⫹␻ z 共 t 兲 •y 共 t 兲 ITRF
⫺␻ y 共 t 兲 •z 共 t 兲 ITRF
y 共 t 兲 NAD 83⫽T y 共 t 兲 ⫺␻ z 共 t 兲 •x 共 t 兲 ITRF⫹ 关 1⫹s 共 t 兲兴 •y 共 t 兲 ITRF
⫹␻ x 共 t 兲 •z 共 t 兲 ITRF
z 共 t 兲 NAD 83⫽T z 共 t 兲 ⫹␻ y 共 t 兲 •x 共 t 兲 ITRF⫺␻ x 共 t 兲 •y 共 t 兲 ITRF
⫹ 关 1⫹s 共 t 兲兴 •z 共 t 兲 ITRF
Here T x (t), T y (t), and T z (t) are translations along the x-, y-, and
z-axes, respectively; ␻ x (t), ␻ y (t), and ␻ z (t) are counterclock-
wise rotations about these same three axes; and s(t) is a differ-
CORS AND OPUS FOR ENGINEERS
ential scale change between ITRFxx and NAD 83. These approxi-
mate equations suffice because the three rotations usually have
rather small magnitudes. Note that each of these seven quantities
is represented as a function of time because improvements in
space-based geodetic techniques have enabled us to detect their
time-related variations with some degree of accuracy. A decade
ago such time-dependent variations were poorly known and often
overlooked 关for example, Soler and Hothem 共1988, 1989兲兴. These
time-dependent variations are assumed to be mostly linear, so that
the quantities may be expressed by the following equations:
T x 共 t 兲 ⫽T x 共 t 0 兲 ⫹Ṫ x • 共 t⫺t 0 兲
T y 共 t 兲 ⫽T y 共 t 0 兲 ⫹Ṫ y • 共 t⫺t 0 兲
T z 共 t 兲 ⫽T z 共 t 0 兲 ⫹Ṫ z • 共 t⫺t 0 兲
␻ x 共 t 兲 ⫽ 关 ␧ x 共 t 0 兲 ⫹␧˙ x • 共 t⫺t 0 兲兴 •m r (2)
␻ y 共 t 兲 ⫽ 关 ␧ y 共 t 0 兲 ⫹␧˙ y • 共 t⫺t 0 兲兴 •m r
␻ z 共 t 兲 ⫽ 关 ␧ z 共 t 0 兲 ⫹␧˙ z • 共 t⫺t 0 兲兴 •m r
s 共 t 兲 ⫽s 共 t 0 兲 ⫹ṡ• 共 t⫺t 0 兲
where m r ⫽4.84813681⫻10⫺9 ⬅conversion factor from milliarc
seconds 共mas兲 to radians.
Here, t 0 denotes a fixed, prespecified time of reference, com-
monly called the ‘‘reference epoch date.’’ Hence the seven quan-
tities T x (t 0 ), T y (t 0 ),...,s(t 0 ) are all constants. The seven other
quantities, Ṫ x , Ṫ y ,...,ṡ, which represent rates of change with
respect to time, are also assumed to be constants.
In 1997, Natural Resources Canada 共NRCan兲 and the NGS
jointly adopted values for these 14 constants to transform ITRF96
positional coordinates into their corresponding NAD 83 coordi-
nates in the following manner 共Craymer et al. 2000兲. Representa-
tives from these two organizations estimated the ‘‘best-fitting’’
values for the seven constants—T x (t 0 ), T y (t 0 ),...,s(t 0 )—for
transforming the ITRF96 coordinates of 12 selected very-long-
baseline-interferometry 共VLBI兲 stations at t 0 ⫽1997.00 to their
corresponding NAD 83 coordinates at this same time 共Fig. 1兲.
They subsequently set s(t 0 ) to zero to ensure that NAD 83 would
have the same scale as ITRF96. In addition, they adopted values
for the three rotation rates—␧˙ x , ␧˙ y , and ␧˙ z —so as to equal those
describing the average motion of the North American tectonic
plate according to the ‘‘no-net-rotation’’ NUVEL-1A geophysical
model of DeMets et al. 共1994兲. The use of this model is consistent
with the IERS convention 关McCarthy 共1996兲, Table 3.2兴. Finally,
they set the values of the remaining four constants—Ṫ x , Ṫ y , Ṫ z ,
and ṡ—to zero. Table 1, fifth column, presents the adopted values
for the constants for this transformation from ITRF96 to NAD 83.
Let us use the notation 共ITRF96→NAD83兲 in referring to this
transformation.
Based on the 12 VLBI stations, this transformation was sub-
sequently used to compute NAD 83 coordinates for all CORS
sites to establish a new ‘‘realization’’ of NAD 83, technically
denoted NAD 83 共CORS96兲. However, when the context is clear,
and to simplify the text, this nomenclature will be truncated in
this article to NAD 83. Snay and Soler 共2000a兲 describe the evo-
lution of NAD 83 from its original realization, denoted NAD 83
共1986兲, to NAD 83 共HARN兲 and then to NAD 83 共CORS96兲. The
definition of all these realizations remains consistent with the
(1)
definition of NAD 83 共1986兲, yet positional coordinates for the
same station may differ between any pair of realizations due to
the periodic implementation of advancements in technology and
computational procedures. That is, NAD 83 共CORS96兲 represents
155
 Fig. 1. Twelve very-long-baseline-interferometry stations used to determine transformation ITRF96→NAD83

an improvement of the original realization, NAD 83 共1986兲.
Schwarz 共1989兲 provides detailed information about the definition
and establishment of NAD 83 共1986兲.
Since the adoption of the 共ITRF96→NAD 83兲 transformation,
the International Earth Rotation Service 共IERS兲 has introduced
two newer realizations, ITRF97 and ITRF00. The transformation
of positional coordinates from ITRF00 to NAD 83, denoted
共ITRF00→NAD 83兲, is defined in terms of the composition of
three distinct transformations, applied sequentially. First, one
transforms positional coordinates from ITRF00 to ITRF97, then
from ITRF97 to ITRF96, and finally from ITRF96 to NAD 83.
This composition may be symbolically expressed via Eq. 共3兲:
共 ITRF00→NAD 83兲 ⫽ 共 ITRF00→ITRF97兲
⫹ 共 ITRF97→ITRF96兲
⫹ 共 ITRF96→NAD 83兲
where 共ITRF00→ITRF97兲 and 共ITRF97→ITRF96兲 denote the
adopted transformations from ITRF00 to ITRF97 and from
ITRF97 to ITRF96, respectively. These adopted transformations
are discussed in the following paragraphs.
When ITRF97 was introduced, some controversy as to its re-
lationship with ITRF96 arose. According to the IERS, the orga-
nization responsible for defining the various ITRFxx realizations,
the ‘‘best-fitting’’ Helmert transformation from ITRF97 to
ITRF96 is the identity function 共that is, all 14 Helmert parameters
are zero in value兲. Indeed, the IERS defined ITRF97 positional
coordinates and velocities for several hundred stations, each of
which had been positioned by one or more space-based geodetic
techniques, so that they would agree on average with their corre-
sponding ITRF96 positional coordinates and velocities 共Boucher
et al. 1999兲.
However, when the IGS independently estimated values for
(3) the 14 parameters to transform ITRF97 positional coordinates and

Table 1. Transformation Parameters between Different Frames for t 0 ⫽1997.00

Parameter Units ITRF00→ITRF97 ITRF97→ITRF96 ITRF96→NAD 83
T x (t 0 ) meters ⫹0.0067 ⫺0.00207 ⫹0.9910
Ṫ x meters/year ⫹0.0000 ⫹0.00069 ⫹0.0a
T y (t 0 ) meters ⫹0.0061 ⫺0.00021 ⫺1.9072
Ṫ y meters/year ⫺0.0006 ⫺0.00010 ⫹0.0a
T z (t 0 ) meters ⫺0.0185 ⫹0.00995 ⫺0.5129
Ṫ z meters/year ⫺0.0014 ⫹0.00186 ⫹0.0a
␧ x (t 0 ) mas ⫹0.0a ⫹0.12467 ⫹25.79
␧˙ x mas/year ⫹0.0a ⫹0.01347 ⫹0.0532
␧ y (t 0 ) mas ⫹0.0a ⫺0.22355 ⫹9.65
␧˙ y mas/year ⫹0.0a ⫺0.01514 ⫺0.7423
␧ z (t 0 ) mas ⫹0.0a ⫺0.06065 ⫹11.66
␧˙ z mas/year ⫺0.02 ⫹0.00027 ⫺0.0316
s(t 0 ) ppb ⫹1.55 ⫺0.93496 ⫹0.0a
ṡ ppb/year ⫹0.01 ⫺0.19201 ⫹0.0a
Note: mas⬅milliarc second. Counterclockwise rotations of axes are assumed positive; 1 ppb⫽10⫺3 ppm.
a
Values set to zero by definition.

156 CORS AND OPUS FOR ENGINEERS

Table 2. Parameters Adopted for Transformation ITRF00→NAD 83 ing, the values adopted for transforming ITRF00→NAD 83
共CORS96兲 共CORS96兲 at epoch t 0 ⫽1997.00 are given in Table 2.
Parameter epoch: A cursory check of the shifts in Table 2 shows that the origin
t 0 ⫽1997.00 Definition Units Values at t 0 of the NAD 83 frame is offset from the geocenter 共as defined by
ITRF00兲 by approximately 2 m in the y component. This fact
T x (t 0 ) x-shift meters ⫹0.9956
makes it imperative that all GPS processing should be computed
T y (t 0 ) y-shift meters ⫺1.9013 initially on a more geocentric frame such as ITRF00, and after the
T z (t 0 ) z-shift meters ⫺0.5215 very last processing phase, transform the positions from ITRF00
␧ x (t 0 ) x-rotation mas ⫹25.915 to the NAD 83 共CORS96兲 frame after substituting in Eq. 共1兲 the
␧ y (t 0 ) y-rotation mas ⫹9.426 adopted parameters of Table 2.
␧ z (t 0 ) z-rotation mas ⫹11.599 Eq. 共1兲, in conjunction with the 14 parameters just described,
s(t 0 ) scale ppb ⫹0.62 has been implemented into the NGS software utility, HTDP 共hori-
Ṫ x x-shift rate meters/year ⫹0.0007 zontal time-dependent position兲. This software is freely available
Ṫ y y-shift rate meters/year ⫺0.0007 at the NGS Web site 共http://www.ngs.noaa.gov兲 by clicking on
Ṫ z z-shift rate meters/year ⫹0.0005 具具Geodetic Tool Kit典典, and then on 具具HTDP典典. The software enables
␧˙ x x-rotation rate mas/year ⫹0.067 people to transform positional coordinates from one reference
␧˙ y y-rotation rate mas/year ⫺0.757 frame to another and/or from one epoch date to another. Indi-
vidual positions may be entered interactively or a collection of
␧˙ z z-rotation rate mas/year ⫺0.051
positions entered as a formatted file. When people expect to trans-
ṡ scale rate ppb/year ⫺0.18
form only a few positions, then they may run HTDP interactively
Note: mas⬅milliarc second. Counterclockwise rotation of axes are as- from the Web page following the stated instructions. Further tech-
sumed positive; 1 ppb⫽10⫺3 ppm.
nical information about HTDP is discussed in 共Snay 1999兲.
The NGS recognized the implications and promise of the GPS
in its early stages of development and embarked on the promotion
velocities to their ITRF96 counterparts using about 50 well- and adaptation of GPS methods to improve the NSRS. However,
established GPS base stations distributed around the world, this this endeavor is an iterative process marked by the everyday de-
organization found some values that differed significantly from mand of improving positional accuracies, constantly guided by
zero 共Springer et al. 2000兲. Hence, while ITRF97 and ITRF96 the latest advancements in technology and the most recent defi-
may be essentially equivalent for a combination of high-precision nitions of coordinate systems. A history of various sets of the
geodetic data types—VLBI, satellite laser ranging 共SLR兲, and NGS-adopted transformation parameters between earlier realiza-
Doppler orbitography and radio-positioning integrated by satellite tions of ITRF and NAD 83 is available on the NGS Web page
共DORIS兲—the two reference frames are not equivalent when 共http://www.ngs.noaa.gov/CORS/metadata1兲.
using only GPS observations. A further consideration should be kept in mind: The transfor-
In contrast to ITRF frames, IGS-derived geodetic frames are mation parameters necessary to obtain NAD 83 coordinates from
exclusively based on GPS observations. NRCan and the NGS ITRF00 are the result of comparing coordinates at 12 VLBI sta-
decided to adopt the IGS-derived transformation from ITRF97 to tions. However, when GPS-derived geodetic networks such as the
ITRF96 because most of the precise geodetic work being per- Federal Base Network 共FBN兲 or the older High Accuracy Refer-
formed in North America is based on GPS technology. Table 1, ence Network 共HARN兲 are adjusted, some observational errors
fourth column, presents the 14 parameters adopted by the NGS, are propagated, and small distortions appear when coordinates
which equal the original parameters derived by IGS scientists. obtained using ITRF00 and the strict application of Eq. 共1兲 are
These values differ, however, from those appearing in Springer contrasted with the results of the FBN/HARN network adjust-
et al. 共2000兲 because they correspond to t 0 ⫽1997.00, whereas ment. These differences 共up to 6 cm in the horizontal compo-
those in Springer et al. 共2000兲 correspond to t 0 ⫽1999.58 共August nents兲 are also influenced by the fact that FBN/HARN results are
1, 1999兲. Also, the value of ␧˙ z in Springer et al. 共2000兲 differs derived from an ensemble of discrete statewide networks that
slightly from the original value derived by IGS investigators. were planned, observed, and adjusted somewhat independently.
Similarly, when ITRF00 was introduced 共Altamimi et al. For this reason, a homogeneous continentwide adjustment—
2002兲, the IERS and IGS assigned different values to the 14 pa- including GPS observations for all A- and B-order reference sta-
rameters in the transformation from ITRF00 to ITRF97. Again, tions stored in the NGS database—is planned to be performed
the IERS values were based on several hundred stations and in- around 2005.
volved various space-based geodetic observational techniques,
whereas the IGS values were based on about 50 GPS base sta-
tions. In this case, however, the IERS and IGS estimates for the NAD 83 Velocities
14 parameters did not differ significantly in a statistical sense.
Hence, NRCan and the NGS adopted the IERS values because the The advancement of GPS technology and methods has reached
IERS shoulders primary responsibility for defining the ITRFxx the point that, without much effort, relative positioning of stations
realizations. Table 1, third column, presents the IERS values for with respect to the National CORS sites can be accomplished
the 14 parameters for the transformation from ITRF00 to ITRF97. with an accuracy of a few centimeters. Accordingly, in March
See also ftp://lareg.ensg.ign.fr/pub/itrf/ITRF.TP. 2002, the NGS upgraded NAD 83 共CORS96兲 positional coordi-
Because the values for the 14 parameters of the three adopted nates and velocities for all CORS sites, except those located on
transformations are rather small in magnitude, the values for the islands in the western Pacific Ocean, so that they equal the trans-
14 parameters for transforming ITRF00 positional coordinates to formed values of their recently computed ITRF00 positional co-
NAD 83 positional coordinates may be computed with sufficient ordinates and velocities. The special case of the Pacific islands is
accuracy by adding across the rows in Table 1. After some round- treated at length by Snay 共2003兲. This upgrade removed inconsis-

CORS AND OPUS FOR ENGINEERS 157

tencies among the previously published NAD 83 共CORS96兲 po-
sitional coordinates and velocities for the CORS. In some cases,
these positional inconsistencies exceeded 2 cm, horizontally,
and/or 4 cm, vertically. Such inconsistencies can be easily de-
tected with current high accuracy GPS surveys. These inconsis-
tencies would have corrupted, for example, results obtained with
the On-line Positioning User Service 共OPUS兲, a Web-based utility
that uses CORS positions and velocities to compute accurate po-
sitions for other points 共Mader et al. 2003兲.
Moreover, for each CORS site, the NGS is now providing
NAD 83 共CORS96兲 positional coordinates that are referenced to
an epoch date of 2002.00. That is, the published coordinates for a
site’s position correspond to this site’s location on January 1,
2002. Special attention should be given to apply NAD 83
共CORS96兲 site velocities when computing NAD 83 site positions
at any other date. Previously, NAD 83 共CORS96兲 positions for
the CORS sites were published for the epoch date of 1997.00
共January 1, 1997兲. The use of a more current epoch date will
reduce those systematic errors introduced when points are posi-
tioned relative to CORS sites at different epochs without appro-
priately applying their site velocities.
This more current epoch date will especially benefit those
people involved in positioning activities in areas of active crustal
motion, such as the western Continental United States and Alaska.
On the other hand, published ITRF00 positional coordinates will
continue to be referenced to an epoch date of 1997.00 to remain
consistent with international convention. Generally speaking,
geographic points located in the eastern and central United States
have NAD 83 velocities that are close to zero, and therefore their
NAD 83 positional coordinates should not change much between
different epochs. This is not the case for geographic points in the
United States that are located within a few hundred kilometers of
the Pacific Coast; here NAD 83 horizontal velocities with magni-
tudes in excess of 5 mm/year are prevalent.
Velocities referred to the NAD 83 共CORS96兲 reference frame
can be obtained from their corresponding ITRF00 velocities by
taking the derivatives of Eq. 共1兲 with respect to time. After ne-
glecting second-order terms, the following equations are ob-
tained:
v x NAD 83⫽ v x ITRF⫹Ṫ x ⫹ṡ•x 共 t 兲 ITRF⫹␻
˙ z •y 共 t 兲 ITRF⫺␻˙ y •z 共 t 兲 ITRF
v y NAD 83⫽ v y ITRF⫹Ṫ y ⫹ṡ•y 共 t 兲 ITRF⫺␻
˙ z •x 共 t 兲 ITRF⫹␻˙ x •z 共 t 兲 ITRF
v z NAD 83⫽ v z ITRF⫹Ṫ z ⫹ṡ•z 共 t 兲 ITRF⫹␻
˙ y •x 共 t 兲 ITRF⫺␻˙ x •y 共 t 兲 ITRF
(4)
where
␻˙ x ⫽␧˙ x •m r
␻
˙ y ⫽␧˙ y •m r (5)
˙ z ⫽␧˙ z •m r
␻ positional coordinates at epoch 2002.00 共or epoch t兲 both in terms
Note that in Eq. 共4兲, and according to Table 2, the magnitudes
of Ṫ x , Ṫ y , and Ṫ z do not exceed 0.7 mm•year⫺1; and similarly,
the products of ṡ and any component of the positional coordinates
do not exceed 1.1 mm•year⫺1 in magnitude on the surface of the
Earth. Eq. 共4兲, in conjunction with the set of adopted transforma-
tion parameters, is implemented in the NGS software, HTDP, to
compute velocities of the CORS sites referred to NAD 83
共CORS96兲. Therefore, CORS sites have coordinates and veloci-
ties referred to the NAD 83 共CORS96兲 reference frame, and the
transformation of NAD 83 coordinates from epoch to epoch is
possible.
158 CORS AND OPUS FOR ENGINEERS
The situation is different when one deals with coordinates of
the FBN/HARN marks that are also retrievable from the NGS
database. First of all, it should be pointed out that these coordi-
nates implicitly refer to the frame and corresponding epoch that
were in use when the statewide or regional network adjustment
was completed. At that particular moment, one or several CORS
sites included in the network were constrained using the then-
available frame and epoch. However, the NGS does not provide a
velocity for an FBN/HARN mark on its ‘‘data sheet’’ 共see ex-
amples of data sheets at 具http://www.ngs.noaa.gov/
datasheet.html典兲 because, generally, insufficient observations exist
to estimate this velocity with good accuracy. Data sheets are the
NGS’s principal informational product. Each data sheet provides
positional and descriptive information for a specific geodetic sta-
tion in the NSRS. NGS data sheets can be retrieved directly from
the NGS database.
HTDP-predicted NAD 83 velocities are zero if the area where
the point is located is free from crustal motion activity, for ex-
ample, most of the eastern United States. However, some geodetic
marks located in the western United States may need to be up-
dated to epoch 2002.00 before they are used for GPS densification
work. In this instance, it is possible to update FBN/HARN NAD
83 point coordinates to epoch 2002.00 using its NAD 83 velocity.
NAD 83 velocity components v x NAD 83, v y NAD 83, and v z NAD 83
at any FBN/HARN mark can be predicted using the
NGS software HTDP available from the Web. From the NGS
main page 共http://www.ngs.noaa.gov/兲, click sequentially
along the following path: 具具Geodetic Tool Kit典典→具具HTDP典典
→具具Interactive Computations典典→具具Interactive Predict Velocities典典
→具具Individual Points Entered Interactively典典→具具NAD 83典典. These
velocities could then be applied to update FBN/HARN NAD 83
共CORS96兲 positions to epoch 2002.00 as follows:
x NAD 83共 2002.00 兲 ⬇x NAD 83共 t F 兲 ⫹ v x NAD 83
• 共 2002.00⫺t F 兲
y NAD 83共 2002.00 兲 ⬇y NAD 83共 t F 兲 ⫹ v y NAD 83
• 共 2002.00⫺t F 兲
z NAD 83共 2002.00 兲 ⬇z NAD 83共 t F 兲 ⫹ v z NAD 83
• 共 2002.00⫺t F 兲 (6)
where t F is the epoch of the FBN/HARN adjustment as given on
the NGS data sheet for this station.
Eq. 共6兲 has been encoded into HTDP so that users of that
software can compute positional coordinates at epoch 2002.00
simply by entering the positional coordinates at epoch t F . Actu-
ally, the code in HTDP is more general than Eq. 共6兲 in four ways.
First, users can apply HTDP to update the positional coordinates
to any arbitrary epoch t, not just to epoch 2002.00. Second, HTDP
enables its users to enter the positional coordinates at time t F in
terms of x, y, and z or in terms of their equivalent latitude, longi-
tude, and ellipsoidal height. HTDP also provides the resulting
of x, y, and z and in terms of latitude, longitude, and ellipsoidal
height. Third, HTDP provides its users the option of entering their
own values for v x NAD 83, v y NAD 83, and v z NAD 83 instead of using the
values predicted by the crustal motion model that has been en-
coded into HTDP. Fourth, HTDP includes mathematical models
for predicting those episodic motions associated with certain
major earthquakes. Eq. 共6兲 is based on the assumption that no
such episodic motions have occurred between epoch t F and epoch
2002.00. For all these reasons, it is recommended that HTDP be
used to transform positional coordinates from one epoch date to
another.
OPUS Transformations
In March 2001, NGS introduced the OPUS Web-based utility.
OPUS enables its users to submit static GPS data to the NGS via
the World Wide Web, whereby OPUS will compute the positional
coordinates for the location associated with these data. OPUS
uses NGS computers and PAGES 共program for the adjustment of
GPS ephemeris http://www.grdl.noaa.gov/GRD/GPS/DOC/
toc.html兲 software. OPUS processes the submitted data together
with GPS data from three National CORS sites, and the user
receives the derived positional coordinates via e-mail in a timely
fashion, usually a few minutes. The following steps outline how
OPUS currently obtains ITRF00 coordinates and then applies the
共ITRF00→NAD 83兲 transformation to obtain corresponding
NAD 83 共CORS96兲 coordinates:
• ITRF epoch transformation: After identifying three ‘‘suitable’’
CORS, OPUS retrieves their adopted ITRF00 positional coor-
dinates and velocities from the NGS Integrated Data Base
共NGSIDB兲. Because the NGSIDB stores these ITRF00 posi-
tional coordinates for an epoch date of 1997.00, OPUS uses
the stored velocities to calculate the corresponding ITRF00
positional coordinates for the midpoint of the time interval
during which the submitted data were observed 共epoch t兲.
• PAGES software invoked: Using the submitted GPS data in
conjunction with the publicly available GPS data for the three
selected CORS, OPUS invokes PAGES software to determine
three independent sets of ITRF00 positional coordinates
共epoch t兲 and their corresponding intersite vector components
(⌬x,⌬y,⌬z), also at epoch t. All these values are computed
using the GPS data from each CORS site while holding fixed
its coordinates determined in the previous step.
• ITRF positions averaged: The above three positions are aver-
aged to obtain the final ITRF00 coordinates of the unknown
point at epoch t.
• Frame transformation: The ITRF00 intersite vector compo-
nents (⌬x,⌬y,⌬z) computed by PAGES are then transformed
to the NAD 83 共CORS96兲 frame using equations similar to Eq.
共1兲. In fact, these equations have the same form and values as
Eq. 共1兲, except T x (t)⫽T y (t)⫽T z (t)⫽0 共Soler et al. 2002兲.
Notice that the resulting NAD 83 intersite vector components
still refer to epoch t, the midpoint of the time interval when the
data were observed.
• NAD 83 epoch transformation: OPUS retrieves NAD 83
共CORS96兲 positional coordinates and velocities for the three
CORS from the NGSIDB. Because the NGSIDB stores these
positional coordinates for an epoch date of 2002.00, OPUS
uses an equation in the form of Eq. 共6兲, to determine the cor-
responding NAD 83 positional coordinates at epoch t, the mid-
point of the time interval when the submitted GPS data were
observed.
• Three NAD 83 positions computed: Each NAD 83 intersite
vector is added to the NAD 83 coordinates of the correspond-
ing CORS, as determined in the previous step, to obtain three
sets of NAD 83 positional coordinates for the unknown point
at epoch t, the midpoint of the data time interval.
• NAD 83 positions averaged: The average of the above three
values is adopted as the NAD 83 positional coordinates of the
unknown point at epoch t.
• HTDP model invoked: Finally, OPUS invokes the HTDP soft-
ware to transform the above NAD 83 positional coordinates to
epoch 2002.00. This step requires HTDP to predict the NAD
83 velocity for the unknown point and to apply this velocity in
a manner similar to Eq. 共6兲.
CORS AND OPUS FOR ENGINEERS
Note that OPUS-derived NAD 83 共CORS96兲 positional coor-
dinates are not obtained by a direct frame transformation of their
corresponding ITRF00 coordinates, but by the sequence of steps
described above.
Conclusions
Positional coordinates and velocities of an arbitrary point may be
transformed from ITRF00 to NAD 83 using Eqs. 共1兲 and 共4兲,
respectively. The NGS applied this technique in March 2002 to
update NAD 83 position coordinates for all CORS sites so that
these coordinates are consistent with adopted ITRF00 coordi-
nates. Furthermore, the NGS updated the NAD 83 coordinates for
all CORS to an epoch date of 2002.00. This latter update makes it
easier for GPS users working in regions prone to crustal motions
to obtain accurate results when site velocities are not appropri-
ately applied. CORS positions effectively act as both ITRF and
NAD 83 fiducial 共reference兲 points from which accurate GPS
networks could be propagated and densified. A new NSRS frame-
work based on the most accurate CORS coordinates and veloci-
ties is expected to be completed by 2005, perpetuating the pri-
mary objective of the NGS: to provide and maintain a spatial
reference frame for all surveying and mapping applications in the
United States.
Acknowledgments
The writers wish to express their sincere thanks to C. Goad, J.
Marshall, D. Milbert, and B. H. W. van Gelder for their thoughtful
review and valuable suggestions.
References
Altamimi, Z., Sillard, P., and Boucher, C. 共2002兲. ‘‘ITRF2000: A new
release of the International Terrestrial Reference Frame for Earth sci-
ence applications.’’ J. Geophys. Res., 107共B10兲, ETG2/1–19.
Boucher, C., and Altamimi, Z. 共1996兲. ‘‘International Terrestrial Refer-
ence Frame.’’ GPS World, 7共9兲, 71–74.
Boucher, C., Altamimi, Z., and Sillard, P. 共1999兲. ‘‘The International Ter-
restrial Reference Frame 共ITRF97兲.’’ Intern. Earth Rotation Serv. Tech
Note 27, Observatoire de Paris, Paris.
Craymer, M., Ferland, R., and Snay, R. 共2000兲. ‘‘Realization and unifica-
tion of NAD 83 in Canada and the U.S. via the ITRF.’’ In Towards an
Integrated Global Geodetic Observing System (IGGOS), R. Rummel,
H. Drewes, W. Bosch, and H. Hornik, eds., IAG Section II Symp.,
International Association of Geodesy Symposia, Vol. 120, Springer,
Berlin, 118 –121.
DeMets, C., Gordon, R. G., Argus, D. F., and Stein, S. 共1994兲. ‘‘Effect of
recent revisions to the geomagnetic reversal time scale on estimates of
current plate motions.’’ Geophys. Res. Lett., 21共20兲, 2191–2194.
Eckl, M. C., Snay, R. A., Soler, T., Cline, M. W., and Mader, G. L. 共2001兲.
‘‘Accuracy of GPS-derived relative positions as a function of intersta-
tion distance and observing-session duration.’’ J. Geodesy, Berlin,
75共12兲, 633– 640.
Mader, G. L., Weston, N. D., Morrison, M. L., and Milbert, D. G. 共2003兲.
‘‘The On-line Positioning User Service 共OPUS兲.’’ Prof. Surv., 23共5兲,
26,28,30.
McCarthy, D. D., ed. 共1996兲. ‘‘IERS Conventions 共1996兲.’’ Technical
Note 21, International Earth Rotation Service, Paris Observatory,
Paris.
Merrigan, M. J., Swift, E. R., Wong, R. F., and Saffel, J. T. 共2002兲. ‘‘A
refinement to the World Geodetic System 1984 Reference Frame.’’
159
 Proc., ION GPS 2002 共CD-ROM兲, Institute of Navigation, Alexan-
dria, Va., 1519–1529.
Schwarz, C. R., ed. 共1989兲. ‘‘North American Datum of 1983.’’ NOAA
Professional Paper NOS 2, U.S. Dept. of Commerce, National Oce-
anic and Atmospheric Administration, Silver Spring, Md.
Snay, R. A. 共1999兲. ‘‘Using the HTDP software to transform spatial co-
ordinates across time and between reference frames.’’ Surv. Land Inf.
Sys., 59共1兲, 15–25.
Snay, R. A. 共2003兲. ‘‘Introducing two spatial reference frames for regions
of the Pacific Ocean.’’ Surv. Land Inf. Sci., 63共1兲, 5–12.
Snay, R. A., Adams, G., Chin, M., Frakes, S., Soler, T., and Weston, N. D.
共2002兲. ‘‘The sinergistic CORS program continues to evolve.’’ Proc.,
ION GPS 2002 共CD-ROM兲, Institute of Navigation, Alexandria, Va.,
2630–2639.
Snay, R. A., and Soler, T. 共2000a兲. ‘‘Modern terrestrial reference systems.
Part 2: The evolution of the NAD 83.’’ Prof. Surv., 20共2兲, 1–2.
160 CORS AND OPUS FOR ENGINEERS
Snay, R. A., and Soler, T. 共2000b兲. ‘‘Modern terrestrial reference systems.
Part 3: WGS84 and ITRS.’’ Prof. Surv., 20共3兲, 1–3.
Soler, T., and Hothem, L. D. 共1988兲. ‘‘Coordinate systems used in geod-
esy: Basic definitions and concepts.’’ J. Surv. Eng., 114共2兲, 84 –97.
Soler, T., and Hothem, L. D. 共1989兲. ‘‘Important parameters used in geo-
detic transformations.’’ J. Surv. Eng., 115共4兲, 414 – 417.
Soler, T., and Marshall, J. 共2003兲. ‘‘A note on frame transformations with
applications to geodetic datums.’’ GPS Solutions, 7共1兲, 23–32.
Soler, T., Weston, N. D., and Han, H. 共2002兲. ‘‘Computing NAD 83
coordinates using ITRF-derived vector components.’’ Proc., XII FIG
Int. Congress, ACSM/ASPRS, Washington, D.C.
Springer, T. A., and Hugentobler, U. 共2001兲. ‘‘IGS ultra rapid products for
共near-兲 real-time applications.’’ Phys. Chem. Earth, 26共6 – 8兲, 623–
628.
Springer, T. A., Kouba, J., and Mireault, Y. 共2000兲. ‘‘1999 analysis coor-
dinator report.’’ 1999 Tech. Rep., International GPS Service for Geo-
dynamics, Jet Propulsion Laboratory, Pasadena, Calif., 15–55.
 20
Horizontal Time-Dependent Positioning Software: User’s Guide
Richard A. Snay1

Abstract: NOAA’s National Geodetic Survey (NGS) has developed the Horizontal Time-Dependent Positioning (HTDP) software to
enable its users to estimate the coordinate changes associated with crustal motion in the United States. HTDP permits the
transformation of positional coordinates across time and between reference frames. Furthermore HTDP contains a model of the
secular velocity field and separate models for the displacements associated with 29 earthquakes (2 in Alaska, 27 in California). This
software will be updated periodically to address the displacements associated with each new earthquake.

Author keywords: Transformations between reference frames; HTDP; GPS positioning; Geodetic networks

Introduction NUVEL1A (DeMets et al., 1994), to compute horizontal

velocities for several other areas of the world, including the
The HTDP (Horizontal Time-Dependent Positioning) software eastern United States.
enables users to estimate horizontal displacements and/or
horizontal velocities related to crustal motion in the United
States and its territories. The software also enables users to Table 1. Dislocation Models incorporated into HTDP
update positional coordinates and/or geodetic observations to a
user-specified date. HTDP supports these activities for
coordinates in the North American Datum of 1983 (NAD 83) Date Earthquake Source of Model
as well as in all official realizations of the International
Terrestrial Reference System (ITRS) (Altamimi et al., 2007) CALIFORNIA
and all official realizations of the World Geodetic System of 06-07-1934 Parkfield (M=6.0) Segall and Du, 1993
1984 (WGS 84) (True, 2004). Accordingly, HTDP may be 05-17-1940 El Centro (M=6.9 Snay and Herbrectsmeier, 1994
used to transform positional coordinates between any pair of 07-01-1941 Red Mountain (M=5.9) Snay (unpublished)
10-21-1942 San Jacinto (M=6.6) Snay and Herbrectsmeier, 1994
these reference frames in a manner that rigorously addresses 07-21-1952 Kern County (M=7.5) Snay and Herbrectsmeier, 1994
differences in the definitions of their respective velocity fields. 03-19-1954 San Jacinto (M=6.4) Snay and Herbrectsmeier, 1994
HTDP may also be used to transform velocities between any 06-26-1966 Parkfield (M=5.6) Segall and Du, 1993
pair of these reference frames. 04-09-1968 Borrego Mtn. (M=6.5) Snay and Herbrectsmeier, 1994
02-09-1971 San Fernando (M=6.6) Snay and Herbrectsmeier, 1994
The software employs models that address both the 03-15-1979 Homestead Valley (M=5.6) Stein and Lisowski, 1983
continuous and the episodic components of crustal motion. For 08-06-1979 Coyote Lake (M=5.9) Snay and Herbrectsmeier, 1994
characterizing continuous motion, the models assume that 10-15-1979 Imperial Valley (M=6.4) Snay and Herbrectsmeier, 1994
points on the Earth's surface move with constant horizontal 05-02-1983 Coalinga (M=6.4) Stein and Ekstrom, 1992
04-24-1984 Morgan Hill (M=6.2) Snay and Herbrectsmeier, 1994
velocities. This assumption is generally acceptable except for 08-04-1985 Kettleman Hill (M=6.1) Ekstrom et al., 1992
the accelerated motion experienced during the years 07-08-1986 N. Palm Springs (M=5.6) Savage et al., 1993
immediately following a major earthquake and for the motion 07-21-1986 Chalfant Valley (M=6.2) Savage and Gross, 1995
associated with volcanic/magmatic activity. For characterizing 10-01-1987 Whittier Narrow (M=5.9) Lin and Stein, 1989
11-24-1987 Superstition Hill (M=6.6,6.2) Larsen et al., 1992
the episodic motion associated with earthquakes, the models 10-17-1989 Loma Prieta (M=7.1) Lisowski et al., 1990
use the equations of dislocation theory (Okada, 1985). Table 1 04-22-1992 Joshua Tree (M=6.1) Bennett et al., 1995
identifies the dislocation models that are incorporated into 04-25-1992 Cape Mendocino (M=7.1) Oppenheimer et al., 1993
HTDP. 06-29-1992 Landers/Big Bear (M=7.5,6.6) Hudnut et al., 1994
01-17-1994 Northridge (M=6.7) Hudnut et al., 1996
HTDP uses a model developed by Dr. Robert McCaffrey to 10-16-1999 Hector Mine (M=7.1) Peltzer, Crampe, & Rosen, 2001
compute horizontal velocities for points located in the western 12-22-2003 San Simeon (M=6.5) Johanson, 2006
United States whose latitudes range from 31ºN to 49ºN and 10-28-2004 Parkfield (M=6.0) Johanson et al., 2006
whose longitudes range from 100ºW to 125ºW. HTDP uses a
ALASKA
model developed by Dr. Richard Snay to compute horizontal 03-28-1964 Prince William Sound (M=9.2) Holdahl and Sauber, 1994
velocities for points located in Alaska whose latitudes range 11-03-2002 Denali (M=7.9) Elliott et al., 2007
from 55ºN to 56º and whose longitudes range from 131ºW to
132ºW. Also, HTDP uses a rigid plate model, similar to

1
Former Chief, Spatial Reference System Division, National Geodetic Survey, NOS, National Oceanic and Atmospheric
Administration, 1315 East-West Hwy., Silver Spring, MD 20910. E-Mail: Richard.Snay@noaa.gov

CORS AND OPUS FOR ENGINEERS 161

 Software characteristics

The source code is written in FORTRAN-77 and resides in the

file, HTDP.FOR. The user needs to compile and link this
source code to create executable code that is compatible with
the operating system on his/her computer. For convenience,
the National Geodetic Survey distributes a file called,
HTDP.EXE, which contains executable code that should work
on most Windows platforms.
The software is menu-driven and most information is
entered interactively. Users may also enter certain information
in the so-called "blue-book" format for horizontal control data
[see Federal Geodetic Control Subcommittee, 2000]. For
example, if requested, the software will predict displacements
and/or velocities for all stations having an *80* record in an
existing blue-book file. Besides predicting displacements
and/or velocities for individual points, the software will predict
these quantities for a set of points which a 2-dimensional array
on the Earth’s surface or which defines an equally spaced

Fig. 1. Schematic diagram showing blocks used by McCaffrey

to model horizontal crustal velocity across the western United
States. Dots identify the data included in modeling this
velocity.

In his model for the western United States, Dr. McCaffrey

represents the region as being comprised of a collection of
elastic, rotating blocks that are separated by geologic faults
(Figure 1). Friction along these faults causes elastic strain
within these blocks. In addition, permanent strain within the
blocks, possibly due to small-scale faulting, is represented by a
spatially uniform strain rate tensor. In this manner, the
deformation--even within a tectonically complex region as the
western United States--can be represented by using only a
relatively few number of geologically relevant parameters. To
estimate the values of these parameters, Dr. McCaffrey used
4,890 horizontal velocities for a collection of sites. These
velocities were derived from repeated GPS observations. He
also used 170 fault slip rates inferred from geologic and
paleomagnetic studies, and 258 fault slip vectors taken from
both earthquake and geologic fault studies. The 4,890
horizontal velocities were assimilated from 13 separate
velocity fields (Table 2). The fault slip rates and the fault slip
vectors were those used in McCaffrey (2005) and McCaffrey
(2007).
Internal to the software, velocities are expressed relative to
the International Terrestrial Reference Frame of 2005
(ITRF2005) as defined by Altamimi et al. (2007). Velocities
relative to other reference frames are obtained from their
corresponding ITRF2005 velocities using transformation
equations adopted by NOAA’s National Geodetic Survey.
Figure 2 illustrates HTDP-predicted velocities for the western
Fig. 2. HTDP-estimated velocities relative to NAD 83
United States relative to NAD 83 (CORS96); that is, the
(CORS96). Different gray tones indicate velocity magnitudes
realization of NAD 83 known as CORS96.
from 4 mm/yr to 56 mm/yr. Arrows indicate velocity directions

162 CORS AND OPUS FOR ENGINEERS

Table 2. GPS velocity used by Dr. McCaffrey in developing the operating system on his/her computer. For convenience,
HTDP model for the western United States. the National Geodetic Survey distributes a file called,
HTDP.EXE, which contains executable code that should work
Code # Weighted Data Source on most Windows platforms.
of RMS The software is menu-driven and most information is
Sites (mm/yr) entered interactively. Users may also enter certain information
ITR5 55 0.66 Altamimi et al. 2007 in the so-called "blue-book" format for horizontal control data
SNRF 18 0.43 www.unavco.org/research_science/ [see Federal Geodetic Control Subcommittee, 2000]. For
workinggroups_projects/snarf/ example, if requested, the software will predict displacements
snarf.html and/or velocities for all stations having an *80* record in an
DXB2 16 0.85 Dixon et al. 2002 existing blue-book file. Besides predicting displacements
HT04 67 0.86 Hammond & Thatcher 2004 and/or velocities for individual points, the software will predict
HT05 94 1.01 Hammond & Thatcher 2005 these quantities for a set of points which defines a 2-
WILL 36 1.14 Williams et al. 2006 dimensional array on the Earth's surface or which defines an
CEA1 1,285 1.33 California Earthquake Authority equally spaced 1-dimensional array along a geodesic curve on
CMM4 1,195 1.22 Shen et al. 2007 an ellipsoid that approximates the Earth's surface. In all cases
the output is written to a user-specified file.
DMEX 12 1.07 Marquez-Azua et al. 2003 The software also has the capability to update positional
PBO7 437 0.95 PBO 4/2007 coordinates and/or geodetic observations to a user-specified
PNW7 578 0.58 McCaffrey 2007 ; Payne 2007 date. For such an application, the user must specify the
USGS 306 1.00 USGS website horizontal coordinates (latitudes and longitudes) and/or the
RWK7 791 1.06 King 2007 ; D’Allesio 2005 observed values for one date, and the software will predict
corresponding values for another user-specified date. The
software can update various observational types, all of which
1-dimensional array along a geodesic curve on an ellipsoid that may be encoded in blue-book format. In particular, the
approximates the Earth's surface. In all cases the output is software accepts direction observations, angle observations,
written to a user-specified file. distance observations, azimuth observations, and GPS
The software also has the capability to update positional observations.
coordinates and/or geodetic observations to a user-specified
date. For such an application, the user must specify the References
horizontal coordinates (latitudes and longitudes) and/or the
observed values for one date, and the software will predict Altamimi, Z., Collilieux, X., Legrand, J., Garayt, B., and
corresponding values for another user-specified date. The Boucher, C. (2007). “ITRF2005: A new release of the
software can update various observational types, all of which International Terrestrial Reference Frame based on time
may be encoded in blue-book format. In particular, the series of station positions and Earth Orientation Parame-
software accepts direction observations, angle observations, ters.” J. Geophys. Res., 112(B09401), 1-19.
distance observations, azimuth observations, and GPS Bennett, R.A., Reilinger, R.E., Rodi, W., Li, Y., Toksoz, M.N.,
observations. and Hudnut, K. (1995). “Coseismic fault slip associated
with the 1992 MW 6.1 Joshua Tree, California, earthquake:
Auxiliary information Implications for the Joshua Tree-Landers earthquake
sequence.” J. Geophys. Res. 100(B4), 6443-6461.
This User's Guide contains a set of five exercises to familiarize D’Alessio, M.A., Johanson, I.A., Burgmann, R., Schmidt,
HTDP users with some of the applications of this software. D.A., and Murray, M.H. (2005). “Slicing up the San
Also, Snay (1999) discusses the HTDP software and its Francisco Bay Area: Block kinematics and fault slip rates
applications in considerable detail. Additional material on from GPS-derived surface velocities.” J. Geophys. Res.,
HTDP has been published by Snay (2003) by Pearson and Snay 110(B06403), 1-19.
(2008) and by Pearson et al. (2010). Moreover, the National DeMets, C., Gordon, R.G., Argus, D.F., and Stein, S. (1994).
Geodetic Survey maintains a LOG that summarizes “Effect of recent revisions to the geomagnetic reversal time
modifications to the HTDP software in chronological order. scale on estimates of current plate motions.” Geophys. Res.
Finally, people may run the latest version of HTDP Lett., 21(20), 2191-2194.
interactively on the world-wide-web. To do that, use the URL: Dixon, T.H., et al. (2002). “Seismic cycle and rheological
<http://www.ngs.noaa.gov/TOOLS/Htdp/Htdp.shtml>. effects on estimation of present-day slip rates for the Agua
Blanca and San Miguel-Vallecitos faults, northern Baja
California - Mexico.” J. Geophys. Res., 107(B10), ETG5/1-
Disclaimer
23.
Ekstrom, E., Stein, R.S., Eaton, J.P., and Eberhart-Phillips, D.
The source code is written in FORTRAN-77 and resides in the
(1992). “ Seismicity and geometry of a 110-km-long blind
file, HTDP.FOR. The user needs to compile and link this
thrust fault. 1.- the 1985 Kettleman Hills, California,
source code to create executable code that is compatible with
earthquake.” J. Geophys. Res. 97(B4), 4843-4864.

CORS AND OPUS FOR ENGINEERS 163

Elliot, J.L., Freymueller, .J.T, and Rabus, B. (2007). “ Coseis-
mic deformation of the 2002 Denali fault earthquake
contributions from synthetic aperture radar range offsets.”
J. Geophys. Res., 112(B06431), 1-19.
Federal Geodetic Control Subcommittee (2000). “Input formats
and specifications of the National Geodetic Survey data
base: Volume I. Horizontal control data.” National
Geodetic Information Branch, NOAA, Silver Spring,
Maryland, 20910
(http://www.ngs.noaa.gov/FGCS/ BlueBook/).
Hammond, W.C., and Thatcher, W. (2004). “Contemporary
tectonic deformation of the Basin and Range province,
western United States: 10 years of observation with the
Global Positioning System.” J. Geophys. Res. 109
(B08403), 1-19.
Hammond, W.C., and Thatcher, W. (2005). “Northwest Basin
and Range tectonic deformation observed with the Global
Positioning System.” J. Geophys. Res., 110(B10405), 1-12.
Holdahl, S.R., and Sauber, J. (1994). “Co-seismic slip in the
1964 Prince William Sound earthquake: A new geodetic
inversion.” Pure Appl. Geophys. 142(1), 55-82.
Hudnut, K.W., and 16 others (1994). “Co-seismic displace-
ments of the 1992 Landers earthquake sequence.” Bull.
Seismol. Soc. Am. 84(3), 625-645.
Hudnut, K.W. and 10 others (1995). “Co-seismic displace-
ments of the 1994 Northridge, California, Earthquake,”
Bull. Seismol. Soc. Am. 86(1B), S19-S36.
Hurst, K.J., Argus, D.F., Donnellan, A., Heflin, M.B., Jeffer-
son, D.C., Lyzenga, G.A., Parker, J.W., Smith M, Webb
F.H., and Zumberge, J.F. (2000) “The coseismic geodetic
signature of the 1999 Hector Mine Earthquake.” Geophys.
Res. Lett. 27(17), 2733-2736. See also:
http://milhouse.jpl.nasa.gov/hector/hectormine3.model .
Johanson, I.A. (2006). “Slip characteristics of San Andreas
fault transition zone segments.” Ph.D. Dissertation, Univ.
of California, Berkeley, 117 pp.
Johanson, I.A., Fielding, R.J., Rolandone, .F, and Burgmann,
R. (2006). “Coseismic and postseismic slip of the 2004
Parkfield earthquake, Bull. Seismol. Soc. Am., 96(4B),
S269-S282.
Larsen, S., Reilinger, R., Neugebauer, H., and Strange, W
(1992). “Global Positioning System measurements of
deformations associated with the 1987 Superstition Hills
earthquake: evidence for conjugate faulting.” J. Geophys.
Res. 97(B4), 4885-4902.
Lin, J., Steinn R.S (1989). “Coseismic folding, earthquake
recurrence, and the 1987 source mechanism at Whittier
Narrows, Los Angeles Basin, California.” J. Geophys. Res.,
94(B7), 9614-9632.
Lisowski, M., Prescott, W.H., Savage, J.C., and Johnston, M.J.
(1990). “Geodetic estimate of coseismic slip during the
Loma Prieta, California, earthquake.” Geophys. Res. Lett.
17(9), 1437-1441.
Márquez-Azúa, B.,and DeMets, C. (2003). “Crustal velocity-
field of Mexico from continuous GPS measurements,
1993to June 2001: Implications for the neotectonics of
Mexico.” J. Geophys. Res., 108(B9), ETG12/1-20.
164 CORS AND OPUS FOR ENGINEERS
McCaffrey, R. (2005). “Block kinematics of the Pacific –North
America plate boundary in the southwestern US from
inversion of GPS, seismological, and geologic data.” J.
Geophys. Res., 110(B07401), 1-27.
McCaffrey, R., Qamar, A.I., King, R.W., Wells, R.,
Khazaradze, G., Williams, C.A., Stevens, C.W., Vollick,
J.J., and Zwick, P.C. (2007). “Plate locking, block rotation
and crustal deformation in the Pacific Northwest.”
Geophys. J. Int., 169(3), 1315-1340.
McCarthy, D.D. (1996 ). “IERS Conventions (1996).” IERS
Technical Note 21, Observatoire de Paris.
Okada, Y. (1985). “Surface deformation due to shear and
tensile faults in a half-space.” Bull. Seismol. Soc. Amer.
75(4), 1135-1154.
Oppenheimer, D., and 19 others (1993). “The Cape Mendo-
cino, California earthquake sequence of April, 1992:
Subduction at the triple junction.” Science 261(5120), 433-
438.
Payne, S.J., McCaffrey, R., and King, R.W. (2007).
“Contemporary deformation within the Snake River Plain
and Northern Basin and Range Province, USA.” EOS
Trans. Am. Geophys. Union, 88(23), Jt. Assem. Suppl.
Abstract G43B-06.
Pearson, C., and Snay, R. (2008). “Updating HTDP for two
recent earthquakes in California.” Surv.and Land Inf. Sci.
67(3), 149-158
Pearson, C., McCaffrey, R., Elliot, J.L., and Snay, R. (2010).
“HTDP 3.0: Software for coping with the coordinate
changes associated with crustal motion.” J. Surv. Eng.
136(2), 80-90.
Peltzer, G., Crampe, F., and Rosen, P. (2001). “The Mw 7.1,
Hector Mine, California earthquake: surface rupture,
surface displacement field, and fault slip solution from ERS
SAR data.” C. R. Acad. Sci. Paris, Series IIA, 333(9),545-
555.
Savage, J.C., and Gross, W.K. (1995) “Revised dislocation
model of the 1986 Chalfant Valley earthquake, eastern
California.” Bull. Seismol. Soc. Am., 85 (2), 629-631.
Savage, J.C., Lisowski, M., and Murray, M. (1993).
“Deformation from 1973 through 1991 in the epicentral
area of the 1992 Landers, California, earthquake (MS =
7.5).” J. Geophys. Res. 98(B2), 19951-19958.
Segall, P., and Du, Y. (1993). “How similar were the 1934 and
1996 Parkfield earthquakes?” J. Geophys. Res. 98(B3),
4527-4538.
Shen, Z.K., King, R.W., Agnew, D.C., Herring, T.A., Wang,
M., and Dong, D. (2007). “A unified analysis of crustal
motion in California, 1970-2004. The SCEC Crustal
Motion Map,” in preparation.
Snay, R.A. (1999). “Using the HTDP software to transform
spatial coordinates across time and between reference
frames.” Surv. Land Inf. Syst., 59(1), 15-25.
Snay, R.A. (2003). “Horizontal time-dependent positioning.”
Profess. Surv., 23(11), 30, 32, 34.
Snay, R.A., and Herbrectsmeier, E. (1994). “The TDP-H91-CA
model for historical horizontal deformation in California.”
Manuscripta Geodaetica, 19(3), 180-198.
Snay, R.A., Cline, M.W., Philipp, C.R., Jackson, D.D., Feng,
Y., Shen, Z.K., and Lisowski, M. (1996). “Crustal velocity
field near the big bend of California’s San Andreas fault.”
J. Geophys. Res., 101(B12), 3173-3185.
Stein, R.S., and Ekstrom, G. (1992). “Seismicity and geometry
of a 110-km-long blind thrust fault, 2, synthesis of the
1982-1985 California earthquake sequence.” J. Geophys.
Res., 97(B4), 4865-4884.
Stein, R.S., and Lisowski, M. (1983). “The 1979 Homestead
Valley earthquake sequence, California: Control of after-
shocks and postseismic deformation.” J. Geophys. Res.,
88(B8), 6477-6490.
True, S.A. (2004). “Planning the future of the World Geodetic
System 1984.” Proc. IEEE Position Loca-tion and
Navigation Symposium, Monterrey, CA, 26-29 April 2004,
10 pp.
Williams, T.B., Kelsey, H.M., and Freymueller, J.T. (2006).
“GPS-derived strain in northwestern California:
Termination of the San Andreas fault system and
convergency of the Sierra Nevada – Great Valley block
contribute to southern Cascadia forearc contraction.”
Tectonophysics, 413(3-4), 171-184.

APPENDIX

HTDP EXCERCISES

The following set of exercises is designed to familiarize users with several capabilities of the HTDP software. Angular brackets
identify text that the user should type into the computer. For example, in response to the instruction, "enter <abc>," the user should
type "abc" and then hit the ENTER key or the RETURN key. It must be pointed out that HTDP only works for certain regions of
North America, the Caribbean, Hawaii, and areas around Guam where the definition of the NAD 83 (CORS96) is applicable.
However, the Fortran-77 source code is freely available free at http://www.ngs.noaa.gov/TOOLS/Htdp/Htdp.shtml. Therefore,
international users can insert parameters for their local plate velocity model and extend the usefulness of the HTDP concept anywhere
in the world.
___________________________________________________________________________________________________________

Excercise 1: Predicting velocities at individual points

1.1 Enter <htdp.exe> to start the program. Some introductory information should now be displayed on the computer's screen.
Hit the ENTER key or the RETURN key to obtain the "MAIN MENU."

1.2 Enter <2> to indicate that you will be predicting velocities.

1.3 Enter a name for the file that will contain the predicted velocities (for example, vfile).

1.4 Enter <1> to indicate that velocities will be predicted relative to the NAD_83(CORS96) reference frame.

1.5 Enter <1> to indicate that you will be entering positional coordinates for individual points in an interactive manner.

1.6 Enter <alpha> for the name of the first point whose velocity will be predicted.

1.7 Enter <1> to specify that you will provide a latitude and a longitude.

1.8 Enter <38,6,12.96> to denote that the latitude of alpha is 38o 06' 12.96" N.

1.9 Enter <122,56,7.80> to denote that the longitude of alpha is 122o 56' 7.80" W.

1.10 Enter <0.> to denote that the ellipsoid height of alpha is 0. meters.
The screen should now be displaying the following information:
Northward velocity = 37.78 mm/yr.
Eastward velocity = –24.48 mm/yr.
Upward velocity = –1.24 mm/yr.
X-dim. velocity = –7.33 mm/yr.
Y-dim. velocity = 33.70 mm/yr.
Z-dim. velocity = 28.96 mm/yr.

CORS AND OPUS FOR ENGINEERS 165

1.11 The screen should also be displaying the menu for continuing. Enter <1> to predict the velocity for another point.

1.12 Enter <beta> for the name of this second point.

1.13 Enter <1> to specify that you will provide a latitude and a longitude.

1.14 Enter <36,40,11.28> to specify the latitude of beta.

1.15 Enter <121,46,19.92> to specify the longitude of beta.

1.16 Enter <0.> to specify the ellipsoid height of beta.

The screen should now be displaying the following information:

Northward velocity = 37.26 mm/yr.
Eastward velocity = –26.16 mm/yr.
Upward velocity = –1.20 mm/yr.
X-dim. velocity = –10.02 mm/yr.
Y-dim. velocity = 33.52 mm/yr.
Z-dim. velocity = 29.17 mm/yr.

1.17 If you wish to predict velocities for additional points, then you may enter <1> and proceed as before. Otherwise, enter <0> to
return to the main menu.

At this time, it is instructive to inspect the output file that contains the predicted velocities. This is the file whose name was
specified in Step 1.3. If you have a windowing capability, then you may open another window to read this file. Otherwise,
enter <0> to exit the HTDP software so that you may read this file. Note that this file contains all the information pertinent to
the velocities that were predicted.

1.18 If you exited the program, enter <htdp.exe> to restart it, then hit the ENTER key, and then enter <2> to predict more
velocities. If you did not exit the program, just then enter <2>.

1.19 Enter a name for a new file that will contain the additional velocities to be predicted. (Caution: if you enter the same name as
was entered in Step 1.3, then the software will overwrite the previous file.)

1.20 Enter <0> to indicate that the following velocities will be calculated relative to a specified point having a specified velocity.

1.21 Enter <alpha> for the name of the reference point.

1.22 Enter <1> to specify that you will provide a latitude and a longitude.

1.23 Enter <38,6,12.96> for the latitude of alpha.

1.24 Enter <122,56,7.80> for the longitude of alpha.

1.25 Enter <0.> for the ellipsoid height of alpha.

1.26 Enter <5.> to indicate that the northward velocity of alpha is to be 5.00 mm/yr.

1.27 Enter <0.> to indicate that the eastward velocity of alpha is to be 0.00 mm/yr.

1.28 Enter <1> to indicate that you will be specifying individual points in an interactive manner.

1.29 Enter <beta> for the name of the first point whose velocity relative to alpha is to be predicted.

1.30 Enter <1> to specify that you will provide a latitude and a longitude.

1.31 Enter <36,40,11.28> for the latitude of beta.

166 CORS AND OPUS FOR ENGINEERS

1.32 Enter <121,46,19.92> for the longitude of beta.

1.33 Enter <0.> for the ellipsoid height of beta.

The screen should now be displaying the following information:

Northward velocity = 4.48 mm/yr.
Eastward velocity = –1.69 mm/yr.
Upward velocity = 0.04 mm/yr.
X-dim. velocity = –0.04 mm/yr.
Y-dim. velocity = 3.14 mm/yr.
Z-dim. velocity = 3.62 mm/yr.

Note that 4.48 = 37.26 – 37.78 + 5.00 where

37.26 is the northward velocity of beta relative to the NAD_83 reference frame,
37.78 is the northward velocity of alpha relative to the NAD_83 reference frame, and
5.00 is to be the northward velocity of alpha in our local reference system.

Similarly, the eastward velocity of –1.69 mm/yr equals (within 0.01 mm/yr due to rounding) the difference between the eastward
velocities of beta and alpha in the NAD_83 reference frame.

The astute user may recognize that this formula for computing relative velocities is not mathematically rigorous because of
Earth's curvature. The error grows as a function of distance from the reference point.

1.34 Enter <0> to return to the main menu.

This concludes Exercise 1. You may find it instructive to inspect the output file whose name was specified in step 1.19.
_________________________________________________________________________________________________________

Excercise 2: Predicting displacements at individual points.

2.1 If needed, enter <htdp.exe> to start the program. Then hit the ENTER key to obtain the MAIN MENU.

2.2 From the MAIN MENU enter <1> to select the option for predicting displacements between two dates.

2.3 Enter <1,1,1985> to indicate that the first date is January 1, 1985.

2.4 Enter <1,1,1995> to indicate that the second date is January 1, 1995.

2.5 Enter <dfile1> for the name of the output file that is to contain the predicted displacements.

2.6 Enter <1> to specify that positions and velocities will be expressed in the NAD_83(CORS96) reference frame.

2.7 Enter <1> to indicate that you will enter individual points interactively.

2.8 Enter <beta> for the name of the first point whose displacement from January 1, 1985 to January 1, 1995 is to be predicted.

2.9 Enter <1> to specify that you will provide a latitude and a longitude.

2.10 Enter <36,40,11.28> for the latitude of beta.

2.11 Enter <121,46,19.92> for the longitude of beta.

2.12 Enter <0.> for the ellipsoid height of beta.

2.13 Enter <0> to indicate that the software will predict the velocity to be used in calculating the displacement.

The screen should now be displaying the following information:

CORS AND OPUS FOR ENGINEERS 167

 Northward displacement = 0.446 meters.
Eastward displacement = –0.263 meters.
Upward displacement = –0.016 meters.

Recall from Exercise 1 that the northward velocity of beta is 37.26 mm/yr. Thus in 10 years beta moved 0.353 meters northward
as a result of its continuous motion. To this displacement, the HTDP software adds those displacements associated with major
earthquakes. For example, the point beta moved northward 0.074 meters during the Loma Prieta earthquake (M=7.1) of October
18, 1989. The sum of 0.353 meters and 0.074 meters equals the total predicted displacement of 0.446 meters (with 0.001 meter
rounding error) for the 10-year period from January 1, 1985 to January 1, 1995. In the following steps, the displacement that
occurred at beta during the Loma Prieta earthquake will be predicted.

2.14 Enter <0> to return to the main menu.

2.15 Enter <1> to predict displacements.

2.16 Enter <10,16,1989> to indicate that the first date is October 16, 1989.

2.17 Enter <10,18,1989> to indicate that the second date is October 18, 1989.

2.18 Enter <dfile2> to name the output file that is to contain the predicted displacements.

2.19 Enter <1> to specify that positions and displacements will be expressed in the NAD_83(CORS96) reference frame.

2.20 Enter <1> to indicate that you will specify individual points interactively.

2.21 Enter <beta> for the point's name.

2.22 Enter <1> to specify that you will provide a latitude and a longitude.

2.23 Enter <36,40,11.28> for the latitude of beta.

2.24 Enter <121,46,19.92> for the longitude of beta.

2.25 Enter <0.> for the ellipsoid height of beta.

2.26 Enter <0> to indicate that the software will predict the velocity to be used in calculating the displacement.

The screen should now be displaying the following information:

Northward displacement = 0.074 meters.
Eastward displacement = –0.001 meters.
Upward displacement = –0.004 meters.

Displacements associated with the Loma Prieta earthquake can now be predicted for other locations by entering <1> and
responding to the prompts. When finished enter <0> to return to the main menu. You may find it instructive to inspect the
output files, dfile1 and dfile2, at this time.

This concludes Exercise 2.

Excercise 3: Predicting velocities for sets of points.

For predicting velocities, the latitudes and longitudes of the points may be entered in several ways in addition to entering
individual points interactively. The options include (a) specifying a grid of points, (b) specifying the name of a file that contains
the positional information in blue-book format, and (c) specifying a sequence of points on a line (or more precisely, a geodesic
curve on Earth's surface). These same options are available for specifying the latitudes and longitudes of points where
displacements between two dates are to be predicted.

168 CORS AND OPUS FOR ENGINEERS

3.1 If needed, enter <htdp.exe> to start the program. Then hit the ENTER key to obtain the MAIN MENU.

3.2 Starting from the MAIN MENU, enter <2> to predict velocities.

3.3 Enter <vfile1> for the name of the output file that is to contain the predicted velocities.

3.4 Enter <1> to predict velocities relative to the NAD_83(CORS96) reference frame.

3.5 Enter <2> to indicate that the points form a regularly spaced two-dimensional grid on Earth's surface.
3.6 Enter a name to identify the grid (for example, grid1).

3.7 Enter <34,0,0> to indicate that the minimum latitude is 34o00'00" N.

3.8 Enter <35,0,0> to indicate that the maximum latitude is 35o00'00" N.

3.9 Enter <300> to indicate that the latitude spacing is 300 seconds (or equivalently, 5 minutes).

3.10 Enter <118,30,0> to indicate that the minimum longitude is 118o30'00" W.

3.11 Enter <119,10,0> to indicate that the maximum longitude is 119o10'00" W.

3.12 Enter <600> to indicate that the longitude spacing is 600 seconds (or equivalently, 10 minutes).

The screen should now be displaying the menu for specifying additional points at which velocities are to be predicted. Predicted
velocities for the grid are contained in vfile1. To examine this file, enter <0> to return to the main menu (and if you do not have
a windowing capability, enter <0> to exit the HTDP software).

In vfile1, the first point (the southeast corner of the grid) should have the northward velocity of 29.90 mm/yr and the eastward
velocity of –24.97 mm/yr. The last point (the northwest corner) should have the northward velocity of 19.58 mm/yr and the
eastward velocity of –14.93 mm/yr.

In the following steps, velocities will be predicted for a set of points in the file bfile.txt which contains data for the California
High Precision Geodetic Network. This file is in blue-book format which is the format adopted by the Federal Geodetic Control
Subcommittee for transferring geodetic data. For predicting velocities, the HTDP software uses only the blue-book records that
have *80* in columns 7 through 10. Furthermore, the program reads only the following fields on these records

Columns Content FORTRAN format

15-44 name of point A30

45-55 latitude (deg-min-sec) I2,I2,F7.5
56 N or S latitude A1
57-68 longitude (deg-min-sec) I3,I2,F7.5
69 W or E longitude A1

Before predicting velocities for the points in bfile.txt, it may be instructive to examine the contents of this file, especially the
*80* records.

3.13 Follow Steps 3.1 through 3.4 as before except use the name, vfile2, for the output file that will contain the predicted velocities.

3.14 Enter <3> to indicate that the points are in a blue-book file.

3.15 Enter <bfile.txt> to specify the name of the blue-book file.

The screen should now be displaying the menu for specifying additional points at which velocities are to be predicted. Predicted
velocities for the points in bfile.txt are contained in the file, vfile2.

3.16 To examine vfile2, enter <0> to return to the main menu (and if you do not have a windowing capability, enter <0> to exit the
HTDP software).

CORS AND OPUS FOR ENGINEERS 169

 In vfile2, the first point, AMBOY, should have a northward velocity of 1.23 mm/yr and an eastward velocity of 0.26 mm/yr.
The last point, TOMTIT 2, should have a northward velocity of 18.06 mm/yr and an eastward velocity of -12.16 mm/yr.

In the following steps, we will predict velocities for a sequence of points that lie along a line that forms a geodesic curve on
Earth's surface.

3.17 Follow Steps 3.1 through 3.4 as before except use the name, vfile3, for the output file that will contain the predicted velocities.

3.18 Enter <4> to indicate that the points lie on a line.

3.19 Enter a name to identify the line (for example, line1).

3.20 Enter <35,17,28.3> to specify the latitude of a point through which the line is to pass. We will refer to this point as the origin.

3.21 Enter <120,15,35.431> to specify the longitude of the origin.

3.22 Enter <90.> to specify that the line is to have an azimuth of 90 degrees (clockwise from north) when it passes through the
origin.

3.23 Enter <-5000.,10000.> to specify that velocities will be predicted for points located between 5000 meters before the origin and
10000 meters after the origin.

3.24 Enter <5000.> to specify that the spacing between the points will be 5000 meters.

The screen should now be displaying the menu for specifying additional points at which the velocities are to be predicted.
Predicted velocities for the points on the line are contained in the file, vfile3.

3.25 To examine vfile3, enter <0> to return to the main menu (and if you do not have a windowing capability, enter <0> to exit the
HTDP software).

The first point in vfile3 should have a northward velocity of 32.61 mm/yr and an eastward velocity of -25.40 mm/yr. This file
should contain predicted velocities for four points. The second of these points should correspond to the origin. Note that the
origin has the highest latitude of the four points because the line forms a geodesic curve whose azimuth is 90 degrees when
passing through the origin.

This concludes Exercise 3.

Excercise 4: Updating positional coordinates at individual points.

4.1 If needed, enter <htdp.exe> to start the program. Then hit the ENTER key to obtain the MAIN MENU.

4.2 Enter <3> to specify that positions will be updated.

4.3 Enter <7,4,1995> to specify that the new coordinates are to correspond to the position of the point on July 4, 1995.

4.4 Enter <1> to specify that positions will be expressed in the NAD_83(CORS96) reference frame.

4.5 Enter <1> to specify that individual points will be entered interactively.

4.6 Enter <5,7,1991> to specify that the input coordinates are to correspond to the position of the point on May 7, 1991.

4.7 Enter <newfile> for the name of the output file that will contain the updated coordinates.

4.8 Enter <alpha> for the name of the point whose positional coordinates will be updated.

4.9 Enter <1> to specify that you will provide a latitude and a longitude.

170 CORS AND OPUS FOR ENGINEERS

4.10 Enter <38,6,12.96> for the latitude of alpha on May 7, 1991.

4.11 Enter <122,56,7.80> for the longitude of alpha on May 7, 1991.

4.12 Enter <0.> for the ellipsoid height of alpha on May 7, 1991.

4.13 Enter <0> to indicate that the software will predict the velocity to be used in updating the position.

The screen should now be displaying the following information:

Updated latitude = 38 06 12.96510N
Updated longitude = 122 56 7.80418W
Updated Ellip. Ht. = –0.005 meters
Updated X = –2732250.867 meters
Updated Y = –4217684.284 meters
Updated Z = 3914499.284 meters

4.14 Enter <n> to indicate that no more coordinates are to be updated at this time.

Examine the file, newfile, at this time. Note that newfile contains both the old and the new coordinates. Also newfile contains
the velocities and the (total) displacements applied to update the positional coordinates.

This concludes Exercise 4.

Excercise 5: Update positional coordinates for points in a blue-book file and update the corresponding observations.

5.1 If needed, enter <htdp.exe> to start the program. Then hit the ENTER key to obtain the MAIN MENU.

5.2 Enter <3> to indicate that coordinates and observations will be updated.

5.3 Enter <7,4,1995> to indicate that the updated coordinates and observations are to correspond to July 4, 1995.

5.4 Enter <1> to specify that positions will be expressed in the NAD 83 reference frame.

5.5 Enter <4> to specify that both coordinates and observations are to be updated. Note that options 2 and 3 allow the user to update
one without updating the other.

5.6 Enter <1> to indicate a standard blue-book file will be used.

5.7 Enter <bfile.txt> to indicate that the original coordinates and the non-GPS observations are contained in the file called bfile.txt.

5.8 Enter <newbf> for the name of the blue-book file that will contain the updated coordinates and the updated non-GPS
observations.

5.9 Enter <5,7,1991> to specify that input coordinates correspond to the positions on May 7, 1991. For updating an observation,
HTDP uses the date that this observation was performed as the starting date. The date of observation is specified within the
blue-book file as part of the corresponding observational record.

5.10 Enter <y> to indicate the existence of a file that contains the GPS observations.

5.11 Enter <gfile.txt> to specify that the GPS observational records are contained in the file called gfile.txt.

5.12 Enter <newgf> to specify that the updated GPS records will be contained in the file called newgf.

5.13 Enter <1> to indicate that the GPS vectors are to be transformed to the NAD_83(CORS96) reference frame.

CORS AND OPUS FOR ENGINEERS 171

 The screen should now be displaying the main menu. You may wish to examine the files, newbf and newgf, at this time. In
newbf, the first *80* record is for station AMBOY. The new latitude for AMBOY should equal 34o 33' 31.04913" N. In newgf,
the first C record is for a GPS observation involving the station whose ID is 8635 and the station whose ID is 8476. The updated
values for this observation should be 89894.4164 meters in X, –59905.9497 meters in Y, and -16773.7910 meters in Z. Also in
newgf, columns 52-53 of the first B record should read "02" to indicate that the updated GPS interstation vector has been
transformed to the original WGS_84 reference frame which is equivalent to the NAD_83 reference frame. (Note that post-1994
realizations of WGS_84 are not equivalent to NAD_83.)

This concludes Exercise 5

172 CORS AND OPUS FOR ENGINEERS

 21
Best Methods for High Accuracy Real Time GNSS Positioning
From a Single Reference Station
William Henning1

Abstract: The National Geodetic Survey (NGS), a program office of the National Oceanic and Atmospheric Administration
(NOAA), recently announced the approval and release of a document titled "National Geodetic Survey User Guidelines for Single
Base Real-Time GNSS Positioning" (See NGS 2009). The guidelines provide definitive criteria to achieve various specific tiers of
precision, with high confidence, using global navigation satellite systems (GNSS). Due to the plethora of variables associated with
Real-Time GNSS positioning (RT), a consistent documented approach for using this technology to best advantage was lacking. In
preparing this publication, thousands of pages were researched to evaluate, refine, and compile comprehensive information into an
integrated form, thereby ensuring the most practical and reliable methodologies were developed for high-precision work. The
guideline document totals some 150 pages, including 35 pages of RT glossary and 50 pages of appendices. Due to the rapidly
changing GNSS constellations, technology and communications, the document will remain dynamic and digital. This paper will
summarize some of the important criteria and field methodology that will give confidence with the results.
Author keywords: Real Time; RTK; GNSS; NGS; GPS positioning; geodetic networks

Introduction Accuracy and Precision

Real-Time GNSS positioning is rapidly becoming the favored
method for obtaining precisions of a few centimeters and will
continue as a dynamic technology, due to advances in hardware
and software, additional GNSS constellations, and new signals
available to the user. The user guidelines will be updated as
these developments affect Real-Time procedures and data.
The new document titled “National Geodetic Survey User
Guidelines for Single Base Real-Time GNSS Positioning”
(ibid) fills a void that exits for Real-Tome GNSS positioning
practitioners in two ways:
1. It provides background information necessary for RT users
in the field
2. It provides specific procedures and criteria to achieve 95%
confidence with RT results
NGS does not purport to have produced a standard or
specification for GNSS RT positioning with the guidelines.
Rather, considering the dynamic nature of the technology and
the additional satellite constellations and signals coming on
line, it considers their content to be a means of assuring
accurate, homogeneous, repeatable coordinates. Other user
techniques and methodologies may indeed be found to provide
equal results. Therefore, rather than the only way to a goal, the
guidelines are a confident path to follow to get users to their
desired end.
It is important to understand that all highest order RT
positioning is differential in that it produces position
coordinates from an earth-centered, earth-fixed (ECEF)
Cartesian XYZ vector from those World Geodetic System 1984
(WGS 84) coordinates of the reference (base) station while it is
in communication with the rover. This vector results from an
iterative least squares adjustment calculated at the rover using
the geometrical (tropospheric delay and orbit errors) and
dispersive (ionospheric refraction and Group delay) corrections
“observed at the base location.” Thus, in single base RT, the
rover is using corrections to the satellite signals it is receiving
based on the conditions at the reference station. It can then be
seen that the validity of the correction at the rover decorrelates
from the correction at the base station the further the rover goes
from this source of error corrections. As a result, the solution
precision suffers. This distance-dependent effect is reflected in
a one part-per-million (ppm) error given in most major GNSS
manufacturers’ specifications. The computed position of the
rover and the baseline root-mean-square (RMS) values reflect
the precision (i.e., repeatability or spread of the results) of the
solution relative to the base. The alignment of the base to
“truth” reflects the accuracy of the survey. What the “true”
coordinate of the base station is, depends upon the application
or needs of the user. If users wish to work within with the
National Spatial Reference System (NSRS), then “truth” may
be considered to be the current U.S national datums (NAD 83
latitude, longitude and ellipsoid height, and NAVD 88
orthometric height). Regardless, it can be seen that precisions
can be excellent while accuracy may be in gross error, and

1
Geodesist, NGS Real Time and RTK Expert, Spatial Reference System Division, National Geodetic Survey, NOS, National Oceanic
and Atmospheric Administration, 1315 East-West Hwy., Silver Spring, MD 20910. E-Mail: William.Henning@noaa.gov

CORS AND OPUS FOR ENGINEERS 173

 Fig. 1. Example of separate satellite availability and PDOP graphs- Using obstructions

Fig. 2. Example of satellite availability and PDOP graphed together

174 CORS AND OPUS FOR ENGINEERS

the coordinates of the rover are generally never more accurate
(except by fortunate accident) than those of the base. Indeed,
autonomous positions can be used in a RT survey as starting
values and the refined coordinates can be introduced later into
the user’s office or field software without loss of project
precision. This will simply shift the vectors to originate at the
new base position. Therefore, the precision is the same, the
accuracy is the variable. Additionally, depending on the brand
of the RT gear, precisions may be shown in the data collector at
68% confidence (or 1 ) and should be doubled to get a sense
of the 95% confidence level (2 ), which is the confidence
level most professionals employ for their error budget.
Planning for the Field Campaign
Most major GNSS equipment manufacturers provide a
planning tool (some are free of cost) to assess times of poor
satellite coverage and/or geometry which would impact the
GNSS data quality, or could even prevent obtaining any
precision RT results at all. Since most manufacturers display
this condition in terms of a unitless “position dilution of
precision” or PDOP number (see Figures 1and 2), the RT
guidelines (ibid) give acceptable values for each of the four
tiers of RT precision, defined therein. These are shown in the
summary table herein as Figure 7. The graphs displayed often
show open sky conditions, but site obstructions can be
interactively added to provide a realistic scenario of the site.
Because the rover’s sky view will change as it moves point to
point, and various satellites may be blocked, it is imperative
that the base occupies a completely open sky site. RT
positioning requires at least 5 common satellites seen by both
the base and rover. The best possible conditions will therefore
be maintained when the base can see all the available satellites,
while the rover will usually lose data reception of differing
satellites depending on its environs. Another tool to supplement
the user’s planning is a “Notice Advisory to NavStar Users”
(NANU) detailing current or impending satellite outages and
Fig. 3. Historical solar sunspot activity
CORS AND OPUS FOR ENGINEERS
Fig. 4. The expected solar maximum in 2013
poor health and sent out by the U.S. Coast Guard (USCG). See:
<http://cgls.uscg.mil/mailman/listinfo/nanu> to subscribe to
this service. Additionally, space weather conditions may
severely impact the ionosphere by exciting the electrons
displaced from oxygen and nitrogen molecules and imparting
group delay and refraction to the GNSS signals. NOAA’s
Space Weather Prediction Center (SWPC) will send out notices
within 15 minutes of a solar storm event as well as various
alerts and warnings if the user wishes to subscribe to the
service free of charge. Increasing sun spot counts indicate
times of potential solar geomagnetic storms, radio blackouts
and solar radiation interference. This sun spot activity has
historically been in very regular 11 year cycles of varying
magnitude (See Figure 3). The current cycle should reach its
maximum around 2013 and thus be an increasing threat to good
RT results for the next few years (See Figure 4). These solar
storms may impact the actual satellites with electrical charging
affecting communication to/from the ground control segment,
proper functioning of the vehicle, and disturbed orbits.
Furthermore, users may face loss of communication to their
base or experience an increase in the RMS noise of any
solution. See: <http://www.swpc. noaa.gov/> for extensive
information on space weather. A final consideration to consider
when planning a RT campaign is tropospheric conditions. This
is the wet and dry “weather” part of the atmosphere extending
up to around 80 Km. Although rain or snow will not adversely
affect RT results outside of the expected error budget levels,
varying conditions between the base and rover can produce
excessive RMS or noise in the solution. In extreme conditions
it can impact the ambiguity resolution so that an improper
integer cycle count is applied. Therefore, the guideline is to
perform RT campaigns in homogeneous conditions between
base and rover. This would include watching for storm fronts,
precipitation events, temperature differences or atmospheric
175
 Fig. 5. Atmospheric conditions affecting the GNSS signals

pressure differences such as at varying altitudes. Atmospheric should be noted that for optimum orthometric heights, a hybrid
influences are depicted in Fig. 5. geoid model as supplied by NGS can be added to the project
allowing for more accurate orthometric heights than an inclined
plane alone would provide. The RT guidelines recommend
Constraining a RT Survey to Passive Marks
using at least 4 passive control monuments which to the best
Many times field locations are necessarily tied to existing extent possible form a rectangle outside of the project area (see
physical monumentation. Legacy data, project compatibility, Figure 6). Additional control monumentation throughout the
local annotated codes and local datum definitions are several project will also add to the robustness of the solution and to the
reasons for this procedure. Additionally, a GNSS RT survey evaluation of how the control fits intrinsically. Further
tied to passive marks establishes a best fit plane (vertically information on ground based coordinates can be found in
and/or horizontally) through the constrained stations and thus
forces the GNSS data to fit the ground at the project with the
monuments as truth. Most major GNSS manufacturers provide
an easy methodology known as a “localization” or
“calibration” to this end, albeit not geodetically traceable to the
datum because of intermediate steps in the conversion process.
It is incumbent upon the geospatial professional, however, to
evaluate the constrained marks for their validity and
compatibility to the necessary project. The RT survey that will
constrain passive monumentation will proceed by occupying
each control mark using best methods as recommended herein.
The local coordinates (horizontal, vertical or both) will then be
entered as well. The data collector in the field or the office
software can then perform a least squares best fit solution,
giving residuals and the plane slope through the solution. These
must be carefully evaluated to make decisions on possible
outliers and what marks are to be held fully constrained. It Fig. 6. Localization of a Rectangle (Quadrilateral in this case)

176 CORS AND OPUS FOR ENGINEERS

___________________________________________________________________________________________________________
Fig. 7. RT class guidelines summary table
Appendices D and E of the RT guidelines, which give
alternative means to establish these coordinates from RT
methods using low distortion projections.
Criteria for GNSS RT Positioning
Based primarily on empirical methods from a wide variety of
successful RT field campaigns and from documents compiled
from national and international sources, the guidelines divide
the collection criteria into four precision categories, labeled as
Classes RT1 through RT4 (See Figure 7). The intent is that
these criteria along with the a priori conditions will produce
RT positions at the 95% confidence level from a single base
solution. A priori requirements noted are that: there are no
loose tripod legs, the actual fixed height has been checked
(worn fixed height pole feet, unseated pole feet and variability
in the height settings in those fixed height poles using dowels
to hold a particular height can yield biases of millimeters to
even a centimeter in base heights), strong batteries are used,
the level bubbles have been adjusted, and the units perform to
manufacturers specifications.
Further requirements are that: there are no blunders in data
collection or entered pole heights, the rover and base are GPS
dual frequency with or without GLONASS, and are receiving
observables with a cut off angle (elevation mask) between 10°
and 15°, the base has been positioned in as open a site as
possible with attempts to have no multipath or electrical
interference, the base occupies an adjusted control point
within the site localization (if any), and its coordinates have
been correctly entered as the base position. Multipath refers
to a signal from the satellite that reaches the GNSS antenna
stance added) bias to the signal and can introduce noise into
the position solution or even cause an incorrect integer
ambiguity resolution. In RT applications the time on point is
CORS AND OPUS FOR ENGINEERS
so short that most of the multipath error cannot be correctly
modeled, as is done in static observations of at least 15
minutes in duration. The worst multipath sources are from
nearby signs, buildings, vehicles, water surfaces, tree canopy,
and metal objects of any kind. Even a delay of a nanosecond
imparts a range error of 30 cm. Multipath must be avoided as
much as possible for high precision work and requires the
awareness and experience of the RT practitioner.
Final important requirements for data collection are that:
communication to the base is strong and continuous while
observing a point of interest, data are received at the rover
from the base and satellite with less than 2 seconds latency, a
check on known or previously located points is made prior to
new data collection and with the same initialization as the new
survey, and the point of interest is observed and data collected
with a fixed solution display and not a float solution as
displayed in the data collector. In the quest to resolve the
ambiguous number of whole carrier cycles between each
satellite and each GNSS receiver’s antenna that will be added
to the partial cycle which the receiver’s record after locking
on to the satellites, many iterations of least squares
adjustments are performed. A first list of candidates produces
a set of “partial whole cycle” counts, that is, a decimal number
to each satellite for each frequency. This decimal cycle count
is said to be the “float” solution – one that still has not yet
forced the number of whole cycles to take an integer value.
Usually, the positional RMS and horizontal and vertical
precisions will slowly decrease as the rover receiver iterates
solutions. The user will see these indicators go from several
meters down to submeter. Sometimes the solution rapidly
goes to fixed and these iterations are not seen. As soon as the
solution is “fixed” and the best initial whole number of cycles
has been solved, the data collector will display survey grade
position precision, usually at the sub-centimeter level. The
177
 rover will experience a “loss of lock” if the satellite signals
are blocked to the extent of reducing the available number to
less than 5, or the communication link to the base station is
lost. This would then require a re-initialization and new
ambiguity resolution to be performed by the rover when
conditions improve. High precision RT work must always be
performed with a fixed solution. The summary table (Fig. 7)
may then be used to establish the corresponding field
parameters of the survey.
For field work proceeding after a localization to passive
marks:
For Accuracy Classes RT1 and RT2:
If a localization has been performed, the base station must be
inside the localization envelope and must be connected to the
nearest localization control monument by a maximum of 1 cm
+ 1 ppm horizontal and 2 cm + 1 ppm vertical tolerances at the
95 percent confidence level.
For Accuracy Classes RT3 and RT4:
If a localization has been performed, the base station must be
inside the localization envelope and should be connected to the
nearest localization control monument at the accuracy level of
the survey.
For Accuracy Classes requiring redundant locations, in
addition to obtaining a redundant location at a staggered time,
use this procedure for each location to prevent blunders:
1. Move at least 30 m from the location to create different
multipath conditions, invert the rover pole antenna for 5
seconds, or temporarily disable all satellites in the data
collector to force a reinitialization then relocate the point after
reverting to the proper settings.
2. Manually check the two locations to verify that the
coordinates are within the accuracy desired or inverse between
the locations in the data collector to view the closure between
locations. (this operation can be automated in some data
collectors). Each location should differ from the average by no
more than the required accuracy.
3. Optionally, after losing initialization, use an “initialization
on a known point” technique in the data collector. If there was
a gross error in the obtained location, initialization will not
occur.
4. For vertical checks, change the antenna height by one or
two decimeters and relocate the point of interest. (Don’t forget
to change the rover’s pole height in the data collector!).
It should be emphasized that the most important field
procedure to follow in order to obtain confidence in the results
with RT is to have redundancy in locations of important
points. Any point that is to be used to generate additional data,
such as a traverse densification point, or that is integral to
achieving correct data, such as a photo identifiable target,
should follow Class RT1 or RT2 recommendations. As can be
seen, both of these classes specify redundant locations
178 CORS AND OPUS FOR ENGINEERS
staggered by 4 hours. The reason for the different times of day
is to obtain a location on the point of interest using different
satellite geometry. It has been shown empirically that the
different satellite geometry will typically produce different
values of up to 2 centimeters in benign conditions and higher
differences in challenging conditions (see Zilkoski et al. 1997).
The closest value to the accepted “truth’ at a point was shown
to be the simple average of the locations. These data were the
result of case studies conducted in the development of NGS
guidelines for static GPS derived ellipsoid heights and static
GPS derived orthometric heights. Additionally, the change in
satellite geometry should mean different multipath conditions
which are mitigated by point averaging. Basically, the more
locations the better.
As a final note, recent RT case studies (e.g., see Appendix A
of the RT user guidelines) have shown that newer GNSS
equipment with better algorithms and increased capabilities
will produce much better agreement between locations at
differing times of day and at extended distances from the base
than has traditionally been seen from legacy GPS equipment.
Further Work in the Office
RT baselines can be viewed and analyzed in most major GNSS
manufacturers’ software. The data are imported into the
software with the field parameters and project configuration
intact. At this point, a re-localization can be done or the field
localization (if any) can be reviewed and left unaltered. If the
site localization is changed in the office, resulting in new
coordinates on all located points, the new localization
information must be uploaded to the data collector before any
further field work is done for that project. Communication
between field and office is critical to coordinate integrity and
consistency of the project. Different localizations can yield
significantly changed coordinates for the same project. If the
data are collected with covariance matrices and there are
multiple locations on the points of interest, a post campaign
adjustment can also be performed (although at typically less
accuracy than with static network observations). The RT
survey baselines can be checked by reviewing various
generated reports or viewing each baseline graphically (see
Figures. 8-11).
Fig. 8. Base station information

Fig. 9. Rover information
Fig. 10. Vector information
Fig. 11. RMS, Precision and PDOP
Entering in the correct coordinates of field checked stations
will let the user actually adjust all the RT located points
holding those known values. Items to check post campaign
include: antenna heights (height blunders are unacceptable and
can even produce horizontal error), antenna types, RMS values,
redundant observations, horizontal & vertical precision, PDOP,
base station coordinates, number of satellites, localization (if
any) residuals. (if calibrating horizontally, also check the scale
of the calibration, and if using a multi-point vertical calibration,
also check the slope of the correction surface).
CORS AND OPUS FOR ENGINEERS
Metadata
RT positioning yields coordinates from the field work
performed, but little else in the way of information on the
equipment used and how the work was performed. The
responsible geospatial professional must put in place
procedures to ensure that adequate metadata (data about data)
is recorded. It is recommended that a standardized form be
produced to accomplish a uniform and complete archival of
pertinent information. Such data should include:
ƒ What is the source of the data?
ƒ What is the datum/adjustment/epoch of the base
station(s)?
ƒ What were the field conditions? Temperature, wind,
precipitation, storms
ƒ What equipment was used, especially- what antenna?
ƒ What firmware was in the receiver and collector?
ƒ What redundancy, if any, was used
ƒ Were local passive monuments constrained (a
localization was performed)? Horizontal?
Vertical, or Both? How did the known points check?
Be sure to record the date of the localization (if any)
and where it was performed (field or office).
ƒ Date, time and field technicians’ names.
Comparison to Real Time Network Positioning
It is important that users are aware of the different
methodologies available to them for their work. With the
convergence of maturing technologies such as wireless Internet
communication, later generation GNSS hardware and
firmware, and augmented satellite constellations, RT
positioning is becoming a preferred method of data acquisition,
recovery and stake out to many users in diverse fields.
Currently, network solutions for RT positioning (RTN) are
sweeping across the United States, spanning a wide sector of
all GNSS users. The cost to benefit ratio and ease of use are
two main factors driving this rapid growth. RT positioning has
outgrown the traditional applications in surveying and
engineering and spread into major markets for precision
agriculture, machine guidance and GIS infrastructure.
Benefits to the user of a RTN over classical RT positioning
include:
9 No user base station is necessary. Therefore, there are
no security issues with the base, no control recovery is
necessary to establish its position, and the user needs
only half the equipment to produce RT work (or the
user can double productivity by also using the legacy
base receiver). Additionally, there is no lost time
setting up and breaking down the base station
equipment and radio.
9 The first order ppm error is eliminated (or drastically
reduced) because ionospheric, tropospheric and orbital
errors are interpolated to the site of the rover.
9 The network can be positioned to be aligned with the
national spatial reference system (NSRS) with high
accuracy. The users will then be collecting positional
179
 data that will fit together seamlessly. This is important
to all users of geospatial data, such as GIS
professionals who may deal with such regional issues
as emergency management and security issues.
9 Datum readjustments or changes can be done
transparently to the user with no post campaign work.
New datum adjustments to NAD 83 or even
transformations to another geodetic reference frame
such as the International Terrestrial Reference Frame
(ITRF) are done at the network level and are broadcast
to the users. Weather this will be accomplished by
NGS or an RTN administrator remains an open issue.
9 With some business models, the user can share in the
network profits by installing a network reference
station and thereby getting a share of the subscription
fees imposed upon other network users.
9 Different formats and accuracies are readily available.
GIS data, environmental resource data, mapping grade
data, etc. can be collected with one or two foot
accuracy while surveyors and engineers can access the
network with centimeter level accuracy. RTCM,
CMR+ and other binary formats can be user selected.
9 The RTN can be quality checked and monitored in
relation to the NSRS using NGS programs such as
OPUS (Weston et al. 2007) and TEQC from
UNAVCO (Estey and Meertens 1999).
Drawbacks to the user of a RTN compared to classical RT
positioning include:
' Network subscription fees. These may be prohibitive
for small companies.
' Limited wireless data access.
' Interpolation issues. Network spacing, communi-
cation and error modeling must be handled optimally
by the administrator.
' Work outside the network envelope (extrapolation of
corrections) degrades accuracy.
' The network solution may not fit to local control.
Localization or control network adjustments may be
necessary.
' Coordinate metadata. Is the network datum the user’s
required datum?
' Can all GNSS manufacturers’ equipment be used and
will different gear produce the same
results?
' Will overlapping RTN produce homogenous coor-
dinates?
There are presently around 37 state departments of transport-
tation (DOT) planning or operating a RTN and perhaps well
over 80 RTN in the USA. NGS has an important role to play in
this new positioning solution, both in providing support for
these networks as well as protecting the public interest. Of
prime importance, NGS plans to encourage RTN to
successfully align to the NSRS within a certain tolerance (to be
determined) by connections to the CORS network (Snay and
Soler 2008). NGS will develop user guidelines and
administrative guidelines for RTN in the effort to keep the
produced positions homogenous and accurate for all levels of
geospatial professionals.
180 CORS AND OPUS FOR ENGINEERS
RT Field Check List
9 Set the base at a wide open site
9 Set rover elevation mask between 10° & 15°
9 The more satellites the better
9 The lower the PDOP the better
9 The more redundancy the better
9 Beware multipath
9 Beware long initialization times
9 Beware antenna height blunders
9 Survey with “fixed” solutions only
9 Always check known points before, during and after
new location sessions
9 Keep equipment adjusted for highest accuracy
9 Communication should be continuous while locating a
point
9 Precision displayed in the data collector is usually
may be at the 68 percent
level (or 1 ), which is only about half the error spread
to get 95 percent
confidence
9 Have back up batteries & cables
9 RT does not like tree canopy or tall buildings
Conclusions
The four cardinal rules of RT locations are:
1. Always check a known point before collecting new
data from a base station
2. Always have redundant locations on important points
3. Always have a strong, continuous communication link
to the base while locating a point
4. Avoid multipath conditions whenever possible
References
Estey, L.H., Meertens, C.M. (1999) “TEQC: The multi-purpose
toolkit for GPS/GLONASS data.” GPS Solutions, 3(1), 42-
49.
National Geodetic Survey (2009). “User guidelines for single
base real time GNSS positioning” Henning, W. (editor)
<http://www.ngs.noaa.gov/PUBS_LIB/NGSRealTimeUser
Guidelines.v1.1pdf>.
Snay, R.A., and Soler, T. (2008). “Continuously Operating
Reference Station (CORS): History, applications, and
future enhancement.” J. Surv. Eng. 134(4), 95-104.
Weston, N.D., Soler, T., and Mader, G.L. (2007). “Web-based
solution for GPS data. NOAA OPUS.” GIM Int.,21(4), 23-
25.
Zilkoski, D., D’Onofrio, J., and Frakes, S. (1997). “Guidelines
for establishing GPS-derived ellipsoig heights (Standards: 2
cm and 5 cm) Version 4.3” NOAA Technical Memorandum
NOS-NGS-58.
 22
Transforming OPUS Results to WGS84
Tomás Soler, M.ASCE1 and Richard A. Snay2

Abstract: Users of the Web-accessible Online Positioning User Service (OPUS) can transform its output coordinates, currently
expressed in the ITRF2000 frame, to the World Geodetic System of 1984 (WGS84), defined by the National Geospatial-
Intelligence Agency (NGA), following a simple set of transformations explicitly outlined in this paper.

Author keywords: Online Positioning User Service; OPUS; Horizontal Time Dependant Positioning; HTDP; GPS positioning;
geodetic networks

has moved between these two times. This motion is not

Introduction
rigorously known until we have constantly monitored the
point in question for a number of years. This is not generally
Many federal and international agencies require the
the case, and we must rely on approximate geophysical
coordinates derived from geodetic GPS projects to be
models. The most common model used these days for
published in the WGS84 (G1150) frame. This is the latest of
correcting for tectonic plate motion is called NNR-NUVEL-
a series of geodetic frames determined by the National
1A (DeMets et al. 1994). This model provides the
Geospatial-Intelligence Agency (NGA, formerly NIMA).
parameters required to correct for plate motion for all major
The G in the extension of the frame name stands for GPS,
tectonic plates (macroplates) that comprise the Earth’s crust.
the number 1150 indicates the first GPS week during which
This model, however, does not provide for the motion
the NGA precise ephemerides were expressed in this frame.
occurings in the boundary zones located between plates.
Recent investigations (True 2004) have shown that for all
Such zones can extend several hundred kilometers in width.
practical purpose, the WGS84 (G1150) frame is identical to
A practical process for converting the ITRF2000
the International Terrestrial Reference Frame of year 2000
coordinates provided by OPUS to WGS84 (G1150) can be
(ITRF2000, also referred as ITRF00).
subdivided into two slightly different series of steps
Currently, OPUS solutions provide ITRF2000 coordinates
depending on the location of the OPUS solution point: (1)
at the epoch corresponding to the midpoint of the
the USA, or (2) the rest of the world. The following two
observational time span. Consequently, every OPUS solution
sections give the steps required for each process.
will refer to a different epoch although the frame of
reference is the same ITRF2000. If it is desired to
transform these ITRF2000 coordinates to WGS84 (G1150), OPUS Transformations to WGS84 (G1150) in the
then it is necessary to specify the epoch to which the USA
WGS84 (G1150) coordinates are to be referred because
crustal motion, especially that associated with plate If the OPUS solution refers to a point in the US, the observer
tectonics, causes both ITRF2000 and WGS84 (G1150) could transform the ITRF2000 coordinates given in the
coordinates to change as a function of time. Such OPUS output for the epoch of observation to
coordinates can change as fast as several centimeters per WGS84(G1150) coordinates at epoch 1997.0 by using the
year. Default ITRF200 coordinates are referred to January Horizontal Time-Dependent Positioning (HTDP) software
1, 1997 (or 1997.00 when expressed in decimal years). described in Snay (1999, 2003). This utility is accessible
Hence, for the processes described in the following text, it is through NOAA’s National Geodetic Survey (NGS) main
assumed that the OPUS user desires WGS84 (G1150) Web page at:
coordinates referred to 1997.00. However, the processes http://www.ngs.noaa.gov/TOOLS/Htdp/Htdp.shtml.
may be applied for any epoch by simply inserting the desired Once the HTDP Web page is reached, the following click-
epoch wherever the text uses 1997.00. Note that if WGS84 paths should be followed:
(G1150) coordinates are desired for the epoch of
observation, then these coordinates equal the corresponding Interactively transform positions between reference frames
ITRF2000 coordinates for the epoch of observation as → Individual points entered interactively
provided directly by OPUS.
To transform ITRF2000 coordinates (or equivalently And then:
WGS84 (G1150) coordinates) from the epoch of observation
to 1997.00, it is necessary to know how the point of interest 1) Reference frame for the input value: ITRF00
1
Chief Technical Officer, Spatial Reference System Division, National Geodetic Survey, NOS, National Oceanic and
Atmospheric Administration, 1315 East-West Hwy., Silver Spring, MD 20910. E-Mail: Tom.Soler@noaa.gov
2
Former Chief, Spatial Reference System Division, National Geodetic Survey, NOS, National Oceanic and Atmospheric
Administration, 1315 East-West Hwy., Silver Spring, MD 20910. E-Mail: Richard.Snay@noaa.gov

CORS AND OPUS FOR ENGINEERS 181


2) Reference frame for the output value: WGS_84
(G1150)
3) Epoch date of the input position: “Enter the epoch
date given in the OPUS output for ITRF00 in
month, day, and year”
4) Epoch date of the output position: “Enter 1, 1, 1997
for January 1, 1997.
5) Select the type of coordinates to be used: “Insert the
ITRF00 coordinates expressed either as geodetic
coordinates latitude, longitude, and ellipsoid
height) or as geocentric Cartesian coordinates (x, y,
z) from the OPUS output”
6) Select how the required velocity (relative to the
input frame) is to be entered: “in the majority of
cases use the default value (predicted by this
program) and ignore the input boxes below.”
Once the “Submit Query” button is pressed the
corresponding WGS84 (G1150) coordinates for 1997.00 will
be given.
Note that in the conterminous United States and Alaska,
the HTDP software uses geophysical models adopted by
NGS (Pearson et al. 2010). These models do provide
velocities in the boundary zone between the North America
plate and the plates to the west of the coterminous US. In
_________________________________________________
x x
 
 y =  y  + (1997 − epoch date)
 z  ITRF 00  z  ITRF 00
 
( epoch 1997.0)
 
( epoch date )
 
 
velocities from
Final coordinates The epoch is different
WGS 84(G1150) for each OPUS solution
The units must be consistent. If the coordinates are given
in meters (m), the velocities must be expressed in m/yr.
Consequently, the unknown parameters in the above
equation are the three components of the velocity at the
point along the Cartesian axes of the WGS84 frame. These
quantities could be computed as a function of the (x, y, z)
ITRF00, epoch date, frame.
To obtain (vx, vy, vz) the OPUS user will introduce into the
appropriate window of the UNAVCO calculator the (x, y, z)
values from the OPUS output referred to the ITRF00, epoch
date. For the plate model selection the authors recommend
to use NUVEL 1A; for the “Tectonic Plate of attributed
motion” Auto and for the “Reference” NNR no-net-
rotation. After clicking the “Submit” button, the program
will return the values that can be inserted into Eq. (1).
182 CORS AND OPUS FOR ENGINEERS
addition to crustal velocities, these models also estimate the
crustal displacements associated with major earthquakes.
Such displacement models are important if one of these
earthquakes occurred in the vicinity of the OPUS point
between 1997.00 and the time when the GPS observations
were performed.
OPUS Transformations to WGS84 (G1150) outside
the USA
The HTDP utility is not designed to predict crustal velocities
outside the United States and its territories. Therefore, for
points located outside of the USA, the OPUS user is
compelled to find a geophysical model to his/her liking to
obtain the plate velocities at the point of observation. This
information is easily available from the Web. The authors
suggest using the “Plate Motion Calculator” devised by
UNAVCO which is available at the following URL:
http://www.unavco.org/community_science/science-support/
crustal_motion/dxdt/model.html
This portal is very complete and contains the references of
all important scientific papers that introduced different
geophysical plate models. Furthermore, if desired, the user
can select other types of Internet plate motion calculators
cited at the bottom of the given Web page.
In essence, and following the line of thought described
above, what the OPUS user needs to implement for each
observed OPUS point in order to get final WGS84 (G1150)
coordinates is the following matrix equation:
 vx 
 
v y  (1)
 
 vz 
N
geophysical mod el
at each po int
However, knowing (vx,vy,vz), the user has another
alternative to mathematically implement Eq. (1) by
recolling HTDP. Although mentioned above, HTDP cannot
predict the velocity components (vx, vy, vz) outside the
United States, nevertheless, it can compute the 1997.00
coordinates using Eq. (1) if the velocities are known. The
step-by-step procedure will be identical to one described
above except that, now, the option used before at point 6)
will not be the default. The new HTDP options are:
6) Select how the required velocity (relative to the
input frame) is to be entered.
7) Specify the velocity in terms of global x-y-z
components (use the input boxes below).
 Notice that HTDP requires the input velocities in mm/yr.
The coordinates themselves should be introduced in units of
meter because, HTDP converts the provided velocity from
mm/yr to m/yr before processing Eq. (1).
Cartesian transformation to curvilinear geodetic
and UTM coordinates
(February, 2011). Before the end of the year, NGS will
switch from ITRF2000 to a newly GPS defined geocentric
frame, probably IGS08. At that time the OPUS output will
be accordingly altered to reflect this change. Therefore,
before transforming to WGS84 (G1150), the following
extra information will be required to perform the
transformation:

The final Cartesian coordinates, from Eq. (1), if desired,
can then be transformed to curvilinear geodetic coordinates
(λ , ϕ , h) by reaching the following URL at NGS Web site:
http://www.ngs.noaa.gov/TOOLS/XYZ/xyz.shtml. This
calculator uses the GRS80 ellipsoid, however, for all
practical applications the GRS80 and WGS84 ellipsoids
may be considered identical. Thus:
IGS08 (epoch date) → ITRF200 (epoch date) (4)
After this transformation is implemented, the logic will
continue as explained before. Once the decision by NGS
about expressing future OPUS solution in the IGS08 frame
is made, the software HTDP will be updated to help OPUS
users to transform coordinates according to Eq. (4).

Conclusions
 x λ 
   
(GRS 80)→ ϕ

⎯⎯⎯⎯⎯ The main intent of this paper was to facilitate to the OPUS
y
(2)
user the possibility of transforming coordinates from the
z  
  ITRF 00  h FrameITRF 00 output solutions of OPUS, currently given in the ITRF2000
(epoch1997.0) (epoch1997.0)
  
(epoch date of the observations), to the WGS84 (G1150)
Geodet ic coordinates frame. It is important to realize that the WGS84 (G1150),
in t heGRS 80 ellipsoid epoch 1997.0, frame is still widely employed around the
world by the geospatial community, consequently, a
Finally in many international GPS projects around the practical rigorous procedure to achieve this transformation
world the values of UTM coordinates are also required. relying on available online software was explained.
From the resulting geodetic coordinates obtained using the
procedure outlined in Eq. (2), the OPUS international user References
could transform into UTM coordinates according to the
following schematic route: DeMets, C., Gordon, R.G., Argus, D.F., and Stein, S.
(1994) “Effect of the recent revisions to the
λ 
geomagnetic reversal time scale on estimates of current
 X 

WGS 84 ⎯⎯⎯⎯
(GRS 80) →
(3) plate motions.” Geoph. Res. Lett., 21(20), 2191-2194.
ϕ Frame ITRF 00  Y UTM
WGS 84
epoch 1997
The link to calculate online the UTM coordinates is:
http://www.ngs.noaa.gov/TOOLS/utm.shtml The procedure
is self explanatory. The user of this software should select
the NAD83 datum which implies that all calculations will
be performed with respect to the GRS80 ellipsoid.
Consequently, the final UTM coordinates will refer to the
GRS80 ellipsoid, that, for all practical purposes, is
equivalent to the WGS80 ellipsoid
Final comments. The procedures indicated here in
conjunction with OPUS are the ones currently valid
CORS AND OPUS FOR ENGINEERS
Pearson, C., McCaffrey, R., Elliot, J.L., and Snay, R.
(2010). “HTDP 3.0: Software for coping with the
coordinate changes associated with crustal motion.” J.
Surv. Eng., 136(2), 80-90.
Snay, R.A. (1999). ‘Using HTDP software to transform
spatial coordinates across time and between reference
frames.” Surv. Land Inf. Syst., 59(1), 15-25.
Snay, R.A. (2003). “Horizontal Time-Dependent Posi-
tioning.” Prof. Surv. 23(11), 30, 32, 34.
True, S.A. (2004) “Planning the future of the World
Geodetic System 1984.” Proc. IEEE Position Location
and Navigation Symposium, Monterey, CA, 26-29 April
2004, 10 p.
183
This page intentionally left blank
 Index
accuracy 88–99; comparison of OPUS-RS and
OPUS-S 95–98; equation to estimate 90–
92; overview 89–90; and real-time GNSS
positioning 173–180; standard errors 92–95
ambiguity resolution 133–142, 143–153;
double difference ionosphere properties
149–152; experimental scenarios 144–145;
ionospheric delay analysis 146–147;
ionospheric models 134–135; positioning
algorithm 134–135; test 147–149; test
criteria 145–146; test data 135–139
continuously operating reference station. see
CORS
coordinate observations 120–122; comparison
of OPUS-RS and OPUS-S 128; network
adjustments 125–132; OPUS-RS
adjustments 128–131; radial fast static GPS
network 126; radial fast static network with
OPUS 126–127; radial fast static network
with OPUS-RS 127–128
CORS: aerial mapping 8; aerial moving
platforms 8; antennas 14–15; applications
of 2–8; crustal motion 6–7; data archives
4–5; GPS observational accuracies 6;
ionospheric studies 7–8; monuments 13–
14; multipath studies 6; Ohio case study
143–153; overview 1–2; pillars 13–14; sea
level changes 7; site creation 11–13; site
metadata 15–16; site operation 13–16;
tropospheric studies 7; user-friendly 5
error messages 100–106; message
descriptions 104–105; statistics of 101–
102; time series of 102–103
GPS, real-time kinematic 133–142;
ionospheric models 134–135; positioning
algorithm 134–135; test data 135–139
GPS vectors 119–124; final combined
adjustment 122–123; OPUS coordinate
observations 120–122; vector adjustment
network 120
HTDP. see positioning, horizontal time
dependent
CORS AND OPUS FOR ENGINEERS
ICON 134, 138–139
IGS GIM 134
IGS orbits 27–29
ionospheric models 134–135, 138–139
ionospheric studies 7–8
MAGIC 134, 138–139
mapping, aerial 8
metadata 15–16, 179
models, ionospheric 134–135, 138–139
monuments: ground-based 13–14; roof-
based 14
MPGPS-NR 134
multipath studies. see studies, multipath
NAD 83 154–160; OPUS transformations
159; transforming positional coordinates
155–157; velocities 157–158
National Spatial Reference Service 2–4;
upgrading 6
network adjustments 125–132, 143–153;
ambiguity resolution test 147–149;
ambiguity resolution test criteria 145–146;
double difference ionosphere properties
149–152; experimental scenarios 144–145;
ionospheric delay analysis 146–147
North American Datum of 1983. see NAD 83
Ohio CORS 143–153
online positioning user service suite. see
OPUS
OPUS 17–26; fundamentals 17–18; future
plans 25; IGS orbits 27–29; and network
adjustments 126–127; precise position
utility 40–45; reports 18–19; and RINEX
62–66; solution accuracy 30–40; solutions.
see OPUS solutions; TEQC utility 46–50;
transferring results to WGS84 181–183;
transformations to NAD 83 159
OPUS data base. see OPUS-DB
OPUS rapid static. see OPUS-RS
OPUS solutions 30–40; data from testing 33–
40; testing methodology 31–32
OPUS static. see OPUS-S
OPUS-DB 22–23
185
 OPUS-RS 21–22; accuracy 74–87; accuracy
estimation 90–92; accuracy of 88–99;
compared to OPUS-S 95–98; coordinate
observation adjustments 128–131;
coordinate observations 125–132; error
messages 100–106; and network
adjustments 127–128; OPUS coordinate
observations 120–122; rapid static GPS
software 67–73; standard errors 92–95;
unified adjustment 119–124. see also rapid
static GPS software; rapid static techniques
OPUS-S 19–20, 51–61; base station
information 55–56; compared to OPUS-RS
95–98; G-File 57–58; individual baseline
computation 57; NAD-3 computations 60;
network accuracy 59–60; OPUS coordinate
observations 120–122; overview 51–53;
remote station information 56–57; standard
report 53–55; state plane coordinates 60–
61; unified adjustment 119–124
platforms, aerial moving 8
positioning, horizontal time dependent 154–
160, 161–172; exercises 165–172; software
characteristics 162–163
positioning, real-time GNSS 173–180;
accuracy and precision 173–175;
comparison to real-time network positioning
179–180; constraining a survey to passive
marks 176–177; criteria for 177–178;
metadata 179; real-time field check list 180
rapid static GPS software 67–73; data
conditioning 70–71; methodology 68;
overview 67–68; performance 71–72;
186 CORS AND OPUS FOR ENGINEERS
reference satellites 69; reference station
68–69; rover constraints 69; tropospheric
refraction 69; weighting schemes 69–70.
see also OPUS-RS
rapid static techniques 74–87; accuracy
visualization 81–82; IDOP 78–80;
interstation distances 80–81; overview 74–
77; standard errors 77–78, 83–84. see also
OPUS-RS
real-time systems: real-time GNSS positioning
173–180; real-time kinematic GPS 133–142
RINEX 46–50; editing data 65; editing files
107–118; fixing OPUS runs 62–66;
observation file 64–65; observation files
109–116; and TEQC 107–109, 116–118
RPGPS. see rapid static GPS software
site metadata 15–16
site operation: operator requirements 13–16;
site metadata 15–16
software: horizontal time-dependent
positioning 161–172; rapid static
GPS 67–73
standard deviation calculation 40–45
studies, ionospheric 7–8
studies, multipath 6
studies, tropospheric 7
TEQC 46–50; quality control report 116–
118; and RINEX 107–109
transformation parameters 154–160
tropospheric studies 7
WGS84 181–183