Back to the BIM & IFC blog
Export fixes · 2026-10-02 · 10 min
IFC Spatial Structure Explained: Project, Site, Building, Storey and Space (With Diagrams)
Every IFC model hangs from the same tree: Project, Site, Building, Storey, Space. Most of the problems people blame on viewers — elements in no storey, plans that cut through slabs, models two kilometres away — are problems in that tree. Here it is, drawn out, with the mistakes that break it.
IFC Spatial Structure Explained: Project, Site, Building, Storey and Space (With Diagrams) — IFC Viewer Online article cover
Open any IFC model in any viewer and the first thing you see, before a single wall, is a tree: the project at the top, a site, a building, a list of storeys. It looks like a navigation aid. It is actually the backbone of the file, and a surprising number of problems that get blamed on viewers, exports or checkers are problems in that tree.
This guide draws the tree out, explains the two different relationships that build it, and lists the mistakes that break it — with what each one does downstream.
The IFC spatial structure. Blue lines are aggregation (the spatial tree); dashed green lines are containment (each element in exactly one storey).
Key takeaways
- The spatial tree is built by aggregation: Project → Site → Building → Storey → Space.
- Physical elements are not part of the tree. They are contained in one spatial element — usually a storey — by a separate relationship.
- An element with no containment is not "somewhere in the building". For plan cuts, schedules, COBie and most checks, it does not exist.
The five levels, and what each one is for
| Entity | What it represents | What it carries |
|---|
| IfcProject | The whole project — exactly one per file | Units, representation contexts, the root of everything |
| IfcSite | The plot of land | Reference latitude/longitude and elevation; the georeferencing starts here |
| IfcBuilding | A building on the site | Name, address, elevation of the ground floor |
| IfcBuildingStorey | A level | Elevation — what plan cuts and level-based schedules rely on |
| IfcSpace | A room or zone of air | Name, long name, area, volume — the room programme |
In IFC4.3 the building level generalises to facilities: IfcBridge, IfcRoad, IfcRailway and IfcMarineFacility sit where IfcBuilding sits, with facility parts below them.Two relationships, not one
The single most useful thing to understand about the spatial structure is that two different relationships are at work, and they mean different things.
- IfcRelAggregates builds the spatial tree. A building is decomposed into storeys; a storey into spaces. This is whole–part.
- IfcRelContainedInSpatialStructure puts a physical element — a wall, a door, a pump — in that tree. Each element can be contained in exactly one spatial element.
- IfcRelReferencedInSpatialStructure adds secondary references: a column that spans two storeys is contained in one and referenced in the other.
Where the model is: placements down the tree
The spatial tree also carries the coordinate system. Each element's position is an IfcLocalPlacement relative to its parent's placement — wall relative to storey, storey relative to building, building relative to site. The model's position on Earth is decided once, at the top.
Placements are relative to their parent. Real-world coordinates belong at the top, in the georeferencing — not in every element.
When real-world coordinates are pushed down into every element instead, models jitter on screen and federated files land kilometres apart. The full story is in IFC coordinates and georeferencing.
Six mistakes that break the tree
| Mistake | Usual cause | What breaks downstream |
|---|
| Elements contained in no storey | Elements hosted on a reference level, or created in a group | Plan cuts, level schedules, COBie locations |
| Elements contained directly in IfcBuilding or IfcSite | Export setting, or site elements modelled without a level | Storey-based checks skip them |
| Storeys with wrong elevations | Unit or base-point mismatch on export | Plan cuts through slabs, wrong levels in schedules |
| No IfcSpace at all | Rooms not exported, or exported as plain geometry | Room programme, areas, COBie Space sheet |
| Two IfcBuilding where one was meant | Linked files exported separately | Duplicate storeys, confused federation |
| Storeys named differently per discipline | No agreed level naming | Federated models that do not line up by level |
Most of these are export settings rather than modelling, and most of them are visible in the first ten seconds of opening a file — if you look at the tree before the geometry. The checks behind them are part of how to validate an IFC file, and the per-tool export settings are in why Revit IFC exports break.
Checking the spatial structure in a minute
- Open the file and read the tree first One project, one site, the buildings you expect, the storeys you expect — in order, with sensible names.
- Check storey elevations They should increase, and match the drawings within the tolerance you agreed. Units are the usual suspect when they are out by a factor of 1000.
- Look for elements outside every storey Validation flags them. An element in the building but not in a storey is the common case.
- Cut a plan per storey If the cut slices through a slab or misses the walls, the elevation or the containment is wrong. See how per-storey cuts are placed in the guide to measuring.
- Check spaces If the project needs a room programme or COBie, every room should be an IfcSpace with a name — not a coloured volume.
The plan-cut step is described in how to measure an IFC model online; why spaces matter for handover is in COBie from IFC.
IFC Spatial Structure Explained: Project, Site, Building, Storey and Space (With Diagrams)