# Accuracy assessment of the National Geodetic Survey’s OPUS-RS utility

## Authors

- First Online:

- Received:
- Accepted:

DOI: 10.1007/s10291-008-0105-0

- Cite this article as:
- Schwarz, C.R., Snay, R.A. & Soler, T. GPS Solut (2009) 13: 119. doi:10.1007/s10291-008-0105-0

- 138 Views

## Abstract

### Keywords

GPSGeodesyRapid 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.

To accomplish this, an entirely new internal processing engine was constructed, replacing the PAGES program used in the original OPUS. OPUS-RS also uses a more restrictive algorithm for selecting reference stations, and it places more restrictions on the data sets it will process.

However, the external interface for OPUS-RS is the same as that for the original OPUS, and most of the information and explanations offered for the original OPUS apply to OPUS-RS. Many 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 very similar as well.

- 1.
Show that it is generally possible to obtain accurate coordinates from GPS tracking sessions as short as 15 min, while using reference stations from the U.S. CORS network. This network of reference stations provides baseline lengths of 100–200 km in many areas, but in areas where the CORS network is sparse, the baseline lengths can be much longer.

- 2.
Design processing options and a station-selection algorithm that will produce accurate coordinates for almost all user data sets, even though these data sets vary widely in terms of receiver type, antenna type, antenna placement, station environment, tracking quality, observing session length, and geographic location. Furthermore, construct algorithms that recognize and notify the user regarding situations that are unlikely to compute a highly accurate solution.

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 first challenge could be met, at least for areas with well behaved reference station data. NGS developed and 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 experimentation. The first approach was to select the three closest CORS, as is done for regular OPUS. The spatial interpolation 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 algorithm 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 allowed to be up to 50 km outside the “convex hull” of the selected reference stations. The convex hull is the smallest convex polygonal area encompassing the reference stations.

## How OPUS-RS works

OPUS-RS solves for the coordinates of the user’s receiver in two steps. In the first step, parameters associated with the reference stations are determined. In the second step, the parameters determined in the first step are combined with the tracking data from the rover to determine the rover coordinates. RSGPS has two operating modes, network and rover, which are used to accomplish these two steps. In network mode, at least 1 h of data from the selected CORS are used to solve for integer ambiguities, tropospheric refraction parameters, and the double difference ionospheric delays at the chosen CORS, with the positional coordinates of the CORS held fixed. In rover mode, the ionospheric delays 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 coordinates of the rover. Again, the positional coordinates of the CORS are held fixed.

- 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 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 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 observations 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 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.

- 4.
*Improve the position*A differential pseudo-range solution is performed using the RINEX file from the closest reference station, the known coordinates of the reference 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. - 5.
*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 continued 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 coordinates 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

*Formal error propagation*. In a least squares adjustment, 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 contained 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. However, 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.

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*dimensions, 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 baselines independent of each other and of the final coordinates, these numbers would be the standard errors of the coordinates 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:

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.

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.

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.

- 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 extrapolates) 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 OPUS utility. In particular, Eckl et al. (2001) showed that both the orientation and length of a baseline between two GPS data-collection stations have negligible influence on the relative positional coordinates between these stations when their GPS data are processed with PAGES (the processing engine contained in the original OPUS). The influence of reference-station geometry on the accuracy of the rover coordinates, as obtained with OPUS-RS, is reflected in the following theorem. We will address the influence of interstation distances in a later section of this article.

**Theorem 1**

*Suppose z = f(x, y) is modeled by the expression*

*and suppose there is a set of n independent observations, denoted z*

_{i}

*, at the points*(

*x*

_{i}

*, y*

_{i})

*for i =*1, 2, 3,…,

*n*.

*We choose to estimate the parameters a, b, and c by least squares. We further suppose that the observations are statistically independent and each has the (unknown) standard deviation σ. The predicted value of z at the point*(

*x*

_{0}

*, y*

_{0})

*then has the standard error*\( \sigma_{{z_{0} }} \)

*given by the expression*

*where*

*and*

*where*Δ

*x*

_{i}

*= x*

_{i }

*− x*

_{0}

*and*Δ

*y*

_{i}

*= y*

_{i }

*− y*

_{0}

*.*

Appendix 1 contains a proof of this theorem.

*x*

_{0},

*y*

_{0}) is located at the centroid of the data points [that is, if \( x_{0} = \left( {\sum x_{i} } \right)/n \) and \( y_{0} = \left( {\sum y_{i} } \right)/n \)], then \( \sum \Updelta x_{i} = \sum \Updelta y_{i} = 0 \) and

*2p*, where

*p*is an arbitrary parameter. The computations in Appendix 2 show that for this example,

IDOP values at various locations when four CORS are at the corners of a square whose sides have a length of 2*p*

( | IDOP |
---|---|

(0, 0) | 0.50 |

(0, | 0.56 |

( | 0.56 |

(0, − | 0.71 |

( | 0.71 |

( | 0.87 |

( | 0.87 |

(− | 0.87 |

(− | 0.87 |

(0, 3 | 0.90 |

(0, 2 | 1.12 |

(3 | 1.17 |

(2 | 1.50 |

The IDOP should not be confused with the well-known unitless quantity called the geometric dilution of precision (GDOP). Nor should IDOP be confused with related measures, such as PDOP, HDOP, VDOP, TDOP, etc. GDOP and its related measures are well explained in many textbooks, including Leick (2004), and they quantify the geometry of the collection of GPS satellites visible from the rover. Thus, IDOP quantifies reference-station geometry relative to the rover, and GDOP quantifies satellite geometry relative to the rover. Both IDOP and GDOP will influence the accuracy of the coordinates obtained with OPUS-RS, but we have restricted our attention to IDOP for this study.

## The effect of interstation distances

*x*and

*y*coordinates by the factors

*s*

_{x}and

*s*

_{y}such that

*x’*

_{0},

*y’*

_{0}) in the

*x*′

*y*′-frame would be the same as the IDOP value at (

*x*

_{0},

*y*

_{0})in the

*xy*-frame. Thus, in the example of four reference stations located at the corners of a square: IDOP equals 0.5 at the centroid, it equals 0.56 at any point that is located at a distance of

*p*/2 from the centroid, and it equals 0.87 at each reference station, no matter what value of

*p*is used. This result may be counterintuitive, because it seems that we should be able to predict the atmospheric conditions at the square’s centroid better when

*p*equals 50 km than when

*p*equals 100 km. Nevertheless, this is the case so long as the function

*f(x*,

*y)*can be “adequately” approximated by the linear mathematical expression

*ax + by + c*over the area involved in interpolation.

To test what happens otherwise, we examined a particular case restricted to one function of one variable.

**Theorem 2**

*Suppose that z is a quadratic function of x*,

*z = f*(

*x*)

*= ax*

^{2}

*+ bx + c, and suppose there is a sample of n independent observations z*

_{i}

*at x*

_{i}

*for i =*1, 2, 3,…,

*n*.

*Suppose also that we attempt to approximate*

*f*(

*x*)

*by the linear expression b′x + c′, then the error of approximation at x = 0 is c′ − c. Furthermore*,

*for the case that*\( \Upsigma x_{i} = 0 \).

Appendix 3 contains a proof of Theorem 2.

This theorem indicates that, for this particular case of *f*(*x*), the linear interpolation process will generate a biased prediction at the point *x* = 0. Moreover, the magnitude of this bias is proportional to \( (\Upsigma x_{i}^{2} )/n \) when \( \Upsigma x_{i} = 0. \)

*f*(

*x, y*) is itself a nonlinear function of

*x*and

*y*within the area of interpolation (extrapolation), then the linear interpolation process may generate a biased prediction of the atmospheric conditions at the rover. The magnitude of this bias will depend on the nature of

*f*(

*x, y*). We will approximate this bias in this study by a quantity that is proportional to the root-mean-square distance (RMSD) from the rover as defined by the equation:

*d*

_{i}equals the horizontal distance between rover and the

*i-*th reference station for

*i*= 1, 2,…,

*n*. We have thus identified two sources of error—the error committed by using a simple plane to model the variation of atmospheric conditions, and the error of interpolation. We combine these two sources into an “overall” standard error of the predicted atmospheric conditions at the rover

*α*and

*β*are constants. Equation 11 embodies the concept that the square of the total error equals the sum of squares of the various error components. Here the term

*α*IDOP quantifies the random error due to linear interpolation, and the term

*β*RMSD approximates the systematic error due to the nonlinearity of the atmospheric delay as a function of

*x*and

*y*. In the next section, we will describe an experiment to estimate nominal values for

*α*and

*β*across the conterminous United States (CONUS) using GPS data 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 coordinates 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 observational 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.

*α*and

*β*of Eq. 11 to quantify

*σ*(IDOP, RMSD) for the east component. Similarly, values for

*α*and

*β*were estimated for the north component and the up component, yielding the following results:

Note that the values for *α* and *β* 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

*α*and

*β*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.

*α*and

*β*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 when using any process that interpolates atmospheric conditions from the reference stations to the rover’s location. Further investigations are planned to study the variability of the accuracy of OPUS-RS solutions when the 15-min observational window varies during the course of a 24-h day. Another relevant issue to address is to contrast the accuracy of OPUS-RS with that of the original OPUS for observing sessions with durations between 1 and 4 h.

## Discussion

Figures 3, 4, 5, 6 exhibit some significant discrepancies between the standard deviations for some of the individual bins and their corresponding curves. These discrepancies perhaps reflect that Eq. 11 is too simplistic. This equation 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 α and β change significantly as the solar max, predicted to occur during the 2011–2012 time frame, approaches. Our current results represent the situation for the 2007–2008 time frame, during which the magnitude of ionospheric refraction is relatively low.

## Vertical standard errors achievable in CONUS using OPUS-RS

*α*

_{u}and

*β*

_{u}from Eq. 12, taking into account the 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 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 are distributed all to one side of a would-be rover. As expected, OPUS-RS yields good vertical standard errors (2 cm ≤ σ

_{u}≤ 3 cm) in regions possessing dense CORS coverage (Ohio, Michigan, etc.). A map showing achievable 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 displayed for vertical standard errors should be divided by about 3.6 to obtain the corresponding horizontal standard errors.

## 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 UTC) during the tenth day of ten consecutive months (from July 2007 to April 2008). The results clearly show that IDOP and RMSD constitute important variables to consider when accurate GPS results are expected from OPUS-RS or, for that matter, any other process that interpolates (extrapolates) atmospheric conditions from several reference stations to the rover’s location, such as real-time GNSS reference station networks.