Fix projected reconstruction export to use a consistent local->proj transform

[lupionpe]

Summary

• port Yann Noutary's projected georeferencing fix from YanNoun/OpenSfM@446a4b06624f38f7dc9922cf737fd3e806e75636 onto OpenDroneMap/OpenSfM:ODM
• replace the projected reconstruction export path with the consistent local-to-projected transform/Jacobian logic while keeping affine exports intact
• keep projection parsing consistent with the new transformer flow and add focused tests for the projection helpers

Attribution

The core solution here was proposed and implemented by Yann Noutary in the commit linked above. This PR ports that fix onto the current ODM branch and packages it for review.

I have some basic coding experience, but most of the porting / validation / integration work for this contribution was done with AI (Codex).

Context

Related discussions:

• Try to fix georeferencing accuracy  ODM#1851
• https://community.opendronemap.org/t/what-is-your-biggest-pain-with-odm-opensfm/25791/22
• https://community.opendronemap.org/t/gcp-show-very-good-results-but-is-not-what-i-see-in-reality/25541

Validation

My conclusion after downstream validation is that this does seem to solve the root cause.

I ran two real tests on two different areas with roughly:

• ~1,600,000 m² survey area
• ~2000 images
• gcp.txt + geo.txt
• RTK on the drone (Mavic 3E)

In both cases the observed precision improved, as expected.

Checks I could run locally here:

• python3 -m py_compile opensfm/geo.py opensfm/io.py opensfm/actions/export_geocoords.py opensfm/test/test_geo.py opensfm/test/test_io.py
• downstream end-to-end validation in a custom ODM / NodeODM deployment on Debian 12
• native OpenSfM unit tests are not runnable in this shell because the local environment here does not have the compiled OpenSfM extensions

[jrstear]

This works for me — great work!

Ran a 6 km aztec highway corridor (1385 DJI M3E images, 41 GNSS control
points, ~3° off UTM central meridian — close to worst-case for the
linearized affine) against unpatched v3.6.0 and v3.6.0 with this PR +
the companion OpenDroneMap/ODM#2008 applied:

• CHK RMS_H: 1.44 ft → 0.28 ft (~5× better)
• GCP RMS_H: 1.62 ft → 0.08 ft (~20× better)
• Beats Pix4D on the same dataset (0.28 vs 0.72 ft CHK)
• Reconstruction RMS_H unchanged — fix is surgical; bundle adjustment untouched

Full write-up, charts, and per-point reports:
https://github.com/jrstear/geo-samples/tree/main/odm-ortho-error