Error/Offset between GCPs and point cloud

1. Introduction

This article will cover the most common causes for a point cloud to not align with GCPs, and how to solve these error or offsets.

The first distinction we will make, is between consistent error (bias) and inconsistent error.

2. Consistent GCPs error or bias

If the difference between the GCPs and the point cloud is consistent, also called bias, it means that the error shown is similar for all GCPs. The GCPs error should have similar size and direction, and is usually related to a human error.

This GCPs error can be solved during post-processing with a translation of the point cloud. Either using the 3D Accuracy from control points or the “Affine Transform LAS” PCT.

Below is a list of common reasons that this might occur.

2.1. Base station

If there is an error with the base station, this error will be translated first to the post-process trajectory, and later to the point cloud.

The base station position, antenna height and antenna calibration file must be correct. Please review the Base Station Settings post regarding the “base station”.

2.1.1. Antenna height

The following issues produce an offset on the Z-axis only.

Antenna height measurement
Check the antenna height value introduced in the GNSS receiver, if this value is wrong, changed it during trajectory processing –> Antenna heigh.

If you see all GCPs between 1.2 to 1.8 meters error in the vertical axis, the issue may be related to the antenna height. The team in the field left it as 0 meters, just introduce the correct value for the antenna heigh to solve the issue.

Antenna measurement type
There are different antenna measurement types, but Trajectory Processing only works with “bottom of antenna height”. If you used a different measurement type during the data collection, add/subtract the height difference from the “Antenna height”.

2.1.2. Coordinates of the survey nail

This issue can produce an offset on the 3-axis, this means in horizontal and vertical.
If the base station was set up in a known point, a mismatch between the CRS of the point and the CRS added in trajectory processing will create a mismatch. Trajectory processing only works with geographical coordinates and ellipsoidal height in meters.

• Location:
  • Geographical coordinates in Latitude & Longitude
  • Ellipsoidal height in meters (common mistake to add orthometric heigh instead of ellipsoidal)
• Frame:
  • By default, is selected NAD83(2011), make sure to change it if you are not working in US.
  • If you are working in WGS84, select ITRF2014 and change the Epoch to the cycle date.
• Epoch, leave it by default, unless you work with WGS84.
• Ellipsoid, leave it by default.

Note: LP360 will show you the difference between introduced survey nail coordinates and the rinex file coordinates. If these are bigger than 10 meters you may want to review them.

2.1.3. Coordinates of an unknown point – OPUS and Trimble RTX

This issue can produce an offset on the 3-axis, this means in horizontal and vertical.
If the base station was set up in an unknown point, most users will rely on Trimble RTX or OPUS to compute the base station coordinates. These services allow you to set up the base station in an unknown point, but the drawback is the accuracy of the base station position. In north America and Europe, the accuracy achieved can be better than 3cm in each axis, however there is a requirement of a minimum 2-hour observation time.

2.2. Ground Control Points & Check Points

The issue is not always with the point cloud generated, but with the points we compare. Any issue with the GCPs will look like an issue in the point cloud.

2.2.1 Accuracy

This issue can produce an offset on the 3-axis, this means in horizontal and vertical.
The GCPs always have an accuracy associated with it. Make sure this accuracy is always better than the accuracy of the point cloud. If the offset shown is smaller than the accuracy of the GCPs, the issue is with the GCPs not with the point cloud.

2.2.2. RTK rover measurements

Good practices using an RTK rover to survey our Check Points:

• Antenna height, any error on it will be reflected in the Z-axis
• Make sure there is enough satellite coverage in the area
• Make measurements of a minimum of 10 seconds
• In North America and Europe RTK can provide accuracies better than 3cm in each axis
• If you are surveying them in a different day, check the KP Index to monitor the solar activity 3-Day Forecast | NOAA / NWS Space Weather Prediction Center . If the ionospheric error is to severe, the measurements may be compromised.

2.2.3. Coordinate Reference System

This issue can produce an offset on the 3-axis, this means in horizontal and vertical.
The GCPs and Check Points should be in the same coordinate system as the point cloud.

• Horizontal datum, attention if there are multiple iteration of the same datum.
  • Projection
  • Zone, attention if you work in an area between 2 zones.
• Vertical datum, ellipsoidal or orthometric
  • Orthometric, attention if there are multiple iteration of the same geoid.
• Epoch; Only important if working with WGS84. In this case, it is recommended to process the flight in the Epoch of the GCPs.
• Units, attention between US feet or International feet.

2.3. Lever arms values – Hardware

The correct lever arms must be used during PPK/RTK processing, or you may see a GCPs error relative to the flight line direction. Please review the Lever arm offsets post for more information. Did you update the lever arm offsets in the payload before flying the payload on a new airframe? Review the Rover Data Summary section of the POSPac QC Report for the installed lever arm values.

3. Inconsistent error

An inconsistent offset between GCPs and the point cloud is usually connected to the data collection quality. It may not be possible to solve these issues in post processing as they are very complex. In general, it is recommended to repeat the flight.

3.1. Source of error

Usually these errors are connected to the quality of the trajectory, the best place to look for them is in the Trajectory Processing Quality report. Either QC-Only (Realtime) or PPK (single base, PPRTX or Smartbase).

The 3 pieces that influence the Trajectory are:

• Ephemerides: they are always used in PPK and Trajectory Processing will always use the best performing Ephemerides. You may only encounter an issue with them if you try to process the same day as the data acquisition. A good practice is to wait 48h to get use the rapid solution.
• Base station: Rinex file or GNSS Static data. If there is an error with the base station data, this will affect the overall quality of the trajectory. Quick way to understand if the issue is withing the base station is to process the data using “Trajectory Processing QC-Only (Realtime)”. Check the following article “Probable Resolution 1”.
• Raw Trajectory: GNSS Inertial data or .T04 file. If there is an error with it, it will appear in the “Trajectory Processing QC-Only (Realtime)” and in any other PPK processing (Single base, PPRTX or Smartbase). Explained below how to QC it.

External sources of error:

• Flight during a day with high KP Index. 3-Day Forecast | NOAA / NWS Space Weather Prediction Center
• Missing/failed alignment during the beginning or end of the flight.
• IMU drift, long strait flight lines.

3.2. How to identify these error?

Check this article to know more about the Trajectory Processing Quality Report
If you reviewed the article and still suspect about an issue, there are 2 more plots to check. Only continue reading if you determine that the issue is related to the Raw trajectory.

3.1.1. Smooth Solution Status

This plot shows the solution type for the trajectory.

• Constant 0: Normal flight.
• Spikes on the beginning or the end; Acceptable, shown an issue with during the take off or landing. Usually connected to the quality of the GNSS signals.
• Single spike in the middle of the flight; Compromised, there was an issue during the flight. There may be a flight line misaligned with the rest. Strip Adjustment may be able to fix the issue.
• Plot with a different result than 0: Compromised, the issues with the flight may not be recoverable. Recommended to repeat the flight.

3.1.2. Smooth Performance Metric

This plot will show what was the accuracy of our trajectory for each axis. But by analysing the Down Position Error RMS, we can discover the source of error.

• Flat line: Acceptable. Normal flights have a plot that shows the vertical axis as a relatively flat line (except take off and landing)
• Curve line: Compromised. Indicates a constant loss of accuracy during the flight, this is usually connected to IMU drift. Review the flight lines length, if they are above 100 seconds, this is highly possible the reason. Repeat the flight, with shorter flight lines.
• Step line: Compromised. Indicates a change of accuracy during the flight. This usually happens during a flight line turn. What will happen is that the flight will be divided in 2 or more zone (before and after the step), where the flight lines of each zone match with each other but the zones mismatch. This can be consequence of a missing/failed alignment in the beginning/end. Strip Adjustment and Control Points can fix the issue.

4. Photogrammetry GCPs Error

When working with photogrammetry, it is good to review also the following.

4.1. Camera calibration

For photogrammetric PPK/RTK processing, it is important to have a valid camera calibration. Verify that the correct camera calibration is used when processing images to generate a point cloud in Agisoft, Pix4D, Context Capture, etc.

The camera calibration values are written inside the “Export photo package”:

• Agisoft values: written in the “SystemCalibration” file and in the exif photos information.
• Pix4D values: written in the “Starboard_*_P4D” file.
• Context Capture: written in the “Starboard_*_P4D” file (same values as Pix4D).

4.2. Camera Positions

PPK/RTK processing – updated camera positions, with the correct accuracy level (Example: 0.02 m – fixed) must be used in the photogrammetric processing software (Metashape, PIX4D, Context Capture, etc.)