Georeferencing inaccuracies on large RTK + GCP datasets

[lupionpe]

On large survey areas, I can get very good GCP error numbers while still seeing a visible mismatch in the final real-world outputs (orthophoto / point cloud) relative to reality.

In my case, I tested on two different areas, both captured with RTK on a DJI Mavic 3E, each roughly:

• ~1,600,000 m²
• ~2,000 images
• gcp.txt
• geo.txt

Reference discussion: https://community.opendronemap.org/t/gcp-show-very-good-results-but-is-not-what-i-see-in-reality/25541

[pierotofy]

Yes that's an outstanding issue with large areas, the entire pipeline needs to keep coordinates in topocentric coordinates until you're ready to export the outputs. Second part of the problem, ODX always outputs in UTM, which introduces shift over large areas, so for accurate results one must use other coordinates system (the same ones as the GCPs)

[lupionpe]

Yes that's an outstanding issue with large areas, the entire pipeline needs to keep coordinates in topocentric coordinates until you're ready to export the outputs. Second part of the problem, ODX always outputs in UTM, which introduces shift over large areas, so for accurate results one must use other coordinates system (the same ones as the GCPs)

Would you say that the changes initially proposed/developed by Yan is a good solution/start point, or should this be handled from another perspective?

[pierotofy]

Yann's changes work correctly for OpenSfM. But they don't help with ODX.

[lupionpe]

Okay, but just for the curiosity, this is the base for the fix in ODX or we could keep using a not-fixed OpenSfM and only ally the fixes direct in ODX?

[lupionpe]

I have been testing a possible fix for this.

I do not think the main issue is that the GCP error numbers are wrong. The problem seems to happen later, when ODX/OpenSfM exports the transformed reconstruction and downstream steps consume the saved reconstruction.json.

In my test, the projected camera positions looked correct in memory. But after OpenSfM saved the reconstruction to JSON and loaded it again, the camera origins drifted by around decimeters. On my dataset, that was enough to be visually relevant in the final output.

The concrete issue seems to be the save/load boundary for projected shot poses.

OpenSfM serializes rotation as a Rodrigues vector. If we compute the projected pose origin using the non-serialized rotation matrix, then write the pose to JSON, the rotation can change slightly when converted to the serialized representation. After reload, the same translation no longer preserves the same camera origin.

The fix I tested is to compute the translation from the exact rotation representation that OpenSfM will serialize:

def _set_pose_rotation_and_origin(pose, rotation_matrix, origin):
    rotation_vector_pose = pygeometry.Pose()
    rotation_vector_pose.set_rotation_matrix(rotation_matrix)

    serial_pose = pygeometry.Pose()
    serial_pose.rotation = np.array(rotation_vector_pose.rotation)
    serial_rotation = serial_pose.get_rotation_matrix()

    pose.rotation = np.array(serial_pose.rotation)
    pose.translation = list(-np.dot(serial_rotation, origin))

Then, instead of:

shot.pose.set_rotation_matrix(rotation_matrix)
shot.pose.set_origin(p0)

use:

_set_pose_rotation_and_origin(shot.pose, rotation_matrix, p0)

I opened this PR as the proposed OpenSfM-side fix:

WebODM/OpenSfM#2

The PR is split into two commits:

1. Port Yan's projection-transformer implementation.
2. Preserve the WebODM/ODX reconstruction.geocoords.json contract, including XY offset handling and serialized shot-pose origins.

Credit for the projection-transformer direction goes to Yan's OpenSfM commit:

YanNoun/OpenSfM@446a4b0

The extra part in my PR is mainly to adapt that idea to the WebODM/ODX OpenSfM version and keep ODX's expected exported reconstruction contract correct.

After this change, I reprocessed the same dataset and checked the saved artifacts directly.

For my test dataset:

• opensfm/reconstruction.json camera-origin drift after save/load went to effectively zero
• max shot XY drift was about 1e-12 m
• sparse point drift was 0 m across about 1.37M points
• opensfm/undistorted/reconstruction.json also preserved the corrected camera origins
• visually, the final output now looks satisfactory in my test

This does not prove the full fix is complete for every dataset, especially multi-camera rig cases, but it does seem to fix one concrete serialization problem in the ODX/OpenSfM georeferencing path.