Warum IFC-Modelle in der Praxis oft „nicht auswertbar“ sind

Viele IFCs sehen im Viewer korrekt aus – und sind trotzdem schwierig zu verwenden. Typische Symptome:

• Bauteile lassen sich nicht sauber filtern (z. B. Wände vs. Stützen vs. Decken)

• Mengen/Listen sind unzuverlässig (weil Klassen falsch sind oder Parameter fehlen)

• Ein Modell ist optisch okay, aber für Koordination & Auswertung zu „flach“ (keine sinnvollen Eigenschaften)

• Fachplaner müssen nacharbeiten: Umbenennen, Re-Klassifizieren, Property-Sets ergänzen

Die Konsequenz ist immer gleich: Mehr Rückfragen, mehr Iterationen, mehr Aufwand.

Estata Planungsservice setzt genau hier an: Wir liefern IFCs so, dass sie koordiniert und ausgewertet werden können – nicht nur „angeschaut“.

1) Bauteilklassen: Der häufigste Hebel für sofort bessere IFCs

Wenn Klassen nicht stimmen, ist alles danach mühsam. Beispiele:

• Eine „Wand“ steckt in einer generischen Kategorie → Filter/Mengen laufen ins Leere

• Ein „Fenster“ ist als „Opening“ oder „Proxy“ exportiert → Tür-/Fensterlisten sind unbrauchbar

• Tragende Elemente sind nicht unterscheidbar → Koordination mit Tragwerk wird unnötig schwer

Praxisregel: Lieber weniger Bauteile, aber richtig klassifiziert, als viele Bauteile als „IfcBuildingElementProxy“.

2) Property Sets: Welche Eigenschaften in Architekturbüros wirklich zählen

Viele Modelle enthalten „irgendwelche“ Eigenschaften – aber nicht die, die im Projekt helfen.

Die Properties, die fast immer Mehrwert bringen

• Bauteiltyp / Typname (einheitlich, nicht „Default 01“)

• Material-Logik (wenigstens über Typen konsistent)

• Geschoss-/Zone-Zuordnung (für Filter, Pläne, Mengen)

• Status / Phase (Bestand/Neu/Abbruch – sofern im Projekt genutzt)

• Brandschutz / Nutzung / Raumbezug (nur wenn wirklich gebraucht)

Wichtig: Properties sind kein Selbstzweck. Ein IFC wird nicht besser, weil es 200 Felder hat – sondern weil die richtigen 20 sauber gepflegt sind.

3) Benennung & Struktur: Das unterschätzte „Büro-Standard“-Thema

Wenn zwei Büros am gleichen Projekt arbeiten, entstehen Reibungen oft durch Namenslogik:

• Typen heißen einmal „Wand_24“, dann „Wand 24cm“, dann „WA-240“

• Räume/Level sind nicht konsistent (EG vs. 00 vs. Ground Floor)

• Bauteile haben ähnliche Namen, aber unterschiedliche Bedeutung

Empfehlung: Ein kurzes Namensschema definieren (Typen, Geschosse, Zonen) – und konsequent durchziehen. Genau so arbeiten wir als verlängerte Werkbank: Wir übernehmen euren Standard oder definieren mit euch einen Minimalstandard.

IFC-Praxis-Checkliste: „Auswertbar in 15 Minuten“

Diese Checkliste kannst du vor jeder Übergabe kurz durchgehen – oder an Estata geben, damit wir sie für dich abarbeiten:

1. Klassen-Check: Sind Wände/Decken/Stützen/Fenster/Türen korrekt klassifiziert?

2. Proxy-Check: Gibt es zu viele generische Proxies? Wenn ja: warum?

3. Typen-Check: Gibt es eine saubere Typstruktur (nicht nur Instanzen)?

4. Geschosse: Levels/Storeys logisch, einheitlich benannt?

5. Properties: Sind die wichtigsten Eigenschaften vorhanden (Typ, Material, Phase falls nötig)?

6. Filter-Test: Lässt sich ein typischer Auszug (z. B. nur Türen) sauber filtern?

7. Mengen-Test: Stimmen grobe Plausibilitäten (Türanzahl, Wandflächen)?

8. Viewer-Test: Öffnet es sauber in einem neutralen IFC-Viewer ohne Warn-Orgie?

Wenn du bei Punkt 1–3 sauber bist, ist das schon die halbe Miete.