01
Collect both tracks
SLAM poses from the reconstruction, GNSS fixes from the recording, matched in time.
Georeferencing
Georeferencing a point cloud with GNSS data
Georeferencing anchors a locally built SLAM map to real-world coordinates, so the map lines up with the actual planet instead of with wherever the recording happened to start.
Why a SLAM map is not georeferenced by default
LiDAR SLAM builds its map from relative measurements: each scan is registered against the previous ones, with IMU data helping through fast motion. The result is internally consistent, and the origin is the sensor pose at the first frame. Nothing in that data says where on Earth the robot was, which way is north, or what the scale drift looks like over a long run. Absolute position has to come from outside, and in field robotics that usually means GNSS.
SLAM trajectory aligned to GNSS
How the alignment works
Conceptually there are two trajectories describing the same drive: the SLAM trajectory, smooth and locally accurate but slowly drifting, and the GNSS track, noisy per fix but absolutely referenced and drift-free over long distances. Georeferencing finds the transform that best matches one to the other, then applies it to the whole map. Because SLAM drift accumulates rather than staying constant, a single rigid transform is usually not enough: the correction is estimated along the trajectory so that the far end of a long run lands in the right place too.
02
Estimate the transform
Fit the SLAM trajectory to the GNSS track, correcting accumulated drift instead of assuming there is none.
03
Apply to the map
Every point moves with the trajectory, producing a cloud in a real-world reference frame.
FlexCloud does this step
LidarFlow runs FlexCloud from TUM for georeferencing, the same way it runs GLIM for reconstruction. Credit where it belongs: these are the engines, and LidarFlow is the managed path to running them on your recording without setting up either.
What you get, with and without GNSS
No GNSS in the recording
You still get a locally consistent map: correct shapes, correct metric scale, usable for inspection, measurement inside the map, and simulation. It just has an arbitrary origin.
GNSS present
The same run also produces a georeferenced map, so it can be merged with other sessions, dropped onto a base map, or handed to a downstream localisation stack.
Frequently asked questions
What is WGS84 and why does it matter for point clouds?
WGS84 is the global reference frame used by GPS and GNSS receivers. A point cloud expressed in WGS84 (or a projected frame derived from it) can be overlaid on maps, merged with other surveys, and reused across sessions. A raw SLAM map has none of that: its origin is wherever the recording started.
Can I georeference a point cloud without GPS or GNSS data?
Not automatically. Without an absolute reference, SLAM can only produce a locally consistent map. You can still align it manually against known control points in another tool, but LidarFlow will not invent coordinates it does not have.
What accuracy can I expect from GNSS-based georeferencing versus RTK?
It depends entirely on the receiver and conditions in your recording, so we will not quote a number. As a rule, standalone GNSS fixes carry metre-level error, while RTK or PPK corrections bring the absolute reference down to centimetre level. Georeferencing cannot be more accurate than the GNSS track it is aligned to.
What tool does LidarFlow use for georeferencing?
FlexCloud, the open-source georeferencing package from TUM. LidarFlow runs it in production rather than reimplementing the alignment step.
Free while we are testing
Have a recording with a GPS topic? Upload it and see the aligned map.