Site Calibration (Localization) Explained: Tying GNSS to Local Grid

You show up with an RTK rover reading centimeter-accurate coordinates, occupy a control monument from the plat, and the numbers do not match. Not by a little: sometimes by a few tenths, sometimes by meters. This is normal, and site calibration (also called localization) is the standard fix. Here is what is actually happening and how the math works.

Why RTK coordinates rarely match project coordinates

An RTK rover measures positions in the reference frame of its corrections. Plat and project coordinates come from somewhere else entirely: an older survey, a state plane projection with a local scale factor applied, an assumed coordinate basis a previous crew set up, or a datum realization that has since shifted. Common causes of mismatch:

• Different datums or epochs. RTK network corrections generally arrive in ITRF2020 at the current epoch, while most US project plans are on NAD83(2011) epoch 2010.00. Those frames differ by roughly 1 to 2 meters.
• Ground vs. grid. Project coordinates are often "ground" coordinates, scaled from state plane grid so distances match what a tape or total station measures on the surface.
• Assumed or truncated coordinates. Many sites use a local basis like 5000, 5000 with an arbitrary rotation.
• Legacy control. The plat's control may carry the errors and adjustments of whoever set it, decades ago.

A calibration does not ask why the systems disagree. It measures the disagreement at known points and builds a transformation that maps your GNSS coordinates into the local system.

What a site calibration actually computes

Horizontal: a four-parameter Helmert transformation

Horizontally, the standard model is a 2D similarity (Helmert) transformation with four parameters: two translations (shift in northing and easting), one rotation, and one scale factor. You occupy control points with the rover, pair each observed GNSS position with its published local coordinate, and the software solves for the four parameters by least squares across all the pairs.

Two point pairs is the mathematical minimum for a unique solution, but with only two you get zero redundancy: the fit will be "perfect" and tell you nothing about whether either point is wrong. Three pairs gives you a first check; four or more is good practice, because the least-squares solution can then expose an outlier.

Vertical: an inclined-plane fit

Vertically, the usual model is a tilted plane fit through the elevation differences at your control points. One benchmark gives a constant shift; three or more let the software solve a plane that can tilt slightly in both directions, absorbing local geoid slope and any systematic tilt in the legacy vertical control. The vertical fit is solved separately from the horizontal one.

Residuals: how to judge the fit

After solving, the software reports a residual for each control point: the leftover disagreement between the transformed GNSS position and the published coordinate. Read them like this:

• Small, uniform residuals (comparable to your RTK noise, a centimeter or two horizontal) mean the two systems really are related by a similarity transformation. Good fit.
• One large residual among small ones usually means that single point is the problem: a disturbed monument, a bad occupation, a typo in the published coordinate. Re-observe it, and if it stays bad, exclude it and re-solve rather than letting it drag the whole fit.
• Residuals that are all moderately large suggest the local system is internally distorted and no rigid transformation can fit it. Tighten expectations or investigate the control's pedigree.

Also glance at the solved scale factor. A value far from 1 (beyond what a ground-to-grid scale explains) is a red flag, often a units mixup; see the PNEZD article for the US survey foot vs. international foot trap that produces exactly this symptom.

Choosing control points: surround the work

Calibration quality depends more on geometry than on math. The rules of thumb:

• Surround the site. Put control pairs around the perimeter of the work area so every shot you take falls inside the figure they form.
• Never extrapolate. A calibration is an interpolation tool. Inside the control polygon, errors stay bounded by the residuals; outside it, the rotation and scale errors grow with distance, and a fit that looked great can be badly wrong a few hundred meters beyond your last control point.
• Spread the vertical control too. An inclined-plane fit hinged on benchmarks clustered in one corner will tilt unpredictably across the far side of the site.
• Use recoverable, trustworthy monuments, and observe each with a fixed RTK solution, ideally checking with a second occupation. (Not sure what "fixed" means here? Start with our RTK GNSS basics article and the NMEA fix-quality explainer.)

When to use a published CRS instead

A site calibration is the right tool when the target system is local, assumed, or of unknown pedigree. It is the wrong tool when the project is simply on a well-defined published coordinate reference system, such as a state plane zone on NAD83(2011). In that case, configure the app to use the published projection and datum transformation directly. A projection is exact and defined everywhere; a calibration is an empirical patch that is only valid inside its control. Calibrating "onto" state plane when you could just select state plane adds error and hides the real relationship.

Datum and epoch pitfalls

Even with clean math, frames can bite you:

• Know your correction source's frame. Network RTK typically delivers ITRF2020, current epoch. If your app assumes those coordinates are NAD83, everything is silently shifted 1 to 2 meters before you ever calibrate. A calibration will absorb that shift, which is convenient, but it means your calibration is only valid while you use the same correction source.
• Epochs move. Plate motion means an ITRF coordinate observed today differs from one observed years ago. A calibration observed and used within the same project window is fine; reusing an old calibration file with a new correction source or years later is asking for a surprise.
• Modernization is landing. NATRF2022 and the NSRS modernization are arriving in 2026, which will change the frames US projects are quoted in. Record datum and epoch with every dataset so future you can reconcile them.

Site calibration is one of the features most field apps place behind a paid tier. Open Survey, which is in development, plans to include localization free and open source, with datum and epoch stamped on every export.