Survey-coords export rotates geometry by 2 × angleToTrueNorth (Revit v3 connector) — quantitative reproduction, follow-up to #15779

Hi guys,

sorry for this AI generated topic, but Claude found out about this, so I lets give him some credit (trimmed it down a bit, but left the AI dashes in.. :sweat_smile:)

Following up on @rklaschka’s thread #15779 (auto-closed without public resolution): we hit the same defect on the v3 Revit connector and have a precise reproduction plus a likely root cause. Our case has no toposurfaces — regular building model on the UK OSGB36 grid, shared coords set via Acquire Coordinates — so the bug is broader than the topo-tool theory.

The problem in plain terms

When we publish from Revit with Reference Point = Survey, the building comes out the right distance from the OSGB grid origin, but rotated to the wrong place.

The numbers

Survey Point in Revit, real OSGB coords (west London):

N +179 383.585 m,  E +510 914.175 m

Same model, Survey-publish, an actual element near the SP:

start = (122 479.56, 527 504.09, 62.45) m

referencePointTransform rotation column-0 = [0.876358, −0.481660, 0]angleToTrueNorth ≈ 28.794°.

Distance from OSGB origin Bearing atan2(N,E)
Real (Revit) 541 490 m 19.346°
Speckle 541 537 m 76.928°
Δ only 46 m apart −57.582° ≈ −2 × angleToTrueNorth

So the bearing is off by exactly twice the project’s angle to true north. To check: rotating Speckle’s output by −2θ around the OSGB origin lands within 72 m of the real SP — and that 72 m is consistent with the actual in-model distance from the SP to that specific beam.

Where the bug likely lives

In ToSpeckleSettingsManager.cs (Survey branch in speckle-sharp-connectors):

translation = Transform.CreateTranslation(surveyPoint.Position);
rotation    = Transform.CreateRotation(XYZ.BasisZ, angleToTrueNorth);
matrix      = translation.Multiply(rotation);   // T · R

Our guess: the connector both (a) rotates the geometry by R before publishing it, and (b) stamps R into the published matrix as well. So anyone applying the matrix downstream rotates a second time, ending up with R · R = R² total. One rotation too many.

That also matches @rklaschka’s observation that survey-publish models “don’t locate correctly… but do locate relative to each other”: a single rotation about the origin preserves every distance and angle inside the model — only its placement on Earth breaks.

Hey @tlmn ,

We’ve addressed this issue in 3.20 release. It’ll be out in 5 minutes. Check once its released and let us know if it matches your expectations.

1 Like