Network RTK With a Failing Check Shot and a Grid-versus-Ground Conflict
An 18-acre topographic survey in Monmouth County is being collected with a network-RTK rover using a real-time correction service. The receiver reports horizontal residuals of 0.02 to 0.04 ft and vertical residuals of 0.05 to 0.07 ft. The project is referenced to the New Jersey State Plane Coordinate System (NAD83(2011)) and NAVD88 using GEOID18. A localization was computed on three NGS-published monuments. Two check shots on a fourth NGS monument came in 0.14 ft horizontally and 0.31 ft vertically from the published values. Under a stand of oaks on the north line, PDOP climbed to 5.8 and several shots were stored with 0.09-ft vertical residuals. Separately, the crew taped between two found property corners and got exactly 500.00 ft, while the RTK-derived state-plane distance between the same corners is 499.94 ft. The client wants both a grid-based surface model and a ground-based stakeout file.
1. Do you accept the RTK work based on the reported residuals, or reject it? Diagnose the check-shot discrepancy and describe what you would do before releasing any coordinates.
Read the worked answer
Residuals are precision, not accuracy. The 0.02–0.07 ft figures describe internal agreement among satellites, not agreement with the datum. A 0.14-ft horizontal and especially a 0.31-ft vertical check-shot miss is well outside what good RTK should deliver against a stable published monument.
Rank the likely causes.
- Datum/epoch mismatch: the published coordinate may be in a realization or epoch that differs from the NAD83(2011) frame you are working in, or the monument may have moved.
- Localization geometry: three points is the minimum, and three points in a line or clustered give a weak, overfit solution. A residual that small in the software can hide a real tilt.
- Geoid model: a few centimeters between GEOID12B and GEOID18 is normal, but 0.31 ft is not; check which model the receiver and the office software are using.
- Antenna height or measurement method entered incorrectly, or a slant-height entry used where a vertical height was required.
- Multipath at the check point itself.
Actions. Pull the datasheet and confirm the realization, epoch, and elevation source. Review the localization residuals and drop or add control to improve geometry (a fourth well-distributed point). Run a differential level or total-station tie between the check monument and a second benchmark to see whether the monument or your solution is at fault. Do not paper over the problem by applying a 0.31-ft shift to everything - that assumes the reference is right and your solution is wrong, which is exactly what has not been established.
Low-PDOP shots. Shots with 0.09-ft vertical residuals under canopy should be re-observed (occupation time, different time of day) or collected by total station from a good RTK/local control point. A DTM built on marginal verticals becomes a grading problem later.
2. Reconcile the 500.00-ft tape distance with the 499.94-ft grid distance. Given a state-plane scale factor of 0.9999 at this location and an average ellipsoid height of 85 m, compute the combined factor and show the conversion both ways.
Read the worked answer
Grid versus ground is expected, not an error. The tape measures ground distance; the RTK coordinates are grid (state plane). The two differ by the combined factor.
Elevation factor. Using R = 6,371,000 m and h = 85 m:
EF = R / (R + h) = 6,371,000 / 6,371,085 = 0.9999867
Combined factor.
CF = SF × EF = 0.9999 × 0.9999867 = 0.9998867
Ground to grid.
Grid = Ground × CF = 500.00 × 0.9998867 = 499.943 ft
That is 499.94 ft, matching the RTK-derived distance to the hundredth - strong evidence the GNSS work is internally sound in the horizontal, whatever the vertical issue is.
Grid to ground (what the stakeout file needs):
Ground = Grid / CF = 499.94 / 0.9998867 = 499.997 ft
Practical consequences.
- Stakeout: compute in grid, but hold the ground distance. Either divide grid distances by CF or build a site calibration; never hand a grid distance to a crew taping on the ground.
- Area: areas scale by CF² = 0.99977. On 18 acres that is about 0.004 acre - trivial here, but state it as measured area versus record area rather than silently mixing frames.
- State the frame and the factor or calibration on every deliverable so the next surveyor can reproduce your work.
3. The vertical check remains 0.25 ft off even after the localization is rebuilt with four points. How does that change what you deliver?
Read the worked answer
If horizontal checks are good but verticals are consistently off by a nearly constant amount, suspect the vertical reference rather than the GNSS geometry: a superseded or disturbed benchmark elevation, a geoid model mismatch between field and office software, or an antenna-height error. A constant offset across many independent checks points to the reference; a random scatter points to observation quality.
Because the offset is systematic, it cannot be averaged away, and it cannot be corrected by subtracting 0.25 ft from every shot until the source is identified. Do one of two things: (1) run differential levels from a benchmark of known quality and tie your GNSS-derived elevations to that, or (2) hold the GNSS verticals as relative only, and label the surface accordingly.
Deliverables: state the vertical datum, the geoid model, the control used, the check-shot results, and the fact that the vertical is unverified pending resolution. If the DTM will drive grading or drainage design, do not release it as NAVD88 until the check is resolved. A 0.25-ft vertical error is a real quantity of dirt and a real drainage problem.