A 419Kb PDF of this article is available by clicking HERE
At the time of this writing, some significant events have come to pass for positioning professionals within the United States and for the National Geodetic Survey (NGS): First, NGS is celebrating the 200th birthday of its predecessor (The Survey of the Coast); second, a nationwide adjustment of NAD83 has been computed and published NAD83(NSRS2007); and third, a new member of the OPUS family OPUS-RS has been created (see Figure 1).
So What is OPUS?
Most surveyors are probably familiar with NGS’s Online Positioning User Service (OPUS). But for those who are not, here is little background.
OPUS is a web-based application that allows a user to submit a minimum of two hours of dual frequency GPS data for post-processing by NGS computers. OPUS will process the data relative to three stations within Continuously Operating Reference Station (CORS) network using NGS PAGES software. It will use the most precise GPS orbits that are available at the time of processing, compute the user’s latitude, longitude, and ellipsoid height referenced to the International Terrestrial Reference Frame (ITRF2000) and NAD 83 (CORS96), and an approximate orthometric height based on GPS and GEOID03 (NAVD 88). OPUS will also compute the State Plane Coordinates, UTM Coordinates, and US National Grid Coordinates. The resulting coordinates will be the average of the three separately computed vectors from the CORS stations, and will generally have a network accuracy of two centimeters or better horizontally and three centimeters or better vertically (ellipsoid height). OPUS provides statistics that will allow the user to evaluate the data and solution. If desired, OPUS will let users select their own set of CORS to process against, provide the vector information in NGS Blue Book format, and provide the variance/covariance matrix of the baselines’ vector components. The user will receive this information in the form of an e-mail, normally within minutes of submittal. Darn, barely time to get a cup of coffee!
OPUS-RS
OPU S-RS (Rapid Static) is a new version of OPUS designed to obtain geodetic quality positioning results from a user dataset as short as 15 minutes (guess I better fill my Thermos with coffee before going to the field.) An Operational Prototype version of OPUS-RS was first made available in September of 2005 and was promoted to Initial Operational Capability Status on January 31, 2007. OPUS-RS provides essentially the same output information as the standard OPUS and maintains a user interface with the same look and feel. As far as the user is concerned, the only significant changes to the output are the quality indicators (statistics) used to evaluate the solution. More on that later.
So What’s Under the Hood?
The internal processing engine for OPUS-RS is based on the RSGPS (rapid static GPS) program, which completely replaced the PAGES program used in the standard OPUS product. RSGPS is based on the MPGPS (Multi Purpose GPS) program developed by the Satellite Positioning and Inertial Navigation (SPIN) group at the Ohio State University. It uses the LAMBDA (Least Squares Ambiguity Decorrelation Adjustment) algorithm to determine the integer values ambiguities. The LAMBDA algorithm has been found to be vastly superior to other ambiguity search algorithms in many applications…okay, more power… I get it.
In addition, RSGPS uses a different set of quality indicators. The standard OPUS product uses a peak-to-peak indicator, while RSGPS uses something called the W-ratio. The W-ratio (as is referenced on the NGS web page www. ngs.noaa.gov/OPUS/OPUS-RS_More.html) is a measure of the separation between the best candidate set for the integer ambiguities and the second best set. RSGPS has the capability to perform a solution at each epoch, using all the data observed (pseudoranges and phases) up to and including that epoch. This allows one to watch the evolution of the W-ratio with time. The quality indicator reported by RSGPS is the average value of the W-ratio at the last three epochs.
How OPUS-RS Works
In order to use OPUS-RS, the user should have a basic understanding of what is going on behind the scenes. This will help to plan a survey, and will help to make sense of problems that may arise.
Selecting Reference Stations
OP U S-RS searches for reference stations in order of increasing distance from the user’s station, selecting reference stations that have suitable data. The search stops when either six stations have been selected or the distance from the user position exceeds 200 km. OPUS-RS will only process a file for which the user’s station is either inside the polygon enclosing the selected reference stations, or no more than 50 km outside that polygon. Also, if the search algorithm does not find at least three stations within 200 km, OPUS-RS will refuse to attempt a solution (see Figure 2).
According to Charlie Schwarz (the primary author of OPUS-RS), the operational prototype of OPUS-RS used a different selection criterion. This first criterion required that the user’s station be within a triangle formed by the reference stations. Charlie said, "This criterion was discarded because it was found that we were unable to satisfy it in twenty-five percent of our files, for example, twentyfive percent of our CORS stations fall on the periphery of the network outside of any triangles than can be formed by other CORS stations. We had not anticipated that it would be so high." This change in approach now makes it possible for those who live in states bordering Canada or Mexico to use OPUS-RS.
Network Mode
RSG PS is run twice to produce an OPUS-RS solution. First RSGPS is run in the network mode, using only data from the selected reference stations. The integer ambiguities resulting from this solution are used to solve for ionospheric and tropospheric delays.
Rover Mode
Next, RSGPS is run in the rover mode (treating the user’s station as a rover). The ionospheric and tropospheric delays computed in the network solution are used to estimate the delays at the rover. This is done either by interpolation (rover inside the polygon), or extrapolation (rover outside the polygon). Unlike OPUS, OPUS-RS computes a full network solution rather than the average of individual vectors.
What to Look For
[According to the OPUS-RS web page as of February 21, 2007] The quality indicators available to the user of OPUS-RS are thus the quality indicator from the network mode adjustment and the quality indicator from the rover mode adjustment. If these are both greater than 3.0, it is likely that the correct ambiguities are found and the solution is valid. If these indicators are less than 3.0, the solution may also be used, but with less confidence. If one or both of these indicators is less than 1.0, the solution should be used only with considerable caution.
If both the quality indicators are above 3.0, the solution for the coordinates of the rover should be of geodetic quality, which in this case means about 2 cm in the horizontal coordinates and 4 cm in the vertical coordinate (ellipsoid height).
The reader will notice that at the bottom of the OPUS-RS Datasheet shown in Figure 3, that much different accuracy statements are made. I asked Charlie about this, and he explained that 2 cm horizontal and 4 cm vertical are what NGS hopes to attain with well-behaved data, but at this time, the numbers at the bottom of the Datasheet are probably more realistic. In addition, Richard Snay, Chief of the Spatial Reference System Division of NGS, indicated that if the correct integers are found, then the 2 cm and 4 cm horizon
tal and vertical accuracies are probably achievable. The trick is knowing that the correct integer set was found. Charlie indicated that there are occasional false positives (cases where an erroneous solution is obtained even though the W-ratio is large), and false negatives (cases where the W-ratio is less than 1.0, but the solution is correct.) "We are hoping that we can improve our results, perhaps by not using solutions with very low quality indicators, so that we may also revise the statement on the data sheet."
This product is still evolving. Currently, any solution that does not abort will generate coordinates for the user, regardless of the value of the quality indicator. Even as I was writing this article, discussions were taking place as to whether results for solutions with quality indicators less than 2 should be reported, and developing an approach of changing reference stations to compute a new solution if the first solution yields low quality indicators.
What to Look Out For
Since RSGPS uses the Double Difference ionospheric delays at the reference stations 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 severe ionospheric storms. Geomagnetic storm alerts are issued by NOAA’s Space Environment Center (www.sec.noaa. gov), so that the surveyor may avoid taking data during these unusual events.
Similarly, RSGPS performs a simple planar geographic interpolation to predict the tropospheric delay at the rover station. 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.
Kicking the Tires
Though I have complete trust in NGS and the products we create, I am after all, a surveyor by nature. So, I naturally started submitting data sets to OPUS-RS to see what was what. I happened to have a number of long data sets that I had previously submitted to OPUS. So I decided to cut these up into 15-minute pieces and submit them as individual OPUS-RS sessions. Every comparison that I made between OPUS and OPUS-RS resulted in no more than about a centimeter in horizontal position and no more than about three centimeters in ellipsoid height. However, all of the quality indicators were significantly greater than three, ranging from 15 to 27.
A Couple More Tidbits
Rover Epoch Interval: Since all CORS data is archived at 30-second epochs, regardless of the original epoch interval, and the original epoch interval of the CORS stations could be anywhere between 1 and 30 seconds, OPUS-RS was designed to work with that in mind. In other words, OPUS-RS processes at 30-second intervals, regardless of the epoch interval of the CORS reference stations or the rover file. So, unless the user has a specific need for collecting data at a shorter epoch interval (post-processing your own data), or you are convinced that more is always better…just collect at 30-seconds.
OPUS Usage: Currently there are about 15,000 OPUS solutions per month…In the first two weeks after OPUS-RS was announced there were about 2000 OPUS-RS solutions produced.
Conclusion
Even though OPUS-RS is still very young, it is clear that it will mature with age and have a significant impact on how surveyors access the National Spatial Reference System. Improvements will continue to be made; accuracies and confidence indicators will no doubt increase.
The OPUS-RS web page states: "In spite of our efforts to test OPUS as thoroughly as practical, new problems will almost certainly occur. Please contact OPUS with any problems you believe you see and they will be addressed as quickly as possible."
In my words this means… OPUS-RS is still a baby, and could behave badly from time to time, throwing the occasional tantrum. Be patient, vigilant, and have that cup of coffee.
Dan Martin is a Physical Scientist with the National Geodetic Survey, and the NGS Geodetic Advisor for the State of Vermont.
A 419Kb PDF of this article is available by clicking HERE