Lang lebe IFC! Aber wie?

Eine der wesentlichen Eigenschaften von IFC-Dateien ist, dass sie mit einfachen Mitteln lesbar sind. Im Grunde handelt es sich um strukturierte Text-Dateien, die in einem einfachen Texteditor (etwa Notepad++) geöffnet und auch bearbeitet werden können. Dadurch ist gewährleistet, dass die darin enthaltenen Daten auch in der Zukunft noch zugänglich sind (ich habe hier 60 Jahre in Erinnerung, die Quelle werde ich bei Gelegenheit ergänzen).

IFC-Viewer erstellen aus diesen Dateien beim Öffnen die beschriebenen Geometrien und stellen diese dann in erster Linie in einem 3D-Fenster dar. Die Eigenschaften und Beziehungen zwischen den Elementen werden ebenfalls interpretiert und in eigenen Fenstern aufgelistet. Zumeist fehlt aber die Möglichkeit, die Objekte zu bearbeiten.

„IFC-Editoren“

Natürlich ist das Manipulieren von IFC-Daten in einem Texteditor ein sehr aufwändiger Prozess, und wenn die Regeln des IFC-Schemas nicht eingehalten werden, so können die Information nur mehr schwer von Viewern etc. dargestellt werden. Glücklicherweise gibt es zahlreiche Programmierbibliotheken, die hier unterstützen können. Einige davon sind auch open-source, sodass auch hier die Verwendbarkeit langfristig möglich ist – immerhin kann jeder Nutzer diese selbst weiterentwicken. Folgende Frameworks sind mir bislang bekannt:

  • ifcopenshell: Dieses open-source-Projekt besteht in erster Linie aus C++-Bibliotheken, diese haben jedoch auch Python-Anbindungen („bindings“), sodass sie auch mit dieser sehr verbreiteten (und gerade für Anfänger einfacheren) Programmiersprache genutzt werden können. Wir werden in folgenden Artikeln noch öfter damit arbeiten; sobald man sich ein wenig in die Arbeitsweise eingearbeitet hat, kann man erstaunlich flexibel mit IFC umgehen.
  • xbim: Wenn man mit .NET (C# oder VB) arbeiten will, so ist dieses Framework das MIttel der Wahl. Die Bibliotheken sind open-source, die Entwickler bieten darauf aufbauend eine Platform zur Verwaltung von IFC-Dateien an.
  • ifcplusplus: Hierbei handelt es sich um eine weitere C++-Bibliothek für IFC.
  • apstex: Wer eher mit der Programmiersprache Java vertraut ist, kann auch diese mit Hilfe dieser Bibliothek zur Bearbeitung von IFC-Dateien nutzen.

Diese Kombination – ein garantiert langfristig lesbares Dateiformat und frei zugängliche Möglichkeiten, dieses zu bearbeiten – ist ein wesentlicher Aspekt, der bei der Wahl von BIM-Systemen berücksichtigt werden muss.

Warum kein natives Format?

Natürlich ist es praktisch, wenn man die nativen Formate in der originalen BIM-Autorensoftware öffnen und bearbeiten kann. Hier stellen sich jedoch mehrere Fragen:

  • Warum muss ein Bauteil, sobald er real gebaut wurde, noch „parametrisch“ sein? Eine gebaute Wand wird nicht mehr „verschoben“, sondern zumeist abgebrochen und neu errichtet. Es handelt sich nicht mehr um dieselbe Wand (z.B. baurechtlich), auch wenn die selben Materialien wiederverwendet wurden.
  • Gebäude ändern sich nicht ständig und dynamisch. Natürlich kommt es immer wieder zu Umbauten; aber viele Bauteile bleiben auch jahrzehntelang „unberührt“ (siehe auch das Konzept von „Slowly Changing Dimensions„). Manche Softwarehersteller ändern ihr BIM-Dateiformat jährlich. Somit müsste entweder regelmäßig ein Update gemacht werden (was bei manchen Betreibern bzw. Immobilienbesitzern ein paar hundert Modelle umfassen kann) ; dabei können jedoch Fehler auftreten, die überprüft werden müssen. Oder man aktualisert die Modelle bei Bedarf und nimmt dabei das Risiko in Kauf, dass diese alten Versionen nicht mehr unterstützt werden (bzw. immer nur z.B. 5-Jahre-Sprünge bei Updates akzeptiert werden). Es zeigt sich jedoch, dass Planer hier rasch aufgeben, und das Gebäude „nachmodellieren“; und zwar auf Basis von IFCs, PDFs und Laserscans (bzw. Vermesserplänen). Das ist natürlich nicht Sinn der Sache.

Auf lange Sicht spricht das auf jeden Fall für IFC. Und das ist auch der Grund, warum sich jede:r „BIM-Beteiligte:r“ auch intensiver damit auseinandersetzen sollte.