Keep dense reconstruction topocentric and apply exact final georeferencing

[lupionpe]

Summary

This ports the downstream ODX integration for the exact OpenSfM georeferencing fix.

It keeps dense reconstruction in topocentric coordinates for OpenMVS/texturing, exports geocoords artifacts separately, and applies the corrected projected transform only to final outputs such as the LAZ point cloud, textured OBJ / orthophoto path, and shots.geojson.

This PR depends on the matching WebODM/OpenSfM PR:
WebODM/OpenSfM#1

I intentionally did not point SuperBuild/cmake/External-OpenSfM.cmake at my personal fork. Before this ODX PR is merged, the OpenSfM PR should be merged first and the ODX OpenSfM GIT_TAG should be updated to that merged WebODM/OpenSfM commit.

Attribution

Credit for the core georeferencing fix belongs to Yann, from:
YanNoun/OpenSfM@446a4b0

I validated and ported the approach into the ODX pipeline. I have basic coding experience; most of the porting and integration work was done with AI assistance from Codex.

Validation context

I tested the same approach downstream in an ODM/NodeODM pipeline on two real RTK Mavic 3E survey areas. Each test was roughly 1,600,000 m² with about 2,000 images, using gcp.txt and geo.txt. In both areas, the observed final precision improved as expected from Yann's commit.

References

• WebODM/OpenSfM dependency PR: Fix projected reconstruction export georeferencing OpenSfM#1
• OpenDroneMap/OpenSfM equivalent PR: Fix projected reconstruction export to use a consistent local->proj transform OpenDroneMap/OpenSfM#48
• OpenDroneMap/ODM equivalent integration PR: Keep dense reconstruction topocentric while applying exact final georeferencing OpenDroneMap/ODM#2008
• ODM discussion / prior PR: Try to fix georeferencing accuracy  OpenDroneMap/ODM#1851
• Community discussion: https://community.opendronemap.org/t/what-is-your-biggest-pain-with-odm-opensfm/25791/22
• Community discussion: https://community.opendronemap.org/t/gcp-show-very-good-results-but-is-not-what-i-see-in-reality/25541
• C4 contribution model: https://github.com/OpenDroneMap/documents/blob/master/C4.md

Local checks

• python3 -m py_compile opendm/align.py opendm/osfm.py opendm/shots.py opendm/types.py stages/odm_georeferencing.py stages/odm_report.py stages/run_opensfm.py
• git diff --check

Not run locally:

• Full ODX/ODM processing, because this PR needs the matching WebODM/OpenSfM PR merged/pinned before an upstream build can exercise export_geocoords --mode projected.

[pierotofy]

Hey @lupionpe I appreciate the PR, but I don't trust that Codex did this correctly. Aside from the memory/performance issues that I can see at a glance, the fact that this was included:

export_geocoords --reconstruction --mode projected

Hints that this is for sure the incorrect approach. (I wrote --mode projected and it should have never been merged, as it was test code that never worked for our pipeline's purposes).

Perhaps we can open an issue to track the problem until there's time to fix it?

[lupionpe]

Thanks, that makes sense.

The --mode projected part is here because this PR was ported together with the matching OpenSfM PR, so I carried over the same interface from that side as well. If that path was only test code and not something that should be used in the real ODX/WebODM pipeline, then I agree this PR is not the right shape as-is.

I'll open an issue with the full context, links, and the validation I saw on my datasets so we can discuss the correct approach there.