Following the Coordinate Through the Software
By the time a coordinate reaches the screen, it has already passed through more stages than this chapter can list from memory alone: satellite observations, base observations, RTK differencing, a raw geocentric solution, a reference frame, an epoch, a translation into latitude and longitude, a map projection, and sometimes a local project grid. Field software is the last set of hands this coordinate passes through, and it is not a passive one.
Field software is not simply a screen that displays a coordinate. It is one more active participant in the chain, capable of applying its own projection, its own geoid model, and its own local calibration, sometimes without the user ever seeing that decision being made.
Every Application Makes Its Own Assumptions
Two different field applications, receiving the exact same raw RTK solution from the exact same receiver, are not guaranteed to display the same final coordinate. One application's project settings may call for an automatic State Plane projection. Another may be configured to display raw latitude and longitude by default, projecting only when explicitly told to. A third may have a project-specific localization already loaded, applying it to every incoming position before anything reaches the screen.
When two applications disagree on a displayed coordinate, the receiver and the RTK solution are rarely the first place to look. The disagreement more often lives in what each application assumed it was supposed to do with that solution.
A Habit This Companion Keeps Returning To
The remedy is the same one this entire series keeps returning to: write down the processing path explicitly, rather than trusting that it happened correctly by assumption. What reference frame did the receiver produce. What projection, if any, was applied, and by which piece of software. Was a local calibration involved, and where. A coordinate that can answer each of those questions is a coordinate that can actually be trusted, or corrected, when something looks wrong.
Two field applications display slightly different coordinates for the same RTK fix. Is the receiver the most likely suspect? Rarely. It is usually more productive to ask what each application assumed about reference frame, projection, and local calibration before comparing the numbers at all.
Field software actively participates in the coordinate chain, capable of applying its own projection, geoid model, or local calibration. Two applications receiving the same RTK solution can disagree not because either one is broken, but because each one made a different assumption about what still needed to be done to that coordinate.
That is where this companion ends: not at the receiver, but here, at the very last hands a coordinate passes through before a person ever sees it. Every stage along the way, from a satellite's broadcast to a piece of field software's own quiet decisions, has been a place where the description of a point changed without the point itself ever moving. That was the question this companion opened with, and it holds all the way to the screen.