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 overview, in each scanner guide and in NTRIP Server Settings.
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:
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.
The GNSS receiver computes RTK positions with those corrections, and the scanner records them with the scan.
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.pcmpin 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?.
"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.
Yellow check mark on the Ntrip card, CORS Account Connected Successfully
Green check mark, RTK Status Fixed
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
RTK configuration successful (Floating point solution), please wait for fixed solution
RTK configuration successful (Fixed Solution)
RTK server connection successful
A rising RTCM counter and RTK:Fixed Solution
The status badge leaves NO GNSS
Emesent documents no fix wording; watch Last correction and Baseline
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
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 and in NTRIP & GGA Essentials. 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.
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.
Where the scanner software shows the frame:
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.
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
CoPre task with Projected Coordinate System > Standard Coord System (EPSG search)
One coordinate system per task; older CoPre versions preset WGS84 / Gaussian Projection / 114E
RayStudio Data Processing > RTK Calibration
WGS84, the only documented option
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 app Coordinate System Settings: with Automatic or Custom Selection; LiDAR360MLS
Automatic gives WGS 84 / UTM zone <zone> outside China; without a target system LiDAR360MLS projects to WGS84 UTM
Aura Base coordinate reference system (required)
You choose it; Emesent's example screenshot shows EPSG:4326 - WGS 84
PCMasterPro Current Model
H-EPSG:<UTM zone> + V-EPSG:5030: WGS 84 / UTM with ellipsoidal height by default
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:
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
AUTOdatum 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 andWGSas 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 the0 0 0 0 0 0 1file from step 3 adds no datum shift, so the data stays in the frameAUTOdelivered.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 theAUTOdatum with the same projection and zone when you import or deliver the result. Do not transform it from WGS 84 to the regional datum.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
AUTOdatum 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 containing0 0 0 0 0 0 1, as in the XGRIDS Lixel guide, not official WGS84-to-national parameters.National grid on another datum. If your deliverable is on a national datum other than the
AUTOdatum, for example OSGB36 / British National Grid, neither declaring the data nor the0 0 0 0 0 0 1file gets you there. Transform from theAUTOdatum with the official grid file, OSTN15 in Great Britain, and use exactly one transformation method, see Grid Files vs. Seven Parameter Transformations. The0 0 0 0 0 0 1file only applies to target systems on theAUTOdatum. If your scanner software cannot apply the grid file, deliver the point cloud on theAUTOdatum and transform it in software that can.Canada:
AUTOdelivers NAD83(CSRS)v7. Assign NAD83(CSRS) to data labelled WGS 84 rather than reprojecting it from WGS 84.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 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.
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, and check a control point.
Match the mountpoint to the target. Stonex's GOapp is an example:
AUTOfor a regional target system,AUTO_WGS84for aWGS 84 / UTM zonetarget.
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 explains the background.
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
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
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".
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 explains it and lists geoid models by region. Where the scanner software applies the geoid:
LixelStudio: a fixed Height anomaly for small sites, or a custom coordinate system with a Geoid
Trion Model: Geoid Model, or Elevation Fitting with control points
CoPre: Geoid model in the task
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
GOapp has no geoid field on the orientation page; apply the geoid in your downstream software
LiDAR360MLS: geoid as TIF file in the geoid folder, vertical coordinate system with Gravity-related
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"
PCMasterPro: New Vertical Model, with the matching PROJ grid file (.tif) in the /proj folder
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.
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 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.
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.pcmpneeds the Inertial Explorer license and base station data. The RTK workflowrtk.pcmpneeds 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 support@rtkdata.com 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
Connection settings
Host, port 2101, username and password as listed in the overview and in NTRIP Server Settings
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: all scanner guides and the shared RTKdata connection settings
XGRIDS Lixel K1, K2 & L2 Pro: LixelGO Ellipsoid setting and georeferencing in LixelStudio
XGRIDS Lixel L3: built-in RTK on the L3, fix check and LixelStudio target system
FJD Trion P1, P2 & S2: check marks in Trion Scan and GNSS Fusion in Trion Model
CHCNAV RS10 / RS30: fix check in SmartGo Neo and the CoPre task coordinate system
3DMakerpro Eagle & Raven: the
RTK_XXXXXX.bincheck and RTK Calibration in RayStudioStonex X200GO & X120GO: real fix checks in GOapp and the Real-time Orientation projections
GreenValley LiGrip: Coordinate System Settings: in the app and geoid heights in LiDAR360MLS
Emesent GX1: the NTRIP profile in Commander and the Base coordinate reference system in Aura
Emesent Hovermap RTK: rover start order, RTK Fix in Commander and base CRS in Aura
Inertial Labs RESEPI:
COMPUTED,NARROW INTEGERbefore takeoff and the WGS 84 / UTM label in PCMasterProGeoSun GS-200G / GS-100G: RTK:Fixed Solution in GeosunMeasure and coordinate settings in PCC
NTRIP Server Settings: regional hosts, port 2101 and how
AUTOselects a base stationNTRIP & GGA Essentials: why the caster needs your GGA position and what happens without it
Coordinate Systems & Datums: the full
AUTOdatum table and the background to datum offsetsUnderstanding Heights: ellipsoidal and orthometric heights, geoid models by region and where the geoid has to be set
Accuracy Expectations: the accuracy to expect by distance to the reference station, so you can tell a datum offset from normal RTK accuracy
Last updated
Was this helpful?