What does “Post-Processing” mean?
Post-processing means you record all raw sensor data during the mission, and you compute the final position solution later (typically back in the office). While you are driving, flying, or scanning, you don’t need a precise real-time position at all – the GNSS receiver, IMU, odometer, LiDAR, cameras, etc. are basically “data loggers”. Because of that, you also don’t need an RTK radio link, mobile internet, or any real-time correction service during the measurement.
Do you really need real-time positioning?
Many systems today deliver a real-time RTK/INS solution, so it feels “natural” to use it as the final truth. But a good question is: do you actually need centimeter-level in real time, or do you need centimeter-level for the final result?
For a lot of applications, real-time is not required: infrastructure monitoring (rail, road), urban mapping, mobile mapping in general, surveying flights, LiDAR point cloud generation, 3D city models, corridor mapping, asset inventories… In these cases, a rough real-time position is often enough to drive through the area (or to fly the plan), and the accurate solution can be computed afterwards with much better quality.
Why is Post-Processing much more simple operationally?
Operationally, post-processing is often a relief, because the field setup becomes less “fragile”. You don’t need the sensors to tightly communicate with each other to produce a fused solution live – they just need stable time stamping and reliable recording. If one component has a hiccup, you still have the data.
Also, you are not dependent on internet coverage or RTK correction delivery. No “we lost the link, so the solution is now degraded”, no roaming issues, no SIM card problems, no base station connection that suddenly drops exactly when you enter a city center. This is exactly the kind of situation where people later search for things like “Novatel SPAN jumps”, “IMU drift in tunnel” or “RTK connection losses”.
Another practical topic: many real-time inertial systems require an alignment phase. In post-processing, you can often be more flexible: you start recording, start your mission right away, and later the software can use the full dataset to estimate biases and the initial attitude much more reliably.
With post-processing, the quality control happens afterwards with proper tools and full context. A pilot or driver can focus on steering and traffic rather than blinking instrument status lights.
Why is Post-Processing much more accurate?
The main reason is powerful: real-time algorithms only know the past and the present. Post-processing algorithms know the past, the present, and the future. That means you can use the complete measurement set to compute a globally consistent trajectory.
A classic example is a GNSS outage, like driving through a tunnel. In real time, the INS error grows and often “snaps” back at the exit. In post-processing, the filter can use measurements after the tunnel exit to also improve the estimate inside the tunnel. The error shape becomes smaller, more symmetric, and the peak error is dramatically reduced.
From an economic perspective, this means you can achieve the same positioning accuracy with much cheaper instruments: an IMU cheaper by a factor of 10 or more can be sufficient, and you save on RTK subscriptions.
Why is Post-Processing more robust and resilient?
Real-time systems can fail due to communication glitches or timing issues. In post-processing, you have more options: detect issues more reliably, re-run with different settings, exclude corrupted segments, or compare multiple GNSS processing strategies. This gives you a second chance to save a mission that might have been lost in real-time.
Again: Do you REALLY need real-time positioning?
If your application is mapping, monitoring, or UAV LiDAR, real-time is rarely a hard requirement. Identify which decisions truly must be made live, and where “later, but accurate” is acceptable. Very often, post-processing is actually the more realistic option for high-quality results.
