Spatial structure and containment
Summary
Every object in an IFC file should have a place: a storey of a building, or a part of a bridge, road or railway. That place is how people and software find things, by floor, by span or by section of road. An element without a place is still in the file, but it drops out of every schedule, filter and quantity that is organised by location.
The report checks this on the Structure page and draws the result in the Spatial structure card.
IfcSite, one facility under it, storeys or facility parts under the facility, and at least 95% of the elements contained in that tree.
How IFC organises an asset
IFC builds a tree of spatial elements joined by aggregation (IfcRelAggregates): the project, the site, the facility and then its storeys or parts. Each physical element is placed in one of those spatial elements by a containment relationship (IfcRelContainedInSpatialStructure).
| Level | Building | Infrastructure (IFC 4.3) |
|---|---|---|
| Project | IfcProject | IfcProject |
| Site | IfcSite | IfcSite |
| Facility | IfcBuilding | IfcBridge, IfcRoad, IfcRailway, IfcMarineFacility, or IfcFacility for assets without their own class, such as tunnels |
| Level or part | IfcBuildingStorey | IfcBridgePart, IfcRoadPart, IfcRailwayPart or IfcFacilityPart |
| Rooms | IfcSpace | Not expected |
Where you meet it in the report
The Spatial structure card on the Structure page (How the model is organised from project down to levels or facility parts) has three parts:
- A summary line: project, sites, facilities with their types, storeys or parts, and spaces with their area. It ends in a status: Hierarchy complete, Needs attention, Looks federated, Incomplete or No facility.
- The findings: one row per rule with the facilities it affects. It opens by itself when it holds a warning or a problem.
- A table of facilities and their parts, with class, predefined type, what each contains and a short note on affected rows.
The check cards below link to this card.
The checks and how they are scored
Elements are all physical objects (IfcElement) except openings.
| Check | What it measures | Score | Weight |
|---|---|---|---|
| Spatial containment | Share of elements contained in a spatial element, or part of an assembly | The share itself; at most 20 when the model has no facility | 1.5 (key), gate |
| Spatial hierarchy | Storeys (buildings) or parts (infrastructure) under the facilities | 100 when present, 50 when the facility has none, 20 without a facility | 1, gate |
| Number of sites | IfcSite elements in the project tree | 100 for one site, 40 for none, 60 for more than one | 1 |
| Spatial structure warnings | The warnings behind the card's findings | See below; 20 without a facility | 1, gate |
| Spaces (buildings only) | Number of IfcSpace elements | 100 with spaces, 0 without, on models that look architectural (walls, slabs and at least one door or window); otherwise information only | 1 |
Only containment counts as a place. An element that is merely referenced to a storey or part (IfcRelReferencedInSpatialStructure) is not counted. Parts of an assembly, such as the flights of a stair, count as placed through their parent.
For Spatial structure warnings, each distinct warning costs 25 points, and a facility without storeys or parts gives one warning per facility. Another 10 come off when the same warning occurs more than once, and 15 more when several buildings share one model. The score does not fall below 30, or 20 with several buildings.
Containment, hierarchy and warnings are gates: at 95 or more they count for a quarter of their weight, so passing adds little and failing costs the full weight. See Scoring versions and what changed.
What the findings mean
| Finding | Severity | What it means |
|---|---|---|
| No facility in the spatial structure | Problem | Elements cannot be assigned to a building, bridge, road or other facility. |
| n buildings in one model | Problem | Separate buildings belong in separate models, unless they are part of an infrastructure asset. |
| n … facilities in one model | Warning | Several facilities of one class usually point to a merged export. |
| n sites in one model | Warning | Location and georeferencing become ambiguous. |
| Facilities sit directly under the project | Warning | No IfcSite between the project and its facilities. |
| Buildings without storeys; Facilities without parts | Warning | Elements can only be located in the facility as a whole. |
| Unrecognised facility class | Warning | The class is not a facility type in the file's IFC version. |
| Levels or parts outside a facility | Warning | Storeys or parts sit under the site or project with no facility in between. |
| Spatial elements outside the project tree | Warning | Not connected to the project, so most viewers will not show them in the tree. |
| Generic IfcFacility used; Facility type not specified | Note | Information only, not scored. |
The number of sites is scored by its own check, not as a warning.
Bridges, roads, railways and tunnels
The facility classes the report recognises depend on the IFC version. IFC 4.3 knows IfcFacility, IfcBuilding, IfcBridge, IfcRoad, IfcRailway and IfcMarineFacility. IFC2X3 and IFC4 know only IfcBuilding.
An IFC 4.3 bridge should therefore read IfcProject → IfcSite → IfcBridge → IfcBridgePart, with the elements contained in the parts. A bridge without parts gets Facilities without parts and scores 50 on hierarchy. A tunnel uses the generic IfcFacility, which the card notes as expected: IfcTunnel only arrives with IFC 4.4.
In IFC2X3 or IFC4, a bridge or road exported as an IfcBuilding with storeys passes these checks. When its elements hang directly under the site instead, the model has no facility: containment is capped at 20 and hierarchy and warnings score 20. On the Benchmark page, infrastructure inside an IfcBuilding is recognised from its elements, alignments, parts, authoring tool or names, and compared with civil infrastructure.
Capabilities that depend on it
| Capability | Spatial condition |
|---|---|
| Clean export | No spatial structure warnings; One site |
| Coordination ready | One site; Containment ≥ 95%, with a facility present |
| AI ready | One site, no duplicate GlobalIds |
| Operations / FM, Energy analysis (draft) | Spaces present; Energy analysis also needs space boundaries |
A model with more than one site or more than three facilities is tagged Federated / merged on the Overview. See the Capabilities directory for every rule.
Other checks on the Structure page
Elements linked to a type scores the share of elements linked to a type object (IfcRelDefinesByType), weight 1.5 (key). Openings linked to doors & windows, for buildings, compares fill relationships with the number of doors and windows: 70 plus up to 30 for the share filled when void relationships exist, 20 when none exist, weight 0.75, not scored without doors or windows. Both link to the card How objects are connected. The buildingSMART result Implementer agreements is also listed here. Proxies have their own article: Proxies: when they are acceptable and how to make them say what they are.
Frequently asked questions
Our IFC4 bridge uses storeys named after the deck and piers. Is that wrong?
The checks accept it, because IFC4 has no bridge class. Other software will read the asset as a building, though. For new projects, ask for IFC 4.3 with IfcBridge and bridge parts.
Why does the card say Looks federated?
The file holds more than one site, or several facilities of the same class. That usually means models were merged at export. Several buildings without infrastructure show as Incomplete instead, because separate buildings belong in separate models. Split the file per asset, or merge the sites into one.
Does the site also matter for location?
Yes. IfcSite is the root the location hangs from. See Georeferencing and the location map.