You open an IFC file and the building shows up as a speck in the corner of the viewer. Or you overlay the architectural and structural models and one sits tens of metres — sometimes kilometres — away from the other. It is tempting to conclude the model is broken. In most cases it is not corrupt data: it is a coordinate-system mismatch. Once you can tell the causes apart, the fix is usually just a matter of settings.

Bottom line first — offsets almost always come from one of three things

Different reference points — one model is exported relative to the project origin, the other relative to survey coordinates.
True north vs project north rotation — the site orientation and the drafting orientation differ, so overlaid models are rotated apart.
Survey coordinates baked in / precision overflow — six-to-seven-digit geographic coordinates land directly on elements, throwing the model far away and making it jitter.

IFC coordinates are defined by nesting

An IFC element does not carry a world coordinate directly. Instead it is placed relative to its parent’s local coordinate system. A Site contains a Building, which contains a Storey, which contains walls and columns — each with its own origin, and each transform (translation + rotation) stacking on the one above to produce the final position.

An element's world coordinate = the Site → Building → Storey → element transforms applied in sequence

The mechanism is robust, but it cuts both ways: if the origin or orientation is wrong at any one level, every element below it drifts together. When you see an offset, the fast path is to isolate whether the element, the storey, the building or the site is the culprit.

Do not conflate the three reference points

Coordinate trouble almost always traces back to disagreement over “which point is zero.” Three reference points show up in IFC / BIM.

🏳 Project origin

The drafting (0,0,0). Usually placed near the model — a building corner or a grid intersection. Also called the project base point.

📐 Survey point

The point that ties the site to real-world survey coordinates. The survey point carries the site's easting/northing (hundreds of thousands to millions).

🌍 Geographic CRS

A projected coordinate system defined by e.g. an EPSG code (UTM, national grid). IFC4 links it with IfcMapConversion.

If architecture and structure share the same drafting origin, they overlay cleanly as long as the export settings match. But when one is exported relative to the project origin and the other relative to survey coordinates, they end up separated by exactly the site distance between those references. That is the classic “I overlaid them and one is far away” case.

How to tell: if only one model has extreme coordinate values (element positions in the hundreds of thousands to millions of mm), that model was exported in survey coordinates. Overlay it with an origin-near model (hundreds to tens of thousands of mm) and they will not align.

True north vs project north

A site rarely faces true north. In drafting it is normal to align the building’s main axes with the screen (project north), while daylight, wind and code analysis are all referenced to true north. IFC preserves this difference as the true north direction.

True north (TN) is rotated by angle θ from project north (PN). If the model you overlay ignores θ, the whole building rotates apart

When sender and receiver disagree on how north is handled, the whole model rotates about the site’s rough centre and drifts. If the origin looks right but the offset grows for elements farther out, suspect a rotation (true north) mismatch rather than a translation.

The “off in deep space” problem

The most disorienting symptom is a building displayed hundreds of thousands to millions of mm from the origin. The cause is that real-world survey coordinates (a national grid, UTM, etc.) were written straight onto the elements. National plane coordinates can be tens of thousands of metres; UTM reaches hundreds of thousands to millions of metres.

Survey coordinates written directly onto elements push the model far from the origin — and the larger the values, the more floating-point rounding makes it jitter

It is not just "far away": with large coordinates, 3D viewers that work in single precision (float32) run out of significant digits, so faces can flicker or elements shimmer. "Far" and "loss of precision" come together. Many viewers subtract the centroid before drawing to mitigate this, but aligning the reference in the source data is the real fix.

IfcMapConversion — the right bridge to map coordinates

You want to avoid the “deep space” problem yet still carry real-world coordinates. That is exactly what IfcMapConversion and IfcProjectedCRS, introduced in IFC4, are for. The idea is simple: build the model in clean local coordinates near the origin, and attach the transform to map coordinates (eastings offset, northings offset, rotation, scale, and the EPSG code) as separate metadata.

Recommended

Local coordinates + IfcMapConversion

All elements near the origin (thousands to tens of thousands of mm)
Real-world position expressed as transform parameters
Precision stays stable and elements overlay well
The CRS is stated explicitly via an EPSG code

Avoid

Survey coordinates written onto elements

Element coordinates reach millions of mm
Floating-point jitter appears
CRS information tends to be lost (only numbers remain)
The receiver is left guessing "relative to what?"

In IFC4.3 this georeferencing matters even more for the wide extents of infrastructure (roads, bridges, tunnels). The larger the area, the more the “hold the real-world position as a transform” design pays off.

Diagnosing when models refuse to line up

You want to overlay architecture, structure and MEP to coordinate and check for issues, but nothing aligns — the single most common question in practice. Work through it in this order.

Check the magnitude of the coordinates

How large are each model's element coordinates? If only one is in the millions of mm, it is a survey-vs-local mismatch.

Translation or rotation?

A constant offset means translation (base-point difference). An offset that grows for distant elements means rotation (true-north difference).

Align the export settings

The root fix is to match "shared coordinates / project base point" in each authoring tool and re-export.

Align in the viewer

If re-exporting is impractical, give each model an offset (translation / rotation) on the overlay side to line them up.

The ideal is to agree a shared base point and CRS for the project at the very start. If every party exports with the same project base point, the same true north and the same EPSG, the models simply overlay. Models gathered without that agreement will need after-the-fact alignment.

✓

Alignment in Bimly: when you overlay several IFC files in one project, you can toggle each model's visibility and give it an XYZ offset to line it up. The offset is treated as a display transform — the original element coordinates are never rewritten. So you can adjust it as often as you like, and the alignment carries through to shared links too.

A checklist for fixing the drift

1. Isolate the level

Find whether the origin/orientation is wrong at the element, storey, building or site level.

2. Check the magnitude

Coordinates in the millions of mm mean survey coordinates. Do not mix them with origin-local models.

3. Suspect true north

If distant elements drift more, it is rotation. Match the true-north setting on both ends.

4. Agree a shared reference

Standardise the project base point, true north and EPSG across the project, then re-export.

5. If you cannot fix it, align on overlay

Use viewer-side offsets to line the models up pragmatically.

Export pitfalls in general (units, lost properties, etc.) are collected in IFC export tips. Checking those alongside coordinates removes most handover accidents.

Summary

IFC coordinates come from nested transforms: Site → Building → Storey → element. Isolate drift by level.
There are three reference points — project origin / survey point / geographic CRS (EPSG). Conflate them and models will not align.
A constant offset is a base-point difference; drift that grows with distance is a true-north (rotation) difference.
Writing survey coordinates onto elements causes “deep space + loss of precision.” Holding them as local coordinates + transform via IFC4’s IfcMapConversion is the right way.
For multiple models, the best move is to agree a shared base point and CRS up front. Failing that, align with viewer-side offsets.

Coordinates are unglamorous, but overlay and clash checking cannot even begin until they agree. Put another way: simply making a habit of checking two things first — magnitude and rotation — turns most “the model is broken” incidents back into a settings conversation. For symptoms beyond position — won’t open, blank screen, empty properties — see common IFC problems and fixes, and pair this with the fundamentals in what is IFC.