Entwicklung einer CityGML-Erweiterung für das Facility Management am Beispiel Landeshauptstadt München

Transkript

1 Entwicklung einer CityGML-Erweiterung für das Facility Management am Beispiel Landeshauptstadt München Rosina BLEIFUSS, Andreas DONAUBAUER, Jan LIEBSCHER und Markus SEITLE Dieser Beitrag wurde nach Begutachtung durch das Programmkomitee als reviewed paper angenommen. Zusammenfassung 3D-Stadtmodelle sind in ihrer Anwendung sehr vielseitig und funktional. Sie sind nicht nur in der Stadtplanung im Einsatz, sondern werden auch zum Beispiel im Tourismus, Mobilfunk, zur Lärmausbreitungsberechnung und im Katastrophenschutz verwendet. Das im OGC-Standard CityGML definierte semantische Modell für 3D-Stadtmodelle ermöglicht einen nahtlosen Übergang zwischen verschiedenen Detaillierungsstufen (Levels of Detail, LoD). Auf der höchsten Detaillierungsstufe LoD4, die heute nur in den wenigsten Stadtmodellen umgesetzt ist, wird der gesamte Innenraum eines Gebäudes mit allen festen Bestandteilen wie Treppen und Heizungsanlagen, aber auch beweglichem Inventar wie Tischen und Stühlen modelliert. Die Verfügbarkeit des Innenraums ruft ganz neue Anwendungen hervor bzw. ermöglicht es, an schon bestehende anzuknüpfen. Eine Anwendung von derartigen Innenraummodellen ist das Facility Management. In diesem Beitrag wird die Entwicklung einer CityGML-Erweiterung für das Facility Management am Beispiel der Landeshauptstadt München beschrieben. 1 Ausgangssituation: Das 3D-Stadtmodell der Landeshauptstadt München Nach wissenschaftlichen Vorarbeiten an der Technischen Universität München, siehe z.b. (SCHILCHER et al. 1998) arbeitet die Landeshauptstadt München seit 2001 operativ am digitalen 3D-Stadtmodell. Zunächst als ein Instrument für die Stadtplanung gedacht, wurde es bald auch für umwelttechnische Untersuchungen wie Lärmausbreitung und Solarpotentialanalysen genutzt. Im Jahr 2005 kam in Zusammenarbeit mit der RSS GmbH und LandXplorer (3D Geo GmbH, heute Autodesk) die erste kommerzielle 3D-Karten- Applikation auf den Markt, die die Daten Bewohnern und Touristen in einer Form auf Ihrem heimischen PC nutzbar machte, wie man es heute von Online-Diensten wie Google Earth oder Microsoft Virtual Earth gewohnt ist (KRANZ et al. 2005). Neben den Anwendungen des Modells stand die Datenhaltung und Datenabgabe im Fokus der Entwicklung. Von Anfang an wurde auf offene Standards gesetzt. Anfangs wurde VRML als zentrale Datenaustauschschnittstelle eingesetzt. Nachdem CityGML konkrete Formen annahm, wurde mit der Implementierung einer CityGML optimierten Datenbank-

2 Entwicklung einer CityGML-Erweiterung für Facility-Management-Anwendungen 123 struktur und mit dem Export nach CityGML begonnen. Davon abgeleitet wurde auch der Datenaustausch mittels des Visualisierungsformats KML realisiert (SEITLE 2007). Mittlerweile sind CityGML 1.0 und KML 2.2 als OGC-Standards anerkannt und die Umsetzung entsprechender optimierter Datenstrukturen in der zentralen Geodatenbank (Geodatenpool) der Landeshauptstadt München erfolgt. Im Zuge dieser Umsetzung soll auch die Etablierung von LOD4-Daten im Bezug auf das Facility Management untersucht werden. Hintergrund sind u.a. die Bestrebungen nach der Etablierung eines standardisierten zentralen Facility Management Datenpools innerhalb der Stadtverwaltung, auf den unterschiedliche Anwender wie Büroraummanagement, Hochbau und Vergabestelle zugreifen können. Basierend auf 2D-Innenraumplänen soll ein entsprechendes semantisches 3D-Innenraummodell erstellt sowie dessen Nutzung und Erweiterung in Verbindung mit Sachdatentabellen untersucht werden. 2 Innenraummodellierung als Grundlage für Facility- Management-Anwendungen 2.1 Innenraummodellierung in CityGML CityGML wird von der Special Interest Group 3D (SIG 3D) der Initiative Geodateninfrastruktur NRW (GDI NRW) seit Mai 2002 entwickelt und ist seit August 2008 als internationaler OGC-Standard verabschiedet. Unter CityGML ist ein geometrisch-semantisches Informationsmodell für 3D-Stadtmodelle zu verstehen. Semantische 3D-Stadtmodelle zeichnen sich dadurch aus, dass "Informationen über den städtischen Raum in Form von klassifizierten Objekten mit räumlichen und nicht-räumlichen Eigenschaften strukturiert sind und damit auch die Bedeutung, Einordnung sowie physikalische und funktionale Eigenschaften repräsentiert werden. Auch die räumlichen und logischen Beziehungen zwischen Objekten werden ausdrücklich beschrieben (KOLBE 2008). Mit CityGML können virtuelle Stadtmodelle für anspruchsvolle Analyseaufgaben genutzt werden. CityGML ist ein offenes, XML basiertes Datenmodell für die Speicherung und den Austausch virtueller 3D-Stadtmodelle. Das Anwendungsschema ist als GML3-Schema implementiert und entspricht damit dem erweiterbaren internationalen OGC-Standard für den Austausch räumlicher Daten. Außerdem basiert CityGML auf einer Reihe weiterer Standards der ISO 191xx-Familie, der OGC, des W3C Consortiums, des Web 3D Consortiums und der OASIS (GRÖGER et al. 2008). Des Weiteren definiert CityGML die Klassen und Beziehungen für die meisten topographisch relevanten Objekte in Städten und regionalen Modellen unter Beachtung der Eigenschaften von Geometrie, Topologie, Semantik und Aussehen. Die Repräsentation von 3D-Stadtmodellen kann in CityGML in fünf Detaillierungsstufen (Level of Details, LoDs) erfolgen. Der einfachste Grad (LoD0) entspricht einem 2,5D Digitalem Geländemodell (DGM). Als Grundgerüst für Gebäude dient das Blockmodell (LoD1), was diese stark vereinfacht in Form von Quadern oder prismatischen Körpern darstellt. Die folgenden Detaillierungsstufen reichen angefangen von einem Stadtmodell mit standardisierten Dachformen (LoD2) über ein weitaus detaillierteres Modell mit Fassa-

3 124 R. Bleifuß, A. Donaubauer, J. Liebscher und M. Seitle den (LoD3) bis hin zu einem begehbaren Innenraummodell mit einzelnen Raumbestandteilen (LoD4) (GRÖGER et al. 2008). In CityGML sind Basisklassen definiert, die die wichtigsten Bestandteile von 3D- Stadtmodellen abdecken. Darunter befinden sich: Gelände (ReliefFeature), Landnutzung (LandUse), Stadtmöblierung (CityFurniture), Vegetation (VegetationObject), Verkehr (Transportation), Objektgruppen (CityObjectGroup), erweiterbare Objekte (GenericCity- Objects), Gewässer (WaterObject) und Bauwerke (Sites). Site ist eine abstrakte Superklasse für Gebäude und Anlagen wie beispielsweise künftig auch Brücken, Tunnel und Dämme (GRÖGER et al. 2008). Die Struktur der Modellierung ergibt sich in CityGML durch die Ableitung von der Oberklasse CityObject. Alle abgeleiteten Klassen erhalten damit deren Basisfunktionalitäten. Die Gebäudeklasse (Building) ist mit ihrer Entwicklung bis zum Detaillierungsgrad LoD4 eine der am weitesten spezialisierten. In ihr sind neben dem Gebäude als Grundgerüst (LoD2) auch Gebäudeaußenbestandteile in LoD3 wie Treppen oder Balkone enthalten, genauso wie Öffnungen für Türen und Fenster. Der Innenbestandteil (LoD4) des Gebäudes der Raum kann mit unbeweglichen Objekten wie Rohren oder Heizungen dargestellt werden, aber auch für bewegliche Artikel wie Möbel steht eine Klasse bereit. Die äußere Baukonstruktion unterscheidet sich in Dach, Boden und Wand, die Räume bestehen aus Decke, Innenwand und Fußboden (GRÖGER et al. 2008). Um das CityGML-Modell mit anwendungsbezogenen Themenfelder zu erweitern, die noch nicht in dem vordefinierten Modell enthalten sind, bietet CityGML ab Version zwei Möglichkeiten dafür an: Einmal das Prinzip der generischen Objekte/Attribute, bei der das Modell in Instanzdokumenten um neue Attribute und Objekte erweitert wird. Eine andere Möglichkeit der Erweiterung ist die Erstellung eines eigenen Schemas, Application Domain Extension (ADE) genannt. Bei einer Application Domain Extension wird ein Fachschema (XML Schema) auf Basis des CityGML-Schemas mit eigenem Namensraum definiert, wobei existierende CityGML-Objekte um zusätzliche räumliche und nichträumliche Attribute und zusätzliche Beziehungen erweitert werden können oder neue, fachspezifische Objektarten auf Basis der abstrakten CityGML-Oberklasse CityObject definiert werden können (GRÖGER et al. 2008). Mit dem bestehenden Modell in CityGML und der Möglichkeit zur Erweiterung um Fachschalen ist der Grundstein gelegt für Anwendungen, die die Bestandteile und Informationen von Gebäuden außen so wie innen nutzen. Eine solche Anwendung ist das Facility Management. 2.2 Facility Management Das Facility Management hat sich in den letzten Jahren stark verbreitet. Es ist in großen Unternehmen, großen Kommunen und anderen Organisationen unentbehrlich geworden, um deren Verwaltung reibungslos ablaufen zu lassen. Als deutscher Verband für Facility Management versteht sich die GEFMA e.v. GErman Facility Management Association, die 1989 gegründet wurde. Die Richtlinie der GEFMA definiert den Begriff des Facility Managements nach dem Stand von Wissenschaft und Forschung sowie dem Verständnis der mitwirkenden Marktteilnehmer folgendermaßen:

4 Entwicklung einer CityGML-Erweiterung für Facility-Management-Anwendungen 125 Facility Management (FM) ist eine Managementdisziplin, die durch ergebnisorientierte Handhabung von Facilities und Services im Rahmen geplanter, gesteuerter und beherrschbarer Facility Prozesse eine Befriedigung der Grundbedürfnisse von Menschen am Arbeitsplatz, Unterstützung der Unternehmens-Kernprozesse und Erhöhung der Kapitalrentabilität bewirkt. Hierzu dient die permanente Analyse und Optimierung der kostenrelevanten Vorgänge rund um bauliche und technische Anlagen, Einrichtungen und im Unternehmen erbrachte (Dienst-) Leistungen, die nicht zum Kerngeschäft gehören (MAY 2006). Die Basis des Facility Managements ist der Raum bzw. das Flächenmanagement, denn über die Fläche des Raumes laufen alle Prozesse ab. Das Flächenmanagement sorgt dafür, dass die bauliche Konstruktion optimiert wird mit dem Ziel der Vergrößerung der für das Kerngeschäft nutzbaren Flächen. Außerdem wird dadurch eine bessere Flächennutzung durch ökonomische Belegung der Flächen und eine ergonomische und funktionelle Gestaltung der Arbeitsplätze angestrebt. Im Rahmen des Flächenmanagements werden Objektdaten mit ihren Attributen gespeichert. Dazu gehören die Raumdaten mit ihren Zuordnungen wie Liegenschaft oder Etage, aber auch Eigenschaften wie Flächenart und Nutzung, Kostenstelle, Inventar und Mitarbeiter. Auch Serviceleistungen wie Reinigung und Sicherheit sind in den Raumdaten enthalten (MAY 2006). Das Flächenmanagement ist die Grundlage für alle anderen Funktionalitäten. Geforderte Funktionalitäten, die ein CAFM erfüllen sollte, sind z.b. das Reinigungsmanagement, die Schlüsselverwaltung, das Instandhaltungsmanagement, die Vermietung, das Vertragsmanagement oder das Umzugsmanagement. Um die Nutzung der Flächen aufzuteilen, wird dafür die DIN 277 Grundflächen und Rauminhalte von Bauwerken im Hochbau" verwendet. Die DIN 277 gilt als maßgebende Grundlage für das Verständnis von Grundflächen und Rauminhalten von Bauwerken oder von Teilen von Bauwerken im Hochbau, sowie für die Ermittlung der Kosten im Hochbau nach DIN 276, der Nutzungskosten im Hochbau nach DIN und bei dem Vergleich von Bauwerken (DIN ). Wird das Facility Management computergestützt abgewickelt, spricht man von einem Computer Aided Facility Management (CAFM). Dabei handelt es sich bei einem CAFM um ein Computerprogramm, welches aus einer Datenbank und einer Anwenderoberfläche besteht. Für die visuelle Darstellung ist ein CAFM häufig mit einem CAD-Programm verknüpft. Werden alle geforderten Funktionalitäten in dem CAFM betrieben, sind beispielsweise folgende Abfragen möglich: Liegen Räume nebeneinander? Ist die Belichtung auf der Nord- oder Südseite? Wo ist der nächste Fluchtweg? Wie oft, wann und von wem wird das Büro gereinigt? Welcher Schlüssel passt zu dieser Tür? Auf der Grundlage von gespeicherten Daten über die Gebäude- und Raumflächen können die Antworten zu Flächenverteilungen, Belegungen und Ausstattungen analysiert, geplant und sowohl grafisch als auch alphanumerisch dokumentiert werden.

5 126 R. Bleifuß, A. Donaubauer, J. Liebscher und M. Seitle 2.3 Anwendungsfälle für ein Facility Management in 3D Heute gängige Lösungen für das CAFM arbeiten auf einer 2D-Datenbasis. Die dritte Dimension wird meist weder bei Abfragen, noch in grafischen Darstellungen verwendet. Ziel der hier beschriebenen Untersuchung ist es, den Nutzen einer semantisch modellierten 3D- Datenbasis für das Facility Management zu dokumentieren. Grundsätzlich sind hierbei alle Anwendungen relevant, die eine Kenntnis von Raum- oder Gebäudehöhe benötigen. In einem Raum können über die Höhe auch Flächen- sowie Massen- oder Volumenberechnungen in Betracht gezogen werden. Eine besondere Anforderung für den 3D-Bereich im Facility Management stellt auch die Energiesparte dar. Ab 1. Januar 2009 ist bei der Errichtung von Gebäuden nach der Energieeinsparverordnung (EnEV 2007) ein Energiebedarfsausweis auszustellen, der das Gebäude energetisch bewertet. Zur Ermittlung des Heizwärmebedarfs sind dafür unter anderem Informationen über Wände, Geschossdecke, Fenster und Türen notwendig. Beispielsweise kann über die Kenntnis der Wand-, Fenster- und Türflächen der Wärmeverlust für energietechnische Anwendungen berechnet werden. Im Folgenden wird der Anwendungsfall Umzugsmanagement bei der Landeshauptstadt München beschrieben. Die Umzugsplanung innerhalb von Bürogebäuden der Landeshauptstadt beinhaltet die Aufgaben der Ermittlung von verfügbaren Freiflächen und Erstellung von Einrichtungs- und Umzugsvarianten. Bei einem möglichen Umzug ist es von Interesse, in welcher Höhe Kabel für IT- oder Telefonanschlüsse vorhanden sind. Das erspart einen unnötigen Aufbruch der Wand. Außerdem können alle Flächen, sowohl Fensterals auch Wandflächen ausgewertet werden. Der Nutzen daraus ist unter anderem die Möglichkeit zur Berechnung der Kosten für Malerarbeiten. Das gleiche gilt für Fensterflächen für einen eventuellen Austausch oder Putzarbeiten. Auch die Höhe von bestimmten Objekten oder Möbeln wie Tische und Schränke kann bei einem Umzug mit einbezogen werden. Durch eine grafische 3D-Darstellung, wird nach (MAY 2006) die Akzeptanz von Umzügen bei den betroffenen Mitarbeitern und Entscheidungsträgern erheblich erhöht. 3 Modellbasierter Ansatz zur Erweiterung von CityGML Bevor die inhaltlichen Aspekte der Erweiterung beschrieben werden, soll zunächst die gewählte Methodik beleuchtet werden. Für die CityGML-Erweiterung bestand die Herausforderung darin, Modelle für zwei Plattformen (XML-Schema, ORACLE) so zu erzeugen, dass Kohärenz gewährleistet und damit die Überführbarkeit von Daten von einer auf die andere Plattform problemlos möglich ist. Als Lösungsansatz für die Synchronisation der Modelle auf beiden Plattformen dient der so genannte Modellbasierte Ansatz, wie er von der Object Management Group in der Model Driven Architecture, MDA definiert wird, siehe z.b. (OBJECT MANAGEMENT GROUP 2003). Die zentrale Idee dieses Vorgehens ist die Beschreibung von plattformunabhängigen Modellen (Platform Independent Models, PIM) mittels einer konzeptionellen Schemasprache (z.b. UML) und der Herleitung plattformspezifischer Modelle (PSM) aus den PIM mittels vordefinierter Regeln (PIM to PSM mapping).

6 Entwicklung einer CityGML-Erweiterung für Facility-Management-Anwendungen 127 Damit soll gewährleistet werden, dass alle im Rahmen der ADE-Entwicklung definierten Erweiterungen der CityGML-Basisschemata, wie anwendungsspezifische Klassen und Attribute sowohl auf der Ebene von XML-Schema als auch auf der Ebene des ORACLE- Datenbankschemas existieren. Für das PIM to PSM mapping konnten im Fall XML-Schema als PSM die Regeln aus ISO verwendet werden. Für den Fall ORACLE DB-Schema als PSM existierten derartige Vorgaben nicht. Abbildung 1 zeigt die Vorgehensweise schematisch. Abb. 1: Modellbasierter Ansatz für die CityGML-Erweiterung Die inhaltlichen Überlegungen zur CAFM-Erweiterung von CityGML lassen sich wie folgt zusammenfassen. In dem Gebäudemodell Building sind schon Klassen für die Kategorisierung aller Bauteile und Ausstattungsobjekte von Gebäuden vorhanden. Um diese für das Facility Management nutzen zu können, müssen die vorhandenen Klassen nur noch erweitert werden. Von den beiden im CityGML-Standard beschriebenen Möglichkeiten für die Erstellung einer ADE wurde die Option umgesetzt, bei der eigene Klassen mit eigenen Attributen von schon bestehenden Klassen abgeleitet werden. Der Hauptgedanke für die Wahl dieses Ansatzes steckt in der Aufteilung der Bauteile eines Raumes nach den Kostengruppen nach DIN 276 Kosten im Hochbau. Die DIN-Norm DIN 276 Kosten im Hochbau regelt die Kostenermittlung im Bauwesen und hat sich zum Beispiel am Flughafen München im dortigen Facility-Management-System bewährt (HALLER 2008). In der DIN 276 werden sieben Stufen der Kostengliederung festgelegt. Diese umfassen den gesamten Bau eines Gebäudes angefangen von der Planung und Erschließung bis zur Kategorisierung jedes kleinsten Objektes innerhalb und außerhalb des Gebäudes. Für die ADE werden hier die Gruppen für das Bauwerk bezogen auf die Baukonstruktion und die Technischen Anlagen verwendet. Darin kann die ganze Baukonstruktion unterschieden werden in Gründung, Außen- bzw. Innenwände, Decken und Dächer etc. Auch die baukonstruktiven Einbauten kommen darin vor. In der Übergruppe Technische Anlagen werden Anlagen wie Abwasser-, Wasser-, Gasanlagen, Wärmeversorgungsanlagen, Starkstromanlagen oder Fernmelde- und informationstechnische Anlagen aufgelistet und unterschieden. Die Ausstattung des Gebäudes ist eine eigene Kostengruppe für sich. Darin sind alle beweglichen Möbel und Geräte enthalten (DIN ). Somit sind alle Bauteile den für das Facility Management notwendigen Gruppen zugeordnet.

7 128 R. Bleifuß, A. Donaubauer, J. Liebscher und M. Seitle Dem Raum als wichtigstem Objekt im Facility Management werden als spezifische Attribute der Klasse Room die Nutzung nach DIN277, die Raumnummer, das Stockwerk und der Mitarbeiter hinzugefügt. Klassen für die Modellierung von beweglichen Objekten wie Büromöbel werden von der vorhandenen Klasse BuildingFurniture abgeleitet, wohingegen für unbewegliche Objekte die Klasse IntBuildingInstallation als Superklasse verwendet wird. Bei unbeweglichen Objekten handelt es sich beispielsweise um Heizungen, Klimaanlagen oder Waschbecken etc. Ist die Beziehung von AbstractBuilding aus gerichtet, so können auch Rohre, Kabel und Leitungen darin enthalten sein. Von diesen werden entsprechende Kostengruppen nach DIN 276 abgeleitet. Im Facility Management muss auch jedes Bauteil von Räumen (Innenwand, Decke, Fußboden) bestimmbar sein. Um dies durchführen zu können, werden von den schon vorhandenen Klassen CeilingSurface, InteriorWall- Surface und FloorSurface eigene Klassen abgeleitet und mit FM-spezifischen Attributen versehen. Die Hauptattribute, die allen neu definierten abstrakten Klassen zustehen, sind der Hersteller, der Zustand, der Ansprechpartner und das Baujahr. Für das Facility Management werden davon Klassen für Kostengruppen nach DIN 276 abgeleitet. Beispielsweise können von der Klasse CeilingSurface Klassen für abgehängte Decken oder normale Decken, von der Klasse InteriorWallSurface Klassen für tragende und nichttragende Innenwände und von der Klasse FloorSurface Klassen für den Fußboden abgeleitet werden. Allen diesen Klassen steht das Attribut Fläche zu und den Decken auch noch die Deckenhöhe. Nachfolgend in Abbildung 2 ist ein Ausschnitt aus dem UML-Modell der CityGML- Erweiterung dargestellt. Die neuen abgeleiteten Klassen in dem Ausschnitt heißen: cafm::_cafm_ceilingsurface, cafm::_cafm_interiorwallsurface und cafm::_cafm_-floorsurface. Abb. 2: Ausschnitt aus dem UML-Modell der CityGML-Erweiterung für das Facility Management (Quelle: GRÖGER et al. 2008, eigene Bearbeitung)

8 Entwicklung einer CityGML-Erweiterung für Facility-Management-Anwendungen Umsetzung und Test Datengrundlage für den Test der CityGML-Erweiterung sind CAD-Grundrisspläne in 2D von einem Verwaltungsgebäude der Landeshauptstadt München, Roßmarkt 3. Für alle städtischen Verwaltungsgebäude liegen CAD-Pläne in 2D für die Innenräume vor, die jedoch teilweise auf Basis analoger Pläne digitalisiert wurden und in den meisten Fällen nur über reine Zeichnungselemente verfügen. Um diese CAD-Pläne in einer Datenbank verwalten zu können und daraus auch 3D-Geometrien zu erzeugen, bedarf es mehrerer Schritte. Zur Speicherung der Pläne in Oracle Spatial wird das Autodesk-Produkt Auto- CAD Map 3D in der Version 2009 verwendet, bei der genutzten Datenbank Oracle handelt es sich um Oracle Spatial 10g. In AutoCAD Map 3D ist mit der FDO-Technologie eine Schnittstelle zu Oracle integriert. Da die 2D-CAD-Pläne alle in einem lokalen Koordinatensystem vorliegen, ist zuerst eine Georeferenzierung notwendig, mit deren Hilfe die Pläne in ein globales Koordinatensystem, hier Gauß-Krüger-Koordinatensystem bezogen auf DHDN eingepasst werden. Ursprünglich handelt es sich bei den vorliegenden CAD-Plänen des Roßmarkts 3 ausschließlich um Zeichnungselemente, die Punkte, Linien oder Flächen kategorisieren. Grundprinzip zur Datenbankspeicherung ist, dass die Anfangsgeometrien erhalten bleiben und für jede Geometrieart (Punkt, Linie, Fläche) eine eigene Tabelle in der Datenbank angelegt wird. Um die Daten speichern zu können muss jedoch zuerst überlegt werden, welche Elemente in den Plänen für das CAFM-Modell von Bedeutung sind, bzw. welche Attribute zu den Daten noch fehlen. Deswegen werden zu allen Elementen Attribute wie das Stockwerk und die Gebäude-ID hinzugefügt. Bei den Räumen ist außerdem die Vergabe der Raumnummer und der Nutzung nötig. Alle Objekte in den Räumen wie z.b. Toiletten oder Waschbecken in Sanitäranlagen werden zu CAD-Blöcken konvertiert mit einem festen Einfügepunkt, einem Drehwinkel und einer Skalierung. Diese werden später als Punktgeometrien in die Datenbank übernommen. Die Geometrie dazu wird extern abgelegt und kann an mehreren Einfügepunkten verwendet werden. Diese Methode entspricht dem Prinzip der impliziten Geometrien bzw. prototypischen Objekte in CityGML. Bevor die Daten jedoch in der Datenbank abgelegt werden können, werden diese in das Autodesk-eigene Format Spatial Data File (SDF) gespeichert. Durch die tabellenartige Struktur dieses Formates ist so ein 1:1-Übergang auf die Datenbank möglich. Mit diesen Schritten können die 2D-CAD Pläne nun in einer zentralen Datenbank allen Anwendern innerhalb der Stadtverwaltung zur Verfügung gestellt werden. Eine Integration der Gebäude- und Raumhöhen eröffnet neue Möglichkeiten im Facility- Management. Da Raumhöhen innerhalb eines Gebäudes oder Stockwerkes nicht zwingend konstant sein müssen und damit auch der höhenmäßige Lagebezug der einzelnen Räume interessant ist, genügt es nicht nur die Raumhöhen als Attribut mit zu führen, sondern es empfiehlt sich ein 3D-Innenraummodell mit NN-Höhen zu erzeugen. Für 3D-Anwendungen des CAFMs muss als nächstes ein 3D-Modell der Räume erstellt werden. Dies geschieht in Oracle Spatial mittels eines PL/SQL-Skriptes, in dem aus den 2D-Polygonen der Räume 3D-Flächen für die Wände generiert werden. Dazu wird jeder Vertex des Polygons aufgetrennt und mit einer vordefinierten Raumhöhe eine Wand in 3D erzeugt.

9 130 R. Bleifuß, A. Donaubauer, J. Liebscher und M. Seitle Zur Verwendung des 3D-Modells im Facility Management ist die Kenntnis der Flächen, sowohl Boden- als auch Wandflächen von Nöten. Da es in Oracle Spatial 10g noch keine Funktion zur Flächenberechnung in 3D gibt, übernimmt diese Berechnung ein weiteres PL/SQL-Skript, in dem die Basislinie jeder Wandfläche mit der vorgegebenen Raumhöhe multipliziert wird. Um die Räume in der räumlichen Lage in die entsprechenden Gebäudekuben einpassen zu können, werden außerdem die NN-Höhen aus den LoD1, LoD2 oder LoD3 Geometrien des jeweiligen Gebäudes genommen und stockwerksabhängig die jeweils gemessenen oder angegeben Raumhöhen dazu addiert. Somit entstehen Flächen, die als LoD4 Elemente in dem CityGML-Schema (3D-Geodatenbank Berlin V 2.0) gespeichert werden. Außerdem werden die in der ADE definierten Tabellen dabei berücksichtigt. Nächster Schritt ist die Anknüpfung des Modells an das in der Landeshauptstadt München bereits eingesetzte Computer Aided Facility Management (CAFM) FaMe der Firma Facilities Management GmbH. Somit sind alle anderen wichtigen Daten wie Mitarbeiter, Kostenstelle, Reinigung etc. verfügbar. In der Landeshauptstadt München sind folglich Abfragen im Bereich Facility Management in 3D möglich. Aufgrund der CityGML-konformen Speicherung der Daten kann mittels eines PL/SQL- Skriptes eine gültige CityGML-Instanz ausgegeben werden und das Ergebnis in einem CityGML Viewer, z.b. dem Autodesk LandXplorer CityGML Viewer visualisiert werden. Außerdem ist ein direkter Zugriff auf die zentrale Datenbank über Applikationen wie Arc- GIS oder AutoCAD Map 3D möglich. Die nachfolgende Abbildung 3 zeigt das Gebäude vom Roßmarkt 3 von außen und von innen im Autodesk LandXplorer CityGML Viewer. Abb. 3: Roßmarkt 3 von außen und von innen in Autodesk LandXplorer CityGML Viewer 2009

10 Entwicklung einer CityGML-Erweiterung für Facility-Management-Anwendungen Schlussfolgerungen Abschließend kann gesagt werden, dass sich CityGML durch seine semantische Fähigkeit sehr gut eignet, um das Facility Management abzubilden. Durch die Möglichkeit der Erweiterung in CityGML (ADE) konnten Klassen für das Facility Management mit FMspezifischen Attributen modelliert werden. Durch die Berücksichtigung des internationalen Standards CityGML und der DIN-Normen aus dem Bereich Hochbau ist der hier beschriebene Vorschlag eines Datenmodells für das 3D Facility Management der Landeshauptstadt München auch auf andere Städte oder Organisationen übertragbar. In Bezug auf das Facility Management wird heute noch mit 2D-Lösungen gearbeitet, doch durch den entscheidenden Mehrwert wird der Umgang mit 3D bei vielen Facility- Management-Anwendungen geläufig werden. Literatur DIN 276: : Kosten im Hochbau. DIN 277: : Grundflächen und Rauminhalte von Bauwerken im Hochbau. EnEV: Einsparverordnung für Gebäude, GRÖGER, G., KOLBE, T., CZERWINSKI, A. & NAGEL, C. (2008): OpenGIS City Geography Markup Language (CityGML) Encoding Standard, Version 1.0.0, International OGC Standard. Open Geospatial Consortium, Doc. No r HALLER, W. (2008): Der Flughafen eine Stadt. In: GIS-BUSINESS, 4/2008. KOLBE, T. (2008): CityGML, KML und das Open Geospatial Consortium. In: Tagungsband zum 13. Fortbildungsseminar Geoinformationssysteme des Runder Tisch GIS e.v. KRANZ, O., SIEGERT, F., LIEBSCHER, J., LEHMANN, F. & HIRSCHMÜLLER, H. (2005): Generierung interaktiver 3D-Stadtinformationssysteme aus Daten der High Resolution Stereo Camera (HRSC) am Beispiel des 3D-Stadtplans München. In: STROBL, J., BLASCHKE, T., GRIESEBNER, G. (Hrsg.): Angewandte Geoinformatik Heidelberg, Wichmann, S MAY, M. (2006): IT im Facility Management erfolgreich einsetzen. Berlin/Heidelberg, Springer. NÄVY, J. (1998): Facility Management. Berlin/Heidelberg, Springer. OBJECT MANAGEMENT GROUP (Hrsg.) (2003): MDA Guide Version OMG specification omg/ SCHILCHER, M., GUO, Z., KLAUS, M. & ROSCHLAUB, R. (1998): Semi Automatic Derivation of 3D-City-Models from existing 2D-Geoinformationsystems (in: Spatial Information Science and Technology SIST, Dezember 1998, Wuhan (China)). SEITLE, M. (2007): Entwicklung eines Datenbankmodells für 3D-Stadtmodelle zur optimierten Ableitung der XML-basierten Transferformate CityGML und KML. Diplomarbeit, Technische Universität München.