> For the complete documentation index, see [llms.txt](https://docs.rtkdata.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rtkdata.com/get-started/coordinate-systems-and-datums.md). # 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 – 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](/get-started/understanding-heights.md) 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](#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](/get-started/understanding-heights.md): the vertical half of the same problem, including which row applies the geoid model * [Accuracy Expectations](/get-started/accuracy-expectations.md): what a correct setup should deliver, so you can tell a datum offset from an accuracy issue * [Emlid Flow](/integration-hub/ntrip-clients-and-field-software/emlid-flow.md): where Global CS belongs and where the project coordinate system belongs * [NTRIP & GGA Essentials](/integration-hub/ntrip-clients-and-field-software/ntrip-and-gga-essentials.md): how the `AUTO` mountpoint uses your GGA position to pick the regional datum * [Troubleshooting & FAQ](/support/troubleshooting-and-faq.md): connection level problems that are not coordinate system problems --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.rtkdata.com/get-started/coordinate-systems-and-datums.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.