The Problem with Terra
QC, Quality Control, is a vital step in our survey workflows. We all know about junk in, junk out. But sometimes even if you put pearls into the system you can inadvertently get swine out of the other end. Recently our QC processes showed up some serious issues with co-ordinate system transformations in the most commonly used LiDAR first-stage processing platform, DJI Terra. Read on to find out the issue and how to solve it.
With all LiDAR data, a proprietary tool has to be used to extract and process the raw sensor data before any further work can be done. In the case of DJI equipment, this tool is DJI Terra. What we have uncovered is that DJI Terra is not accurate in reprojecting from its native co-ordidinate system to the projection standard for the UK, based on Ordnance Survey.
How QC Revealed the Issue
The basic principle of our QC is to hold back reference data in such a way that it stands completely separate from the workflow. Our main weapon is checkpoint data, GPS observations which never interact with the gathering of drone data. By comparing those checkpoints with the drone data at the very end of the process we can see if things have gone wrong.
In this case, we process our drone data in its native reference to ETRS89, the European localisation of WGS84, the global standard for angular GPS co-ordinates. We then export our data from Terra using its inbuilt transformation to OSGB36 (the UK standard), at which point we can see if our checkpoints sit accurately on the checkerboard markers in the data. In the case of Terra, they do not. The errors are in fact considerable, roughly 400mm lateral shift which is way outside of our survey tolerances.
In the image below, the error can be seen clearly within the red circle. The marker should stand precisely in the centre of the checkerboard.
Evidencing it’s a Transformation Issue
Suspicions that Terra is using an inaccurate transformation between co-ordinate systems can be seen right at the start of the processing. One of our checkpoints is directly at the position of the RTK base station which communicates corrections to the drone during flight. By loading the drone data as ETRS89 into Terra, but loading the checkpoints in their native OSGB we can instantly see the discrepancy, even before full processing of the raw LiDAR data.
How we get around the issue
There appears to be only one solution: do not perform co-ordinate transformations within Terra. In this case, this gives us a headache because we optimise our data subsequently in Terrascan for strip alignment and cleaning, and Terrascan does not accept non-Cartesian ETRS89 data. The one transformation we do allow Terra is from ETRS89 to WGS84, but everything else must be done further downstream. And, just to prove the case, here is our beautifully aligned finished data.
Leaping Wing provides a full range of LiDAR survey services, including standard CAD and BIM outputs. For more information, contact us today for a free consultation.