← All articles IFC

The IFC unit trap that makes a 39 m culvert 1 km long

5 August 2026 · 3 min read

We hit this on two real culvert models from a live civil project, and it is worth writing down because nothing about it looks like a bug until you measure something.

The model opened. The geometry was right. The proportions were right. The only thing wrong was the size: a culvert we knew to be 39.5 m long came out at 1,004 m.

What the file actually says

An IFC declares its own length unit near the top of the file. These two models contained this:

IFCCONVERSIONBASEDUNIT(.LENGTHUNIT., 'inch')

The coordinates in the body of the file were millimetres. So anything that trusts the declaration multiplies by 25.4 and produces a building the size of a small suburb.

39.5 × 25.4 = 1,003.3. That is the whole bug.

Why this is worse than it sounds

A wrong unit does not look like an error. It looks like a model.

You can open it, orbit it, section it, and everything is internally consistent — because every dimension is wrong by the same factor. There is no visual tell. The only way to notice is to measure something whose real length you already know, and that is exactly the check nobody does on a file they have just received.

And the failure mode is quiet. If you measure a clearance off that model to decide whether a pipe fits, you get a number, to two decimal places, that is confidently and completely wrong.

Why software can't just fix it for you

The obvious answer is "detect it and correct it automatically". We deliberately don't, and it took us a while to be sure that was right.

A mis-declared unit and a genuinely enormous site model are identical in the geometry. There is no property of the file that distinguishes "this is in the wrong unit" from "this is a 1 km linear infrastructure model", because 1 km linear infrastructure models exist and get opened too. Anything that silently rescales will eventually silently rescale something that was correct — and now the tool has introduced the error instead of the exporter, which is worse.

So ARfield reads the declared unit, and when the resulting size is implausible it offers a one-tap rescale with the corrected figure shown, rather than deciding for you. Confirming it rebuilds the GLB and the USDZ, so the fix survives sharing and native AR rather than being a display-only trick that reverts the moment somebody opens the link on a phone.

What to do with your own exports

  • Measure one known dimension on any IFC you receive, before you trust any other

measurement from it. A door, a grid spacing, a column centre-to-centre. It takes ten seconds and it is the only check that catches this.

  • If it is out by exactly 25.4, you have this bug: millimetres declared as

inches. Out by 1,000? Metres declared as millimetres, the other common one.

  • Tell your civil team which export preset produced it. This is a setting, not

bad luck, and it will keep happening on every file from that workstation until someone changes it.

None of this is a criticism of anyone's modelling. The geometry in both of those culvert models was fine. It is the six characters between two quote marks in the header that were wrong, and nothing in the normal workflow ever shows them to you.