Zurück zum BIM- & IFC-Blog
Werkzeuge & Vergleiche · 2026-10-02 · 11 Min.
Was steckt in einer IFC-Datei? Das Format mit Diagrammen erklärt
Eine .ifc-Datei ist Klartext, den man im Code-Editor öffnen kann – und wer sie lesen kann, dem lösen sich die Hälfte der IFC-Rätsel. Der Header, die nummerierten Instanzen, die GlobalId, die Beziehungen, die Eigenschaften tragen: Hier ist das Format, gezeichnet.
Was steckt in einer IFC-Datei? Das Format mit Diagrammen erklärt — IFC Viewer Online article cover
Die meisten sehen eine IFC-Datei nur durch einen Viewer. Schade, denn eine .ifc-Datei ist Klartext, und zehn Minuten Lesen erklären Dinge, die sonst rätselhaft bleiben: warum GUIDs zählen, warum eine Eigenschaft „fehlen“ kann, obwohl man sie sieht, warum Dateien so groß werden, warum eine falsche Exporteinstellung alles Nachgelagerte zerbricht.
Diese Anleitung öffnet die Datei und zeichnet, was darin steckt.
Eine IFC-Datei im STEP-Format (ISO 10303-21): ein Header, der das Schema nennt, dann eine nummerierte Instanz pro Zeile.
Das Wichtigste
- Eine IFC-Datei ist eine Liste nummerierter Instanzen. Die Nummern gelten nur in der Datei und ändern sich bei jedem Export.
- Die GlobalId – die 22-stellige Zeichenkette in jeder Instanz – ist die Identität, die bestehen bleiben soll.
- Fast alles Interessante, auch Eigenschaften und räumliche Zuordnung, hängt über Beziehungsentitäten am Element, statt am Element gespeichert zu sein.
Der Header: welches Schema, welche View
Die Datei beginnt mit ISO-10303-21; und einem kurzen HEADER-Abschnitt. Drei Zeilen sind wichtig:
- FILE_DESCRIPTION nennt die Model View Definition – Coordination View, Reference View, Design Transfer View –, also die Teilmenge von IFC, die der Exporter verwenden wollte.
- FILE_NAME hält Dateinamen, Zeitstempel, Autor und Autorenanwendung fest.
- FILE_SCHEMA nennt das Schema: IFC2X3, IFC4 oder IFC4X3. Jede Zeile darunter wird nach diesem Schema gelesen; dieselbe Entität kann in verschiedenen Versionen verschiedene Attribute haben.
Die Wahl zwischen Schemaversionen ist ein eigenes Thema: IFC2x3 vs. IFC4.
Die Daten: eine Instanz pro Zeile
Nach DATA; hat jede Zeile dieselbe Form: eine Nummer, ein Entitätsname und eine Liste von Attributen in der vom Schema festgelegten Reihenfolge.
#245= IFCWALL('1kTvXnbbzCWw8lcMd1dR4o',#2,'Basic Wall:Ext 300',$,$,#210,#240,$,.STANDARD.);
| Element | Bedeutung |
|---|
| #245 | Instanznummer (Express-ID) – gilt nur in dieser Datei |
| '1kTvXnbbz…' | GlobalId – eine komprimierte 22-stellige GUID |
| #2 | Verweis auf eine andere Instanz (hier die Owner History) |
| $ | Attribut nicht gesetzt |
| .STANDARD. | Ein Aufzählungswert (der vordefinierte Typ) |
| #210, #240 | Platzierung und geometrische Darstellung, in anderen Zeilen definiert |
Ändert sich die GlobalId selbst bei jedem Export, brechen alle nachgelagerten Prozesse auf einmal. Ursache und Lösung je Autorenwerkzeug stehen in warum sich IFC-GUIDs bei jedem Export ändern.
Entitäten erben voneinander
IFC ist ein Objektmodell. Eine IfcWall ist ein IfcBuiltElement, das ein IfcElement, ein IfcProduct, ein IfcObject und letztlich ein IfcRoot ist – und sie trägt die Attribute aller davon. Deshalb hat jede Wand, Tür und jeder Raum eine GlobalId und einen Name: Sie stammen aus IfcRoot.
Jede Entität erbt die Attribute ihrer Obertypen. Eine Prüfung für IfcElement gilt für alle Wände, Türen und Stützen darunter.
Namen ändern sich zwischen Versionen: Was IFC4.3 IfcBuiltElement nennt, hieß in IFC2x3 und IFC4 IfcBuildingElement. Ein Werkzeug, das einen Namen fest kodiert, übersieht den anderen – ein Grund, warum dasselbe Modell in einem Werkzeug eine Prüfung besteht und in einem anderen durchfällt.
Auch Beziehungen sind Entitäten
Die Designentscheidung, die IFC anfangs schwer lesbar macht, macht es zugleich mächtig: Beziehungen sind eigenständige Objekte. Eine Wand hat keine Liste ihrer Eigenschaften. Stattdessen zeigt eine IfcRelDefinesByProperties-Instanz auf die Wand und auf ein Property Set. Räumliche Zuordnung, Materialien, Typen, Öffnungen und Gruppen funktionieren genauso.
Eigenschaften leben in Property Sets, die am Element oder an seinem Typ hängen. Ein Property Set am Typ gilt für jede Instanz.
Hier liegt die Wurzel des häufigsten Fehlalarms bei IFC-Qualitätsprüfungen: Eine am Typ definierte Eigenschaft scheint einem Werkzeug, das nur die Instanz liest, zu fehlen. Fehlende IFC-Eigenschaften nach dem Export behandelt die echten Ursachen; Property Sets in Python lesen zeigt, wie man diesen Beziehungen im Code folgt.
Warum IFC-Dateien so groß werden
- Geometrie dominiert. Eine triangulierte Fassade oder ein detailliertes TGA-Bauteil kann tausende Zeilen füllen; Extrusionen und gemappte (instanziierte) Geometrie sind weit kleiner.
- Wiederholte Daten werden wiederholt. Exporter, die Property Sets oder Darstellungen nicht teilen, schreiben dieselben Zeilen einmal pro Element.
- Im reinen STEP ist nichts komprimiert. ifcZIP verkleinert eine Datei typischerweise um ein Mehrfaches und ist ein sinnvolles Lieferformat, wenn die Werkzeuge des Empfängers es akzeptieren.
Sichere Wege, Dateien zu verkleinern, stehen in IFC-Dateigröße reduzieren. Und wenn eine Datei so groß ist, dass der Browser abstürzt, siehe große IFC-Dateien und Browserabstürze.
Eine Datei selbst lesen
- In einem Texteditor öffnen Jeder Editor, der große Dateien verkraftet. Zuerst den Header ansehen: Schema und Model View sagen, was zu erwarten ist.
- Nach der gewünschten Entität suchen IFCWALL(, IFCSPACE(, IFCBUILDINGSTOREY(. Schon die Anzahl ist eine schnelle Plausibilitätsprüfung.
- Den Verweisen eines Elements folgen Von einer Wand aus nach ihrer #-Nummer suchen, um die Beziehungen zu finden, die auf sie zeigen – Zuordnung, Eigenschaften, Typ.
- Dann zum Viewer wechseln Dieselben Informationen, navigierbar: der räumliche Baum, das Eigenschaftenfenster und eine Validierung, die diese Beziehungen für Sie prüft.
Wie Elemente in Geschosse und Räume gegliedert sind, behandelt die räumliche Struktur von IFC erklärt.
Was steckt in einer IFC-Datei? Das Format mit Diagrammen erklärt