Although I don’t normally write about National Geodetic Survey (NGS) software programs, I’m making an exception in this column.
OPUS-RS (Online Positioning User Service-Rapid Static) is an operational program available to GPS surveyors atwww.ngs.noaa.gov. The inspiration for writing on this topic came from an old friend. Charles R. Schwarz was an office mate of mine when we were graduate students at The Ohio State University. In August 2008, the American Society of Civil Engineers’ “Journal of Surveying Engineering” published an article by Schwarz that goes into great detail on the logic used in developing this software, which is something users can’t find easily.
In 1997, I attended the American Congress on Surveying and Mapping (ACSM) conference in Seattle and listened to a presentation by Charles Trimble, then president of Trimble Navigation. Trimble referred to a (then) recent equipment survey by POB in which 41 percent of respondents said they were going to purchase a total station in the next year, and another 41 percent said they were going to purchase survey-grade GPS receivers. This was the first time in POB’s survey history that predicted GPS sales matched predicted total station sales.
GPS is a geodetic positioning system, and with the increase in GPS sales, more land and construction surveyors had to upgrade to work in geodetic coordinates. As it is today, the horizontal coordinate system at that time was the North American Datum of 1983 (NAD 83). There were many different adjustments to NAD 83 because each state or group of states had its own high accuracy reference network (HARN), and it was necessary to date these networks, e.g., NAD 83 (1992). However, this nomenclature could be confusing; for example, both Arizona and New Mexico were referenced NAD 83 (1992), but even though the two states had a common border, their networks were from two different adjustments.
In the mid-1990s, NGS established a network of continuously operating reference stations (CORS), which today has expanded to more than 1,200 stations and extends far beyond the boundaries of North America. Users cannot occupy these stations with their own receivers, but they can access the CORS data at a later date. The CORS are dual-frequency carrier-phase receivers from different manufacturers that collect code and phase data, convert it to the RINEX format, and send this data daily to NGS in Silver Spring, Md. Because the CORS network is adjusted daily, it uses a different notation than other NAD 83 stations: NAD 83 (CORS).
GPS surveyors in the 1990s had two or more receivers and observed a minimum of 15 to 30 minutes per station. They then leapfrogged to other stations and performed a network adjustment using software provided by the GPS equipment manufacturer. The network, in most cases, was tied to the state HARN.
In his article, Schwarz notes that the NGS developed a program in 1999 called PAGES (Program for Adjustment of GPS Ephemerides) for the “computation of both orbits and positions from GPS tracking data for many years.” Schwarz explains that this program became the major processing engine for the NGS OPUS utility. “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.”
I’d be preaching to the choir if I gave a detailed description of OPUS; it’s widely used by surveyors. In a telephone conversation with Dave Doyle, senior geodesist at NGS, he told me that the organization is averaging 16,000 to 17,000 OPUS solutions per month, and some months, it’s more than 20,000 solutions. Basically, a surveyor positions his or her receiver over a point of unknown position, gathers data for a minimum of two hours, logs on to the OPUS utility on the NGS Web site, answers a few questions, then sends the receiver data to NGS. The data file is then processed with respect to three CORS sites. I’ve been told by users that the results from the adjustment can be received in a few minutes, but at press time I saw a notice on the NGS Web site that users may have to wait up to 24 hours for a solution.
If data collected by a surveyor is sent immediately after being collected (or within 24 hours of collection), the data will be processed by the predicted orbit, called the ultrarapid orbit. If the surveyor waits 24 hours to transmit the data, it will be processed by the rapid orbit, which is more accurate and gives a better solution. If the data is transmitted a week after collection, it will be processed by the precise orbit, which sometimes gives even better results. In most cases, solutions using the rapid orbit are excellent.
OPUS has changed the way GPS surveyors operate. Now they can forget the network adjustment software. They go into the field, establish the position of a point using OPUS, then use that point for the base station of their RTK system and complete the survey using RTK. If it’s necessary to extend the RTK network, they use OPUS to get another position and use this point as the new RTK base station.
Before the readjustment of NAD 83 in 2007, surveyors had to be careful in labeling their surveys. If you referenced the survey to a state HARN, your survey coordinates were in NAD 83 (year of HARN adjustment). If you used OPUS for your reference, your survey coordinates were in NAD 83 (CORS). The 2007 readjustment changed that because the entire NAD 83 network was adjusted to the CORS network.
Subsequent developments at NGS have continued to change the way surveyors operate. Referring again to Schwarz’s article:
At a series of continuous operating reference stations (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) for short data sets using reference stations from the NGS CORS archive. 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 are much longer.
Research conducted by the satellite positioning and inertial navigation (SPIN) group at the Ohio State University indicated that the challenge could be met, at least for areas in which reference station data is well behaved. The new NGS rapid static GPS software RSGPS is based on the ideas and methodology developed by the SPIN group and implemented in its multipurpose GPS (MPGPS) software. RSGPS became the major processing engine for the OPUS-RS web utility, which became operational in Jan 2007.
When you log on to the NGS Web site and click on OPUS, a form gives users the option to “upload to OPUS” or “upload to OPUS-RS.” Relatively speaking, OPUS is an easy solution; a good static solution is possible with a minimum of two hours of data. In contrast, the processing software has to do much more work for OPUS-RS solutions. With OPUS-RS, your receiver is referred to as the “rover.” The NGS software performs a network adjustment of the three CORS to determine reference station coordinates, tropospheric refraction parameters and ionospheric delays. The software then uses these parameters and goes to the rover mode of the adjustment. A plane is formed from the reference network to the rover, and the ionospheric delay and tropospheric refraction are interpolated. These values are held as constraints in the solution of the rover position. The same OPUS data submission rules apply to OPUS-RS outlined above.
Schwarz’s article uses data from Ohio and Florida where the rover was inside the figure of reference stations--a triangle in Ohio and a four-sided figure in Florida. (It is extrapolation, not interpretation, if the rover is outside the reference station figure.) The study concluded:
The rapid static GPS method can be used to find the position of unknown rover stations with an accuracy of a few centimeters using as little as 15 min of tracking data and reference stations separated by 200 km. However, the rover data set must be carefully conditioned to ensure it is free of cycle slips, short data spans, and excessive multipath effects.
OPUS-RS has its limitations. The rover must be in a location that is surrounded by CORS sites. Many areas of North America do not have a dense enough CORS network. For example, where I live in southern New Mexico is one of the areas without a dense CORS network. You can submit more than 15 minutes of data to OPUS-RS, but if the geometry is weak, the solution will also be weak.
This scenario might change if more CORS stations are added; however, there is talk of reducing the number of operational CORS. Still, considering the rapid advances in technology within the past few years, it is likely that OPUS-RS will provide enhanced functionality in the future.
1- “Heuristic Weighting and Data Conditioning in the National Geodetic Survey Rapid Static GPS Software,” by Charles R. Schwarz, Journal of Surveying Engineering, ASCE, August 2008