Beyond WGS84: Why a Perfect GNSS Fix Can Still Put You Off the Map

A perfect RTK fix can still appear in the wrong place if your receiver, correction service, map layer, and downstream software are not using the same coordinate frame.

In a previous issue of this series, we walked through correction stream access through NTRIP and how to configure a client connection. One detail is easy to overlook: selecting a mountpoint is not just a routing choice. Different mountpoints can deliver corrections referenced to different coordinate frames. WGS84, NAD83, and ITRF2020 may all appear on the configuration screen, and each can produce a subtly different position output.

Most developers make this choice once and never think about it again — until a position lands a meter from where it should be, a height reading is off by thirty meters, or a track log that looked perfect on the bench drifts off-road in the field. Those are not always RF or accuracy problems. They are often coordinate-frame problems, and they are preventable.

This issue is dedicated to the layer of the stack that sits beneath every latitude/longitude value you will ever work with: the Geographic Coordinate System. If you are validating receiver behavior on a real device, the related setup path usually starts in the Kalmix documentation center and continues into the receiver-specific protocol and integration notes.

What Is a Geographic Coordinate System?

A Geographic Coordinate System (GCS) is a reference framework based on a mathematical model of the Earth's shape, used to express positions on the Earth's surface as angular coordinates — latitude and longitude. The key word is framework. A latitude/longitude pair is incomplete unless you know which GCS it belongs to. The same physical point on Earth will have slightly different coordinates in WGS84, NAD83, and CGCS2000. Depending on location, epoch, and precision target, that difference may range from centimeters to more than a meter.

Every GCS is built from a small set of assumptions about the Earth and how positions should be expressed:

• Ellipsoid / datum: The mathematical surface used to approximate the Earth's shape, defined by its semi-major axis, flattening ratio, and relationship to the Earth's center of mass.
• Prime meridian: The zero-degree longitude reference line. In most modern systems, this is the Greenwich Meridian.
• Angular unit: How angles are expressed. Decimal degrees are standard in most developer contexts, while degrees-minutes-seconds and degrees-decimal-minutes still appear in hardware outputs and legacy systems.

WGS84, NAD83, ITRF, and Local Datums

Understanding the classification logic explains why so many coordinate systems exist — and why choosing the wrong one introduces error even when your GNSS hardware is working properly.

Geocentric Datums

Each major GNSS constellation publishes its own geocentric datum, and while WGS84, CGCS2000, GTRF, and PZ-90.11 are closely aligned in modern realizations, treating them as identical breaks down once accuracy targets reach the centimeter level. The constellation-level datum map is:

Note: In sub-meter applications, these differences may be smaller than your error budget. In centimeter-level workflows, they must be documented and transformed explicitly.

For developers, three global or near-global frames appear repeatedly in GNSS and GIS workflows:

• WGS84 is the reference datum for GPS and the default coordinate system for GNSS output worldwide. Most GNSS receivers output NMEA positions in WGS84 unless configured otherwise. In GIS software, it is commonly identified as EPSG:4326.
• CGCS2000 is the official geodetic datum of China and the reference frame for BeiDou. Its ellipsoid parameters are very close to WGS84. CGCS2000 is a geocentric datum; it is not an encrypted or obfuscated map coordinate system.
• ITRF — the International Terrestrial Reference Frame — is the high-accuracy global reference framework maintained by the International Earth Rotation and Reference Systems Service. ITRF2020 is the current realization commonly referenced by precision GNSS workflows.

The practical differences are easier to keep straight in a decision table:

If you are comparing coordinate-frame behavior across live receiver logs, store the receiver's NMEA output together with the correction mountpoint, base-station ID, and firmware configuration. For SCOUT PRO integrations, the receiver-side references are collected in the product documentation.

Regional Datums

A regional datum optimizes fit for a specific geographic area by anchoring the ellipsoid to stable points on a local tectonic plate. This improves local consistency at the cost of global portability. The motivation is plate motion: a point fixed to the ground in Seattle does not remain stationary relative to a global Earth-centered frame. A regional datum fixed to the North American plate moves with the plate, keeping local coordinates stable over time.

Regional datums exist because the Earth is not static: NAD83 anchors North American coordinates to the North American plate, ETRS89 anchors European coordinates to the Eurasian plate, and systems such as JGD2011 reflect regions where crustal motion and seismic events make coordinate maintenance more dynamic.

• NAD83 is the official horizontal datum for U.S. federal surveying and mapping, covering North America. The current realization, NAD83(2011), uses the nationwide CORS network as its physical foundation.
• ETRS89 is the European Terrestrial Reference System, fixed to the stable Eurasian plate. It diverges from WGS84 over time because Europe and the global ITRF frame are not static relative to each other.
• JGD2011 is Japan's national coordinate system. Japan has also moved toward dynamic datum handling because local crustal motion and seismic events make static coordinates difficult to maintain over time.

The pattern is consistent: regional datums anchor to local tectonic stability and absorb plate motion into the coordinate definition. Dynamic frameworks — where time is treated as an explicit coordinate variable — are the direction high-precision geodesy is moving.

Three Heights, One Position

Altitude is where many GNSS integrations become confusing, because the height a receiver reports is rarely the same as the elevation shown on a map or engineering drawing. There are three distinct height concepts at play, but the NMEA GGA sentence only directly exposes two of them:

• Field 9 — MSL altitude (H): In standard NMEA GGA, this field is reported as altitude above mean sea level. In practice, the receiver derives it by applying an internal geoid model or configured height handling to the GNSS solution.
• Field 11 — Geoid separation (N): The separation between the mathematical ellipsoid and the physical geoid, based on the receiver's internal model.

To recover the pure ellipsoidal height (h) — required for high-precision workflows such as applying a formal geoid model — you must add the two fields together:

h = Field 9 + Field 11
  = ellipsoidal height

The conceptual relationship remains:

H = h − N
  = orthometric height
  where N = geoid separation

If your parser reads altitude from GGA, make sure it also stores the geoid separation field. The detailed field behavior is covered in the NMEA GGA parsing guide. For receiver-output troubleshooting on Kalmix hardware, the SCOUT PRO protocol reference is the natural next reference.

WGS84: The Default Language of GNSS

WGS84 has been the reference datum for GPS since 1984; in GIS software it is registered as EPSG:4326 and remains the default coordinate frame for most GNSS NMEA output worldwide.

Most GNSS receivers output NMEA positions in WGS84 by default. When integrating field-ready RTK hardware such as the Kalmix SCOUT PRO, document the receiver output format, correction source, and coordinate frame together.

If your system consumes receiver output directly, document both the NMEA fields and the coordinate frame in your integration notes. For Kalmix receivers, start from the documentation center before wiring the output into a control stack or map layer.

Can an RTK receiver output NAD83 NMEA? In standalone GNSS mode, most receivers output WGS84 unless the vendor exposes a datum configuration command; in RTK mode, the safer assumption is that the rover solution follows the correction stream's reference frame.

Two exceptions matter. First, some chipsets support proprietary commands to switch the output frame at the receiver level. Second, in high-precision RTK mode, the output frame is often determined by the reference station's datum. That is the mechanism behind correction-service mountpoint selection. RTK positioning is fundamentally relative: the rover's position is computed with respect to the base station. If a CORS network broadcasts corrections in NAD83(2011), the rover output should be treated as NAD83(2011), regardless of the GNSS chip's normal single-point default.

For robot and machine-control deployments, this is why RTK should be treated as a system interface rather than a black-box accuracy feature. See our RTK GPS for robotics and outdoor robot navigation guide for the broader localization-stack view, and treat correction stream access as a separate interface decision.

In GIS software and APIs, WGS84 geographic coordinates are commonly identified as EPSG:4326.

Why a Perfect RTK Fix Can Still Look Wrong on a Map

An RTK Fixed status proves that the rover has resolved its carrier-phase solution relative to the correction source. It does not prove that the resulting coordinates match the map layer, parcel file, engineering drawing, or farm-management boundary that will consume them later.

A common failure pattern is quiet and expensive. A rover logs a clean boundary with centimeter repeatability, the acreage number looks stable, and the track displays smoothly. Later, the same polygon lands beside the parcel line because the correction stream, GIS layer, or export path used a different coordinate frame. In field work, field boundaries can shift when coordinate frames differ, even when the GNSS fix itself was real.

The debug question is therefore not only “Was the fix good?” It is also “Good in which frame, at which epoch, and for which downstream map?”

The U.S. Coordinate Ecosystem

Three coordinate systems define almost every centimeter-grade positioning project in the United States: NAD83 anchors horizontal positions to the North American plate, NAVD88 defines the vertical reference for elevations, and ITRF provides the high-precision global backbone that ties the U.S. ecosystem to the rest of the world.

NAD83 — The Official U.S. Horizontal Datum

NAD83 is the horizontal datum used for U.S. federal and state surveying and mapping, covering the United States, Canada, Mexico, and Central America with the GRS80 ellipsoid. The current widely used realization, NAD83(2011), was finalized using a nationwide adjustment of CORS stations.

NAD83(2011), commonly registered as EPSG:6318 in GIS workflows, is realized through the U.S. CORS network of permanently installed GNSS reference stations. When a precision correction service delivers NAD83 output, positions are computed relative to those station coordinates.

The CORS network — Continuously Operating Reference Stations — is the physical realization of NAD83 in the United States. The WGS84–NAD83 gap is time-dependent. NAD83 is fixed to the North American tectonic plate, while WGS84 follows the global frame more closely. The plate moves relative to ITRF over time, so the offset between WGS84 and NAD83 coordinates for the same physical point changes continuously. Any conversion between the two at centimeter-level precision requires an epoch — a reference date.

ITRF — The High-Precision Backbone

ITRF is maintained by the International Earth Rotation and Reference Systems Service using a global network of space-geodesy observations. Where WGS84 is defined and controlled for GPS operations, ITRF is independently verified against a global observation network and represents the international scientific standard for high-accuracy positioning.

ITRF is the global backbone; WGS84 is operationally aligned to ITRF for GPS use; NAD83 is anchored to the North American plate and drifts relative to ITRF over time. The chain matters: a CORS correction stream broadcast in NAD83(2011) cannot be reinterpreted as ITRF2020 without an epoch-aware transformation.

For autonomous navigation, precision agriculture, robotics, and centimeter-level machine-control applications, the specific ITRF realization your correction service outputs — and its associated epoch — is a system-design parameter. The ITRF–NAD83 relationship carries the same epoch dependency described above, accumulating error when the wrong frame or epoch is assumed.

When the correction stream itself becomes the suspect, read it together with the RTCM correction-data workflow. RTCM content, NTRIP delivery, base-station coordinates, and receiver output should be checked as one chain.

NAVD88 — The U.S. Vertical Datum

Recall the earlier height issue: GGA Field 9 is a receiver-estimated MSL altitude using an internal geoid model. For precision elevation work in the U.S., that is not the final answer.

NAVD88 — the North American Vertical Datum of 1988 — is the U.S. vertical reference datum managed by the National Geodetic Survey. When a U.S. topographic map, construction drawing, or flood-zone designation specifies an elevation, that number is commonly referenced to NAVD88.

GEOID18 is the NGS hybrid geoid model used to convert GNSS ellipsoidal heights to NAVD88 orthometric elevations in covered U.S. regions. This workflow requires compatible horizontal datum and epoch handling. NGS provides official tools such as NCAT for coordinate transformations and VDatum for vertical datum conversions.

NATRF2022 and Future Datum Changes

NATRF2022 and NAPGD2022 are part of the National Geodetic Survey's planned modernization of the U.S. National Spatial Reference System. As of June 2026, the modernized NSRS is still being rolled out and tested through NGS beta products, while NAD83 and NAVD88 remain the official NSRS references. The practical message for system designers is simple: do not hard-code “NAD83 forever” or “NAVD88 forever” into a product, database, or export format.

For a deployed GNSS workflow, future datum changes are a data-governance problem as much as a geodesy problem. Store the datum realization, epoch, vertical datum, units, and transformation method with the coordinates so a future conversion can be audited instead of guessed.

Map SDKs and Coordinate Compatibility

The most popular web mapping SDKs and GIS platforms generally accept WGS84 (EPSG:4326) coordinate input by default, while professional GIS tools may require explicit datum, projection, and vertical reference configuration. The common web and GIS defaults are:

The most common EPSG confusion in web mapping: EPSG:4326 and EPSG:3857 are not the same thing.

• EPSG:4326 is WGS84 — latitude and longitude in decimal degrees. This is what GNSS receivers commonly output and what most map SDK APIs accept as input.
• EPSG:3857 is Web Mercator, the projected coordinate system used internally by many tile renderers. Coordinates are in meters and do not resemble degrees. Accidentally passing EPSG:3857 or State Plane values into an API expecting EPSG:4326 may not crash the application; it may simply plot the point near Null Island or throw an out-of-bounds error.

For high-precision applications, centimeter-level systems typically feed coordinates directly into the navigation or control stack. The coordinate frame is configured at the correction-service and system level. Map SDKs used only for visualization may still expect WGS84 lat/lon even if the precision workflow behind the scenes uses NAD83 or ITRF.

Coordinate Systems in Field Mapping Workflows

Field mapping makes coordinate-frame mistakes visible because it combines several data sources at once: receiver output, correction-service metadata, parcel or county GIS layers, farm-management software exports, and sometimes an offline map app. Each layer can be internally consistent and still disagree with the others.

The safest workflow is boring on purpose. Decide the target coordinate reference system before capture, record the correction mountpoint and datum with the job, export in a format that preserves CRS metadata, and archive the raw receiver log when the boundary or acreage value may be reused later.

Conclusion

Coordinate-frame alignment belongs in the same system-design conversation as antenna placement, multipath mitigation, correction-service selection, and receiver logging. Define the output frame, document it, and verify it at every integration boundary: the correction-service mountpoint, the GNSS output parser, the GIS layer, and the upstream data consumer.

A frame mismatch that slips through undetected rarely announces itself clearly. It appears in production as a position that is almost right, in a way that is difficult to trace.

When you find yourself back at the mountpoint selection screen, scrolling past WGS84, NAD83(2011), and ITRF2020, the choice should no longer feel like metadata. It is part of the positioning system.

Frequently Asked Questions

Zero Jiang

Founder, Kalmix

Zero Jiang founded Kalmix to make practical RTK and receiver-integration knowledge accessible to engineers working in field robotics and machine automation.