Warum die IFC-Version in Projekten so viel auslöst

In vielen Projekten wird „IFC“ als einheitliches Austauschformat verstanden. In der Praxis ist es eher wie „PDF“: Es gibt Varianten, Versionen und unterschiedliche Interpretationen durch Software. Genau deshalb entstehen diese Klassiker:

• „Bei uns fehlen Bauteile / Öffnungen.“

• „Attribute sind weg oder heißen anders.“

• „Das Modell wirkt kaputt, aber im Autorensystem ist alles korrekt.“

• „TGA/Tragwerk kann’s nicht zuverlässig einlesen.“

Die Ursache ist oft nicht die Modellqualität, sondern: Version & Exportprofil passen nicht zur Empfängerlandschaft.

Estata Planungsservice arbeitet deshalb nach einem einfachen Prinzip: Erst Empfänger-Use-Case klären, dann Version festlegen, dann testen.

1) IFC2x3 vs IFC4 – was ist der Kernunterschied?

IFC2x3 (der „Kompatibilitäts-Oldtimer“)

• Sehr weit verbreitet in vielen Workflows

• Oft die sicherere Wahl, wenn mehrere Tools im Spiel sind oder ältere Systeme genutzt werden

• In manchen Konstellationen: weniger „Überraschungen“ beim Import
  
  

IFC4 (die modernere Basis)

• Technisch weiterentwickelt (bessere Strukturmöglichkeiten)

• In aktuellen Toolchains häufig sinnvoll – aber nur, wenn alle Beteiligten es stabil verarbeiten

• Je nach Softwarestand: Import kann sehr gut sein – oder einzelne Inhalte anders interpretieren

Praxisregel:
Wenn du nicht 100% sicher bist, was auf Empfängerseite stabil läuft, ist die „richtige“ Entscheidung nicht theoretisch – sondern die, die bei eurem Projektpartner am zuverlässigsten ankommt.

2) Die 4 häufigsten Kompatibilitätsfallen (und wie du sie vermeidest)

Falle A: „Wir exportieren IFC4, weil es neuer ist“

Neu heißt nicht automatisch kompatibler. Entscheidend ist: Wer liest es ein – und womit?

Lösung: Vorab klären: Toolchain + gewünschter Use-Case (Koordination, Mengen, Kollisionsprüfung, FM).

Falle B: Exportprofil passt nicht zum Zweck

Ein Koordinationsmodell ist etwas anderes als ein Modell für Mengenermittlung oder Übergabe an FM.

Lösung: Pro Zweck ein klares Profil:

• Koordination: klare Klassen, stabile Geometrie, saubere Storeys

• Mengen: Typen/Properties konsistent, Material-/Flächenlogik plausibel

• Abstimmung: „schlank“ statt überfrachtet
  
  

Falle C: Kein „Viewer-Realitätscheck“

„Im Autorensystem passt’s“ ist keine Garantie. Der IFC-Viewer ist die Realität des Empfängers.

Lösung: Immer 10-Minuten-Viewer-Check (siehe Checkliste unten).

Falle D: Versionswechsel mitten im Projekt

Wenn du im Projekt von IFC2x3 auf IFC4 wechselst (oder umgekehrt), kann sich Filter-/Property-Logik verändern.

Lösung: Version fixieren – und nur mit klarer Abstimmung wechseln.

3) Entscheidungshilfe: Welche IFC-Version solltest du wählen?

Nutze diese einfache Matrix als Büro-Regel:

IFC2x3 ist oft die bessere Wahl, wenn …

• viele Beteiligte mit unterschiedlichen Tools arbeiten,

• du maximale „Ankommenswahrscheinlichkeit“ brauchst,

• ein Teil der Beteiligten ältere Softwarestände nutzt.
  
  

IFC4 ist oft sinnvoll, wenn …

• ihr eine moderne, abgestimmte Toolchain habt,

• klar ist, dass alle Partner IFC4 stabil importieren,

• ihr von erweiterten Strukturen profitiert (und diese auch genutzt werden).
  
  

Estata-Ansatz:
Wir fragen im Kick-off gezielt nach Empfänger-Tools und Use-Case – und liefern dann die Version, die im Projekt wirklich funktioniert.

4) Übergabe-Checkliste: „IFC kommt sauber an“ (15 Minuten)

1. IFC-Version dokumentiert (2×3/4 – eindeutig in der Übergabe)

2. Storeys/Geschosse plausibel (benannt, richtig sortiert)

3. Klassifizierung stimmt (keine Proxy-Flut)

4. Geometrie plausibel (keine wilden Versätze, keine Maßstabsfehler)

5. Filter-Test: Türen/Fenster/Wände sind sauber selektierbar

6. Properties-Test: Typname/Material/Status (nur was gebraucht wird) vorhanden

7. Viewer-Test: Öffnet stabil in neutralem IFC-Viewer ohne Fehlermeldungs-Orgie

8. „What’s new“-Notiz bei Revisionen (kurzer Text, was sich geändert hat)