RTK Coordinate Systems & Datums Explained

Which regional datum each RTKdata mountpoint delivers, and how to resolve datum mismatches, ellipsoidal vs orthometric heights and survey feet settings.

RTKdata corrections are available in multiple geodetic reference frames. The mountpoint you choose determines the coordinate system of the corrections streamed to your device.

---

Mountpoints

Mountpoint names are case-sensitive and must be entered in ALL CAPS. The table below covers the reference frames documented for RTKdata corrections; a source table scan in your NTRIP client can show further entries. A local coordinate system name is not a mountpoint. Typing one into that field, for example OSGB36, does not produce a transformation, it produces no corrections at all.

Mountpoint	Details
AUTO	Regional Geodetic Coordinate System (RGCS): automatically delivers corrections in your region's local datum. Recommended for most workflows.
AUTO_ITRF2020	ITRF2020, delivered at the current epoch
AUTO_ITRF2014	ITRF2014, delivered at the current epoch
AUTO_WGS84	WGS84(G2139) in the middle of the current year (e.g., 2025.5 for year 2025, 2024.5 for year 2024)

Recommendation: Use AUTO unless your project specifically requires a global reference frame. AUTO eliminates the most common source of coordinate shifts by delivering corrections in your regional datum.

---

Regional Geodetic Coordinate System (RGCS)

When you connect with the AUTO mountpoint, RTKdata automatically selects the correct regional geodetic coordinate system based on your location. The table below shows exactly which datum and epoch is delivered per region.

#	Geodetic Coordinate System Name	Epoch #	Effective Regions
1	NAD83(2011)	2010.0	USA
2	NAD83(PA11)	2010.0	USA Hawaii
3	NAD83(MA11)	2010.0	Guam
4	NAD83(CSRS)v7	2010.0	Canada
5	ETRS89, realization ETRF2000	2010.0	Europe
6	GDA2020(2020.0)	2020.0	Australia
7	NZGD2000(2000.0)	2000.0	New Zealand
8	TUREF(2005.0)=ITRF96(2005.0)	2005.0	Turkey
9	ITRF2008(2005.0)=ITRF2008(2005.0)	2005.0	India
10	ITRF2008(2011.811)	2011.811	Egypt
11	NGD2012(2012.0)=ITRF2008(2012.0)	2012.0	Nigeria
12	PGD2020=ITRF2014(2020.044)	2020.044	Philippines
13	ITRF2014(2010)	2010.0	Mexico
14	ITRF2014	current epoch	Kenya
15	CGCS2000(2000.0)=ITRF97(2000.0)2	2000.0	China
16	JGD2011(2011.3945)=ITRF2008(2011.3945)	2011.3945	Japan
17	IGRS2013(2012.0)=ITRF2008(2012.0)	2012.0	Indonesia
18	ITRF1991(1994.0)	1994.0	South Africa
19	WGS84(G730)(1994.0)	1994.0	Sri Lanka
20	ITRF2020(2025.0)	2025.0	Taiwan
21	ITRF2014(2010)	2010.0	Thailand
22	KGD2002(2002.0)=ITRF2000(2002.0)	2002.0	South Korea
23	MGRF2020(2020.0)=ITRF2020(2020.0)	2020.0	Malaysia
24	MTRF2000(2004.0)=ITRF2000(2004.0)	2004.0	United Arab Emirates
25	SIRGAS2000(2000.4)=ITRF2000(2000.4)	2000.4	South America
26	GGD=ITRF2008(2011.353)	2011.353	Georgia
27	WGS84(G2139)(20xx.5)1	20xx.5	Other regions

Note: For regions not listed above, AUTO falls back to WGS84(G2139) at the mid-year epoch.

---

Why Your Coordinates May Be Offset

If you see a consistent 50 cm to 1 m offset compared to local survey control, this is almost certainly a datum mismatch, not an accuracy problem.

The earth's tectonic plates move, and the two families of reference frame handle that differently. Global frames such as ITRF2014 and ITRF2020 follow the plates, so a point on the ground slowly changes its coordinates in them. Regional frames such as NAD83, ETRS89 and GDA2020 ride along with their own plate, so the same point keeps roughly the same coordinates year after year. Neither is wrong, but the gap between them widens every year, which is why mixing the two shows up as a steady, predictable offset rather than as noise.

The Fix:

1. Use AUTO. It delivers corrections in your regional datum, eliminating the shift in most cases.

2. Software transformation: If you must use a global mountpoint (AUTO_ITRF2020, AUTO_WGS84), set your rover/drone software to transform from WGS84/ITRF to your local system.

---

Vertical Reference: Ellipsoidal vs. Orthometric Heights

RTKdata provides ellipsoidal heights (height above the WGS84 ellipsoid). These are NOT the same as:

• Mean Sea Level (MSL)

• Orthometric height

• Local vertical datum

To convert to orthometric heights, apply a geoid model in your software:

• EGM96 / EGM2008: global geoid models

• OSGM15: UK geoid model

• GEOID18: US geoid model

• AUSGeoid2020: Australian geoid model

Most surveying software and GIS applications can apply geoid corrections automatically when the correct vertical datum is selected.

See Understanding Heights for a detailed guide.

---

US Survey Feet vs. International Feet

If you see a steady ~4 ft / 1.2 m offset in the United States, check your controller's unit settings. The difference between US Survey Feet and International Feet causes a noticeable shift at scale.

Fix: Set your controller/software project to use the correct foot definition for your state.

---

Where the Coordinate System Has to Be Set

Most field software stores a coordinate system in more than one place, and only one of them affects the points you record. Three levels come up repeatedly in support cases:

#	Level	What it controls	Applies to recorded points?
1	NTRIP profile / correction input	How the incoming corrections are treated. Leave this on the global option (Global CS in Emlid Flow).	No
2	Workspace or app default	Preselects a system for projects created after the change.	No, and not retroactively
3	Project settings	The transformation actually applied when points are recorded, displayed and exported.	Yes

One customer selected OSGB 1936 / British National Grid with ODN height, confirmed it was saved, and still got points in the wrong frame. The setting had been made in Workspace settings while the survey project had been created earlier, so the project kept its original system. Setting the same system inside the active project resolved it.

Rule of thumb: the workspace default only seeds new projects. If the project already exists, change the project.

The same split applies to the NTRIP profile. The NTRIP connection stays on the global option, and the local datum and projection belong in the project's Coordinate System field. Setting a local grid in the NTRIP profile does not transform your output.

---

Grid Files vs. Seven Parameter Transformations

Some national datums cannot be reached accurately by a seven parameter (Helmert) transformation. They require a grid shift file in NTv2 format, usually a .gsb. Great Britain is the clearest example.

Method	Typical accuracy	Suitable for OSGB36 / British National Grid?
Grid shift file (OSTN15, .gsb)	Centimetre level	Yes, this is the official Ordnance Survey method
Seven parameter Helmert (e.g. ΔX 375, ΔY -111, ΔZ 431)	Metre level, and it varies across the country	No
OSTN02 grid file	Superseded by OSTN15	Legacy data only

When Two Transformations Are Active at Once

A UK surveyor reported: "I am getting incorrect OSGB36 co-ordinates but the Lat and Long are fine." After loading OSTN15 and OSGM15 he added the decisive detail: "there is no difference in transformation whether it is loaded or not."

That symptom means the grid file is present on the device but is not the active transformation. Two separate causes were found in the same thread:

1. The prebuilt UK profiles used the seven parameter method, so the .gsb was never read at all.

2. The predefined OSGB 1936 / British National Grid OSTN15 profile had both the OSTN15 grid file and a seven parameter Helmert active at the same time. Applying two datum transformations in sequence produces coordinates that are wrong by metres.

Fix: use exactly one datum transformation method.

• Projection: British National Grid (EPSG:27700)

• Datum transformation method: grid / NTv2, with the OSTN15 .gsb assigned and the "use grid file" option enabled

• Seven parameters: None or unchecked. Do not leave them active alongside a grid file

• Vertical: OSGM15, so heights reference ODN (Newlyn) rather than the ellipsoid

If a predefined profile keeps the seven parameters active and they cannot be switched off inside it, build a custom coordinate system instead. The published EPSG:27700 definition is:

Parameter	Value
Projection	Transverse Mercator
Ellipsoid	Airy 1830
Central meridian	-2.0
Latitude of origin	49.0
Scale factor	0.9996012717
False easting	400000
False northing	-100000
Grid file	OSTN15 (.gsb), enabled
Seven parameters	Off
Geoid	OSGM15

Field labels vary by app and version. On the controller in that case the relevant rows were named Plane Grid File, SevenParameter and Geoid File. In Emlid Flow the route is shorter: open the project's Coordinate System field, search for OSGB, select British National Grid, and accept the grid shift file download when the app prompts for it.

---

Several Versions of the Same Datum in One List

Field software often ships more than one predefined system for the same country, under names that differ by only a few characters. The UK controller above offered three entries under the same OSGB 1936 heading:

#	Predefined system	Transformation method	Verdict for RTK
1	OSGB 1936 / British National Grid	Seven parameters (ΔX 375, ΔY -111, ΔZ 431)	Metre level, do not use
2	OSGB 1936 / BNG OSTN02	Grid file	Superseded
3	OSGB 1936 / BNG OSTN15	Grid file	Use this one

Check which transformation method an entry actually uses before trusting its name. A profile named after a grid file can still have a seven parameter shift enabled inside it.

---

Building a Projection by Hand

If you create a projection manually, the values the dialog starts with are almost never correct for your country. In one case the projection type was right (Transverse Mercator) but four fields had been left at their defaults:

Field	Left at default	Required for that grid
Central meridian	E 0°00'00"	W 59°35'00"
False easting	500000 m	400000 m
Scale factor	1.0000000000	0.9995
Datum parameter	None	Clarke 1880 (RGS)

A None in the datum row means no datum shift is applied at all, so coordinates stay significantly off even after the projection parameters are corrected. Check every field against the published definition rather than only the projection type.

---

Matching the Frame in Your Processing Software

The AUTO mountpoint delivers your regional datum, for example NAD83(2011) in the USA and GDA2020 in Australia. Photogrammetry and GIS software frequently defaults to WGS84 instead, so the frame has to be matched on both sides of the workflow.

• Ground control collected on AUTO in the USA is in NAD83(2011). If the photogrammetry project (Pix4D, DJI Terra, Agisoft) is set to WGS84 or ITRF, the whole block shifts by the amount described in Why Your Coordinates May Be Offset, because NAD83 and the global frames drift apart with plate motion.

• In Australia, a receiver left on the software's global coordinate system option outputs ITRF2014, roughly 0.1 to 0.2 m from GDA2020. Older GDA94 control can sit up to about 1.8 m from WGS84 depending on location.

• DJI Terra outputs WGS84 by default, so ground control in a regional datum has to be declared as such in the processing project rather than assumed.

Set the GCP frame, the rover or drone output frame and the processing project frame to the same system before you process.

---

Common configuration mistakes

Symptom	Cause	Fix
"I am getting incorrect OSGB36 co-ordinates but the Lat and Long are fine"	Datum transformation is wrong or inactive. The RTK position itself is correct.	Diagnose in the project's coordinate system settings, not in the NTRIP connection.
"There is no difference in transformation whether it is loaded or not" (grid file loaded, output unchanged)	The active method is seven parameters, so the .gsb is never read.	Switch the datum transformation method to grid / NTv2 and assign the grid file.
Coordinates wrong by metres although the OSTN15 grid file is loaded and enabled	A grid file and a seven parameter Helmert are both active in the same profile.	Set seven parameters to None. Use exactly one method. If a predefined profile forces both, build a custom system.
Correct system selected and saved, exported points still in the wrong frame	Set at workspace or app default level, project was created before the change.	Set the same system inside the active project's settings.
Local grid entered in the NTRIP profile, coordinates still off	The NTRIP profile describes incoming corrections, not your output.	Leave the NTRIP profile on the global option, apply the local system in project settings.
"I could not find anywhere to select/add the OSTN15 and OSGM15 transformations"	Looking in the NTRIP or correction settings instead of the project.	Open the project's Coordinate System field, search for the national grid, accept the grid file download prompt.
The same country appears several times in the predefined list and each option gives a different answer	The entries differ by transformation method, not by projection.	Select the entry that uses the current official grid file for your country.
Large, unpredictable offset after building a projection by hand	Central meridian, false easting, scale factor or datum row left at dialog defaults.	Enter every parameter from the published definition, including ellipsoid and datum.
Ground control and drone imagery do not line up in the photogrammetry project	GCPs in the regional datum, processing project on WGS84, or the reverse.	Set GCP frame, rover output frame and processing project frame to the same system.
Repeat observations of the same point differ by decimetres between sessions	Receiver was on the software's global coordinate system in one session and the regional datum in the other.	Fix the output coordinate system in the field software and re-observe. Confirm the mountpoint is AUTO.

---

Related Guides

• Understanding Heights: the vertical half of the same problem, including which row applies the geoid model

• Accuracy Expectations: what a correct setup should deliver, so you can tell a datum offset from an accuracy issue

• Emlid Flow: where Global CS belongs and where the project coordinate system belongs

• NTRIP & GGA Essentials: how the AUTO mountpoint uses your GGA position to pick the regional datum

• Troubleshooting & FAQ: connection level problems that are not coordinate system problems