Tier Five: Short Static Log and OPUS-RS
Every method so far has solved a position in real time, or close to it. This tier changes that entirely: log raw satellite observations for a relatively short, unattended session, and let a rapid-static processing service resolve the position afterward, against better information than any real-time method has access to.
A rapid-static service, most notably NGS's OPUS-RS, processes a comparatively short static log, often under an hour, using double-differenced carrier-phase solutions against a small network of nearby continuously operating reference stations, producing an accuracy and reliability that a same-length real-time session generally cannot match. This depends entirely on nearby CORS coverage; OPUS-RS requires several reference stations within roughly 250 kilometers of the site and reasonably close to it geometrically, so it can fail outright in areas the network doesn't reach well.
Why a Short Log Can Outperform a Longer Real-Time Session
A rapid-static service is not simply averaging a short session the way plain survey-in would. It performs a double-differenced network adjustment, differencing the logged observations against several real, nearby reference stations at once rather than just one, canceling shared error the same way RTK does against a single base, while also drawing on more refined satellite information than what was available live in the field, the same principle behind the accuracy advantage of delayed processing discussed at length in the fourth companion of this series.
Rapid-static processing borrows RTK's own error-cancellation trick, double-differencing against a small network of real reference stations rather than one, and combines it with the accuracy advantage of waiting for better satellite information, rather than choosing between the two.
Where This Method Actually Shines
This approach performs best reasonably near a continuously operating reference network, since it depends on nearby stations to difference against, the same dependency RTK itself has on a nearby reference. A site far from any such network sees this method's advantage shrink, in exactly the same way RTK's own accuracy degrades with baseline length.
A rapid-static service is not simply post-processed survey-in. It differences against real, nearby reference stations rather than averaging an isolated, uncorrected position, which is why it can outperform a same-length real-time session rather than merely matching one after a delay.
A Genuine Middle Ground
This method demands more patience than any real-time establishment covered so far, an unattended log rather than an immediate answer, and considerably less than the full month-long commissioning still ahead. For a project with reasonable network coverage nearby and a tolerance for a short processing delay, it is often the best return on effort in this entire companion.
A project sits within good reach of a continuously operating reference network and can tolerate a short delay before a base coordinate is finalized. Is real-time network RTK establishment still the better choice? Not necessarily. A short static log processed through a rapid-static service can outperform it, for a modest cost in immediacy.
A rapid-static service processes a relatively short, unattended static log against nearby reference stations, combining RTK's own differencing advantage with better satellite information than real time provides. It performs best near existing reference infrastructure, and offers a strong balance of effort and accuracy for many projects.
Extending that same static log considerably longer, and processing it against even more refined satellite products, is the next, more rigorous step in this companion's ladder.