Der Vortrag dokumentiert die Vorgehensweise und Ergebnisse des Forschungsprojekts FLS – Harmonisierung der Fachobjekte, das am Zentrum für Angewandte Forschung und Technologie (ZAFT) an der HTW Dresden im Auftrag des ITKo von April 2022 bis Februar 2023 durchgeführt wurde. Ziel des Projektes war die Analyse der sogenannten Fachbedeutungslisten des OKSTRA®. Für jedes Bundesland gibt es eine eigene Fachbedeutungsliste.

Diese 16 Fachbedeutungslisten haben teilweise unterschiedliche Diskursbereiche, enthalten Synonyme und Homonyme und weisen unterschiedliche attributive Metadaten aus. Um aktuellen IT-Anforderungen gerecht zu werden und perspektivisch eine Nutzung im Building Information Modeling (BIM) zu ermöglichen, ist eine Harmonisierung und Neustrukturierung der Fachbedeutungen notwendig. Während die derzeit gültigen Fachbedeutungen als „flache“ Liste geführt werden, sollen die harmonisierten Objektklassen eine objektorientierte Modellierung innerhalb des OKSTRA® vorbereiten.

Die ITKo-Fachgruppe „FLS“ Fachobjektmodell über den Lebenszyklus der Straße befasst sich mit der Entwicklung eines Fachobjektmodells, um einen einheitlichen Informationsaustausch über Ländergrenzen hinweg zu gewährleisten. Langfristig soll ein Datenmodell mit Objektklassen erstellt werden, dass Informationen zu allen physikalischen und funktionalen Objekten über den gesamten Lebenszyklus einer Straße abbilden kann. Dieses Modell soll einheitlich gelten und die Fachbedeutungen ablösen. Zentrale Aufgabe des Projektes ist die Erstellung von harmonisierten Objektklassen. Diese werden analytisch aus den mehr als 30.000 Fachbedeutungen der Bundesländer gebildet. Ziel dieser Aufgabe ist ein (formalisiertes) Verständnis davon zu erhalten, welche Modellinhalte derzeit bereits in den Fachbedeutungslisten abgebildet sind.

Das Modell der harmonisierten Objektklassen soll nach Abschluss des Projektes die Grundlage für ein OKSTRA®-Fachmodell „Vermessung“ bilden, das zukünftig ohne die heterogenen Fachbedeutungslisten für die Bestandsdokumentation angewendet wird. Die anschließende Modellierung und Abstimmung mit bereits im OKSTRA® vorhandenen Objekten erfolgt durch die Fachgruppe FLS und ist nicht Bestandteil dieses Projektes. Die Einführung einer verstärkten objektorientierten Modellierung kann auch zu benötigten Anpassungen bestehender Arbeitsprozesse führen. Beispielsweise wird eine Überarbeitung vorhandener Zeichenvorschriften notwendig werden. Das Forschungsprojekt wurde von der Fachgruppe in Auftrag gegeben und durch ihre Mitglieder begleitet. Während des Harmonisierungsprozesses wurde mit Ansprechpartnern aus den Bundesländern die grundlegende Vorgehensweise abgestimmt und Zwischenergebnisse validiert.

Als Ausblick wird vorgestellt, wie in BIM-Projekten Merkmalserver eingesetzt werden, damit CAD-, BIM- und GIS-Software die gleichen Fachbedeutungen domänenübergreifend verwenden können.

Der Fachvortrag zur Veranstaltung ist im Volltext verfügbar. Das PDF enthält alle Bilder und Formeln.

1 Einleitung

Der Begriff „Semantik“ beschreibt den Aspekt der inhaltlichen Bedeutung von Worten und deren Beziehungen untereinander. Die Konzepte der Semantik können zunächst unabhängig von geometrischen Konzepten spezifiziert werden. Wenn Objekte mit formalen Methoden klassifiziert und attribuiert werden sowie Relationen zwischen Objektklassen spezifiziert werden, können Computerprogramme die Semantik inhaltlich „interpretieren“. Interpretation bedeutet im Kontext der geometrisch-semantischen Modellierung, dass Computerprogramme die Semantik für Algorithmen nutzen, also zum Beispiel, um Objekte zu filtern, vergleichen, sortieren, zählen, gruppieren oder zu validieren. Eine automationsgerechte Interpretierbarkeit lässt sich durch eine einheitliche Beschreibung der Semantik erreichen. Diese wird erlangt, wenn sich die Akteure eines fachlichen Diskursbereiches auf die Verwendung einheitlicher Begriffe einigen und diese für alle zugänglich machen. Dafür gibt es im Bereich der Bauindustrie verschiedene Möglichkeiten zur Bereitstellung. Neben den zwei klassischen Möglichkeiten der Nutzung von einfachen Listen/Tabellen und komplexen Schemata (z. B. OKSTRA® mit XML-Schema, IFC mit EXPRESS) etablieren sich im BIM (Building Information Modelling) Kontext die noch relativ jungen Merkmalserver. Die Varianten Liste, Schema und Merkmalserver sollen hier diskutiert werden.

Als praktisches Beispiel dient die Harmonisierung der Fachbedeutungslisten des OKSTRA®, die im Rahmen des Forschungsprojekts FLS – Harmonisierung der Fachobjekte bearbeitet wurde. Das Projekt wurde am Zentrum für Angewandte Forschung und Technologie (ZAFT) an der HTW Dresden im Auftrag des ITKo¹⁾ von April 2022 bis Februar 2023 durchgeführt und hatte die Analyse der sogenannten Fachbedeutungslisten des OKSTRA® zum Ziel. Die größte Schwierigkeit war dabei, dass es aktuell für jedes Bundesland eine eigene Fachbedeutungsliste gibt.

Diese 16 Fachbedeutungslisten haben teilweise unterschiedliche Diskursbereiche, enthalten Synonyme und Homonyme und weisen unterschiedliche attributive Metadaten aus. Um aktuellen IT-Anforderungen gerecht zu werden und perspektivisch eine Nutzung im BIM zu ermöglichen, ist eine Harmonisierung und Neustrukturierung der Fachbedeutungen notwendig. Während die derzeit gültigen Fachbedeutungen als „flache“ Liste geführt werden, sollen die harmonisierten Objektklassen eine objektorientierte Modellierung innerhalb des OKSTRA® vorbereiten.

Die ITKo-Fachgruppe Fachobjektmodell über den Lebenszyklus der Straße (FLS) befasst sich mit der Entwicklung eines Fachobjektmodells, um einen einheitlichen Informationsaustausch über Ländergrenzen hinweg zu gewährleisten. Langfristig soll ein Datenmodell mit Objektklassen erstellt werden, dass Informationen zu allen physikalischen und funktionalen Objekten über den gesamten Lebenszyklus einer Straße abbilden kann. Dieses Modell soll einheitlich gelten und die Fachbedeutungen ablösen. Zentrale Aufgabe des Projektes ist die Erstellung von harmonisierten Objektklassen. Diese werden analytisch aus den mehr als 30.000 Fachbedeutungen der Bundesländer gebildet. Ziel dieser Aufgabe ist ein (formalisiertes) Verständnis davon zu gewinnen, welche Modellinhalte derzeit bereits in den Fachbedeutungslisten abgebildet sind.

Das Modell der harmonisierten Objektklassen soll nach Abschluss des Projektes die Grundlage für ein OKSTRA®-Fachmodell „Vermessung“ bilden, das zukünftig ohne die heterogenen Fachbedeutungslisten für die Bestandsdokumentation angewendet wird. Die anschließende Modellierung und Abstimmung mit bereits im OKSTRA® vorhandenen Objekten erfolgt durch die Fachgruppe FLS und ist nicht Bestandteil dieses Projektes. Die Einführung einer verstärkten objektorientierten Modellierung kann auch zu benötigten Anpassungen bestehender Arbeits prozesse führen. Beispielsweise wird eine Überarbeitung vorhandener Zeichenvorschriften notwendig werden. Das Forschungsprojekt wurde von der Fachgruppe in Auftrag gegeben und durch ihre Mitglieder begleitet. Während des Harmonisierungsprozesses wurde mit Ansprechpartnern aus den Bundesländern die grundlegende Vorgehensweise abgestimmt und Zwischenergebnisse validiert.

^{1) https://itko-strassenwesen.de/}

Als Ausblick wird vorgestellt, wie in BIM-Projekten Merkmalserver eingesetzt werden, damit CAD-, BIM- und GIS-Software die gleichen Fachbedeutungen domänenübergreifend verwenden können.

2 Strukturkonzepte für Semantik

Die Semantik im Bereich des Bauwesens befasst sich mit der Bedeutung von Informationen, die in Beziehung mit Objekten der realen Welt stehen. Diese Informationen werden als Merkmale und Werte bezeichnet und geben den Objekten einen eindeutigen Sinn. Beispielweise erhält das Objekt „Bank“ erst durch das Hinzufügen eines spezifischen Merkmales einen eindeutigen Sinn. Hat die Bank ein Merkmal „Anzahl Sitzplätze“, kann sie eindeutig als Sitzmöbel interpretiert werden. Enthält das Objekt jedoch ein Merkmal „Öffnungszeiten“, muss das Objekt als Gebäude interpretiert werden. Ohne die Verwendung von Merkmalen und deren semantischer Interpretation kann in diesem Beispiel keine eindeutige Aussage getroffen werden, um welche Art Objekt es sich handelt. Diese Mehrdeutigkeit führt auch im Bauwesen häufig zu Missverständnissen, z.B. bei der Kommunikation zwischen Gewerken, die unterschiedliche Sichten auf die Objekte haben, da sie aus verschiedenen Domänen stammen, in denen unterschiedliche Informationen wichtig sind. Die Anreicherung der Objekte mit Merkmalen zur eindeutigen Interpretation bringt hier einen Mehrwert.

Aus diesem Grund haben sich Richtlinien, Standards und de-facto Standards entwickelt, mit denen sich die Objekte einheitlich beschreiben lassen (vgl. Borrmann; König et al., 2021, S. 213 ff). Im Laufe der Zeit haben sich verschiedene Formen zur Bereitstellung von Merkmalsdefinitionen und Wertebereichen etabliert. Die Verwendung zweidimensionaler Listen bzw. Tabellen ist die einfachste Form zur Bereitstellung von vordefinierten Merkmalen. Beispiele für solche Listen sind die Fachbedeutungslisten für die Allgemeinen Geometrieobjekte des OKSTRA® und Codetabellen bei der Vermessung. Der Aufbau der OKSTRA®-Fachbedeutungslisten wird im Abschnitt Analyse der Fachbedeutungslisten vertieft.

2.1 Listen/Tabellen

Listen werden meist als Codelisten mit weiteren Merkmalen verwendet, die über ein allgemeines Merkmal an ein Objekt angehangen werden. Im Falle des OKSTRA®-Schemas dient die Klasse „allgemeines Geometrieobjekt“ mit dem Merkmal „fachliche_Bedeutung“ als Verbindung zum Listeneintrag der Fachbedeutung des Objektes. Vorteile sind die relativ leichte Verständlichkeit der „flachen“ Listen, da jede Zeile der Liste für sich abgeschlossen ist. Das heißt aber auch, dass es keine Verbindungen zwischen Merkmalen gibt. Listen bieten eine einfache Möglichkeit, um in kleinem Maßstab einheitliche Definitionen festzulegen, wie z. B. bei einem bilateralen Austausch zwischen Auftraggeber und Auftragnehmer. Eine darüberhinausgehende Standardisierung von Listen ist kaum vorhanden. Nachteilig ist, dass die Listen meist nur als Dokumente im Excel- oder PDF-Format verfügbar und damit nur schwer maschinenlesbar sind. Ebenso führt die dezentrale Verwendung der Dokumente dazu, dass nach Aktualisierungen der Originaldokumente mehrere Versionen der Listen im Umlauf sind, weil der Nutzer selbstständig darauf achten muss, seine Dokumente aktuell zu halten. Inhaltlich gibt es zwischen den Einträgen keine Relationen und es kann zu Redundanzen kommen. Speziell bei den OKSTRA®-Fachbedeutungslisten ergeben sich weitere Nachteile, wie die Führung einer eigenen Fachbedeutungsliste durch jedes Bundesland. Die Listen können durch die Bundesländer bis auf das gemeinsame Grundgerüst beliebig um Spalten erweitert werden und in einigen Bundesländern wird die Liste jährlich aktualisiert, während andere Bundesländer an ihrer initialen Liste festhalten. Häufig fehlt in den Einträgen eine klare Trennung von Objektklassen, Merkmalen und Werten. Zum Beispiel gibt es die Fachbedeutungen „Schacht rund“ und „Schacht eckig“, wobei der „Schacht“ eine Objektklasse ist und „rund“ und „eckig“ Werte eines Merkmals „Form“. Manche Einträge sind durch eine Vielzahl an zugsetzten Werten stark spezialisiert, z. B. „Bestand Diensttreppe 80 cm mittig Brücke“. Generell besitzen die Einträge der Fachbedeutungslisten keine einheitliche Struktur in ihrer Definition.

Allgemein kann festgehalten werden, dass die bestehenden (Fachbedeutungs-) Listen für den im Bauwesen immer stärker werdenden Detaillierungsgrad der Informationen nicht ausreichend geeignet sind. Teilweise werden Codelisten auch im Schema spezifiziert, um Objektklassen eine Vorauswahl an Merkmalen oder Werten zu geben.

2.2 Schemata

Ein Schema legt den Inhalt und die Struktur eines Diskursbereiches so fest, das Softwareprogramme valide Dokumente erzeugen können oder die Validität eines Dokumentes prüfen können. Das OKSTRA®-Schema ist hierfür ein Beispiel. Es stellt Objektklassen mit vordefinierten Merkmalen und Wertelisten für eine konsistente Datenerfassung und -verwaltung zur Verfügung. Indem Objekten eine Objektklasse zugeordnet wird, erhalten sie deren vordefinierte Merkmale mit objektspezifischen Werten. Weitere Beispiele für Schemata sind das Anwendungsschema des AAA®-Modells (AFIS-ALKIS-ATKIS) und die ASB-ING. Ein Vorteil eines Schemas ist die einheitliche, feste Struktur zur Beschreibung von Daten. Daher kann ein Schema auch zur Integration von Daten aus anderen Quellen verwendet werden. Schemata sind langlebiger als Listen, da die Objektklassen und Merkmale weniger speziell als Listeneinträge sind und daher langfristig weniger Veränderungen unterworfen sind. Schemata verfolgen einen so genannten Closed-World-Ansatz. Der Diskursbereich wird aus praktischen Gründen sehr eng gefasst und als statisch betrachtet, Nachbardisziplinen werden ausgeblendet. Dies widerspricht sowohl dem interdisziplinären BIM-Ansatz als auch den dynamischen Anforderungen an die semantische Tiefe in BIM-Projekten.

2.3 Merkmalserver

Merkmalserver bzw. Merkmaldatenbanken sind Softwaresysteme, die für die zentrale Verwaltung von Merkmalen im Bauwesen entwickelt wurden. „... ein Merkmalserver [stellt] harmonisierte, eindeutige und maschinenlesbare Merkmale bereit und bietet einen Standard zur parametrisierten Beschreibung von digitalen Bauteilen“ (Fröch, Gächter et al., 2019). Beispiele sind das buildingSMART Data Dictionary (bSDD)²⁾, der freeBIM Merkmalserver³⁾, das Open Source Projekt datacat⁴⁾ und der Merkmalserver des BIM-Portal Deutschland⁵⁾. Merkmalserver haben den Vorteil, dass sie die Merkmale zentral zur Verfügung stellen und verwalten. Merkmale lassen sich über API (Application Programming Interfaces) suchen und maschinenlesbar ausgeben. Wenn die internationalen Standards wie DIN EN ISO 12006-3 (2017) als Meta-Schema und DIN EN ISO 23386 (2020) als Redaktionsleitfaden im Merkmalserver eingesetzt werden, können Merkmale zukünftig auch zwischen Merkmalservern ausgetauscht werden, was die Interoperabilität von Taxonomien verschiedener Domänen zusätzlich verbessert. Wie dies umgesetzt werden kann, wurde in (Clemen; Thurm et al., 2021) untersucht.

²⁾ https://technical.buildingsmart.org/services/bsdd/

³⁾ https://db.freebim.at

⁴⁾ https://github.com/dd-bim/datacat

⁵⁾ https://via.bund.de/bim/merkmale/search

Eine scharfe Trennung zwischen Listen, Schemata und Merkmalservern ist nicht möglich, da Listen auch in Schemata und Merkmalservern als Codelisten verwendet werden können und Schemata die Merkmalstruktur des Merkmalserver festlegen. Im Merkmalserver sind die Vorteile aller Konzepte vereint. Die Tabelle 1 stellt wesentliche Eigenschaften von Listen, Schemata und Merkmalservern gegenüber.

Tabelle 1: Vergleich von Listen, Schemata und Merkmalserver

3 Harmonisierung der OKSTRA® Fachbedeutungslisten

Für die Fachbedeutungslisten sollte zunächst der Schritt von der Listenstruktur in ein Objektklassenschema untersucht werden, um die Fachbedeutungen aufzulösen. Damit ließe sich das OKSTRA®-Schema in einem künftigen Schritt auch in einem Merkmalserver bereitstellen. Die Harmonisierung der Fachbedeutungslisten zu Objektklassen mit Merkmalen im Rahmen des Forschungsprojektes FLS – Harmonisierung der Fachobjekte wird in den folgenden Abschnitten beschrieben.

3.1 Analyse der OKSTRA® Fachbedeutungslisten

Innerhalb des „Objektkatalog für das Straßen- und Verkehrswesen“ (OKSTRA®) gibt es ein Paket mit allgemeinen Geometrieobjekten, denen über das Attribut „fachliche_Bedeutung“ Informationen aus den Fachbedeutungslisten zugeordnet werden können. Seit 2009 hat jedes Bundesland seine eigene Liste. Alle Fachbedeutungslisten haben mit den Spalten Datum, Fachbedeutung, RAS-Verm, Bedeutung, Symbolart und Landescode im Kern die gleiche Struktur, wurden jedoch durch die Bundesländer teilweise mit weiteren Spalten ergänzt. Die Analyse erfolgte mit den zum Stand 1. 4. 2022 aktuellen Listen und umfasste insgesamt 33784 Fachbedeutungen. Diese sind unter den Bundesländern sehr ungleich verteilt, wie das Bild 1 zeigt.

Bild 1: Aufteilung der Fachbedeutungen nach Bundesländern

Während Hessen mit 8513 ein Viertel aller Fachbedeutungen stellt, hat Hamburg mit 84 nur einen Anteil von 0,2 %. Ein Grund für die vielen Fachbedeutungen in einigen Bundesländern sind von der Bedeutung her identische Einträge, die sich nur durch ihre Symbolart unterscheiden. Werden diese Duplikate entfernt, reduziert sich die Anzahl bereits auf 18119 Fachbedeutungen. Zudem wurde angenommen, dass es auch zwischen den Bundesländern Duplikate gibt. Die Analyse ergab jedoch, dass keine Fachbedeutung mit exakt gleicher Bedeutung in allen Bundesländern vorkommt. Die Fachbedeutungen „Sonstiges“ und „Bankett“ kamen mit 15- bzw. 14-Mal am häufigsten vor, während mit 16.453 Fachbedeutungen über 90 % nur einmal vorkamen (siehe Bild 2).

Bild 2: Aufteilung der Fachbedeutungen nach Häufigkeit ihres Vorkommens in unterschiedlichen Bundesländern

Die Analyse hat gezeigt, dass die Fachbedeutungen oft sehr detailliert beschrieben sind, wodurch sie sich in anderen Bundesländern nicht eins zu eins wiederfinden lassen. Dadurch ergibt sich eine hohe Zahl zu harmonisierender Fachbedeutungen.

3.2 Harmonisierung der Fachbedeutungen

Für eine jederzeit transparente und nachvollziehbare Harmonisierung wurde eine SQLite Datenbank als Speicher für alle Bearbeitungsschritte an den Fachbedeutungen verwendet. In diese wurden zu Beginn alle Fachbedeutungen importiert. Die Datenbank speichert für jede Fachbedeutung die Grundlage der Harmonisierung, welche Fachbedeutungen ein harmonisiertes Objekt bilden, und welche Attribute und Attributwerte sich ergeben.

Die Harmonisierung wurde nach dem Grundsatz durchgeführt, so wenig eigene Objekte wie möglich, jedoch so viele Objekte wie nötig zu definieren. Anhaltspunkte für die Objekterstellung bieten unter anderem die Spalte RAS-Verm der Fachbedeutungslisten, in welcher Objekte der „Richtlinie für die Anlage von Straßen – Teil Vermessung“ referenziert werden, sowie die in OKSTRA® bereits bestehenden Objekte.

In Absprache mit der Fachgruppe FLS wurden zunächst weitere Fachbedeutungen von der Harmonisierung ausgeschlossen, welche lediglich der Plandarstellung dienen. Dies betrifft unter anderem Fachbedeutungen, welche die Symbolart Text haben, Strichstärken besitzen oder Kartenobjekte bezeichnen. Ebenso wurden Fachbedeutungen aus ALKIS nicht in der Harmonisierung berücksichtigt, um Redundanzen zu vermeiden. Im nächsten Schritt wurden die Duplikate innerhalb der Bundesländer entfernt, welche nur auf Grund ihrer unterschiedlichen Symbolart bestanden. Mit Hilfe der RAS-Verm-Referenzen wurden erste Objekte gebildet, sowie aus Duplikaten die sich aus exakt gleichen Fachbedeutungen unterschiedlicher Bundesländer ergaben. Die bis dahin nicht zugeordneten Fachbedeutungen wurden mit Hilfe eines Fuzzy-Stringvergleiches analysiert. Bei diesem unscharfen Vergleich werden die Fachbedeutungen auf ähnliche Zeichenketten untersucht. Zum Beispiel würde das „europäische Vogelschutzgebiet“ bei einem exakten Stringvergleich nicht mit dem „Europäischen Vogelschutzgebiet“ übereinstimmen, mit einem Fuzzy-Stringvergleich schon. Mittels Fuzzy-Methoden (z. B. Hamming-Distanz) wurde so versucht, in den bis dahin bestehenden harmonisierten Objektklassen Übereinstimmungen zu finden und entsprechend zuzuordnen. Bis hier ließen sich die durchgeführten Schritte teilweise automatisieren. Die restlichen ca. 1.500 Fachbedeutungen wurden „in Handarbeit“ harmonisiert. Die Abstimmung der harmonisierten Objektklassen erfolgte in einem iterativen Prozess, in den auch Vertreterinnen und Vertreter der Bundesländer und die Fachgruppe FLS einbezogen wurden. Als Ergebnis entstanden 168 harmonisierte Objektklassen.

3.3 Attribuierung der Objektklassen

Ein Teil der Harmonisierung machte auch die Generalisierung der teilweise sehr spezifischen Fachbedeutungen aus. Damit diese speziellen Fachbedeutungen nicht verloren gehen, erhielten die allgemeinen harmonisierten Objektklassen Attribute, sowie teilweise Wertetabellen als Wertebereiche für die Spezialisierung von Objekten. Ein Beispiel ist im Bild 3 zu finden. In verschiedenen Fachbedeutungen wurde die Objektklasse Baum als Gemeinsamkeit identifiziert. Die weiteren Informationen wurden unter anderem zu Wertelisten der Attribute Baumtyp und Baumart zusammengefasst und an die Objektklasse Baum gehangen.

Bild 3: Harmonisierung verschiedener Fachbedeutungen zum Objekt Baum (Beispiel nicht abschließend)

Die Attributvergabe an die generalisierten Objektklassen hat zur Folge, dass widersprüchliche Kombinationen entstehen können. So kann eine Leitung als Wasserleitung typisiert werden und gleichzeitig ein Attribut Spannung erhalten. Da das Projekt in erster Linie der Bestandsaufnahme dient, ist diese Zuordnung in Absprache mit der Fachgruppe FLS erlaubt.

Die Attribute und Attributwerte wurden alle aus den Fachbedeutungen entnommen. Eine Zuordnung neuer Attribute erfolgte nicht. Zusätzlich wurden einfache Teil-Ganzes-Beziehungen zwischen den Objektklassen definiert, indem die Attribute „Teil von“ und „Ganzes aus“ hinzugefügt wurden.

Einige der gefundenen Attribute können von allen Objektklassen verwendet werden. Daher wurden sie als allgemeine Attribute eingeführt. Die Tabelle 2 gibt einen Überblick über die allgemeinen Attribute, deren Datentypen und Werte.

Tabelle 2: Allgemeine Attribute aller harmonisierten Objektklassen

Die Objektklassen wurden außerdem für eine bessere Filterung thematisch über das Attribut Themen gruppiert. Objektklassen können mehreren Themen zugeordnet sein. Die Themen sind:

• Entwässerung,
• Straßen,
• Geländeform,
• Tunnel,
• Versorgung,
• Andere Verkehrsträger,
• Vegetation,
• Verkehrszeichen.

In den ursprünglichen Fachbedeutungslisten ist über die Spalte Symbolart geregelt, in welcher Geometrie die jeweilige Fachbedeutung dargestellt werden kann. Aus allen Fachbedeutungen, die zum jeweiligen harmonisierten Objekt beigetragen haben, wurde die Summe der Symbolarten gebildet und als Attribut Geometrie angehängt. So ist es möglich, dass einer harmonisierten Objektklasse alle Geometrien Punkt, Linie, Fläche und Volumen zugeordnet wurden. Dies bildet nur den derzeitigen Stand ab. In Zukunft sollen die Objekte als 3D-Volumenkörper für die Verwendung in BIM modelliert und bereitgestellt werden, wodurch sich eine Angabe der Symbolart erübrigt.

3.4 UML und XMI Repräsentation

Die OKSTRA®-Objektklassen werden als UML-Klassendiagramm und im XML (Extensible Markup Language) Austauschformat XMI (XML Metadata Interchange) bereitgestellt. Daher sollten die harmonisierten Objektklassen ebenfalls als UML modelliert und in XMI übergeben werden, wofür die jeweilige Version 2.1 verwendet wurde. Die Struktur der XMI-Datei des OKSTRA® wurde analysiert, um ein Java-Tool zu implementieren, welches automatisiert alle harmonisierten Objektklassen, deren Attribute und Beziehungen mittels SQL-Statements aus der SQLite Datenbank abfragt und daraus eine XMI-Datei generiert. Anschließend wurde die XMI-Datei in Enterprise Architect importiert und die Objektklassen als UML-Klassendiagramme visualisiert (siehe Bild 4).

Bild 4: Auszug UML-Klassendiagramm zum Thema Brücke

3.5  3D-Modellierung

Für eine zukünftige Verwendung der OKSTRA®-Objektklassen als vordefinierte, attribuierbare 3D-Bauteilklassen in BIM-Modellen sollten einige der harmonisierten Objektklassen für eine beispielhafte Umsetzung modelliert und attribuiert werden. Für die Modellierung der 3D-Modelle wurde die BIM-Autorensoftware Autodesk Revit verwendet, in der die Bauteile als sogenannte Familien modelliert wurden. Da die Modellierung nur einfache Objekte erstellen soll, wurden diese nicht geometrisch parametrisiert und es wurde nur die Außenhülle modelliert. Anschließend wurden jedem Bauteil mit Hilfe eines Dynamo-Skriptes automatisiert die Attribute der jeweiligen Objektklasse vergeben.

Im nächsten Schritt wurden die Bauteile in Szenen angeordnet und beispielhafte Attributwerte vergeben, um deren Verwendung zu demonstrieren. Zuletzt wurden die Szenen nach IFC (Industry Foundation Classes) exportiert, damit diese mit den Attributwerten der einzelnen Bauteile auch in anderer Software angesehen werden kann (Bild 5). Während des Exportes wurden die Bauteile mit dem IfcClassification-Konzept als FLS-Objektklassen definiert, um zu demonstrieren, wie zukünftig die Klassifizierung und Attribuierung mit Informationen aus Merkmalskatalogen durchgeführt werden kann. Dies kann durch die Abfrage eines Merkmalserver über Plugins in der jeweiligen Modelliersoftware geschehen.

Bild 5: Innerstädtische Szene mit zugehörigen IFC-Attributen

3.6 Ergebnis der Harmonisierung

Neben den bereits genannten UML-Klassendiagrammen und den 3D-Modellen ist eine Objektliste (Bild 6) entstanden, welche alle 168 harmonisierten Objektklassen mit allgemeinen (orange) und spezifischen (blau) Attributen, Werten und weiteren Informationen (grün) enthält. Eine Migrationstabelle schlüsselt für jedes Bundesland auf, zu welcher Objektklasse die Fachbedeutungen aus der ursprünglichen Liste harmonisiert wurden. 12526 Fachbedeutungen bleiben dabei aus den genannten Gründen ohne Zuordnung zu einem harmonisierten Objekt. Eine weitere Liste schlüsselt für jede harmonisierte Objektklasse auf, aus welchen Fachbedeutungen sie entstand. Alle Listen werden aus der Projektdatenbank automatisiert erzeugt. Die Datenbank selbst kann ebenfalls genutzt werden, um über SQL-Abfragen spezifische Fragen zur Harmonisierung zu beantworten.

Bild 6: Ausschnitt aus der harmonisierten Objektliste

4 Ausblick

Für eine konventionelle Modellierung müssen in zukünftigen Entwicklungsprojekten die harmonisierten Objektklassen in das bestehende OKSTRA®-Schema integriert werden. Die Fachbedeutungslisten der Bundesländer wären damit obsolet. Wenn darüber hinaus eine schemaübergreifende Nutzung der Fachbedeutungen angestrebt wird, müssen die Fachbedeutungen auf einem Merkmalserver publiziert werden. Dieser Merkmalserver könnte dann bei der Erstellung der Teil- und Fachmodelle des Straßenwesens in CAD-, BIM-, GIS- und ERP-Systemen genutzt werden, um Objekte auf gleiche Art und Weise zu klassifizieren und zu attribuieren. Der Merkmalserver des BIM-Portal Deutschland oder auch das bsDD können also sinnvolle Publikationsmedien für einen BIM-fähigen OKSTRA®-Katalog sein.

Bekanntmachung

Die praktischen Ergebnisse wurden im ITKo-Projekt „FLS – Harmonisierung der Fachobjekte“ erarbeitet und durch das FBA finanziert. Die theoretischen Hintergründe werden derzeit in einem Promotionsvorhaben (TU Dresden/Prof. Menzel, HTW Dresden/Prof. Clemen, HTW Dresden/Dr. Tauscher) von Sebastian Schilling bearbeitet. Die kooperative Promotion wird durch den Freistaat Sachsen und die Europäische Union kofinanziert.

Literaturverzeichnis

1. Borrmann, A., König, M., Koch, C. & Beetz, J. (Hrsg.). (2021): VDI-Buch. Building information modeling: Technologische Grundlagen und industrielle Praxis (2., aktualisierte Auflage). Springer Vieweg.
2. Clemen, C., Thurm, B. & Schilling, S. (2021): Managing and publishing standardized data catalogues to support BIM processes. CIB W78 Conference. Proceedings of the 38th International Conference of CIB W78. https://www.researchgate.net/publication/355486637_Managing_and_publishing_standardized_data_catalogues_to_support_BIM_processes
3. Fröch, G., Gächter, W., Tautschnig, A. & Specht, G. (2019): Merkmalserver im Open-BIM-Prozess. Bautechnik, 96(4), 338–347. https://doi.org/10.1002/bate.201800092
4. ISO (2017): DIN EN ISO 12006-3 – 2017-04: Bauwesen – Organisation von Daten zu Bauwerken – Teil 3: Struktur für den objektorientierten Informationsaustausch. https://www.beuth.de/de/norm/din-en- iso-12006-3/263869434
5. ISO (2020):DIN EN ISO 23386:2020-11: Bauwerksinformationsmodellierung und andere digitale Prozesse im Bauwesen – Methodik zur Beschreibung, Erstellung und Pflege von Merkmalen in miteinander verbundenen Datenkatalogen. https://www.beuth.de/de/norm/din-en-iso-23386/317329650