> 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/integration-hub/lidar-scanners-and-mobile-mapping/georeferencing-slam-point-clouds-with-rtk.md). # Georeference SLAM LiDAR Point Clouds with RTK: Datum Guide How RTK georeferences SLAM LiDAR point clouds: fix before you scan, AUTO vs AUTO\_WGS84, WGS84 labels in LixelStudio or Aura, datum offsets, ellipsoidal heights. A georeferenced SLAM point cloud with RTK needs two things to line up: a scanner that records fixed RTK positions while it scans, and processing software that knows which reference frame those positions are in. This guide covers both for the handheld, backpack, vehicle and payload LiDAR scanners that take RTKdata NTRIP corrections: when a fix counts, what the `AUTO` mountpoint delivers, why scanner software still says WGS84, and where horizontal and height offsets come from. This page has no connection steps. Host, port `2101`, mountpoint and credentials are listed on the [LiDAR Scanners & Mobile Mapping](/integration-hub/lidar-scanners-and-mobile-mapping.md) overview, in each scanner guide and in [NTRIP Server Settings](/get-started/network.md). {% hint style="info" %} Don't have an RTKdata.com account yet? 👉 [Start 30-day Free Trial](https://rtkdata.com/try-rtk-corrections-free-for-30-days/) or [View Pricing](https://rtkdata.com/pricing/) {% endhint %} ## How does RTK georeference a SLAM point cloud? RTK georeferences a SLAM point cloud by recording fixed RTK positions, for example from RTKdata NTRIP corrections, along the scanner's trajectory, which the processing software then uses to place the whole cloud in the reference frame of the mountpoint you connected to. The chain is the same on every scanner in this section: 1. RTKdata streams corrections over NTRIP to a client in the scanner, in the phone or tablet app, or, for the Emesent Hovermap, in an external GNSS rover. 2. The GNSS receiver computes RTK positions with those corrections, and the scanner records them with the scan. 3. The processing software ties the SLAM trajectory to the RTK positions. The step has a different name in each program: **Coordinate Transformation** in LixelStudio, **GNSS Fusion** in FJD Trion Model, **RTK POS Optimization** in CHCNAV CoPre, **RTK Calibration** in RayStudio, **Use RTK data** in Emesent Aura, `rtk.pcmp` in PCMasterProGL and **Process GNSS** in LiDAR360MLS. If that processing step is skipped, or switched off by another option, the point cloud keeps local SLAM coordinates, even when the scanner had a fix in the field. In LixelStudio, **High-Precision Optimization** excludes **Coordinate Transformation**, and in FJD Trion Model, turning on **Optimize with Control Point** disables the RTK integration. RTKdata delivers **ellipsoidal heights**, so the georeferenced cloud has ellipsoidal heights until you apply a geoid model, see [Why are my point cloud heights tens of meters off?](#why-are-my-point-cloud-heights-tens-of-meters-off). ### "Connected" is not "Fixed" Every scanner in this section can show a connection or status message before it has an RTK fix from RTKdata corrections, so start the scan only when the fixed status in the table appears, or, where no fix indicator is documented, after the check the table lists. | Scanner | Shows a connection, not yet a fix | Wait for | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [XGRIDS Lixel K1, K2, L2 Pro](/integration-hub/lidar-scanners-and-mobile-mapping/xgrids-lixel-k1-k2-l2-pro.md) and [L3](/integration-hub/lidar-scanners-and-mobile-mapping/xgrids-lixel-l3.md) | **RTK** and **NTRIP** indicators green in LixelGO | Status **Fixed** | | [FJD Trion P1, P2, S2](/integration-hub/lidar-scanners-and-mobile-mapping/fjd-trion-p1-p2-s2.md) | Yellow check mark on the Ntrip card, **CORS Account** **Connected Successfully** | Green check mark, **RTK Status** **Fixed** | | [CHCNAV RS10 / RS30](/integration-hub/lidar-scanners-and-mobile-mapping/chcnav-rs10-rs30.md) | **Differential data transmission in progress.** in SmartGo Neo | Solution status **Fixed** | | [Stonex X200GO / X120GO](/integration-hub/lidar-scanners-and-mobile-mapping/stonex-x200go-x120go.md) | **Differential Data: Normal** in **Device State**, which GOapp shows even with no server set | **Fixed** on the standby page, or the GNSS LED solid green | | [GreenValley LiGrip](/integration-hub/lidar-scanners-and-mobile-mapping/greenvalley-ligrip.md) | **RTK configuration successful (Floating point solution), please wait for fixed solution** | **RTK configuration successful (Fixed Solution)** | | [GeoSun GS-200G / GS-100G](/integration-hub/lidar-scanners-and-mobile-mapping/geosun-gs-handheld.md) | **RTK server connection successful** | A rising **RTCM** counter and **RTK:Fixed Solution** | | [Emesent Hovermap RTK](/integration-hub/lidar-scanners-and-mobile-mapping/emesent-hovermap-backpack-vehicle-rtk.md) | **RTK Float** in Commander | **RTK Fix** | | [Emesent GX1](/integration-hub/lidar-scanners-and-mobile-mapping/emesent-gx1.md) | The status badge leaves **NO GNSS** | Emesent documents no fix wording; watch **Last correction** and **Baseline** | | [Inertial Labs RESEPI](/integration-hub/lidar-scanners-and-mobile-mapping/inertial-labs-resepi-echoone.md) | Base block with **Base Lon**, **Lat**, **Alt** and **Hgt** on the **Status** page | **GNSS Solution** `COMPUTED,NARROW INTEGER` (blue GUI), not `COMPUTED,NARROW FLOAT`; in the newer GEN-II and EchoONE GUI, **Lat STD**, **Lon STD** and **Alt STD** at centimeter level | | [3DMakerpro Eagle / Raven](/integration-hub/lidar-scanners-and-mobile-mapping/3dmakerpro-eagle-raven.md) | **Connect success!** | No fix indicator is documented; check that the exported project contains `RTK_XXXXXX.bin` | The manufacturers add their own rules for scanning with RTK. The figures below are examples for the named scanners, not general limits: * **Start in the fix.** FJD Trion Scan asks *Abnormal RTK status. Are you sure you want to start scanning?* when there is no fix; tap **Cancel** and wait. SmartGo Neo blocks RTK changes during capture with **Unable to switch while capturing.**, so set up RTK before you start. Emesent starts GX1 and Hovermap scans outdoors with a fix, even when the job continues indoors. * **Hold the fix before you move.** Stonex asks for at least one minute in **Fixed** before **Start work**. For the L2 Pro, XGRIDS asks for a walking range of more than 10 m in the fix, and an XGRIDS dealer's field guide gives the same 10 m for the K1 and K2. * **Keep gaps short.** XGRIDS keeps stretches without a fix under 50 m on the K1 and K2 and under 100 m on the L2 Pro, and asks for more than 100 valid RTK points. Stonex asks for **Fixed** during at least 50% of the scan time. * **End in the fix.** GreenValley support recommends walking a figure eight before and after the scan, and Stonex asks you to capture outdoor areas before and after indoor sections. * **Do not switch NTRIP accounts mid-scan.** LixelGO warns: "Switching NTRIP accounts during scan affects accuracy." * **Check the result.** If the real-time RTK was not valid, CoPre's **RTK POS Optimization** processes the scan in pure SLAM mode without an error message. Check a known control point after processing. ### GGA: the position AUTO needs RTKdata's `AUTO` mountpoint selects the nearest reference station from the position your scanner sends as NMEA GGA, and it can hand off to a closer station as you move; without GGA the login succeeds, but no corrections arrive. This is described in [How AUTO Selects a Base Station](/get-started/network.md#how-auto-selects-a-base-station) and in [NTRIP & GGA Essentials](/integration-hub/ntrip-clients-and-field-software/ntrip-and-gga-essentials.md). What the scanner guides document about GGA: * **LixelGO (XGRIDS):** no GGA switch. Give the scanner a position before you connect: wait outdoors until the satellite tile shows satellites and **Single**, then tap **Connect**. * **SmartGo Neo (CHCNAV):** no GGA switch. Without a position, the app reports **No device location information. Please check if the device is connected and can search for stars normally.** * **RESEPI web GUI:** GGA is sent automatically. The GUI notes: "RESEPI sends back GPGGA messages with its current position for virtual reference stations." * **Emlid rovers for Hovermap:** switch on **Send receiver's position to the provider** in Emlid Flow. * **FJD Trion, 3DMakerpro, Stonex, GreenValley, Emesent GX1 and GeoSun:** the NTRIP screens have no GGA setting, and the manufacturers do not document how the position is sent. Switch the scanner on outdoors and let it find its own position before you connect. ## Why does my scanner software say WGS84 when I use AUTO? Scanner apps and processing software show WGS84 as a default label or as their only option, while RTKdata's `AUTO` mountpoint delivers your region's datum, for example NAD83(2011) in the USA, ETRS89 (realization ETRF2000) in Europe and GDA2020 in Australia; the label does not change the frame your RTK positions are in, so do not transform them from WGS84 to the regional datum a second time. {% hint style="info" %} **Datum with AUTO.** Excerpt from the [full AUTO table in Coordinate Systems & Datums](/get-started/coordinate-systems-and-datums.md#regional-geodetic-coordinate-system-rgcs): * USA: NAD83(2011), epoch 2010.0; Hawaii: NAD83(PA11), epoch 2010.0; Guam: NAD83(MA11), epoch 2010.0 * Canada: NAD83(CSRS)v7, epoch 2010.0 * Europe: ETRS89, realization ETRF2000, epoch 2010.0 * Australia: GDA2020, epoch 2020.0 * New Zealand: NZGD2000, epoch 2000.0 * South America: SIRGAS2000, epoch 2000.4 * Regions not listed: WGS84(G2139) at the mid-year epoch Heights are ellipsoidal in every frame. Declare this datum in your processing software, or choose a target system on it, instead of transforming to it from WGS84. {% endhint %} The frame comes from the corrections, not from the label. The mountpoint you choose determines the coordinate system of the corrections streamed to your device, and the RTK position follows it. NovAtel, the receiver maker in the RESEPI GEN-II M2X-ILX and Ultra LITE, documents this for its receivers: "For differential solutions such as RTK or PSRDIFF, the datum is reported as WGS84. However, the position solution is in the same datum as the base station." The same rule for photogrammetry and GIS software is described in [Matching the Frame in Your Processing Software](/get-started/coordinate-systems-and-datums.md#matching-the-frame-in-your-processing-software). Where the scanner software shows the frame: | Scanner | Where you set or see the frame | What it shows | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | [XGRIDS Lixel K1, K2, L2 Pro](/integration-hub/lidar-scanners-and-mobile-mapping/xgrids-lixel-k1-k2-l2-pro.md), [L3](/integration-hub/lidar-scanners-and-mobile-mapping/xgrids-lixel-l3.md) | LixelGO **Ellipsoid**; LixelStudio **Source CRS** and **Target CRS** | **Ellipsoid** offers **WGS84**, **CGCS2000** and **OTHER**. The field names an ellipsoid, not the frame of your corrections. | | [FJD Trion P1, P2, S2](/integration-hub/lidar-scanners-and-mobile-mapping/fjd-trion-p1-p2-s2.md) | Trion Model **GNSS Fusion**, **Coord System** > **Predefined Coordinates** | A preselected system, which has been seen set to China CGCS 2000 or to the last system used | | [CHCNAV RS10 / RS30](/integration-hub/lidar-scanners-and-mobile-mapping/chcnav-rs10-rs30.md) | CoPre task with **Projected Coordinate System** > **Standard Coord System** (EPSG search) | One coordinate system per task; older CoPre versions preset `WGS84 / Gaussian Projection / 114E` | | [3DMakerpro Eagle / Raven](/integration-hub/lidar-scanners-and-mobile-mapping/3dmakerpro-eagle-raven.md) | RayStudio **Data Processing** > **RTK Calibration** | **WGS84**, the only documented option | | [Stonex X200GO / X120GO](/integration-hub/lidar-scanners-and-mobile-mapping/stonex-x200go-x120go.md) | GOapp **Real-time Orientation**: **Source Projection** and **Target Projection** | `WGS` as source in Stonex's screenshot, a `WGS 84 / UTM zone` system as example target | | [GreenValley LiGrip](/integration-hub/lidar-scanners-and-mobile-mapping/greenvalley-ligrip.md) | GreenValley app **Coordinate System Settings:** with **Automatic** or **Custom Selection**; LiDAR360MLS | **Automatic** gives `WGS 84 / UTM zone ` outside China; without a target system LiDAR360MLS projects to WGS84 UTM | | [Emesent GX1](/integration-hub/lidar-scanners-and-mobile-mapping/emesent-gx1.md), [Hovermap RTK](/integration-hub/lidar-scanners-and-mobile-mapping/emesent-hovermap-backpack-vehicle-rtk.md) | Aura **Base coordinate reference system** (required) | You choose it; Emesent's example screenshot shows `EPSG:4326 - WGS 84` | | [Inertial Labs RESEPI](/integration-hub/lidar-scanners-and-mobile-mapping/inertial-labs-resepi-echoone.md) | PCMasterPro **Current Model** | `H-EPSG: + V-EPSG:5030`: WGS 84 / UTM with ellipsoidal height by default | | [GeoSun GS-200G / GS-100G](/integration-hub/lidar-scanners-and-mobile-mapping/geosun-gs-handheld.md) | PointCloudCreater (PCC) **Coordinate** > **Coor. System** | `WGS84 UTM`, `WGS84 Gauss 3-Degree` and similar, or a user-defined system | With RTKdata's `AUTO` mountpoint, keep **Ellipsoid** on **WGS84** in LixelGO (in China **CGCS2000**), never **OTHER**: the positions already arrive in your regional datum, so add no WGS84-to-ETRS89, WGS84-to-NAD83 or WGS84-to-GDA2020 transformation in LixelStudio. With `AUTO`, handle the frame the same way in every program: 1. **Base CRS is the frame of the mountpoint.** Where the software asks which frame the RTK data was recorded in, as Aura does with **Base coordinate reference system**, choose the `AUTO` datum of your region. Emesent's own setup videos select GDA2020 in Aura because the corrections used there are in GDA2020. LixelStudio **Source CRS** and GOapp **Source Projection** work differently: leave them as the scanner guide says, WGS84 for **Source CRS** and `WGS` as in Stonex's screenshot for **Source Projection**, and set your regional datum as the target (step 3). **Source CRS** stays on WGS84 because, as with **Ellipsoid** in LixelGO, the label outside China stands for the ellipsoid, not the frame: ETRS89, NAD83 and GDA2020 use the GRS80 ellipsoid, which is nearly identical to WGS84, and the `0 0 0 0 0 0 1` file from step 3 adds no datum shift, so the data stays in the frame `AUTO` delivered. 2. **Declare instead of transforming.** Where the software only offers WGS84-labelled output, such as RayStudio **WGS84**, the PCMasterPro default, GreenValley **Automatic** or PCC `WGS84 UTM`, assign the regional coordinate system on the `AUTO` datum with the same projection and zone when you import or deliver the result. Do not transform it from WGS 84 to the regional datum. 3. **Pick the target on the same datum.** Where you choose a target system, as in Trion Model **Predefined Coordinates**, CoPre **Standard Coord System**, LixelStudio **Target CRS** or GOapp **Target Projection**, choose one on the `AUTO` datum of your region, for example an ETRS89 / UTM zone in Europe, and add no WGS84-to-regional transformation parameters. If LixelStudio asks for seven parameters, load a text file containing `0 0 0 0 0 0 1`, as in the [XGRIDS Lixel guide](/integration-hub/lidar-scanners-and-mobile-mapping/xgrids-lixel-k1-k2-l2-pro.md), not official WGS84-to-national parameters. 4. **National grid on another datum.** If your deliverable is on a national datum other than the `AUTO` datum, for example OSGB36 / British National Grid, neither declaring the data nor the `0 0 0 0 0 0 1` file gets you there. Transform from the `AUTO` datum with the official grid file, OSTN15 in Great Britain, and use exactly one transformation method, see [Grid Files vs. Seven Parameter Transformations](https://docs.rtkdata.com/integration-hub/lidar-scanners-and-mobile-mapping/pages/PAzvrf6Hx6NvWJ9260lS#grid-files-vs.-seven-parameter-transformations). The `0 0 0 0 0 0 1` file only applies to target systems on the `AUTO` datum. If your scanner software cannot apply the grid file, deliver the point cloud on the `AUTO` datum and transform it in software that can. 5. **Canada:** `AUTO` delivers NAD83(CSRS)v7. Assign NAD83(CSRS) to data labelled WGS 84 rather than reprojecting it from WGS 84. 6. **Check one control point on the first project.** Most manufacturers do not document whether their software applies a datum transformation behind a WGS84 label, so a known point is the only reliable test. [Accuracy Expectations](/get-started/accuracy-expectations.md) shows the accuracy to expect from the RTK corrections themselves. The scanner guides linked in the table have the exact steps for each program. ## When should you use AUTO\_WGS84 or AUTO\_ITRF2020 instead? Use RTKdata's `AUTO_WGS84`, `AUTO_ITRF2020` or `AUTO_ITRF2014` only when the deliverable has to stay in that global frame, for example when the point cloud is combined with data referenced to WGS84; for work tied to local control, plans or a national grid, stay on `AUTO`. | Mountpoint | Frame delivered | Use it when | | --------------- | --------------------------------------------------------------- | -------------------------------------------------------------------------- | | `AUTO` | Your region's datum, see the excerpt above | Local control points, BIM, national grids. Recommended for most workflows. | | `AUTO_ITRF2020` | ITRF2020 at the current epoch | The project specifies ITRF2020 | | `AUTO_ITRF2014` | ITRF2014 at the current epoch | The project specifies ITRF2014 | | `AUTO_WGS84` | WGS84(G2139) at the mid-year epoch, for example 2025.5 for 2025 | The project is explicitly in WGS84 or merged with WGS84 data | If you use a global mountpoint: * **Declare that frame** as the base or source CRS, for example WGS 84 in Aura for `AUTO_WGS84`. * **Transform in the software** if you need regional coordinates after all: set the processing software to transform from WGS84 or ITRF to your local system, as described in [Why Your Coordinates May Be Offset](/get-started/coordinate-systems-and-datums.md#why-your-coordinates-may-be-offset), and check a control point. * **Match the mountpoint to the target.** Stonex's GOapp is an example: `AUTO` for a regional target system, `AUTO_WGS84` for a `WGS 84 / UTM zone` target. Keep one mountpoint per project. CoPre allows one coordinate system per task, so scans made with different mountpoints go into separate tasks, and projects you combine in XGRIDS **Map Fusion** should all be recorded with the same mountpoint. Measure control points with the same mountpoint as the scans. Mountpoint names are case sensitive and entered in ALL CAPS. A coordinate system name such as `ETRS89` is not a mountpoint and returns no corrections at all. ## Why is a point cloud 50 cm to 1 m off from control points? With RTKdata corrections, a consistent offset of 50 cm to 1 m between the point cloud and local control is almost certainly a datum mismatch, not an RTK accuracy problem: the point cloud and the control points are in different reference frames. Global frames such as ITRF2014 and ITRF2020 follow the tectonic plates, while regional frames such as NAD83, ETRS89 and GDA2020 ride along with their own plate. The gap between them widens every year, which is why mixing the two shows up as a steady, predictable offset rather than as noise. [Coordinate Systems & Datums](/get-started/coordinate-systems-and-datums.md#why-your-coordinates-may-be-offset) explains the background. | Situation | Cause | Fix | | --------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Scan on `AUTO`, control points in a global frame, or the reverse | Two frames in one comparison | Measure control with the same mountpoint as the scan, or transform the control points into the scan's frame in your software and check one point | | Offset appears after a WGS84-to-regional transformation in the software | `AUTO` data transformed as if it were WGS84 | Assign the regional coordinate system instead of transforming | | Scan on `AUTO_WGS84` or `AUTO_ITRF2020`, deliverable labelled regional | Global frame declared as regional without a transformation | Declare the global frame and transform in the software, or scan on `AUTO` | | Scans with different mountpoints in one project | Mixed frames | One mountpoint per project | | Offset in Australia of roughly 0.1 to 0.2 m, or up to about 1.8 m against older control | 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 | Put control points, scan and processing project on the same system, see [Matching the Frame in Your Processing Software](/get-started/coordinate-systems-and-datums.md#matching-the-frame-in-your-processing-software) | | Steady offset of about 4 ft (1.2 m) in the United States | US Survey Feet and International Feet mixed | Set the foot definition for your state, see [US Survey Feet vs. International Feet](https://docs.rtkdata.com/integration-hub/lidar-scanners-and-mobile-mapping/pages/PAzvrf6Hx6NvWJ9260lS#us-survey-feet-vs.-international-feet) | Control points have to be in the same frame and height system as the mountpoint, and the RTK step has to stay on. The processing programs spell this out: * **LixelStudio Accuracy Check** expects a control point file with "Point Name, Easting, Northing, Ellipsoidal Height", in the same coordinate system as the GNSS target. * **CoPre:** control points for the absolute check have to be consistent with the point cloud coordinate system and the CORS system used. * **GreenValley** support checks the coordinate system and height system of the control points, and whether they were measured with the same correction source as the SLAM scan. * **SurveyPro Tools** (RESEPI) expects GCPs as "Easting, Northing, Ellipsoidal Height" and "does not convert units or coordinate systems". * **FJD Trion Model:** leave **Optimize with Control Point** off. FJD states that enabling control point optimization disables RTK integration, so use control points to check accuracy. * **LixelStudio:** leave **High-Precision Optimization** off. It excludes **Coordinate Transformation**, so the point cloud is not georeferenced. An offset that is not constant, for example one that grows along the trajectory, does not fit the datum pattern. It points to the scan itself, such as long stretches without a fix; see the rules under ["Connected" is not "Fixed"](#connected-is-not-fixed). ## Why are my point cloud heights tens of meters off? Point cloud heights that are 10 to 50+ m off from benchmarks or plans are a geoid issue, not an RTK error: RTKdata delivers ellipsoidal heights, your benchmarks use heights above the geoid, and the point cloud needs a geoid model before the two match. The difference between the two surfaces depends on your location. [Understanding Heights](/get-started/understanding-heights.md) explains it and lists geoid models by region. Where the scanner software applies the geoid: | Scanner | Where to apply the geoid | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [XGRIDS Lixel](/integration-hub/lidar-scanners-and-mobile-mapping/xgrids-lixel-k1-k2-l2-pro.md) | LixelStudio: a fixed **Height anomaly** for small sites, or a custom coordinate system with a **Geoid** | | [FJD Trion](/integration-hub/lidar-scanners-and-mobile-mapping/fjd-trion-p1-p2-s2.md) | Trion Model: **Geoid Model**, or **Elevation Fitting** with control points | | [CHCNAV RS10 / RS30](/integration-hub/lidar-scanners-and-mobile-mapping/chcnav-rs10-rs30.md) | CoPre: **Geoid model** in the task | | [3DMakerpro Eagle / Raven](/integration-hub/lidar-scanners-and-mobile-mapping/3dmakerpro-eagle-raven.md) | RayStudio 1.0.13 calculates orthometric heights only with a `.pgm` geoid file. The `.pgm` geoid files distributed with GeographicLib are worldwide models such as EGM96 and EGM2008, not national geoids; for official heights, export the ellipsoidal point cloud and apply your national geoid in the GIS | | [Stonex X200GO / X120GO](/integration-hub/lidar-scanners-and-mobile-mapping/stonex-x200go-x120go.md) | GOapp has no geoid field on the orientation page; apply the geoid in your downstream software | | [GreenValley LiGrip](/integration-hub/lidar-scanners-and-mobile-mapping/greenvalley-ligrip.md) | LiDAR360MLS: geoid as TIF file in the **geoid** folder, vertical coordinate system with **Gravity-related** | | [Emesent GX1](/integration-hub/lidar-scanners-and-mobile-mapping/emesent-gx1.md), [Hovermap RTK](/integration-hub/lidar-scanners-and-mobile-mapping/emesent-hovermap-backpack-vehicle-rtk.md) | Aura: **Reprojection** > **Vertical**, or **Import geoid file** (GTX or TIF). Reproject single scans only; for scans you merge, reproject in the merge workflow, because Aura warns that "reprojected point clouds are not suitable for alignment in merge" | | [Inertial Labs RESEPI](/integration-hub/lidar-scanners-and-mobile-mapping/inertial-labs-resepi-echoone.md) | PCMasterPro: **New Vertical Model**, with the matching PROJ grid file (.tif) in the `/proj` folder | | [GeoSun GS-200G / GS-100G](/integration-hub/lidar-scanners-and-mobile-mapping/geosun-gs-handheld.md) | GeoSun does not document whether PCC outputs `ENH` heights as ellipsoidal or applies a geoid; compare with a control point of known height | * **Apply the geoid in the active project.** A geoid file that sits on the device or in a folder but is not assigned changes nothing. See [Where the Geoid Model Has to Be Set](/get-started/understanding-heights.md#where-the-geoid-model-has-to-be-set). * **Compare like with like.** Compare ellipsoidal heights with ellipsoidal control heights, or apply the same geoid model to control points, rover points and the point cloud. For smaller height differences, the quick diagnostic in [Understanding Heights](/get-started/understanding-heights.md) lists further causes. ## Is RTK or PPK better for a handheld SLAM scanner? RTK with RTKdata NTRIP corrections is the simpler path for most handheld SLAM work, because the georeference comes from the corrections while you scan and no base station of your own is needed; PPK is the fallback for sites without mobile coverage or scans with correction dropouts, and it needs base station observation data for the whole scan, usually from a base you run yourself. PPK can only rescue a scan if raw GNSS data logging ran for the whole scan, so decide before you start. On the Emesent GX1 and Hovermap, the logging has to be switched on or started before the scan, and on XGRIDS scanners PPK replaces RTK, see the list below. | | RTK with RTKdata | PPK | | ------------ | -------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Base station | None of your own. `AUTO` selects the nearest reference station from your GGA position. | Your own base station logging for the whole scan, or a reference network's observation data where the software accepts it; Emesent, for example, needs a navigation file and at least 1 Hz | | In the field | Internet for NTRIP on the scanner or phone, fix before you start | Base set up before the scan, raw data logging on the scanner | | Processing | RTK workflow in the scanner software | Extra step with the base data; some programs need an additional license | | Fits when | Mobile coverage on site, open sky at the start and end | No mobile coverage, or corrections dropped during the scan | PPK in the scanner software: * **XGRIDS:** record with **GNSS Mode** **PPK** and post-process the scan. PPK replaces RTK on XGRIDS: in **PPK** mode, LixelGO does not log in to NTRIP, and on the K1, K2 and L2 Pro a change of **GNSS Mode** applies after a restart (**RTK mode: Changes apply after restart**). Decide before the scan. * **Emesent GX1:** switch on **PPK Logging RINEX** in the mission as a fallback; RTK and PPK can run at the same time. For PPK, Emesent uses a trajectory from Emlid Studio. * **Emesent Hovermap:** the **PPK** toggle in Commander 2.3 only works if RINEX logging on the rover was started before the scan. * **Inertial Labs RESEPI:** `ppk.pcmp` needs the Inertial Explorer license and base station data. The RTK workflow `rtk.pcmp` needs no Inertial Explorer license, but it only gives a usable result if corrections arrived during the recording. * **CHCNAV:** **PPK POS Optimization** in CoPre. * **FJD Trion:** **PPK Calculation** in Trion Model with base station data. * **3DMakerpro:** **Select the rtk file directory (optional)** in RayStudio takes base station files for PPK. * **GeoSun:** PPK-SLAM with your own base; GeoSun's guide asks for base data in RINEX 3.0 or later at 1 Hz, within 10 km. Plan PPK with base station observation data for the whole scan, usually from a base station of your own. RTKdata manages raw observation data; contact if you need base station observation files. If you measure your own base point or control points with RTKdata, use the same mountpoint as for the RTK scans, so all coordinates share one frame. ## Frequently asked questions ### How does RTK georeference a handheld SLAM LiDAR point cloud? The scanner records fixed RTK positions from RTKdata corrections along its trajectory, and the processing software ties the SLAM trajectory to them, so the whole point cloud lands in the frame of your mountpoint. Start and end the scan with a fix, make sure the scanner's position reaches the caster as GGA, and run the RTK step in the processing software, for example **GNSS Fusion** in FJD Trion Model or **RTK POS Optimization** in CoPre. ### Should I use a regional datum or a WGS84 mountpoint for my SLAM scanner? Use the regional datum through RTKdata's `AUTO` mountpoint when your control points, plans or national grid are regional, which is the normal case, and use `AUTO_WGS84` only when the deliverable has to stay in WGS84. Mixing the two in one project shifts the point cloud against the control points. ### Why is my LiDAR point cloud about 1 meter off from my control points? A steady offset of 50 cm to 1 m is almost certainly a datum mismatch: the point cloud and the control points are in different frames, or data from RTKdata's `AUTO` mountpoint was transformed as if it were WGS84. Measure control with the same mountpoint as the scan, declare the `AUTO` datum instead of transforming, and check the foot definition if you work in the United States and the offset is about 4 ft. ### Why are the heights in my SLAM point cloud tens of meters off? RTKdata delivers ellipsoidal heights, and a difference of 10 to 50+ m to benchmarks is the geoid separation, not an RTK error. Apply a geoid model in the active project of your processing software, for example **Vertical** under **Reprojection** in Aura or **Geoid model** in CoPre. ### Is RTK or PPK better for a handheld SLAM scanner? RTK needs no base station of your own and gives the georeference directly from the scan, as long as the scanner holds a fix with RTKdata corrections arriving. PPK needs base station observation data for the whole scan, usually from your own base station, and is the fallback when there is no mobile coverage or corrections dropped. For base station observation files from RTKdata, contact support. ## Quick reference | Field | Value | | --------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Connection settings** | Host, port `2101`, username and password as listed in the [overview](/integration-hub/lidar-scanners-and-mobile-mapping.md) and in [NTRIP Server Settings](/get-started/network.md) | | **Mountpoint for regional coordinates** | `AUTO` (ALL CAPS) | | **Global mountpoints** | `AUTO_ITRF2020`, `AUTO_ITRF2014`, `AUTO_WGS84` | | **Frame with `AUTO`** | Regional datum, for example NAD83(2011) USA (Hawaii NAD83(PA11)), NAD83(CSRS)v7 Canada, ETRS89 (realization ETRF2000) Europe, GDA2020 Australia; WGS84(G2139) at the mid-year epoch in regions not listed | | **GGA** | Required. `AUTO` selects the nearest reference station from it. | | **Start of scan** | Only at the fixed status, not at the connection message | | **Base CRS (Aura)** | The frame of the mountpoint. LixelStudio **Source CRS** stays on WGS84, GOapp **Source Projection** as in the Stonex guide | | **WGS84 label with `AUTO`** | Declare the regional datum or pick a target on it; do not transform from WGS 84 | | **National grid on another datum** | Transform from the `AUTO` datum with the official grid file, for example OSTN15 for OSGB36 / British National Grid; one transformation method only | | **Control points** | Same frame and height system as the mountpoint | | **Heights** | Ellipsoidal; apply a geoid model in processing | | **Offset of 50 cm to 1 m** | Datum mismatch | | **Height offset of 10 to 50+ m** | Geoid model not applied | | **PPK** | Base station observation data for the whole scan, usually from your own base; files from RTKdata on request through support | ## Related Guides * [LiDAR Scanners & Mobile Mapping](/integration-hub/lidar-scanners-and-mobile-mapping.md): all scanner guides and the shared RTKdata connection settings * [XGRIDS Lixel K1, K2 & L2 Pro](/integration-hub/lidar-scanners-and-mobile-mapping/xgrids-lixel-k1-k2-l2-pro.md): LixelGO **Ellipsoid** setting and georeferencing in LixelStudio * [XGRIDS Lixel L3](/integration-hub/lidar-scanners-and-mobile-mapping/xgrids-lixel-l3.md): built-in RTK on the L3, fix check and LixelStudio target system * [FJD Trion P1, P2 & S2](/integration-hub/lidar-scanners-and-mobile-mapping/fjd-trion-p1-p2-s2.md): check marks in Trion Scan and **GNSS Fusion** in Trion Model * [CHCNAV RS10 / RS30](/integration-hub/lidar-scanners-and-mobile-mapping/chcnav-rs10-rs30.md): fix check in SmartGo Neo and the CoPre task coordinate system * [3DMakerpro Eagle & Raven](/integration-hub/lidar-scanners-and-mobile-mapping/3dmakerpro-eagle-raven.md): the `RTK_XXXXXX.bin` check and **RTK Calibration** in RayStudio * [Stonex X200GO & X120GO](/integration-hub/lidar-scanners-and-mobile-mapping/stonex-x200go-x120go.md): real fix checks in GOapp and the **Real-time Orientation** projections * [GreenValley LiGrip](/integration-hub/lidar-scanners-and-mobile-mapping/greenvalley-ligrip.md): **Coordinate System Settings:** in the app and geoid heights in LiDAR360MLS * [Emesent GX1](/integration-hub/lidar-scanners-and-mobile-mapping/emesent-gx1.md): the NTRIP profile in Commander and the **Base coordinate reference system** in Aura * [Emesent Hovermap RTK](/integration-hub/lidar-scanners-and-mobile-mapping/emesent-hovermap-backpack-vehicle-rtk.md): rover start order, **RTK Fix** in Commander and base CRS in Aura * [Inertial Labs RESEPI](/integration-hub/lidar-scanners-and-mobile-mapping/inertial-labs-resepi-echoone.md): `COMPUTED,NARROW INTEGER` before takeoff and the WGS 84 / UTM label in PCMasterPro * [GeoSun GS-200G / GS-100G](/integration-hub/lidar-scanners-and-mobile-mapping/geosun-gs-handheld.md): **RTK:Fixed Solution** in GeosunMeasure and coordinate settings in PCC * [NTRIP Server Settings](/get-started/network.md): regional hosts, port 2101 and how `AUTO` selects a base station * [NTRIP & GGA Essentials](/integration-hub/ntrip-clients-and-field-software/ntrip-and-gga-essentials.md): why the caster needs your GGA position and what happens without it * [Coordinate Systems & Datums](/get-started/coordinate-systems-and-datums.md): the full `AUTO` datum table and the background to datum offsets * [Understanding Heights](/get-started/understanding-heights.md): ellipsoidal and orthometric heights, geoid models by region and where the geoid has to be set * [Accuracy Expectations](/get-started/accuracy-expectations.md): the accuracy to expect by distance to the reference station, so you can tell a datum offset from normal RTK accuracy --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.rtkdata.com/integration-hub/lidar-scanners-and-mobile-mapping/georeferencing-slam-point-clouds-with-rtk.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.