The Difference Between IFC Geometry and IFC Data

An IFC file arrives. You open it in a viewer. The building is there, the colors look right, you can spin it around and everything is where it should be. Everyone nods. The delivery gets accepted.

Here is the problem. You just checked half the file. Maybe the less important half.

An IFC file carries two different things: geometry and data. The geometry is what you see. The data is what everything downstream actually runs on. And they fail separately, which is why a model that looks perfect can be worthless, and a model that looks rough can carry exactly what the project needs.

Geometry is the picture. Data is the answers.

Geometry answers one question: what shape is this and where is it? That is genuinely important. Coordination, clash detection, visual review, all of it runs on geometry.

Data answers every other question. What is this element? What is it made of? What is its fire rating, its diameter, its wall thickness? Which system does it belong to, which storey, which zone? Who is responsible for it, and at what status?

Quantity takeoff runs on data. Automated checking runs on data. Facility management runs on data. Cost, scheduling, classification, requirements validation. Almost every workflow that makes BIM worth the effort reads properties, not shapes.

The viewer shows you the geometry beautifully. It shows you the data only if you go looking, element by element, property by property. That asymmetry is why so many bad files get accepted. The half that is easy to see gets checked. The half that carries the value does not.

The file that looks fine

The most dangerous IFC file is not the one that fails to open. That one gets caught immediately. The dangerous one is the file where the property sets exist but every value is blank.

You open it. You see Pset_WallCommon on the walls. It looks like the data is there. An automated check that only tests for the presence of the property set passes it. Then someone downstream tries to use the fire ratings, and there is nothing inside.

Empty property sets create the illusion of data. That illusion survives longer than a missing file ever would, and it costs more when it finally breaks. Perfect geometry makes it worse, because a good-looking model buys unearned trust for the data underneath it.

The fix is a habit: check geometry and data separately, every time. Spin the model, yes. Then open real elements and read real values.

What this looked like on site

I spent 11 years on Norwegian construction and infrastructure projects. On my last one, the new Oslo water supply program, the models were production data. The site placed reinforcement directly from model data, and installed elements were checked back against model properties. A pipe with the right diameter, the right thickness, the right part in the right place.

Notice what did the work in that sentence. The geometry put things in the right place. The data said what each thing had to be. If either half was wrong, the site was wrong. Nobody on a site like that confuses a nice-looking model with a correct one, because concrete does not care how the viewer renders it.

That experience is why I refuse to treat "the model looks good" as an acceptance criterion. It is one criterion. The property check is the other, and it is the one that fails silently.

The two halves do not even have to live together

Here is the part that changes how you think about authoring, and I learned it from a guest on my podcast who works on railway projects in Germany with more than 500 IFC files.

His team went through every property requirement on the project and asked one question: does this actually need to be entered in the authoring tool? The answer was no for 80 percent of them.

So they moved them out. Authoring tools export the geometry. The data lives in a database, entered by the person who actually knows it, validated against the requirements at the point of entry. The two halves get merged into IFC whenever a delivery needs them, using open tooling.

Think about what that means. Most of the information in an IFC file never needed to pass through the modeler at all. When you force it through the authoring tool anyway, you get the classic failure chain: the modeler does not know the value, types something to fill the field or leaves it blank, and the error is discovered weeks later, if ever.

Geometry and data are separable. Treating them as one thing, produced by one person in one tool, is exactly why data quality in our industry is as bad as it is.

What to do with this

Three habits, all free.

When you receive a file, check the two halves separately. Geometry in the viewer, data by opening real elements and reading real values.

When you write requirements, write them against data content, not against appearance. A requirement a machine can check beats a requirement a human has to interpret.

And when data quality is chronically bad on a project, stop blaming the modeler first. Ask whether the person entering the data was ever the right person to know it. The workflow is usually the bottleneck, not the individual.

The geometry gets the attention. The data carries the value. Check accordingly.