Wir werden uns noch sehr oft mit dem Format IFC auseinandersetzen, oder genauer gesagt, wie in diesem Fall, mit dem IFC-Schema. Nicht viele Personen im Bauwesen – BIM-Experten eingeschlossen – haben sich im Detail mit diesem Schema auseinander gesetzt. Dadurch sind zahlreiche Mythen und Fehlinterpretationen entstanden. Deshalb wollen wir dem Schema hier etwas genauer auf den Grund gehen.
Grundlegendes
Die Dokumentation des IFC-Schema (derzeit aktuellste Version mit der sperrigen Bezeichnung IFC4 ADD 2 TC1, auch als 4.0.2.1 abgekürzt) ist dabei leider nur wenig förderlich. Sie ist zwar wirklich sehr strukturiert und umfangreich, allerdings benötigt man bereits ein sehr fundiertes Wissen über IFC, um sich darin zurecht zu finden. Anhand einer einfachen Wand werden wir daher einige grundlegende Konzepte von IFC erläutern, und dabei auf für viele überraschende Neuigkeiten treffen.
Die IFC-Klasse „IfcWall“ wurde bereits in der ersten Version IFC1.0, veröffentlicht im Jahre 1996, angelegt. Wenn man in der Dokumentation nachliest, so besteht die Beschreibung dieser Klasse – wie die meisten anderen auch – aus folgenden Abschnitten (die Grafiken sind der Dokumenation entnommen):
Natural language names
Was bereits zu Beginn auffällt: die gesamte Dokumentation ist in Englisch geschrieben, zu einer Übersetzung ist es leider noch nicht gekommen. Aber grundsätzlich könnte das IFC-Schema in jede beliebige Sprache übersetzt werden (nicht nur die Website). Und das zeigt sich in diesem ersten Abschnitt. Derzeit sind Übersetzungen für Deutsch, Französisch und Englisch angelegt. Warum Englisch auch? „IfcWall“ wird als sprachunabhängige Bezeichnung verwendet, immerhin ist es mühsam, ständig dieses „Ifc“ als Präfix mitzuziehen. „Wall“ hingegen ist die Form, in der diese Klasse in einer Benutzeroberfläche bezeichnet werden sollte.
Change log
Der zweite Abschnitt stellt nur eine tabellarische Aufstellung dar, was gegenüber der Vorversion geändert wurde. In diesem Fall wurde das Attribut OwnerHistory modifiziert; konkret wurde die Angabe dieses Attributs auf OPTIONAL heruntergestuft (dazu noch mehr weiter unten). Die Eigenschaft PredefinedType wurde hinzugefügt.
Entity definition
Im nächsten Abschnitt folgt die Beschreibung, wie eine Wand im IFC-Schema definiert ist. Wie in vielen Fällen wird auch hier auf internationale Normen verwiesen, um eine konsistente Verwendung der Begriffe und Konzepte zu bewerkstelligen. Am Ende findet man noch den Hinweis, dass diese Klasse („entity“) mit Version 1.0 eingeführt wurde.
Die folgendenden beiden Überschriften „Attribute definitions“ und „Formal propositions“ überspringen wir vorerst, weil uns das mit der bisherigen Beschreibung noch nicht im „großen Ganzen“ einordnen können.
Entity inheritance
Hier wird es interessant, denn im folgenden Diagramm zeigt sich der hierarchische Aufbau des IFC-Schemas sehr gut. Wir werden dieser Darstellung und diesem Konzept noch sehr oft begegnen. Programmierern, insbesondere bei der objektorientierten Programmierung, ist das Prinzip der Vererbung geläuftig. Wenn man jedoch von der (bau-)technischen Seite kommt, oder aus anderen Bereichen des Bauwesens, so ist dies zu Beginn etwas verwirrend, oder anders ausgedrückt: umständlich. Warum benötigen wir sechs „Überschriften“, um eine Wand beschreiben zu können? Und warum finden sich diese nicht in einer IFC-Datei wieder (Dazu ein andermal)?
Das Prinzip der Vererbung sorgt dafür, dass gleiche Objekte gleich behandelt werden, und nicht an mehreren Stellen gleiche Eigenschaften definiert werden müssen. Ein Fenster und eine Wand sind auf den ersten Blick völlig verschiedene Dinge. Allerdings können wir beide angreifen, was bedeutet, dass beide Klassen eine Geometrie haben (können). Somit ist es sinnvoll, dass eine Eigenschaft „Geometrie“ nicht zweimal (also für Wände und für Fenster) definiert wird, sondern an einer übergeordneten Stelle (in diesem Fall bei IfcProduct). Mit jeder zusätzlichen IFC-Klasse würde andernfalls der Wartungsaufwand dieser Schemadefinition überproportional steigen.
Daher lässt sich ableiten, dass die IfcWall von IfcRoot, IfcObjectDefiniton, IfcObject, IfcProduct, IfcElement und IfcBuildingElement abhängt. Durch jedes dieser Mutterklassen („Parents“) können Eigenschaften dazukommen, wie der nächste Abschnitt zeigen wird. Die beiden rot dargestellten IFC-Klassen (IfcWallElementedCase und IfcWallStandardCase) sind als DEPRECATED, also veraltet markiert. Das bedeutet, dass ihre Verwendung nicht mehr empfohlen wird, weil in einer der Folgeversionen ihre Löschung geplant ist. An ihrer Stelle soll IfcWall verwendet werden.
Attribute inheritance
In der Dokumentation folgt jetzt eine umfangreiche Tabelle, in der alle möglichen Attribute und Zusammenhänge aufgelistet werden, welche für eine Wand im IFC-Schema vorgesehen sind. Das ist auf den ersten Blick etwas einschüchternd, den Großteil der Zeilen können wir derzeit noch ignorieren. Nehmen wir uns zuerst der Spalten an.
Die erste Spalte („#“) zeigt an, an welcher Position bei der Definition einer Wand das jeweilige Attribut steht. Öffnet man eine IFC-Datei in einem Texteditor, so sieht die Definition einer Wand etwa so aus:
#303=IFCWALL('0DWgwt6o1FOx7466fPk$jl',#56,$,$,$,#306,#318,$,$)
Die Stellennummerierung bezieht sich hier auf die Auflistung innerhalb der Klammer nach „IFCWALL“, die Attribute werden durch Kommata getrennt. Hier zeigt sich, dass nur neun Stellen benötigt werden. Genauso sieht man das auch in der ersten Spalte in der Dokumenation.
Die zweite Spalte bezeichnet das Attribut, also die Eigenschaft des Wand. In der dritten Spalte wird das noch präsziert, indem dort ein Datentyp angegeben wird. In der Spalte „Description“ folgt noch eine Beschreibung der Eigenschaft.
Interessant ist aber insbesondere die vierte Spalte, die mit „Cardinality“ beschriftet ist. Diese zeigt nämlich an, ob und wie viele Einträge für jede Eigenschaft gemacht werden können oder müssen. Das wird in weiterer Folge noch zu interessanten Erkenntnissen führen.
Nun zu den einzelnen Zeilen. Wir sehen, dass es zwischendurch immer wieder Überschriften gibt, die sich auf IFC-Klassen (Mutterklassen) der IfcWall beziehen. Das verdeutlicht uns, dass mit in jeder Ebene der Vererbung tatsächlich Attribute hinzu kommen. IfcRoot beispielsweise legt fest, dass alle untergeordneten Klassen die Atttribute GlobalID oder Name aufweisen, und somit auch unsere Wand.
Spannend ist an dieser Stelle der Blick in die vierte Spalte. Dort steht bei Name ein Fragezeichen („?“), während bei GlobalID die Zelle leer ist. Das heißt, dass eine GlobalID immer eingetragen werden muss, während die Angabe eines Namens optional ist.
Wenn wir nun weiter nach unten scrollen, und die restlichen Attribute der Wand inspizieren, so stellt sich heraus, dass alle ein Fragezeichen in der vierten Spalte haben. Daraus schließen wir, dass sämtliche Angaben zur Wand, abgesehen von der GlobalID, optional sind, also nicht eingetragen werden müssten.
Diese Erkenntnis ist etwas schwer zu verdauen, daher noch ein paar Aspekte zur Verdeutlichung. Attibut Nummer 6, ObjectPlacement, legt im IFC-Schema fest, an welcher Position im Projekt (Koordinaten) sich unsere Wand befindet. Da die Angabe jedoch optional ist, könnten wir eine Wand definieren, ohne ihre Postition überhaupt zu kennen.
Noch ein Stück verwirrender wird es, wenn wir Attribut Nummer 7, Representation, unter die Lupe nehmen. Diese beschreibt nämlich vereinfacht gesagt die Geometrie unseres Objekts. Die Angabe ist jedoch ebenfalls wieder optional. Das bedeutet, dass es für eine korrekt im IFC-Schema definierte Wand unerheblich ist, wie diese aussieht. Die Geometrie kann völlig unbekannt sein, oder aus anderen Gründen nicht angegeben werden (Datenschutz, Sicherheitsbedenken etc.).
Eine völlig legitime Definition einer Wand in einer IFC-Datei kann daher so aussehen (die Dollarzeichen („$“) stehen hierbei als Platzhalter für „leer“):
#303=IFCWALL('0DWgwt6o1FOx7466fPk$jl',$,$,$,$,$,$,$,$)
Die Wand ist also ausreichend definiert, wenn sie eine ID hat. Damit kann sie (datentechnisch) „angegriffen“ und weiterverwendet werden. Natürlich kann diese Wand in einem 3D-Viewer nicht dargestellt werden. Wir werden jedoch in weiteren Beträgen sehen, dass IFC zu weit mehr fähig ist, als zur bloßen Darstellung von Geometrien.
Conclusio
Dies ist ein etwas längerer Artikel, daher zum Schluss noch ein Paukenschlag, um vollens für Verwirrung zu sorgen. Hinter dem Attribut Representation „versteckt“ sich die Definition der Darstellug unserer Wand, und zwar als sogenannte IfcProductRepresentation. Sieht man sich deren Aufbau an, so besteht sie aus drei Attributen, von denen die letzte die tatsächliche Repräsentation beschreibt. Unter „Cardinality“ ist hier jedoch der Eintrag L[1:?] finden. Das heißt, hier kann eine Liste mit einer oder mehreren Darstellungen angelegt werden.
Nochmals zum Mitschreiben: Die Angabe einer Repräsentation ist für unsere Wand grundsätzlich optional. Wenn jedoch eine Repräsenation angegeben wird, so kann diese aus einer oder mehreren parallel existierenden Geometrien bestehen, die je nach Situation verwendet werden können. Im Detail werde ich darauf in einem späteren Artikel eingehen. Die Erkenntnis, dass eine Wand im IFC-Schema keine oder beliebig viele Geometrien aufweisen kann, ist für einen Tag genug.