In the previous article, we looked at the history of IFC and the basics of how the schema and file formats work. That gave us the big picture and now it’s time to delve into an IFC file to see how the information is structured.
This article will focus on the overall organisation of IFC files and their core entities — the digital building blocks that represent walls, spaces, buildings, and more. In Part 3, we’ll dive deeper into properties and relationships.
When working with IFC Schema in openBIM projects, understanding the IFC file structure is crucial for architects, engineers, and BIM coordinators.
An IFC file may look like a block of cryptic text when you open it in a text editor, but it follows a clear logic. It is divided into two main parts: 📂
The header defines the context of an IFC file. It tells the receiving software what it’s looking at. Typical content includes: 📝
Without the header, software would not know which rules to apply to the following data. For example the header is crucial to interpret the IFC Schema version and ensure compatibility. Think of it as the cover page of a technical report — without it, the rest is much harder to interpret.
ISO-10303-21;HEADER;FILE_DESCRIPTION(('no view'),'2;1'); FILE_NAME('C://der/pfad/zur/datei.ifc',('Linda'),('Software Name', 'Konrad-Zu 1,Germany'), 'EDMsix Version 2.0100.09 Sep 7 2016','Allplan 2019.1 24.06.2019 16:10:06',''); FILE_SCHEMA(('IFC4'));ENDSEC;
The IFC data section contains the actual project information. Each object in the project is represented as an instance of an entity from the schema. 📊
Every instance is given:
Here’s a simplified example of a wall in STEP syntax:
#42 = IFCPROJECT('2C45vBrGbB_w_CB97snkya', ...);#101 = IFCBUILDING('0oHfLk3df5wPq6', ...);#201 = IFCBUILDINGSTOREY('3K9xGv4C5T$zQq', ...);#301 = IFCWALLSTANDARDCASE('1Lm8y2FfH9R7Ts', 'Wall-001', ...);
The above snippet illustrates how IFC entities are referenced and nested, which is a defining feature of the IFC Schema. For example, the wall (#301) belongs to a storey (#201), which belongs to a building (#101), which in turn belongs to the project (#42).
To make sense of this, it helps to know how IFC is layered internally. Entities aren’t all on the same level — they are organised in a hierarchy of layers that build on each other:
These layers (Kernel, Core, Interoperability, Domain) form the backbone of the Industry Foundation Classes (IFC) Schema, ensuring both flexibility and interoperability across BIM tools. This layering is what makes IFC both flexible, extendable (new domains can add new entities) and consistent (everything shares a common kernel).
In addition to layering, the IFC Schema makes heavy use of inheritance — a concept borrowed from object-oriented programming. IFC Entities don’t exist in isolation; they inherit attributes and behaviour from higher-level entities.
Take the example of IfcWall:
This hierarchical inheritance has two big advantages:
The downside? It can make IFC files look abstract and verbose, since attributes aren’t always defined where you expect them — they might come from three levels up the inheritance chain.
Entities are the backbone of IFC. Each entity describes a certain kind of object or concept and defines which attributes it can have (e.g. IfcWall, IfcDoor). 🧱
We can group entities into three main categories: physical elements, spatial structure, and resources.
Physical elements are the most important parts of the IFC Schema, since they map directly to building elements in BIM models. Examples include:
One of the tricky parts of IFC is that geometry can be defined in different ways:
Here is a simple wall with extruded geometry:
#100 = IFCCARTESIANPOINT((0.0,0.0));#101 = IFCAXIS2PLACEMENT2D(#100, $);#102 = IFCRECTANGLEPROFILEDEF(.AREA., 'Wall Profile', #101, 200.0, 3000.0);#103 = IFCDIRECTION((0.0,0.0,1.0));#104 = IFCAXIS2PLACEMENT3D(#100, #103, $);#105 = IFCEXTRUDEDAREASOLID(#102, #104, #103, 3000.0);#106 = IFCSHAPEREPRESENTATION(#context, 'Body', 'SweptSolid', (#105));#107 = IFCPRODUCTDEFINITIONSHAPE($,$,(#106));#108 = IFCWALLSTANDARDCASE('1Lm8y2FfH9R7Ts', 'Wall-001', $, $, #localplacement, #107, $);
In the above example a wall is geometrically represented using an extruded rectangular profile (200 mm × 3000 mm × 3000 mm):
Geometry tells us what an element looks like, but not where it belongs in the building. For that, IFC uses a placement hierarchy.
Every element has a local placement defined by:
Placements are usually chained:
This hierarchy mirrors real construction: a wall isn’t just floating in 3D space; it has a defined location inside a storey, inside a building, on a site.
Here is an example of a wall placed in a storey:
#200 = IFCCARTESIANPOINT((0.0,0.0,0.0));#201 = IFCAXIS2PLACEMENT3D(#200, $, $);#202 = IFCLOCALPLACEMENT($, #201); -- Placement of Ground Floor storey#210 = IFCCARTESIANPOINT((5000.0,2000.0,0.0));#211 = IFCAXIS2PLACEMENT3D(#210, $, $);#212 = IFCLOCALPLACEMENT(#202, #211); -- Placement of Wall relative to Storey#220 = IFCBUILDINGSTOREY('3K9xGv4C5T$zQq', 'Ground Floor', $, $, #202, $, $);#230 = IFCWALLSTANDARDCASE('1Lm8y2FfH9R7Ts', 'Wall-001', $, $, #212, #geometry, $);
This placement system is one reason the IFC file structure is reliable for digital construction workflows — from design to on-site execution.
Spatial entities provide the hierarchical backbone of every IFC file, being a key part of the IFC Schema. They are mandatory for organising all physical elements.
The hierarchy typically looks like this:
Each element in the model must be contained in this hierarchy through relationships. For example, walls and slabs are “contained” in a storey, which belongs to a building.
Resources in IFC are entities that define supporting information used by multiple elements.
Some key examples:
By separating resources from physical elements, gives the ability to the IFC files to support consistency and reusability across the IFC Schema. If the material definition changes (e.g. switch from C30/37 to C35/45 concrete), all elements using that material can be updated accordingly.
To better understand the IFC file structure, let’s walk through a simple but complete example: a wall positioned in context within a building storey. 🧱📐
#10 = IFCPROJECT('2C45vBrGbB_w_CB97snkya', $, 'Demo Project', $, $, $, $, (#50));#20 = IFCSITE('0oHfLk3df5wPq6', 'Main Site', $, $, #100, $, $, $, .ELEMENT., $);#30 = IFCBUILDING('1abCDeFgHiJkLmNo', 'Building A', $, $, #110, $, $, $, .ELEMENT., $);#40 = IFCBUILDINGSTOREY('3K9xGv4C5T$zQq', 'Ground Floor', $, $, #120, $, $, $, .ELEMENT., $);#100 = IFCLOCALPLACEMENT($, #200); -- Placement of site#110 = IFCLOCALPLACEMENT(#100, #210); -- Placement of building relative to site#120 = IFCLOCALPLACEMENT(#110, #220); -- Placement of storey relative to building#130 = IFCLOCALPLACEMENT(#120, #230); -- Placement of wall relative to storey#200 = IFCAXIS2PLACEMENT3D(#500, $, $);#210 = IFCAXIS2PLACEMENT3D(#501, $, $);#220 = IFCAXIS2PLACEMENT3D(#502, $, $);#230 = IFCAXIS2PLACEMENT3D(#503, $, $);#500 = IFCCARTESIANPOINT((0.0,0.0,0.0));#501 = IFCCARTESIANPOINT((0.0,0.0,0.0));#502 = IFCCARTESIANPOINT((0.0,0.0,0.0));#503 = IFCCARTESIANPOINT((5000.0,2000.0,0.0)); -- Wall offset 5 m X, 2 m Y#600 = IFCCARTESIANPOINT((0.0,0.0));#601 = IFCAXIS2PLACEMENT2D(#600, $);#602 = IFCRECTANGLEPROFILEDEF(.AREA., 'Wall Profile', #601, 200.0, 3000.0);#603 = IFCDIRECTION((0.0,0.0,1.0));#604 = IFCAXIS2PLACEMENT3D(#500, #603, $);#605 = IFCEXTRUDEDAREASOLID(#602, #604, #603, 3000.0);#700 = IFCSHAPEREPRESENTATION(#50, 'Body', 'SweptSolid', (#605));#710 = IFCPRODUCTDEFINITIONSHAPE($,$,(#700));#800 = IFCWALLSTANDARDCASE('1Lm8y2FfH9R7Ts', 'Wall-001', $, $, #130, #710, $);#900 = IFCRELAGGREGATES('rel-1', $, $, #10, (#20)); -- Project contains site#901 = IFCRELAGGREGATES('rel-2', $, $, #20, (#30)); -- Site contains building#902 = IFCRELAGGREGATES('rel-3', $, $, #30, (#40)); -- Building contains storey#903 = IFCRELCONTAINEDINSPATIALSTRUCTURE('rel-4', $, $, (#800), #40); -- Storey contains wall
This chain of entities and references is what gives the wall meaning. It’s not just a 3D block — it is a specific wall, in a specific storey, with a defined material, that software can interpret consistently.
Entities may look abstract, but they are what make IFC different from a 3D model in a CAD tool. IFC is not just shapes — it’s structured information with identity, hierarchy, and meaning: ⚙️
This is why IFC is so verbose and sometimes difficult to read — but also why it is powerful.
The IFC Schema is more than just a file format — it is the structured foundation for openBIM interoperability.
In this article, we opened up the IFC file and looked at its overall structure (header and data) and the entities it contains: physical elements, spatial hierarchy, and resources. ✅📌
In the next article (Part 3), we’ll continue with the properties and relationships that enrich entities and tie them together. This is where IFC really shows its strength: turning disconnected objects into an integrated digital model.
If you have any questions do not hesitate to leave a comment below!