Master-Arbeit. Hochschule für Technik Stuttgart. Als PL nach der SPO-2012 Ausgeführt für die Master-Prüfung im Sommersemester 2018

Transkript

1 Hochschule für Technik Stuttgart Master-Studiengang Vermessung Matrikel-Nr Hochschule für Technik Stuttgart Master-Arbeit Als PL nach der SPO-2012 Ausgeführt für die Master-Prüfung im Sommersemester 2018 Generierung und Evaluierung dreidimensionaler Landschaftsmodelle für eine CFD-Windsimulation Erstprüfer und Betreuer: Zweitprüfer: Prof. Dr. Volker Coors Dr. Franziska Wild-Pfeiffer

2 Erklärung Generierung und Evaluierung dreidimensionaler Landschaftsmodelle für eine CFD-Windsimulation bearbeitet von Master-Arbeit gemäß 40 der Studien- und Prüfungsordnung 2012 für Masterstudiengänge der Hochschule für Technik Stuttgart Erklärung Hiermit versichere ich, dass ich die Arbeit selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe. Gefertigt: Ort, Datum () Gesehen: Erstprüfer und Betreuer: Datum (Prof. Dr. Volker Coors) Zweitprüfer: Datum (Dr. Franziska Wild-Pfeiffer) 2

3 Danksagung Danksagung Mein Dank gilt Prof. Dr. Volker Coors und Dr. Franziska Wild-Pfeiffer für die Betreuung dieser Arbeit. Vielen Dank auch an Hr. Graf und Fr. Blessing vom LGL, dass sie sich ebenfalls bei jeder Besprechung die Zeit genommen haben. Bei Fr. Blessing bedanke ich mich natürlich auch für die hilfreichen Tipps, insbesondere zu Beginn der Arbeit mit FME, und für die Übernahme des 3D-DLM in die Webanwendung Niedernhall. Dank auch an Caroline Marx von der TU München für die Bereitstellung des Tessellations- und Mapping-Workflows. Bei Dr. Martina Deininger bedanke ich mich für die tolle Zusammenarbeit bei der Optimierung der Geometrien und für die Einblicke in die Windsimulation. Matthias Betz danke ich für die Bereitstellung der CityDoctor-Erweiterung und den geleisteten Support bei Problemen mit dem Programm. 3

4 Zusammenfassung Dreidimensionale Landschaftsmodelle für eine CFD-Windsimulation Zusammenfassung Durch 3D-Landschaftsmodelle (3D-DLM) werden 3D-Stadtmodelle um weitere Objekte wie z.b. Vegetation, Gewässer oder Straßen erweitert. Dadurch werden bestehende Anwendungen verbessert und neue kommen hinzu. Zunächst werden Einführungen in die digitalen Landschaftsmodelle und die CFD- Windsimulation gegeben. Für den speziellen Anwendungsfall der CFD-Windsimulation werden Kriterien aufgestellt, welche die 3D-DLM erfüllen müssen, um für die Windsimulation bestmöglich geeignet zu sein. Es wird ein Workflow entwickelt, mit dem 3D- DLM aus verschiedenen Datensätzen erzeugt und geprüft werden können. Dabei kommen hauptsächlich die Programme Feature Manipulation Engine (FME) von Safe Software und der 3dfier der TU Delft zum Einsatz. Als Ausgangsdaten stehen u.a. das ATKIS-Basis-DLM, OpenStreetMap- und LiDAR-Daten zur Verfügung. Die erzeugten 3D- DLM aus verschiedenen Datensätzen werden bewertet und miteinander verglichen, auch im Hinblick auf unterschiedliche Anwendungen. Es zeigt sich, dass die mit 3dfier erzeugten 3D-DLM nicht den speziellen Anforderungen der CFD-Simulationssoftware ANSYS Academic entsprechen. Deshalb werden eigene Workflows zur Erstellung der zusätzlich benötigten Objektklassen entwickelt. Somit können neben den bereits in der CFD-Windsimulation eingesetzten Objektklassen Gebäude und Terrain auch die Objektklassen Vegetation und über Rauhigkeitsflächen auch andere Objektklassen wie z.b. Gewässer berücksichtigt werden. Zur künftigen Vorgehensweise bei der Erstellung neuer Testgebiete für die CFD-Windsimulation wird ein entsprechender Plan vorgestellt. Als andere Anwendung der 3D-DLM erfolgt die Visualisierung in einer Webanwendung. Zuvor werden die 3dfier-Objekte in die 3DCity-Datenbank importiert, z.t. gegen andere Objekte ausgetauscht und die 3D-DLM mit der CityDoctor-Software überprüft. Als Ausblick wird zusammengefasst, welche Möglichkeiten die Software novafactory zur Erstellung von 3D-DLM bietet und welche weiteren Elemente des 3D-DLM, die im 3dfier nicht berücksichtigt sind, damit erstellt werden können. Schlüsselbegriffe: Dreidimensionales digitales Landschaftsmodell, 3D-DLM, CFD- Windsimulation, Vegetation, 3D-Stadtmodelle, CityGML, Feature Manipulation Engine (FME), 3dfier, novafactory, CityDoctor, ANSYS, Runder Tisch GIS, i_city, Smart Villages 4

5 Hochschule für Technik Stuttgart, Matrikel-Nr.: Inhaltsverzeichnis Erklärung...2 Danksagung...3 Zusammenfassung...4 Inhaltsverzeichnis Einleitung Stand der Wissenschaft Grundlagen Unterscheidung digitales Geländemodell, digitales Oberflächenmodell, digitales Landschaftsmodell Digitale Landschaftsmodelle CFD-Windsimulationen CityGML Verwandte Untersuchungen Projekt 3D-DLM am Runden Tisch GIS e.v Projekt Intelligente Stadt (i_city) Projekt Smart Villages Untersuchungsablauf und Ziele Untersuchungsablauf Ziele Forschungsschwerpunkte und hypothese, Methodologie Benötigte Ressourcen Geodaten ATKIS-Basis-DLM Laserscandaten Digitales Geländemodell Gebäudemodelle OpenStreetMap/Geofabrik Baumkataster Stuttgart Digitale Orthophotos Software Feature Manipulation Engine dfier

6 Inhaltsverzeichnis FZK Viewer D City Database CityDoctor und CityDoctor-Erweiterung XMLSpy ArcGIS Desktop novafactory ANSYS Sonstige Vorbereitende Arbeiten und Untersuchungen Anforderungen an Geometrien für die CFD-Windsimulation Stand der CFD-Windsimulation an der HFT Stuttgart im Frühjahr Ergänzung der Objektarten Anwendung 3dfier Funktionsweise des 3dfiers dfier-Optionen Prozessieren und prüfen der 3dfier-Beispieldaten der TU Delft Workflows der TU München Tessellation Mapping Konzeption eines Workflows zur Erstellung eines 3DLM D-DLM aus ATKIS und Baumkatasterdaten D-DLM aus OpenStreetMap-Daten Geplante Vorgehensweise zur Erstellung der 3D-DLM für die Windsimulation Workflow mit ATKIS- und Baumkatasterdaten Workflows zur Vorverarbeitung und Ergänzung der Punktwolken Verarbeitung.laz-Daten und hinzufügen von DGM-Punkten Verarbeitung XYZ-Daten D-Daten aufbereiten Prüfung der LoD2-Gebäudemodelle Extrahieren der Gebäudeumringe Tessellation dfier Mapping Mapping nach CityGML-Schema Bezeichnungen nach ATKIS-Objektartenkatalog für Webanwendung Niedernhall

7 Inhaltsverzeichnis 7.5 3DCityDB Validierung Import und Austausch Objektarten Export Workflow mit OpenStreetMap-Daten D-Daten aufbereiten Vorbetrachtung der OSM-Daten Tessellation dfier Mapping DCityDB Workflow für Windsimulation Weitere Tests mit 3dfier zur Erzeugung geeigneter Vegetationskörper Wald als Gebäude Wald ohne Bodenpunkte Rauhigkeitsgrenzen für die CFD-Windsimulation Teilautomatisiert mit ArcGIS und FME Automatisiert mit FME D-Flächen aus Baumkataster D-Extrusion Evaluation der Ergebnisse Qualitätsprüfung Prüfung der 3D-DLM aus ATKIS- und Baumkatasterdaten Prüfung der 3D-DLM aus OSM-Daten Visuelle Betrachtung der 3D-DLM aus ATKIS-/Baumkatasterdaten Visuelle Betrachtung 3D-DLM aus OSM-Daten Eignung der 3D-DLM aus 3dfier für die Visualisierung Eignung der 3D-DLM aus 3dfier für die Windsimulation Eignung für ANSYS Discovery Live Student Eignung für ANSYS Academic Eignung der Vegetationsgeometrien Eignung der manuell erzeugten Geometiren Bewertung der automatisch erzeugten Geometrien Vorgehensweise zur Erzeugung künftiger 3D-DLM für Windsimulation Zusammenfassung und Ausblick

8 Inhaltsverzeichnis 12.1 Zusammenfassung Ausblick Abbildungsübersicht Tabellenübersicht Abkürzungen Anhang Inhalte der Daten-DVD Anwendung des 3dfier dfier Konfigurationsdatei Prüfungen des CityDoctor Validation Tool Verwendete Hardware Verwendete Geodaten Quellenverzeichnis

9 Einleitung 1 Einleitung Digitale Stadtmodelle sind dreidimensionale, maßstäbliche Modelle einer Stadt (vergl. Bill 2016). Hierbei wird der Fokus vor allem auf die Gebäude und die Erdoberfläche gelegt, da diese für eine Vielzahl von bestehenden Anwendungen der Analyse und Visualisierung am bedeutendsten sind. Dreidimensionale digitale Landschaftsmodelle (3D-DLM) erweitern 3D-Stadtmodelle um weitere Objekte wie z.b. Straßen, Brücken und Vegetationsflächen. Für viele Anwendungen sind diese Objekte relevant, können aber durch die Uneinheitlichkeit der Modellierung, fehlende Standards und Werkzeuge noch nicht automatisiert visualisiert oder analysiert werden (Runder Tisch GIS e.v. 2017). Diese Arbeit soll zeigen, wie ein digitales Landschaftsmodell aus vorhandenen Daten (z.b. DGM, DOM, ATKIS-Basis- DLM) für eine dieser Anwendungen, eine Windsimulation, erstellt und aufbereitet werden kann. Die Erstellung soll anhand eines möglichst automatisierten Prozesses am Beispiel eines Testgebiets erfolgen. Der Prozess wird dann mit Daten eines zweiten Testgebiets validiert. Da erstellte 3D-DLM für möglichst viele Anwendungen gleichzeitig geeignet sein sollen, wird die Visualisierung auch in einer Webanwendung getestet. In Kap. 2 werden Grundlagen zu den Themen Landschaftsmodelle und Windsimulationen erläutert und die mit dieser Arbeit in Verbindung stehenden Projekte 3D-DLM am Runden Tisch GIS e.v., i_city und Smart Villages vorgestellt. Kap. 3 beschreibt den geplanten Untersuchungsablauf und die Ziele der Arbeit. Im folgenden Kap. werden die verwendeten Ressourcen, d.h. die eingesetzten Geodaten und Programme vorgestellt. Kap. 5 beschreibt die Arbeiten, welche vor der Erstellung der Workflows durchgeführt werden: Die Anforderungen der Windsimulation an 3D-DLM werden festgelegt und die Möglichkeiten welche die Software 3dfier zur Erstellung der 3D-DLM bietet getestet. Außerdem werden die aus dem Projekt 3D-DLM des Runden Tisch GIS e.v. zu Verfügung gestellten Workflows betrachtet. Kap. 6 liefert einen Überblick über die erstellten Workflows, welche in den folgenden Kapiteln näher erläutert werden: Die Erstellung eines Workflows zur Generierung von 3D-DLM aus ATKIS- und Baumkatasterdaten wird in Kap. 7 beschrieben. Es werden 3D- DLM für zwei Testgebiete erstellt. Die Prüfung, ob die Workflows auf anders strukturierte Daten übertragbar sind, findet mit OpenStreetMap-Daten in Kap. 8 statt. Die Erstellung von Workflows, um weitere Objektarten für die Windsimulation zu erzeugen, ist in Kap. 9 beschrieben. In Kap. 10 werden die erzielten Ergebnisse bewertet. Kap. 11 liefert einen Plan zur Erzeugung neuer Testgebiete für die Windsimulation. Abschließend werden die Untersuchungsergebnisse zusammengefasst und ein Ausblick auf die Erstellung von 3D-DLM mit der Software novafactory gegeben. 9

10 Stand der Wissenschaft 2 Stand der Wissenschaft In diesem Kapitel werden die Grundlagen zu den behandelten Themen und verwandte Untersuchungen jeweils kurz zusammengefasst. 2.1 Grundlagen Unterscheidung digitales Geländemodell, digitales Oberflächenmodell, digitales Landschaftsmodell Digitale Geländemodelle (DGM) beschreiben die Form der Erdoberfläche ohne die auf ihr befindlichen Objekte wie z.b. Gebäude oder Vegetation. Digitale Oberflächenmodelle (DOM) beinhalten im Gegensatz hierzu alle Objekte, die zum Zeitpunkt der Befliegung vorhanden sind. Hierbei sind die einzelnen Objekte jedoch nicht klassifiziert oder ausmodelliert (LGL o.d. a). Erst durch die semantische Modellierung in einem digitalen Landschaftsmodell ergibt sich die tatsächliche Bedeutung einzelner Landschaftsobjekte (Abb. 1). Abb. 1: V.l.n.r: Digitales Geländemodell, digitales Oberflächenmodell (beide LGL o.d. a) und 3D-DLM (Streilein 2012) Digitale Landschaftsmodelle DLM stehen derzeit in Deutschland flächendeckend nur in 2D z.b. durch das ATKIS- Basis-DLM zur Verfügung (BKG 2018). Des Weiteren gibt es 3D-Stadtmodelle, in einzelnen Bundesländern bereits flächendeckend. Durch das 3D-DLM werden 3D- Stadtmodelle um weitere Objekte erweitert, hierdurch ergeben sich neue Anwendungen oder bestehende Anwendungen werden verbessert (Abb. 2). 10

11 Stand der Wissenschaft 3D-DLM- Erstellungsmöglichkeiten werden derzeit erforscht und getestet. Hierzu gibt es ein Pilotprojekt des Runden Tisch GIS. In diesem wurden und werden Vorschläge erarbeitet, wie 3D-DLM generiert werden können. Als Daten zur Erstellung der 3D-DLM stehen grundsätzlich zweidimensionale Vektordaten (ATKIS-Basis-DLM, ALKIS, OpenStreetMap, Abb. 2: Anwendungszenarien für 3D-DLM und dafür benötigte (schwarze Punkte) bzw. sinnvolle Objektarten (Kreise) (Runder Tisch GIS 2017) Stadtkarte Stuttgart, Baumkataster) und dreidimensionale Daten (DGM, DOM, LiDAR-Punktwolken) sowie 3D Gebäudemodelle zur Verfügung CFD-Windsimulationen CFD steht für Computational Fluid Dynamics, zu Deutsch numerische Strömungsmechanik. CFD-Windsimulationen berechnen mit Hilfe mathematischer Ansätze die Strömung des Windes, seine Richtung und Geschwindigkeit. Windsimulationen mit 3D Stadtmodellen werden durchgeführt, um für Gebiete bis zu einer Größe von mehreren Quadratkilometer Fragen zur natürlichen Lüftung, der Schadstoffausbreitung (Feinstaub, Qualm, Rauch, Abgase) oder Überhitzung im Sommer, aber auch der Windgeschwindigkeit in Fußgängerzonen zu simulieren. Außerdem können mit ihnen Potentiale für die Aufstellung von Wind-Strömungsturbinen aufgezeigt werden (i_city Teilprojekt o.d.). Bisher werden Windsimulationen an der HFT Stuttgart nur mit Gebäudemodellen und digitalen Geländemodellen, ohne weitere Objekte des urbanen Raums durchgeführt (Coors und Voß 2017). Das Simulationsprogramm ANSYS Academic stellt hierbei besondere Anforderungen an die Eingangsdaten. So müssen die Objekte als 3D-Volumenmodelle vorhanden sein, um verarbeitet werden zu können. Auch sollte das Modell nicht zu groß oder einzelne Objekte nicht zu detailliert sein, um keinen zu hohen Rechenaufwand zu verursachen. Vorhandene 3D-Stadtmodelle müssen deshalb ggf. vor der Simulation vereinfacht werden. Die Rauheitswerte von Oberflächen werden bisher, wenn überhaupt, nur grob von Hand erfasst (z.b. Stadtgebiet und Stadtumland). Einzelne Rauheitswerte z.b. von un- 11

12 Stand der Wissenschaft terschiedlichen Landnutzungen können nicht berücksichtigt werden, da die nötigen Objekte fehlen CityGML Als Standard bei der Erstellung und Verwendung von 3D-Stadtmodellen hat sich das GML-Anwendungsschema CityGML etabliert (Bill 2016). Innerhalb eines semantischen Modells können Gebäude, Stadtobjekte, Landnutzung, Gelände, Transport, Vegetation, Wasser und weitere Objekte des urbanen Raums modelliert werden. Auch digitale Landschaftsmodelle können somit in CityGML modelliert werden. CityGML kennt verschiedene Level of Detail (LoD). Die Angaben der LoD beziehen sich vor allem auf den Detailierungsgrad der Gebäude (nach Coors et al und SIG 3D 2014, siehe Abb. 3): Abb. 3: Unterschiedliche Level of Detail (Rautenbach et al. 2015) LoD0: Grundriss des Gebäudes (oder des Daches) LoD1: Ebene Dachfläche in mittlerer Dachhöhe des Gebäudes ( Klötzchenmodell ) LoD2: Verschiedene Dachflächen, Texturen möglich LoD3: Vollständig modellierte Gebäudefassade, Texturen möglich LoD4: Gebäude innen und außen vollständig modelliert (begehbares Architekturmodell) Je nach Anwendung ist es sinnvoll, neben den Gebäuden noch weitere Objekte zu modellieren. In welchem Detailgrad dies geschieht, hängt von der Anwendung ab. Für die Modellierung der weiteren Objekte gibt es noch keine exakten Standards oder Empfehlungen zur Modellierung. Die Art der Modellierung der weiteren Objekte ist deshalb zwischen Anwender und Produzent des Modells im Einzelfall abzustimmen. In dieser Untersuchung wird mit der CityGML-Version 2.0 gearbeitet, welche sich auf das XSD-Schema der GML stützt (Gröger et al. 2012). Aktuell arbeitet die OGC 12

13 Stand der Wissenschaft CityGML Standards Working Group (SWG) und die Special Interest Group 3D (SIG 3D) an der CityGML-Version 3.0 (TUM 2018 a). 2.2 Verwandte Untersuchungen Projekt 3D-DLM am Runden Tisch GIS e.v. Das Projekt 3D-DLM dient insbesondere dem Erfahrungsaustausch zwischen den Beteiligten (vergl. Runder Tisch GIS 2017). Auftraggeber sind Österreichisches Bundesamt für Eich- und Vermessungswesen (nur in der Konzeptionsphase), Landesamt für Digitalisierung, Breitband und Vermessung Bayern und Landesamt für Geoinformation und Landentwicklung Baden-Württemberg Beratend tätig ist das Schweizerische Bundesamt für Landestopographie swisstopo, da in der Schweiz durch das swisstlm 3D bereits flächendeckend ein 3D-DLM vorliegt. Testgebiet des Projekts ist der östliche Bodensee. Im Abschlussbericht der Konzeptionsphase werden Anwendungsszenarien vorgestellt (die Windsimulation wird nicht erwähnt) und die unterschiedlichen vorhandenen Daten evaluiert. Des Weiteren werden Vorschläge zur Datenmodellierung sowie für Methoden zur 2D -> 3D- Transformation gemacht. Dabei werden auch viele Probleme angesprochen, die sich bei unterschiedlicher Modellierungsweise für unterschiedliche Anwendungen ergeben (Runder Tisch GIS 2017). Laut dem Abschlussbericht des Runder Tisch GIS e.v. (Konzeptionsphase) müssen in Deutschland Gebäudemodelle bei der Erstellung von 3D-DLM nicht mehr besonders betrachtet werden, da für diese bereits ausreichend Modellierungsmöglichkeiten etabliert oder, insbesondere in Deutschland, Gebäudemodelle bereits vorhanden sind (Runder Tisch GIS 2017). Für den Übergang von 2D- zu 3D-Daten anderer Objekte (z.b. Gewässer, Straßen, Vegetation) existieren verschiedene Ansätze. Je nach Ansatz ergeben sich gewisse Vorund Nachteile entweder auf Seite der Analysemöglichkeit oder der Darstellung. Das Kapitel aus dem Abschlussbericht soll nachfolgend stichwortartig zusammengefasst werden, um zumindest ein Einblick in die vielfältigen Probleme, aber auch Möglichkeiten zu geben (Runder Tisch GIS 2017): Ansätze für punkthafte Elemente (z.b. Windkraftanlage als senkrechte Linie modellieren): Implizite Geometrie: Punkt in der richtigen Höhe als Einfügepunkt für ein Modell des Objekts (z.b. Windkraftanlage) 13

14 Stand der Wissenschaft Explizite Geometrie: Wenn eine Punktgeometrie direkt extrudiert wird, entsteht ein Strich (z.b. Turm). Ist das als Modell nicht ausreichend, kann zunächst der Punkt in eine Fläche (Rechteck, Kreis) umgewandelt werden. Ansätze für linienhafte Elemente (Flüsse, Straßen): Als symbolisiertes Band (keine 3D-Körper) Als Polygone (3D-Flächen, z.b. Flüsse) Geschlossenes Objekt als Extrudierung (3D-Objekt mit Dicke z.b. des Straßenbelags). Ansätze für flächenhafte Elemente: Extrudierung (Gebäude und Vegetation; Gewässer eher nicht, diese nur auf DGM-Höhe anheben) o Bestimmung der Grundfläche: Als ebene 3D-Grundfläche auf minimaler Geländehöhe des Objekts oder Verschneidung mit Geländemodell. o Bestimmung obere Abschlussfläche (Abb. 4): Ebene obere Abschlussfläche (Gebäude, See) Uneben, Höhe = DGM-Höhe + Objekthöhe oder DOM-Höhe (Vegetationsflächen) Abb. 4: Modellierungsmöglichkeiten für flächenhafte Objekte (Runder Tisch GIS 2017) Projektion auf DGM o Einfache Projektion auf DGM (ohne Triangulierung): Es treten zwei Probleme auf: 1. Koplanare Flächen des DGMs schimmern bei der Visualisierung durch, da die Verdeckungsreihenfolge zwischen Objektfläche und DGM-Fläche nicht ermittelbar ist. Vorgeschlagene Lösung ist ein Höhenoffset (wenige Zentimeter bis Dezimeter ausreichend), dies versagt aber bei bewegtem Gelände (stark wechselnden Hangneigungen) oder bei starker Vereinfachung des DGMs durch die Visualisierung. Außerdem werden die Höhen verändert, sind also streng genommen nicht 14

15 Stand der Wissenschaft mehr korrekt. 2. Die Flächen des erzeugten Polygone sind nicht mehr koplanar und somit laut ISO ungültig. Dies kann durch Triangulierung der Flächen behoben werden. Partitionierung des DGMs (Unterteilung des DGM gemäß der 2D Objekte): o Linienhafte Polygonränder werden als Bruchkanten des DGM eingerichtet Vorteile sind, dass jeder Teil der DGM-Fläche nur einmal vorhanden ist (keine Probleme bei Visualisierungen) und das jedes TIN-Dreieck genau einem ATKIS-Objekt zugeordnet werden kann, was gut für die Analysemöglichkeit ist. Allerdings muss dann bei jeder Veränderung des DLM eine Neuberechnung erfolgen, was problematisch für die Fortführung ist. Volumenobjekte mit planarer oberer Abschlussfläche o DGM als Basis für absolute Grundhöhe: Das Gelände ist aber i.d.r. nicht flach, deshalb gibt es folgende Möglichkeiten zur Generierung einer Grundfläche: Grundrisspolygon auf Gelände projiziert Grundriss mit Gelände verschnitten Grundriss auf tiefstem Geländepunkt Grundrissknoten mit Gelände verschnitten Volumenobjekte mit zum DGM parallel verlaufender oberer Abschlussfläche (z.b. Wald, Vegetation allgemein) o Höhe aus Attribut oder Differenz zwischen DOM und DGM Im Abschlussbericht der folgenden Demonstrationsphase wird anhand des Testgebiets die Machbarkeit einer landesweiten Generierung eines 3D-DLM mit 3dfier nachgewiesen und die dabei auftretenden Fehler und Probleme aufgezeigt (Runder Tisch GIS 2018 a). Der Abschlussbericht befasst sich mit der Vorverarbeitung der Daten (Tessellation), der Anwendung des 3dfiers, der Abbildung auf das CityGML-Datenmodell (Mapping), der Qualitätsbewertung sowie der Bereitstellung der Ergebnisdaten (vergl. Runder Tisch GIS 2018 a). Bei der Tessellation werden die sich z.t. überlappenden punkt-, linien- und flächenhaften Daten des ATKIS-Basis-DLM in lückenlos vorliegende flächenhafte 2D-Daten überführt. Dies ist eine Voraussetzung für die Anwendung des 3dfier. Nur Brücken befinden sich über dem Gelände (Runder Tisch GIS 2018 a). 15

16 Stand der Wissenschaft Nach Anwendung des 3dfier, welcher die 2D-Daten mit Hilfe der Höheninformationen aus den LiDAR-Punktwolkendaten in die dritte Dimension abhebt, findet das Mapping statt. Hierbei werden die Attribute des ATKIS-Basis-DLMs und dessen Codelisten in CityGML-spezifische oder in generische CityGML-Attribute und Attributwerte überführt (Runder Tisch GIS 2018 a). Der Bericht kommt zu dem Schluss, dass 3dfier mit den beschriebenen Ausgangsdaten im vollautomatischen Prozess ein fachlich sinnvolles Ergebnis, das aber im Detail noch inhaltliche Fehler enthält (Runder Tisch GIS 2018 a) liefert. Der Ressourcenbedarf und die Laufzeiten für die Prozessierung seien auch für landesweite Datenbestände geeignet (Runder Tisch GIS 2018 a). Es werden Lösungsvorschläge für einige auftretende Probleme aufgezeigt, welche in dieser Arbeit, wo möglich, umgesetzt werden. Beispielsweise werden Lücken in den LiDAR-Daten durch DGM-Punkte aufgefüllt oder die LoD2-Gebäudeumringe in der Tessellation verwendet, um Inkonsistenzen zu vermeiden (Runder Tisch GIS 2018 a) Projekt Intelligente Stadt (i_city) Im Projekt Intelligente Stadt (i_city) geht es um Konzepte für eine nachhaltige, energieeffiziente und ressourcenschonende Stadtentwicklung (vergl. i_city o.d.). Das Gesamtprojekt ist in sechs Handlungsfelder unterteilt (i_city o.d.): 1. Nachhaltige Stadtentwicklung und energetische Quatierskonzepte 2. Informationsplattform und Urbane Simulationssysteme 3. Energiemanagement, Informations- und Kommunikationstechnologien 4. Innovative Gebäudestrukturen und Technologien 5. Nachhaltige Mobilität 6. Finanzierung und Akzeptanz Im Teilprojekt vier des Handlungsfelds zwei geht es um Werkzeuge und Verfahren zur Simulation des urbanen Mikroklimas (i_city Teilprojekt 2.4 o.d.). In Kap wurden bereits die Anwendungen für Simulationen des urbanen Mikroklimas, insbesondere Windsimulationen, genannt. Im i_city Teilprojekt 2.4 wird das Testgebiet Stuttgart- Stöckach zur Erforschung der Windsimulation genutzt. Das Testgebiet beinhaltet u.a. auch die durch die Medien bekannte Feinstaubmessstation am Neckartor. Abb. 5: Bisheriger Workflow zur CFD-Windsimulation und Visualisierung (nach Schneider und Piepereit 2017, bearbeitet) 16

17 Stand der Wissenschaft Abb. 6: Künftig zusätzlich möglicher Workflow unter Verwendung von 3D-Vegetationskörpern und 2D-Rauhigkeitsgrenzen (nach Schneider und Piepereit 2017, bearbeitet) Daher ergibt sich, dass für dieses Testgebiet nun durch diese Arbeit ein 3D-DLM erstellt werden soll, um die Forschungsschwerpunkte der Arbeit (Kap. 3.3) untersuchen zu können und evtl. die CFD-Windsimulation zu verbessern. Diese Arbeit steht somit am Beginn des Workflows des i_city-teilprojekts (Abb. 5). Der geplante neue Prozessablauf ist in Abb. 6 zu sehen. Durch das 3D-DLM kommen weitere Objekte in die CityGML-Datei, welche im CityDoctor geprüft wird. Anschließend erfolgen (durch andere Projektbeteiligte) der Import in ANSYS Academic sowie die eigentliche CFD-Windsimulation. Die Ergebnisse werden mit dem virtuellen Globus Cesium visualisiert (Schneider und Piepereit 2017) Projekt Smart Villages Smart Villages attraktive Orte im ländlichen Raum ist ein Leuchtturmprojekt des Ministeriums für Ländlichen Raum und Verbraucherschutz Baden-Württemberg (MLR). Es gliedert sich im Rahmen der Digitalisierungsstrategie digital@bw in das Handlungsfeld Smarte Daten / smartes Leben: Digitalisierungsbereich Smarte Geoinformation ein. Dabei sollen die für smart cities gefundenen Konzepte auf Gemeinden des ländlichen Raums übertragen werden (vergl. MLR o.d.). Konkret geht es zunächst um die bestehende 3D-Webplattform mit dem Gebäudemodell der Stadt Niedernhall, wel- Abb. 7: Ausschnitt aus der 3D-Webanwendung Niedernhall ( LGL) 17

18 Stand der Wissenschaft che aktuell vor allem für die Planung von Sanierungs- und Baumaßnahmen eingesetzt wird (Abb. 7). Durch die Ergänzung des Gebäudemodells um ein 3D-DLM sollen weitere Anwendungen ermöglicht werden. Zwar ist für Niedernhall derzeit keine Windsimulation geplant. Dennoch kann das 3D-DLM so erstellt und evaluiert werden, als ob es für eine CFD- Simulation eingesetzt werden sollte. 18

19 Untersuchungsablauf und Ziele 3 Untersuchungsablauf und Ziele 3.1 Untersuchungsablauf Durch die Masterarbeit soll evaluiert werden, wie 3D-DLM so erstellt werden können, dass sie als Eingangsdaten für CFD Windsimulationen nutzbar sind. Es soll untersucht werden, mit welchen Daten und ggf. mit welcher Software die Modellierung am geeignetsten für CFD-Anwendungen umzusetzen ist. Gleichzeitig sollen die 3D-DLM aber auch für möglichst viele weitere Analysen und zur Visualisierung geeignet sein. Es wird zunächst ein Workflow erstellt, um aus vorhandenen ATKIS-Basis-DLM- und LiDAR-Daten mit den Programmen FME und 3dfier ein 3D-DLM des Testgebiets Niedernhall (Hohenlohekreis) zu erstellen. Anschließend wird geprüft, ob es den zuvor definierten Kriterien entspricht, um für Windsimulationen geeignet zu sein. Der Workflow wird etwas abgeändert, um auch mit OpenStreetMap-Daten durchlaufen werden zu können. Die Validierung der Workflows erfolgt mit den Daten des Testgebiets Stuttgart-Stöckach. Hier können auch andere Daten, z.b. des Baumkatasters der Stadt Stuttgart, als Ausgangsdaten verwendet werden. Damit soll sichergestellt werden, dass die gewählte Vorgehensweise auch auf andere Gebiete und Datensätze übertragbar ist. Die 3D-DLMs werden geprüft und (durch andere Projektbeteiligte) für die Windsimulation getestet. Außerdem erfolgt eine Bewertung der erzeugten 3D-DLM für andere Anwendungen, z.b. der Visualisierung. 3.2 Ziele Durch das 3D-DLM werden neue Objekte (z.b. Vegetation) in die CFD-Windsimulation eingebracht. Durch die Berücksichtigung der zusätzlichen Elemente wird die Modellierung der realen Welt in der Simulation verbessert, sodass die berechneten Windgeschwindigkeiten voraussichtlich realistischer werden. Zum einen handelt es sich bei diesen Objekten um flächige Vegetationsobjekte (z.b. Wald, Gehölzstreifen), die generell in der Simulation als poröse Medien berücksichtigt werden können (Coors und Voß 2017). Interessant sind hierbei auch Alleen oder Baumgruppen. Die Bäume erhalten der Einfachheit halber zunächst die gleichen physikalischen Eigenschaften wie eine Wand, sind also luftundurchlässig. Dann kann die Simulation mit und ohne diese Vegetationsobjekte durchgeführt und die Unterschiede betrachtet werden. In einem zweiten Schritt kann geprüft werden, ob anhand des Blattflächenindex ein Grad der Durchlässigkeit modelliert werden kann, sodass die Objekte tatsächlich als poröse Medien in die Simulation eingehen (Deininger 2018). 19

20 Untersuchungsablauf und Ziele Die andere Art der Objekte sind Rauhigkeitsflächen, welchen in der Simulation unterschiedliche Bodenrauhigkeiten zugewiesen werden. Beispielsweise werden urbane Gebiete mit einer anderen Bodenrauhigkeit versehen als offene Landschaften oder Gewässerflächen (Deininger 2018). Die erzeugten 3D-DLM für die CFD-Windsimulation sollen auch für andere Anwendungen, insbesondere der Visualisierung in der Webanwendung Niedernhall, geeignet sein. Zur Prüfung der 3D-DLM soll eine derzeit in Entwicklung befindliche Erweiterung des CityDoctor Validation Tool der HFT Stuttgart eingesetzt werden. So kann einerseits die Qualität der 3D-DLM bewertet und andererseits die CityDoctor-Erweiterung im praktischen Anwendungsfall getestet werden. 3.3 Forschungsschwerpunkte und hypothese, Methodologie Durch die Arbeit soll herausgefunden werden, wie 3D-DLM-Daten aufbereitet werden müssen, um als Eingangsgrößen für CFD-Windsimulationen möglichst geeignet zu sein. Es soll ein entsprechender Workflow entwickelt werden. Die Hypothesen im Einzelnen sind: 3D-DLM können aus vorhandenen Daten weitestgehend automatisiert erzeugt und als Eingangsdaten für CFD-Windsimulationen aufbereitet werden Der hierzu zu erarbeitete Workflow ist auf andere Gebiete (räumlich) und andere Datensätze (Datenstruktur) übertragbar Mögliche erreichbare Forschungsergebnisse sind: Verbesserungen bei der Modellierung von CityGML-Objekten (insbesondere Vegetationskörper) als Eingangsgrößen für CFD-Windsimulationen Verbesserung der CFD-Windsimulation durch 3D-DLM Die Untersuchung wird als Experiment - die prototypenhafte Erstellung der 3D-DLM - mit anschließender Analyse durchgeführt. Es ist konzeptionelle Arbeit zu erbringen, um die Modellierung der Objekte des 3D- DLM an die Anforderungen der CFD-Windsimulation anzupassen. Auch der zu erstellende Workflow muss konzeptioniert und anschließend evaluiert werden. 20

21 Benötigte Ressourcen 4 Benötigte Ressourcen Nachfolgend werden die für die Untersuchung benötigten Ressourcen vorgestellt. Hierbei handelt es sich um verschiedene Geodaten und Software zu deren Verarbeitung. 4.1 Geodaten Für die Testgebiete in Niedernhall (Hohenlohekreis) und Stöckach (Stuttgart) liegen unterschiedliche Geodaten vor. Die Testgebiete sind jeweils ca. 2 x 2 km groß. Eine tabellarische Übersicht der verwendeten Geodaten befindet sich im Anhang. Es erfolgt eine grundsätzliche Beschreibung der Datensätze und eine Einordnung der Relevanz für diese Untersuchung ATKIS-Basis-DLM Das ATKIS-Basis-DLM ist ein zweidimensionales Landschaftsmodell, welches die realen Objekte der Landschaft vektoriell modelliert. Bearbeitet und vertrieben wird es in Baden-Württemberg durch das Landesamt für Geoinformation und Landentwicklung (LGL). Die Landschaftselemente werden kartographisch generalisiert und sind mit Attributen versehen. Die angestrebte Genauigkeit wesentlicher Elemente, z.b. Straßen, wird mit m angegeben (LGL o.d. a). Das Basis-DLM ist nicht überlappungsfrei, punkt-, linien- und flächenhafte Elemente können sich überlagern. Das Basis-DLM bildet in dieser Arbeit die Grundlage für die Tessellation, den vorbereitenden Schritt vor der Anhebung der 2D-Daten in ein 3D-DLM. Es werden die Daten aus der Auskunfts- und Präsentationskomponente verwendet, nicht die Daten aus dem primären Datenbestand, welche eine andere Struktur aufweisen Laserscandaten Die LAS-Daten des LGL entstehen durch flugzeuggebundenes Laserscanning. Es sind first- und last pulse-daten mit einer Punktdichte von 8 Punkten pro m² enthalten (LGL o.d. b). Die Laserscanpunkte werden durch das LGL in fünf Klassen klassifiziert (Tab. 1). Bei Unterbodenpunkten handelt es sich u.a. um Treppenabgänge, Schwimmbecken, Licht- und Kellerschächte, Klärbecken und Baugruben. Sonstige Nichtbodenpunkte können z.b. Leitungsmasten sein. 21

22 Benötigte Ressourcen Tab. 1: Klassifizierung der Laserscandaten des LGL (nach LGL o.d. c, gekürzt) LAZ-Klasse Beschreibung 2 Bodenpunkte 17 Brückenpunkte 6 Gebäudepunkte 7 Unterbodenpunkte 8 Vegetation und sonstige Nichtbodenpunkte Für Niedernhall liegen die Laserscandaten als 1x1 km-kacheln im Format LAZ, einer komprimierten Version des LAS-Formats, vor. Für Stuttgart wurden die Dateien im ASCII-Format bereitgestellt, mit je fünf Dateien je 1x1 km-kacheln, in welchen die unterschiedlich klassifizierten Punkte enthalten sind. In Stuttgart sind die Laserscandaten aus dem Jahr 2016, in Niedernhall von Die Laserscandaten liefern die benötigten Höheninformationen für die 3D- Modellerstellung Digitales Geländemodell Für Niedernhall liegt ein Digitales Geländemodell mit 1 m-gitterweite im XYZ-Format vor. Höhenbezug ist das Deutsche Haupthöhennetz 1912 (DHHN12). Des Weiteren liegt ein 2 m-dgm als Esri ASCII Grid vor. Für diese Arbeit wird das genauere 1 m-dgm genutzt. Es stammt aus der landesweiten DGM-Erstellung aus den Jahren Es wird verwendet, um exemplarisch die Laserscandaten im Gewässerbereich zu ergänzen und so die resultierende Vermaschung des 3dfier zu verbessern. Für Stuttgart liegt kein aktuelles DGM vor, da dieses durch das LGL aus den Laserscandaten von 2016 noch nicht produziert wurde. Auf die Verwendung eines älteren DGMs wird verzichtet. So können in den 3D-DLMs die Effekte, welche durch unvollständige Punktwolken auftreten, verglichen und bewertet werden Gebäudemodelle Für Niedernhall stehen Gebäudemodelle des LGL in LoD1 und LoD2 als CityGML- Dateien zur Verfügung. Das LoD2-Modell weist einen Stand von 2017 auf und ist das aktuell (Stand Juli 2018) in der Webanwendung enthaltene Modell. Der Stand von 2017 ist positiv zu bewerten, da auch die Laserscandaten aus diesem Jahr stammen. Somit treten hier keine Diskrepanzen aufgrund der unterschiedlichen Aktualität der Datensätze auf. Da das 3D-DLM in die Webanwendung integriert wird, erfolgt die Verwendung des LoD2-Modells, um Diskrepanzen zwischen 3D-DLM und den Gebäuden in der Webanwendung zu vermeiden. 22

23 Benötigte Ressourcen In Stuttgart stehen LoD1 und LoD2-Gebäudemodelle sowie ein grob trianguliertes Geländemodell der Stadt Stuttgart zur Verfügung. Auch hier wird mit den genaueren LoD2-Gebäudeumringen gearbeitet OpenStreetMap/Geofabrik Die Daten von OpenStreetMap werden verwendet, um 3D-DLMs zum Vergleich der erstellten 3D-DLM aus dem ATKIS-Basis-DLM zu erzeugen. Die Daten können auf der OpenStreetMap-Webseite heruntergeladen werden und sind unter der Open Data Commons Open Database Lizenz (ODbL) lizenziert. Da das originäre Datenformat von OSM einige zur Erstellung von 3D-DLM ungünstige Details aufweist (s. Kap. 8.1), werden überwiegend weiterverarbeitete Daten der Firma Geofabrik verwendet. Diese sind ebenfalls kostenfrei, werden regierungsbezirksweise abgegeben und sind unter der Creative Commons Attribution-ShareAlike 2.0 Generic (CC BY-SA 2.0)-Lizenz u.a. auch für die kommerzielle Nutzung freigegeben Baumkataster Stuttgart Das ATKIS-Basis-DLM weist im Bereich von Stuttgart keine Waldflächen auf. Daher wird ein anderer Datensatz zur Bestimmung von Vegetationsflächen benötigt. Im Baumkataster der Stadt Stuttgart sind alle Bäume im Stadtgebiet als 2D-Punkte mit diversen Attributen wie z.b. Art und Baumhöhe hinterlegt. Im vorliegenden Datensatz sind diese Attribute jedoch ohne Eintrag. Daher ergibt sich aus diesem Datensatz nur die Lage der Bäume. Wie von dieser punkthaften Information auf Vegetationsflächen geschlossen wird, ist in Kap beschrieben. Die Stadt Niedernhall hat kein Baumkataster erfasst (Stand Juli 2018), somit können hier keine Tests mit dem Baumkataster erfolgen Digitale Orthophotos Für beide Testgebiete werden seitens des LGL digitale Orthophotos mit 20 cm Bodenauflösung bereitgestellt. Diese dienen zur Ergebniskontrolle, indem die tessellierten 2D-Daten und die erzeugten 3D-DLM mit den Luftbildern verglichen werden. 4.2 Software In diesem Abschnitt wird auf die wichtigsten verwendeten Programme zur Erzeugung und Prüfung der 3D-DLM eingegangen Feature Manipulation Engine Die Feature Manipulation Engine ist eine Software der Safe Software Inc., welche zum formatunabhängigen Bearbeiten von Geo- und sonstigen Daten dient. Mit ihr können 23

24 Benötigte Ressourcen Prozesse erstellt werden, welche mit Readern vorhandene Daten einlesen (extrahieren), diese mittels Transformern transformieren und anschließen durch Writer in neue Datensätze schreiben (laden). Die Abkürzungen dieser drei Prozessschritte ETL (extrahieren, transformieren, laden) geben FME auch die Bezeichnung als eine Spatial ETL Software (vergl. con terra 2015). Neben dem Hauptwerkzeug zur Prozesserstellung, der FME Workbench, bietet die Software darüber hinaus den FME Quick Konverter zur schnellen Datenkonvertierung ohne allzu komplexe Transformationen sowie den FME Data Viewer zur Betrachtung der Daten (con terra 2015). In dieser Arbeit wird FME zur Vor- und Nachbereitung der Daten eingesetzt, die mittels 3dfier nach 3D angehoben werden. Außerdem wird die Erstellung der Vegetationsgeometrien für die CFD-Windsimulation komplett in drei FME-Prozessen durchgeführt dfier dfier ist eine freie Software der Technischen Universität Delft, welche aus 2D- Vektordaten (z.b. Katasterdaten) und Punktwolken (z.b. LiDAR-Daten aus Laserscanningbefliegungen) 3D-Landschaftsmodelle im CityGML-Format erzeugt. Die Punktwollen müssen vorab klassifiziert werden. Die 2D-Objekte werden auf die Höhe der Punkte angehoben. Hierbei entstehen LoD1-Objekte, je nach Klasse in anderer geometrischer Ausprägung. Gebäude werden als LoD1-Volumenkörper mit planarer oberer Abschlussfläche erzeugt. Die Ausgabe erfolgt im Format Obj oder CityGML. Das Programm ist kommandozeilenbasiert und wird derzeit noch weiter entwickelt (TU Delft 2017). Zu beachten ist, dass von den durch das Programm erzeugten Objekten nur die weiteren Objekte des 3D-DLM verwendet werden, da die Gebäude bereits in einem höheren Level of Detail vorliegen. Mit der in dieser Arbeit verwendeten Version steht das Programm als ausführbare Datei zur Verfügung, welche unter Windows direkt ausgeführt werden kann. Die Funktionsweise des 3dfiers ist in Kap näher erläutert FZK Viewer 4.8 Der FZK Viewer des Karlsruher Instituts für Technologie dient zur Visualisierung von semantischen Datenmodellen. Neben CityGML-Dateien können mit ihm u.a. auch IFC- Dateien betrachtet werden. Außerdem ist mittels der Im- und Exportfunktionen die Konvertierung von CityGML nach STEP möglich (KIT 2018). Die Performance bei der Betrachtung großer CityGML-Dateien (z.b. 3 GB) ist stark von der Leistung des PCs abhängig. Während 2x2 km große 3D-DLM auf dem PC in wenigen Minuten geladen sind, kann dies auf dem Laptop bis zu eine Stunde dauern (verwendete Hardware s. Anhang). 24

25 Benötigte Ressourcen D City Database Das Open-Source-Programmpaket 3D City Database (3DCityDB) dient Anwendern von CityGML-Stadtmodellen als umfassendes Werkzeug zur Validierung sowie dem Im- und Export in relationale Datenbanken, welche um räumliche Datenbanktypen erweitert werden. Derzeit (Stand Juli 2018) werden Oracle Spatial und PostGIS-Datenbanken unterstützt. Entwickelt wird das Programm vom Lehrstuhl für Geoinformatik der Technischen Universität München sowie den Firmen virtualcitysystems und M.O.S.S. (vergl. TUM 2018 b). Mit dem Werkzeug pgadmin4 werden die Datenbanken (DB) erstellt und verwaltet. Der 3DCityDB Importer Exporter dient anschließend zur Validierung sowie dem Im- und Export der Dateien (TUM 2018 b). Die 3DCityDB wird in dieser Arbeit eingesetzt, um die durch 3dfier erzeugten und durch FME nachverarbeiteten 3D-DLM zunächst zu validieren. Anschließend wird gezeigt, dass der fehlerfreie Import dieser 3D-DLM in eine relationale DB möglich ist, und wie verschiedene Objektarten ausgetauscht werden können, z.b. die durch 3dfier erzeugten LoD1-Gebäudemodelle durch die amtlichen LoD2-Gebäudemodelle CityDoctor und CityDoctor-Erweiterung CityDoctor ist eine Prüf- und Korrektursoftware für CityGML-Stadtmodelle. Es besteht aus den Komponenten CityDoctor Validation Tool und CityDoctor Healing Tool 1.0. Das Validation Tool ist frei verfügbar und dient dem prüfen der CityGML-Modelle. Eine Liste der durchgeführten Tests befindet sich im Anhang. Das Healing Tool korrigiert die gefundenen Fehler (CityDoctor 2018 a). Da nicht alle Fehler automatisiert korrigiert werden können, wird die Heilung von Gebäudemodellen projektbezogen durch die HFT Stuttgart angeboten. An der HFT Stuttgart wird die Komponente Validation Tool weiterentwickelt, um auch andere Objektklassen, neben den Gebäuden, prüfen zu können. In dieser Arbeit werden neue Versionen des Validation Tools in Zusammenarbeit mit B.Sc. Matthias Betz getestet. Somit können einerseits die erzeugten 3D-DLM getestet, andererseits Anregungen zu wünschenswerten Weiterentwicklungen und Fehlerkorrekturen bei der Entwicklung des Validation Tools gegeben werden. In dieser Arbeit wird dieses erweiterte CityDoctor Validation Tool kurz als CityDoctor-Erweiterung bezeichnet. Für diese Erweiterung ist noch keine grafische Nutzeroberfläche vorhanden. Die Ausgabe erfolgt als PDF- Bericht. Zu beachten ist, dass in der CityDoctor-Erweiterung noch nicht alle Prüfungen, wie sie im Validation Tool für Gebäude vorhanden sind, für alle Objektklassen implementiert bzw. funktionsfähig sind (Betz 2018). 25

26 Benötigte Ressourcen XMLSpy 2018 XMLSpy von Alova ist ein XML Editor, mit welchem u.a. auch CityGML-Dateien validiert werden können (Altova 2018). Da das Programm jedoch nicht zum Öffnen von großen Dateien (über ca. 300 MB) geeignet ist, wird überwiegend die Validierungsfunktion der 3DCityDB (Kap ) verwendet ArcGIS Desktop 10.5 ArcGIS Desktop ist ein Geoinformationssystem der Firma Esri. Es besteht aus den Komponenten ArcMap, ArcCatalog, ArcScene und ArcGlobe (Esri 2018). In dieser Arbeit werden die drei erstgenannten Komponenten eingesetzt, um Ausgangsdaten und Ergebnisse im Prozess der 3D-DLM-Erstellung zu betrachten und zu analysieren. So können z.b. 2D-Vektordaten und Luftbilder gemeinsam in ArcMap betrachtet werden. Mit ArcScene können 3D-Ansichten von Vektor- und Rasterdaten erstellt werden. Außerdem werden ArcMap und ArcScene zunächst für die Erstellung von Vegetationskörpern verwendet, bevor diese Prozessschritte in FME übertragen werden novafactory 7.3 novafactory der Firma M.O.S.S. Computer Grafik Systeme GmbH stützt sich auf ArcGIS Server und ist die umfassende Lösung für Daten und Dienste der Geotopografie (M.O.S.S. o.d.). Auf der Internetseite der Firma wird u.a. mit den Erstellungsmöglichkeiten für 3D-Stadtmodelle geworben. Da die Software an der HFT Stuttgart aktuell (Stand Juli 2018) eingeführt wird, werden die Möglichkeiten, welche novafactory zur 3D-DLM-Erstellung bietet, in den Workflows zum Teil bereits berücksichtigt, indem notwendige Vorbereitungen bereits durchgeführt werden. Die Möglichkeiten zur Erstellung von 3D-DLM mit novafactory werden, da sie voraussichtlich künftig an der HFT Stuttgart möglich sein werden, im Ausblick beschrieben ANSYS Mit der ANSYS-Software wird an der HFT Stuttgart die CFD-Windsimulation durchgeführt. Neben dem Programm ANSYS Academic zur 3D-Modellierung, zur wissenschaftlichen Berechnung und Analyse mit sehr vielen Einstellungsmöglichkeiten existiert mit ANSYS Discovery Live Student ein für Studenten kostenloses Programm, mit welchem ohne großen Aufwand einfache Tests und Analysen durchgeführt werden können (AN- SYS 2018). Jedoch verhält sich die Software in wesentlichen Punkten anders als ANSYS Academic. Z.B. ist keine Vermaschung bzw. Modellierung des Luftraumvolumens notwendig. Dafür existieren nur sehr wenige Einstellungsmöglichkeiten, Objekte wie Gebäude oder Wald haben in der Simulation keinen oder nur sehr geringen Einfluss auf die Windgeschwindigkeit. 26

27 Benötigte Ressourcen Sonstige Der Notepad des Herstellers Don Ho ist ein Texteditor, der sich u.a. gut zum Bearbeiten der Konfigurationsdatei des 3dfier eignet, andererseits aber auch zur Betrachtung kleinerer CityGML-Dokumente (bis ca MB Dateigröße) verwendet werden kann. Größere CityGML-Dokumente bis 40 GB können mit dem Texteditor PilotEdit Lite 11.7 betrachtet werden (Chip.de 2018). 27

28 Vorbereitende Arbeiten und Untersuchungen 5 Vorbereitende Arbeiten und Untersuchungen Vor der 3D-DLM Erstellung werden einige vorbereitende Arbeiten und Untersuchungen durchgeführt. Mit Fr. Dr. Deininger, welche an der HFT Stuttgart für die Windsimulation im Testgebiet Stuttgart-Stöckach zuständig ist, werden die Anforderungen an die Geometrien für die CFD-Windsimulationen besprochen, da das Simulationsprogramm ANSYS Academic besondere Anforderungen an die Geometrie stellt. Die Beispieldaten der TU Delft werden prozessiert und geprüft, um mit der Funktionsweise und den Einstellungsmöglichkeiten des 3dfier vertraut zu werden. Außerdem werden die zur Verfügung gestellten Workflows der TU München zur Vor- und Nachbereitung des 3dfier-Laufs betrachtet. 5.1 Anforderungen an Geometrien für die CFD-Windsimulation Die nachfolgenden Ausführungen beschreiben die Anforderungen an geometrische Objekte, welche zur CFD-Simulation in ANSYS Academic genutzt werden. Die Anforderungen wurden zum Teil in einer Vorbesprechung zu Beginn dieser Arbeit, zum Teil durch einen iterativen Prozess festgelegt. Dieser beinhaltet die Prozessschritte des Erstellens, des Testens und die anschließende Optimierung der Geometrien Stand der CFD-Windsimulation an der HFT Stuttgart im Frühjahr 2018 Vor Beginn dieser Arbeit werden an der HFT-Stuttgart für das i_city-projekt (Kap ) u.a. Windsimulationen im Testgebiet Stuttgart-Stöckach durchgeführt. Hierbei werden nur die Objektklassen Gebäude und Terrain verwendet. Die Gebäude liegen im LoD1 vor und werden für den interessierenden Bereich von Hand noch weiter vereinfacht, indem z.b. Erker entfernt oder Innenhöfe geschlossen werden. Als Terrain liegt ein stark vereinfachtes, trianguliertes DGM vor (Schneider und Piepereit 2017). Algorithmen, welche sich damit befassen, LoD1-Gebäude oder DGM automatisch für die CFD-Simulation zu vereinfachen, sind nicht Bestandteil dieser Arbeit, werden aber aktuell ebenfalls an der HFT Stuttgart erforscht (Schneider und Piepereit 2017). Vielmehr sollen in dieser Arbeit 3D-DLM möglichst so erzeugt werden, dass sie ohne weitere Bearbeitung für die CFD-Simulation einsetzbar sind Ergänzung der Objektarten Die bestehenden Objektarten Gebäude und Terrain werden durch diese Arbeit um Vegetationsobjekte und Rauhigkeitsflächen ergänzt. Insgesamt ergibt sich für die geplante CFD-Simulation folgender Modellierungsansatz (Abb. 8): 28

29 Vorbereitende Arbeiten und Untersuchungen In einem inneren, interessierenden Bereich des Testgebiets wird für eine Fläche von ca. 1 km² ein 3D-Modell mit Gebäuden, Vegetationskörpern und DGM erstellt. In einem umgebenden, größeren Bereich (z.b. 4 km²) wird lediglich ein stark vereinfachtes DGM verwendet, auf welches zusätzlich Flächen unterschiedlicher Rauhigkeit projiziert werden. Diese Flächen mit unterschiedlichen Rauhigkeiten drücken beispielsweise aus, ob es sich Abb. 8: Planung der Eingangsobjekte für eine CFD- Windsimulation (Deininger 2018) um urbanes oder offenes Gelände handelt. In der Literatur finden sich hierzu unterschiedliche, aber ähnliche Tabellen, z.b. Tab. 2. Tab. 2: Rauhigkeitsklassen- und Längen für verschiedene Landschaftsbilder (nach Lengwinat (2014), von diesem nach Troen und Lundtang Petersen (1989), bearbeitet) Rauhigkeitsklasse Rauhigkeitslänge z 0 (m) Landschaftsbild 0 0,0002 Ruhende Wasseroberfläche 0,5 0,0024 Offenes, ebenes Gelände 1 0,03 Offene Agrarfläche 1,5 0,055 Agrarfläche, Hecken, einzelne, auseinanderliegende Häuser 2 0,1 Agrarfläche mit Hecken und vereinzelten Häusern 2,5 0,2 Agrarflächen, viele Häuser 3 0,4 Ortschaften, Kleinstädte 3,5 0,8 Große Städte mit hohen Gebäuden 4 1,6 Großstadtgebiete mit sehr hohen Gebäuden und Wolkenkratzern 29

30 Vorbereitende Arbeiten und Untersuchungen Nach Absprache mit Fr. Dr. Deininger werden für das Testgebiet Stuttgart-Stöckach testweise zwei Bereiche gebildet: Ein Bereich mit Freiflächen ohne Gebäude, welcher in der späteren Simulation die Rauhigkeitslänge 0,3 erhält, sowie ein urbaner Bereich mit dem Wert 0,7. Diese Rauhigkeitsbereiche sollen als 2D-Flächen bereitgestellt werden. In ANSYS Academic werden sie dann auf das bereits in der Simulation vorhandene Terrain projiziert. Für das innere 3D-Modell sollen neben den bereits verwendeten und zum Teil auch bereits von Hand vereinfachten LoD1-Gebäuden Vegetationsgeometrien erstellt werden. Diese Vegetationsgeometrien müssen folgende Vorgaben erfüllen: 1. Modellierung als Volumenkörper (Solids) Um aus den Vegetionskörpern das Luftvolumen ausschneiden zu können, muss deren Geometrie als Volumenkörper modelliert werden, nicht als einzelne Oberflächen (MultiSurfaces) 2. Begrenzte Anzahl von Flächen, minimal mögliche Dateigröße, Vermeidung komplexer oder spitzwinkliger Geometrien Bei der CFD-Simulation dauern Berechnungen, u.a. abhängig von der Gebietsgröße und der Größe der modellierten Luftraumzellen, durchaus Tage bis Wochen. Um die Berechnungszeiten nicht zu sehr zu verlängern, müssen die 3D- Objekte auf einfache Weise modelliert werden. Die resultierenden Luftraumzellen sollen eine Kantenlänge von mindestens ein bis zwei Metern aufweisen. Daher müssen auch die Vegetationskörper möglichst einfach modelliert werden. ANSYS Academic muss in der Lage sein, mit den erzeugten Vegetationskörpern geometrische Operationen, z.b. Verschneidungen mit anderen Volumenkörpern, durchzuführen. Positiv wirken sich hierbei einfache Primitive wie z.b. Quader aus. Dagegen sorgen große triangulierte Oberflächen oder spitze Winkel für sehr kleine Luftraumzellen, was wiederrum Import-, Weiterverarbeitungs- und Berechnungsprobleme mit sich bringt. Durch diese Anforderungen ist eine Generalisierung der 2D-Grundflächen notwendig, welche in einem gewissen Fehler in der CFD-Simulation resultieren wird. Bei Betrachtung der starken Vereinfachung der Gebäude ist dieser Generalisierungsfehler zum jetzigen Zeitpunkt zu akzeptieren. Zum Test und besseren Vergleich der Auswirkungen des Generalisierungsfehlers sollen zwei verschieden stark generalisierte 2D- Grundflächen verwendet werden. Mit diesen können wiederum bis zu sechs verschiedene Repräsentationen der Vegetationskörper erstellt werden. 3. Homogenes Gesamtmodell Die erzeugten Geometrien dürfen keine Lücken zum bisherigen Bestand erzeugen, z.b. zwischen unterer Abschlussfläche der Vegetationskörper und dem DGM. Die untere Abschlussfläche soll im Zweifel so weit unterhalb des DGM sein, das dieser Fehler ausgeschlossen ist. 30

31 Vorbereitende Arbeiten und Untersuchungen 4. Tatsächliche Höhe Die Volumenkörper sollen der realen Höhe des Baumbestandes entsprechen. Hierbei soll aber aufgrund der in Punkt 2 beschrieben Anforderungen die obere Abschlussfläche möglichst einfach modelliert sein. Für ein erstes worst-case -Szenario soll die maximal innerhalb eines Baumbestandes vorhandene Höhe verwendet werden (rote Linie in Abb. 9). Hierbei entsteht neben dem Generalisierungsfehler in der Lage auch ein Modellierungsfehler in der Höhe (blaue Line). Daneben soll die Erzeugung von Vegetationskörpern mit einer einheitlichen mittleren Höhe und mit unterschiedlichen Höhen möglich sein. Abb. 9: Modellierungsfehler bei Verwendung der maximalen Höhe innerhalb jedes Baumbestandes Zunächst führt Fr. Dr. Deininger diese Vegetationskörper mit den gleichen physikalischen Eigenschaften wie die Gebäude in die CFD-Simulation ein. In diesem worstcase -Szenario wird die Vegetation wie eine Wand berücksichtigt, der Wind kann die Vegetation nicht durchdringen. 5.2 Anwendung 3dfier In diesem Abschnitt wird zunächst auf die Funktionsweise des 3dfier genauer eingegangen, dann werden die für die 3D-DLM-Erstellung verwendeten Optionen beschrieben. Abschließend wird über die Erkenntnisse berichtet, welche aus dem prozessieren der bei Programm mitgelieferten Beispieldaten gewonnen werden Funktionsweise des 3dfiers Als Eingangsdaten stehen 2D- und 3D-Datensätze zur Verfügung. Bei den 2D-Daten handelt es sich um lückenlose, bis auf die Brücken überlappungsfreie 2D-Kartendaten, welche z.b. als Shapefile vorliegen (siehe Kap. 7.2). Die einzelnen Kartenlayer werden 31

32 Vorbereitende Arbeiten und Untersuchungen Abb. 10: 2D-Kartendaten werden als Eingangsdaten den Objektklassen des 3dfier zugeordnet (Commandeur 2017) den zugehörigen Klassen des 3dfier zugeordnet, z.b. Straßen, Wege und Gleise der Klasse Road (Abb. 10). Die 3D-Daten sind klassifizierte LiDAR-Punktwolkendaten im.las oder.laz-format (Abb. 11, siehe auch Kap.7.1) Abb. 11: Eingangsdaten des 3dfier: LiDAR-Punktwolkendaten und 2D-Kartendaten (Commandeur 2017) Im ersten Berechnungsschritt wird für jedes Polygon aus den Punktdaten die geeignete Höhe ermittelt. Hierbei ist entscheidend, welcher Klasse das Polygon angehört. Für jede Klasse wird die Höhe anders ermittelt (Abb. 12). Abb. 12: Bestimmung der Höhe gemäß der Zuordnung zu den 3dfier-Objektklassen (Commandeur 2017) Building: Einheitliche obere Abschlusshöhe, einheitliche Grundhöhe Terrain, Road und Forest: Unterschiedliche Höhen, triangulierte Flächen Water: Oftmals einheitliche Höhe Separation: Vertikale Wände Bridge: Einheitliche Höhe Mit der Wahl der Einstellungen in der Konfigurationsdatei kann ein gewisser Einfluss auf die Höhenlage der Objekte genommen werden, indem der Perzentil-Wert geändert wird. Wichtig ist hierbei, dass für die Berechnung der Höhe nur die Punkte verwendet werden, welche die zur Klasse des Polygons korrespondierende Klassifizierung aufweisen. 32

33 Vorbereitende Arbeiten und Untersuchungen Beispielsweise werden für die Berechnung der Gebäudehöhen nur Punkte verwendet, welche auch als Gebäudepunkte klassifiziert sind (TU Delft 2018). Im zweiten Schritt werden die Höhen an den Rändern der Polygone betrachtet. Je nach Klasse werden die Höhe der Polygone gemittelt (z.b. bei Terrain und Forest) oder vertikale Wände gebildet (z.b. Building und Road), um ein homogenes Gesamtmodell ohne Löcher zu erhalten (Abb. 13). Für die Gebäude werden die vertikalen Wände bis zur Grundfläche des Gebäudes verlängert und Solids generiert, sofern diese Option in der Konfigurationsdatei eingestellt ist. Abb. 13: Mittelung der Höhen an den Rändern oder Erstellung senkrechter Wände je nach Objektklasse (Commandeur 2017) Nach der Modellerstellung erfolgt die Ausgabe wahlweise im OBJ oder im CityGML- Format dfier-Optionen Die 3dfier-Konfigurationsdateien sind auf der DVD gespeichert. Diese können mit einem beliebigen Texteditor betrachtet und editiert werden. Die Zuordnung der Layer aus dem Basis-DLM zu den 3dfier-Klassen erfolgt wie in Runder Tisch GIS (2018 a) und kann Tab. 3 entnommen werden. Tab. 3: Zuordnung der Eingabedateien zu den 3dfier-Klassen (Runder Tisch GIS 2018 a) Eingabedatei(en) Gewaesser Restflaeche, LWS Strassen, Wege, Gleise SportAnlage, Gebaude Wald Bruecken 3dfier-Klasse Water Terrain Road Building Forest Bridge/Overpass 33

34 Vorbereitende Arbeiten und Untersuchungen Für die Brücken muss das height_field den Namen des in der Tessellation erzeugten Attributs height_fld erhalten, damit die Brücken korrekt verarbeitet werden. Für die anderen Objektarten kann auf die Definition des height_field verzichtet werden. 3dfier gibt dann eine Warnung aus, verarbeitet die Daten aber korrekt. Im Abschnitt lifting options kann festgelegt werden, mit welchem Grad die resultierenden 3D-Elemente in den Klassen Terrain und Forest vereinfacht werden. Ein höherer Wert entspricht einer stärkeren Vereinfachung, was in einer geringeren Datenmenge resultiert (vergl. Runder Tisch GIS 2018 a). Für die Klassen Buildings, Water, Road, Separation sowie Bridge/Overpass kann das Perzentil für die Höhenbestimmung eingestellt werden. Nach der Angabe der Punktwolke-Eingabedateien folgt mit omit_las_classes die Möglichkeit, bestimmte Punktklassen auszuschließen. Hier sollte die Klasse 1 - unklassifizierte Punkte - immer ausgeschlossen werden. Der thinning-wert gibt an, wie viele Punkte der Punktwolke zur Berechnung verwendet werden sollen. Dabei ist zu beachten, dass es sich nicht um einen Prozentwert, sondern einen absoluten Wert handelt. Bei Einstellung 0 wird jeder Punkt verwendet, bei zehn nur jeder zehnte Punkt (also der 1.,11.,21.,31., Punkt der Punktwolke) (TU Delft 2018). Das Verwenden von weniger Punkten führt dazu, dass für das Einlesen der Punktwolken weniger Zeit benötigt wird, aber auch zu wesentlich schlechteren Ergebnissen (vergl. Runder Tisch GIS 2018 a). Unter options können einige allgemeine Einstellungen getroffen werden, z.b. in welchem Abstand von einem Polygon Punkte noch zur Berechnung der Höhe desselbigen verwendet werden oder ab welchem Grenzwert beim Vernähen der Schnittstellen zwischen Polygonen vertikale Wände erzeugt werden sollen (TU Delft 2018). Die output-optionen ermöglichen die Wahl des Ausgabeformats, ob Gebäudegrundrisse und somit Solids erzeugt werden und ob die Objekte in der Höhe skaliert werden sollen. 34

35 Vorbereitende Arbeiten und Untersuchungen Prozessieren und prüfen der 3dfier-Beispieldaten der TU Delft Die Beispieldaten, welche mit dem 3dfier zur Verfügung gestellt werden, sind in die Ordner bgt, ahn3 und output unterteilt. BGT steht dabei für die zweidimensionale Topographische Karte 1:1000 der Niederlande, ahn3 für den aktuellen Höhenbestand Niederlande 3D (TU Delft 2018). Die 2D-Grundkarte liegt in Form von 12 Layern im sqlite-format vor, welche wie von der TU Delft empfohlen mit dem kostenlosen Geoinformationssystem QGIS betrachtet werden können (Abb. 14). Die Daten können aber Abb. 14: Topographische Karte des Beispielgebiets im Programm QGIS geöffnet (Daten: TU Delft 2018) auch mit dem FME Data Inspector betrachtet oder mit dem FME Quick Translator in das Shape-Format konvertiert und mit ArcMap geöffnet werden. Diese 2D-Karte weist einige deutliche Unterschiede zum ATKIS-Basis-DLM auf. Alle Objekte sind flächenhaft vorhanden, außer im Bereich der Brücken überlappungsfrei und wesentlich weniger kartographisch generalisiert. Dies macht deutlich, dass die ATKIS- Basis-DLM-Daten vor Anwendung des 3dfiers im Schritt der Tessellation vorverarbeitet werden müssen. Die AHN3-Daten liegen im komprimierten LAS-Format.laz Version 1.2 vor. Die Punkte sind nach der LAS-Spezifikation der ASPRS, Version 1.4 klassifiziert. Die Beachtung dieser Vorgaben ist essentiell. Werden 3dfier.laz-Punktwolkendaten in einem anderen Dateiformat, z.b..laz Version 1.4 bereitgestellt, bricht das Programm ab. Werden die Punkte nicht nach der Tabelle der ASPRS klassifiziert, führt dies zu Fehlern im Ergebnis. In Abb. 15 ist zu erkennen, dass die bereitgestellte Punktwolke jedoch nicht komplett nach ASPRS 1.4 klassifiziert ist. Die Vegetationspunkte befinden sich in Klasse 1 nach ASPRS-Tabelle also unklassifizierte Punkte. Bei der Modellerstellung mittels 3dfier werden diese Punkte dann durch die Voreinstellung omit_las_classes: in der Konfi- 35

36 Vorbereitende Arbeiten und Untersuchungen gurationsdatei nicht berücksichtigt. Somit werden für die Vegetationsbereiche nur die Bodenpunkte verwendet und nur der Erdboden der Vegetationsbereiche modelliert. Abb. 15: LAS-Punktwolke im FME Data Inspector. Der ausgewählte Vegetationspunkt (roter Pfeil) weist die Klassifikation 1 unklassifiziert auf (gelber Pfeil) (Daten: TU Delft 2018) Abb. 16: Ergebnis-3D-Modell aus den Bespieldaten des 3dfiers. Links: Ohne Verwendung der unklassifizierten Punkte (inkl. Vegetationspunkte). Rechts: Mit Verwendung der unklassifizierten Punkte (Daten: TU Delft 2018) In Abb. 16 sind die Ergebnisse des 3dfier-Laufs einmal mit und einmal ohne die Verwendung der Klasse 1 zu sehen. In der linken Abbildung zeigt sich ein homogenes Gesamtmodell. Es werden flache Plant-Cover-Objekte erstellt, welche die 3D-Grundfläche der Vegetationsbereiche repräsentieren. Unklassifizierte Punkte, welche neben den Vegetationspunkten auch andere Objekte z.b. Masten oder Fahrzeuge enthalten, werden nicht zur Berechnung verwendet. Solche Punkte werden im Folgenden als Störpunkte bezeichnet. Das rechte Modell gewährt einen ersten Eindruck, wie 3dfier Vegetation modelliert. Daneben zeigen sich zahlreiche Fehler im Modell, vor allem im Bereich der Mauern 36

37 Vorbereitende Arbeiten und Untersuchungen und Gewässer, welche durch die Störpunkte entstehen, die keine Vegetationspunkte sind. Außer den Gebäuden sind alle Geometrien MultiSurfaces und weisen eine Dreiecksvermaschung auf. Die Gebäude können, abhängig von der Einstellung in der Konfigurationsdatei, als LoD1-MultiSurfaces oder als LoD1-Solids gebildet werden. Hierbei entstehen keine triangulierten Oberflächen, sondern die Wandflächen sind Rechtecke, die Grund- und Dachfläche oft auch Polygone mit mehr Eckpunkten. Die Flächen sind grundsätzlich planar. Das Modell ist insgesamt homogen, weist also keine Löcher auf. Um das rechte Modell in Abb. 16 zu verbessern, müssten die derzeit in Klasse 1 (unklassifiziert) eingeordneten Vegetationspunkte in Klasse 5 (hohe Vegetation) reklassifiziert werden. Da jedoch auch Punkte in Klasse 1 enthalten sind, die keine Vegetationsobjekte sind, kann dies nicht durch einen trivialen FME-Prozess erfolgen. Eine weitere Klassifizierung wäre nötig, welche mit den zur Verfügung stehenden Werkzeugen nicht durchgeführt werden kann. Somit kann anhand der Beispieldaten keine abschließende Aussage darüber getroffen werden, ob die Modellierung der Vegetation für die Windsimulation geeignet ist. Diese Aussage kann erst anhand der Daten des Testgebiets Niedernhall erfolgen. Mit diesen Daten erfolgen auch zusätzliche weitere Tests des 3dfiers, um verschiedene Optionen in 3difer zu testen (Kap. 9.1). Bei dem im Modell ungewöhnlich aussehenden Objekt im Vordergrund von Abb. 17 handelt es sich um ein Wehr (zu sehen in den Ausgangsdaten). Die Brücke weiter flussaufwärts ist korrekt modelliert, ohne Lücken im Modell. Abb. 17: Modellierung eines Wehrs und einer Brücke (Daten: TU Delft 2018) Die Prüfung des erzeugten Beispieldatensatzes mit dem CityDoctor Validation Tool zeigt, dass durch den CityDoctor nur Gebäude geprüft und geheilt werden können. PlantCover-Objekte können dargestellt, aber nicht geprüft werden. Alle anderen Objekte können nicht geprüft werden und werden auch nicht dargestellt. Die CityDoctor-Erweiterung (Kap ) ermöglicht die Prüfung der sonstigen Objektarten. Somit kann eine Aussage zur Qualität der einzelnen Objekte des Modells und eine 37

38 Vorbereitende Arbeiten und Untersuchungen statistische Aussage zur gesamten Qualität der einzelnen Objektklassen getroffen werden. Der Vergleich der Berichte zu den beiden Modellen belegt statistisch, dass für den 3dfier die Herausfilterung von Störpunkten wichtig ist. Insgesamt ergibt sich ohne Verwendung der unklassifizierten Punkte weniger als die Hälfte an fehlerhaften Objekten. Dabei fällt auf, dass sich statistisch nicht alle Objektklassen verschlechtern, sondern sich bei zwei Klassen sogar weniger Fehler ergeben (Tab. 4). Tab. 4: Fehlerhafte Objekte in den 3D-DLM mit und ohne Verwendung unklassifizierter Punkte bei Prüfung mit der CityDoctor-Erweiterung Objektart Anz. Objekte gesamt Anz. falsche Obj. ohne Klasse 1 in % Anz. falsche Obj. mit Klasse 1 in % Differenz in % Buildings ,6 1 0,6 0,0 Vegetation , ,0 25,4 Transportation ,7 6 4,2-3,5 Bridge , ,0 0 Water , ,0 66,7 LandUse ,7 0 0,0-3,7 Gesamt ,1 47 9,1 5,0 Das CityGML-Modell testarea TU Delft.gml (einmal mit, einmal ohne Verwendung der unklassifizierten Punkte) und die beiden zugehörigen Prüfberichte sind auf der DVD gespeichert. Der auf häufigsten vorkommende Fehler ist das Auftreten doppelt vorhandener Punkte. 5.3 Workflows der TU München Nachfolgend werden die Workflows beschrieben, die für das Projekt 3D-DLM des Runden Tisch GIS an der TU München erstellt wurden. Diese stehen als Grundlage zu Beginn dieser Arbeit zur Verfügung (Marx 2018) Tessellation Durch die Tessellation werden die 2D-Daten für die 3D-Modellerstellung vorbereitet. Dies erfolgt mittels einer FME-Workbench. Hierbei werden linienhafte Objekte gepuffert, Flächen miteinander verschnitten und neue Flächen erzeugt, sodass eine lückenlose, überlappungsfreie Karte des Testgebiets entsteht. Nur Brückenflächen überlappen sich mit anderen Flächen, da diese gedanklich und verarbeitungstechnisch eine Ebene über der überlappungsfreien Karte liegen. Zu beachten ist, dass im Tessellati- 38

39 Vorbereitende Arbeiten und Untersuchungen ons-workflow Daten des LGL und des bayrischen Landesamt für Digitalisierung, Breitband und Vermessung (LDBV) gleichzeitig verarbeitet werden. Zum besseren Verständnis der Tessellation werden die wichtigsten verwendeten Transformer kurz erläutert. Weitergehende Beschreibungen finden sich in con terra (2015) und in der FME-Hilfe. Alle Eingangsdaten stehen als Shape-Dateien zur Verfügung, diese werden mittels Readern nach Layern getrennt eingelesen. Der Transformer AttributeCreator vereint eine Vielzahl von Möglichkeiten, neue Attribute zu erstellen, vorhandene umzubenennen oder mit neuen Werten zu versehen. Der TestFilter filtert Objekte nach definierbaren Bedingungen, z.b. ob ein Objekt einen bestimmten Attributwert aufweist. Ein Bufferer puffert linien- oder punktförmige Objekte um einen bestimmten Betrag und erzeugt so eine Fläche. So werden z.b. linienhafte Straßenelemente aus dem AT- KIS-Basis-DLM zu Flächen. Der Aggregator vereint Objekte. Dabei kann festgelegt werden, dass nur bestimmte Objekte vereint werden, z.b. solche mit identischer Objektidentifikationsnummer (OBJID). Der Transformer AreaOnArea- Overlayer führt flächenhafte Verschneidungen durch und kann so Überlappungen zwischen Flächen aufheben. In Abb. 18 ist die Funktionsweise anhand eines einfachen Beispiels dargestellt. Im oberen Drittel sind die beiden Ausgangsquadrate zu sehen, welche durch die Creator, links im mittleren Drittel der Abbildung, erzeugt werden. Diese Quadrate sind die Eingangsdaten, welche in den Abb. 18: Funktionsweise des Transformers AreaOnAreaOverlayer AreaOnAreaOverlayer eingehen. Dieser verschneidet die Flächen miteinander und weist den entstehenden Teilflächen das Overlaps Count Attribut zu. Dieses gibt an, wie oft sich Flächen überlagert haben. Auf der rechten Seite der mittleren Abbildung sind die Ausgangsdaten des AreaOnAreaOverlayers dargestellt. Aus dem Output Area werden die drei Teilflächen, welche im unteren Bereich der Abbildung zu sehen sind, an 39

40 Vorbereitende Arbeiten und Untersuchungen einen Inspector weitergegeben. Dieser ermöglicht das temporäre Betrachten der Daten im FME Data Inspector, ohne die Daten in eine Datei zu schreiben. Zwei der drei Teilfächen haben für den Wert des Overlaps Count Attribut, welches hier overlaps genannt wird, den Wert eins erhalten, sie überlappen sich mit keiner anderen Fläche. Die Fläche des Überlappungsbereichs hat den Wert zwei erhalten. Bei einer Erweiterung des Beispiels auf drei sich teilweise überlappende Quadrate ergibt sich folgerichtig, dass der Bereich der dreifachen Überlappung mit dem Wert drei gekennzeichnet wird. Im Workflow der TUM findet sich sehr häufig eine Anordnung von vier Transformatoren, welche dazu dient, eine Objektklasse (z.b. Brücken) von einer anderen Objektklasse (z.b. Wald) auszusparen, sodass am Ende nur noch dort Waldflächen vorliegen, wo keine Brücken sind (Abb. 19, Marx 2018). Abb. 19: Übliche Transformer-Anordnung in Workflow der TUM zum Aussparen einer Objektklasse von einer anderen (nach Marx 2018, bearbeitet) Als Eingangsdaten des AreaOnAreaOverlay_4 dienen die Waldflächen und zwei Datensätze mit Brückenflächen. Nach diesem werden im TestFilter_3 alle Flächen gefiltert, die im _overlaps-attribut nur den Wert eins aufweisen. Alle Flächen mit größerem Wert (z.b. zwei) werden an den AreaOnAreaOverlayer_5 weitergegeben. In diesen fließen zusätzlich die noch unbearbeiteten Waldflächen ein. Das Overlapscount-Attribut heißt auch im AreaOnAreaOverlayer_5 wieder _overlaps. Durch die erneute Verschneidung der nicht bearbeiten Waldflächen mit den Flächen, an denen sich Wald und Brücken überlagern, kann anschließend mit einem weiteren TestFilter dafür gesorgt werden, dass nur noch Waldflächen an den nächsten Verarbeitungsschritt weitergegeben werden, welche sich nicht mit Brücken überlappen. 40

41 Vorbereitende Arbeiten und Untersuchungen In Abb. 20 ist das Ergebnis des AreaOnAreaOverlayer_5 zu sehen. Es liegt die Waldfläche ohne Brückenflächen (rot) und der gemeinsame Überlappungsbereich (hellblau) vor. Durch den anschließenden TestFilter wird die Überlappungsfläche mittels des Attributwerts _overlaps >=2 herausgefiltert. Somit liegen am Ende dieses Ausschnitts aus dem Workflow nur noch die Waldflächen vor, welche sich nicht mit Brückenflächen überlagern (rot). Abb. 20: Teilflächen nach Anwendung des üblichen Workflows der TUM, um eine Objektklasse von einer anderen freizustellen Der Transformer LineOnAreaOverlayer hat eine ähnliche Wirkungsweise wie der AreaOnAreaOverlayer. Im Tessellationsworkflow wird er dazu genutzt, linienhafte Elemente wie z.b. Gräben, welche in flächenhafte Elemente (z.b. Flüsse) hineinragen, zu entfernen, um bereits vor der Pufferung der linienhaften Elemente die daraus resultierenden Überlagerungen gleichartiger Flächen zu vermeiden. Nach der Verarbeitung durch die Transformer werden die Daten, wiederum getrennt nach Objektklassen, in Shape-Dateien geschrieben und stehen jetzt für den 3dfier bereit Mapping Im Mapping-Workflow werden die in 3dfier zusammengefassten Objektklassen wie z.b. Roads wieder in Straßen, Wege und Gleise getrennt. Außerdem werden die ATKIS- Attribute und Attributwerte in die CityGML-Codelisten übertragen. Die CityGML-Dateien werden nach Objektklassen getrennt durch Reader eingelesen. Anschließend wird mit dem CoordinateSystemSetter die Angabe des Koordinatensystems geändert, da 3dfier grundsätzlich das Niederländische Bezugssystem EPSG 7415 vergibt, ohne dass dies geändert werden kann (Runder Tisch GIS 2018 a). Durch den CoordinateSystemSetter werden die Koordinaten der Objekte nicht geändert, sondern nur die Angabe des Koordinatensystems. Die folgende Beschreibung gilt für alle Objektklassen außer den Sportanlagen, diese wird im Anschluss gesondert beschrieben. Für die meisten Objektarten erfolgt mit den drei Transformatoren DuplicateRemover, Counter und StringConcatenator eine Bereinigung der OBJIDs. Mehrfach vorhandene OBJIDs erhalten eine fortlaufende Unternummer, sodass jedes Objekt eine eindeutige OBJID hat. Im nächsten Schritt wird bei den meisten Objektarten eine semantische Bedeutungsübertragung mit dem AttributeValueMapper durchgeführt. Hierbei werden die ATKIS- Codes für bestimmte Attributwerte auf die CityGML-Codetabellen übertragen (Runder Tisch GIS 2017). 41

42 Vorbereitende Arbeiten und Untersuchungen Dann werden die maximale und minimale Höhe sowie der Flächeninhalt, gerundet auf eine Nachkommastelle, berechnet und jeweils als Attribute hinzugefügt. Weitere Attribute werden mittels eines AttributeCreator angepasst, z.b. wird das Attribut bwf aus den ATKIS-Daten in ein generisches CityGML-Attribut Bauwerksfunktion überführt. Durch CityGMLGeometrySetter wird die Geometrie der Objekte auf LoD1MultiSurfaces mit der Feature Role CityObjectMember gesetzt. Abschließend erfolgt die Erzeugung des Attributs citygml_creationdate und das Schreiben der Objekte in CityGML-Dateien. Für die Objektklasse Sportanlage findet eine etwas andere Verarbeitung statt. Nach dem CoordinateSystemSetter (s.o.) werden hier alle Objekte zunächst in ihre Teilflächen zerlegt (Deaggregator). Der GeometryCoercer ändert den Geometrietyp aller Flächen in ein fme_polygon, sofern dies möglich ist. Liegen zusammengesetzte Polygone (fme_composit_surfaces) vor, werden diese nochmals zerlegt, sodass nur noch fme_polygone übrig bleiben. Mit dem SurfaceNormalCalculator und einem Tester wird anschließend geprüft, dass die Flächennormale in die richtige Richtung zeigt. Die weitere Verarbeitung erfolgt dann wieder ähnlich wie bei den anderen Objektklassen: Berechnung der minimalen und maximalen Höhe sowie des Flächeninhalts, Anpassung weiterer Attribute, setzen der Geometrie und Erzeugung und Formatierung des Attributs citygml_creationdate sowie Schreiben der Datei mittels eines CityGML-Writers. 42

43 Konzeption eines Workflows zur Erstellung eines 3DLM 6 Konzeption eines Workflows zur Erstellung eines 3DLM In diesem Kapitel wird ein Überblick über die erstellten Workflows gegeben und erläutert, wie die Ergebnisse getestet werden sollen. Die Erstellung der 3D-DLM mit 3dfier erfolgt in Kap. 7 mit ATKIS-Daten und zum Vergleich hierzu in Kap. 8 mit OpenStreetMap-Daten (OSM-Daten). Durch die Verwendung der OSM-Daten wird auch untersucht, ob der Workflow auf anders strukturierte Datensätze übertragbar ist. In Kap. 9 wird auf die besonderen Anforderungen bei der Erstellung von 3D-DLM für die Windsimulation eingegangen. In Kap. 10 werden die erzeugten 3D-DLM auch in Hinblick auf ihre Eignung für unterschiedliche Anwendungen bewertet D-DLM aus ATKIS und Baumkatasterdaten In Abb. 21 ist der gesamte Workflow zur Erstellung von 3D-DLM mit 3dfier aus ATKISund Baumkatasterdaten zu sehen. Nachfolgend werden die Inhalte der zugehörigen Kapitel kurz vorgestellt, um einen Überblick über den Workflow zu ermöglichen. In Kap. 7.1 wird beschrieben, wie die LiDAR-Punktwolkendaten als Eingangsdaten für den 3dfier vorbereitet werden. Da für die beiden Testgebiete zwei unterschiedliche Datenformate zur Verfügung stehen, sind zwei verschiedene Workflows notwendig. Diese vorverarbeiteten Punktwolken werden dann in allen weiteren Workflows verwendet, unabhängig von der Art der verwendeten 2D-Daten. Abb. 21: Workflow zur Erstellung von 3D-DLM mit 3dfier aus ATKIS- und Baumkatasterdaten 43

44 Konzeption eines Workflows zur Erstellung eines 3DLM Im weiteren Verlauf des Kap. 7 wird auf die Erstellung von 3D-DLM aus ATKIS-Basis- DLM-Daten eingegangen. Die LoD2-Gebäudeumringe der Gebäudemodelle, welche später gegen die Gebäudemodelle des 3dfier ausgetauscht werden sollen, werden geprüft und bei Bedarf korrigiert, um korrekt in die Tessellation eingehen zu können. Im Testgebiet Stuttgart gehen auch die Baumkatasterdaten in die Tessellation ein. Diese werden mit dem FME-Workflow PktTo2DVegLod1/2 auf die Tessellation vorbereitet. Nach diesen Vorarbeiten wird mit den tessellierten 2D-Daten und den LiDAR- Punktwolkendaten durch 3dfier das 3D-DLM erzeugt. Durch den folgenden Mapping- Prozess (Kap. 7.4) werden die ATKIS-Attributnamen und -werte in das CityGML-Schema überführt und weitere notwendige Änderungen an den 3D-DLM vorgenommen. Mit der 3DCityDB (Kap. 7.5) werden die Objektarten ausgetauscht, welche nicht aus dem 3dfier verwendet werden sollen: Die LoD1-Gebäudemodelle werden gegen die LoD2-Gebäudemodelle getauscht, die Vegetationsgeometrien aus 3dfier gegen die manuell erstellen Vegetationskörper (Kap. 9.3). Außerdem können mit der 3DCityDB die 3D-DLM validiert werden. Nach dem Export der 3D-DLM-Gesamtmodelle aus der 3DCityDB erfolgt die Qualitätsprüfung mit der CityDoctor-Erweiterung, diese ist in Kap beschrieben. Außerdem erfolgt eine visuelle Betrachtung im FZK Viewer bzw. beim Testgebiet Niedernhall auch in der Webanwendung des LGL D-DLM aus OpenStreetMap-Daten Da bei der Erstellung der 3D-DLM aus OSM-Daten zum Vergleich mit den 3D-DLM aus ATKIS-Daten keine Baumkatasterdaten verwendet werden und die LoD1- Gebäudemodelle des 3dfiers nicht ausgetauscht werden, vereinfacht sich der Workflow deutlich (Abb. 22). Abb. 22: Workflow zur Erstellung von 3D-DLM aus OSM-Daten 44

45 Konzeption eines Workflows zur Erstellung eines 3DLM In Kap. 8.1 wird zunächst auf die verwendeten Daten eingegangen. Dann erfolgen wie bei den ATKIS-Daten nacheinander die Schritte der Tessellation, der Anwendung des 3dfiers, des Mappings und des Imports in die 3DCityDB, bevor die 3D-DLM mit dem CityDoctor geprüft und mit dem FZK Viewer betrachtet werden (Kap ). 6.3 Geplante Vorgehensweise zur Erstellung der 3D-DLM für die Windsimulation In Kap ist beschrieben, dass im Frühjahr 2018 an der HFT Stuttgart kein komplett neues 3D-DLM für die CFD-Windsimulation benötigt wird, da für Niedernhall keine Windsimulation geplant ist und für Stuttgart bereits mit der Vereinfachung der Gebäude für die Simulation begonnen wurde. In Kap werden die Anforderungen beschrieben, welche die CFD-Simulation an weitere Objekte stellt. Für diese Arbeit ist von erheblicher Bedeutung, dass das vorliegende praktischen Problem nicht die Erstellung eines komplett neuen 3D-DLM für die CFD-Windsimulation ist, sondern dass ein bereits bestehendes und in der Simulation genutztes Modell durch Rauhigkeitsflächen und Vegetationskörper ergänzt werden soll. Neben der Erzeugung komplett neuer 3D-DLM müssen so auch Lösungen gefunden werden, bestehende Stadtmodelle mit weiteren Objekten für die CFD-Simulation anzureichern. Die komplett neuen 3D-DLM wiederum werden nicht unmittelbar in der CFD- Simulation praktisch getestet, sondern können nur theoretisch auf ihre Eignung hin beurteilt werden. Die Anforderungen aus Kap ergeben, dass viele Objektklassen, welche allgemein für ein 3D-DLM sinnvoll sind und mit dem 3dfier automatisiert erzeugt werden können (Gleise, Straßen, Wege, Gewässer, Brücken), in der CFD-Simulation zum aktuellen Stand an der HFT Stuttgart nicht in 3D modelliert werden sollen. Teilweise würde die Berücksichtigung dieser Objektklassen in der CFD-Simulation sich negativ auf die Simulation auswirken. Dies kann so weit gehen, dass eine Simulation aufgrund der langen Import-, Bearbeitungs- und Berechnungsdauern nicht mehr sinnvoll möglich ist. Dennoch sollen weitere Tests des 3dfier auch mit diesen Objektklassen erfolgen, um die Möglichkeiten dieser Software auch für die Erstellung von 3D-DLM für andere Anwendungen zu ermöglichen. Diese weiteren Tests sind in Kap. 9.1 beschrieben. 45

46 Workflow mit ATKIS- und Baumkatasterdaten 7 Workflow mit ATKIS- und Baumkatasterdaten In diesem Kapitel wird die Erstellung der Workflows zur Generierung von 3D-DLMs mit 3dfier aus ATKIS-und Baumkatasterdaten beschrieben. Baumkatasterdaten werden nur im Testgebiet Stuttgart-Stöckach eingesetzt. Ansonsten erfolgt die Erstellung der 3D- DLM für die Testgebiete Niedernhall und Stuttgart im Wesentlichen mit denselben FME-Workflows. 7.1 Workflows zur Vorverarbeitung und Ergänzung der Punktwolken Vor der Anwendung des 3dfiers müssen die Punktwolkendatensätze in das richtige Datenformat gebracht und die Punkte korrekt klassifiziert werden (TU Delft 2018). Je nach vorhandenen Eingangsdaten ist hierbei eine unterschiedliche Vorverarbeitung notwendig Verarbeitung.laz-Daten und hinzufügen von DGM-Punkten Für diese Arbeit standen für das Testgebiet Niedernhall.laz-Daten im Koordinatensystem EPSG 4647, DHHN16 mit nach LGL BW-klassifizierten Punkten (Tab. 1, S. 22) zur Verfügung. Der FME-Workflow PktWolkeLASdurchDGMergänzt.fmw ist auf der DVD gespeichert. Zunächst werden die.laz-daten mittels eines Readers eingelesen. Ein Reprojector übernimmt die Transformation der Daten von EPSG 4647 nach EPSG 25832, wobei diese nur aus dem Wegstreichen der Zonenkennung im Easting besteht. Der Anwender kann im Creator die gewünschte Gebietsgrenze mittels UTM-Koordinaten bestimmen. Anhand dieser Gebietsgrenze werden die benötigten Punktdaten mittels eines Clippers ausgeschnitten. Anschließend erfolgt die Höhentransformation vom DHHN16 ins DHHN12, indem alle Höhenwerte durch den PointCloudExpressionEvaluator um 4 cm angehoben werden. Der Wert ergibt sich, da sich für das Testgebiet bei Anwendung des Transformationsdienstes des LGL für ausgewählte Punkte am Rand und im Testgebiet Werte zwischen 3,5 cm und 3,6 cm ergeben (LGL 2018). Da es sich um LiDAR-Daten handelt, bei welchen die Angabe nur mit cm-genauigkeit erfolgt, kann die Transformation der Daten mit hinreichender Genauigkeit mit dem konstanten Wert + 4 cm durchgeführt werden. Im nächsten Schritt wird die Punktwolke nach dem Attribut classification gesplittet und wo erforderlich die Reklassifizierung ins ASPRS 1.4-Format durchgeführt (ASPRS 2011). Im unteren Abschnitt des Workflows wird beispielhaft gezeigt, wie die LiDAR- Punktwolke durch das DGM ergänzt werden kann. Bei Bedarf können diese Reader und Transformer deaktiviert werden. 46

47 Workflow mit ATKIS- und Baumkatasterdaten Eine Trackline liest die Punkte des 1-m- DGM im XYZ-Format ein. Da diese bereits im richtigen Lage-und Höhesystem vorliegen, ist keine Transformation mehr erforderlich. Ein PointCloudCombiner kombiniert alle Punkte zu einer Punktwolkengeometrie. Mittels eines Shape-Readers werden die Gewässerflächen aus dem ATKIS-Basis-DLM eingelesen. Durch den Clipper werden nur die Punkte des DGM verwendet, welche im Bereich von Gewässerflächen liegen. Diese erhalten dann die richtige Abb. 23: Mit DGM-Punkten im Gewässerbereich angereicherte LiDAR-Punktwolke ( LGL) Klassifizierung nach ASPRS 1.4 und werden anschließend mit den LiDAR-Punkten zu einer Punktwolke vereinigt (Abb. 23). Dann werden diese durch einen PointCloudSplitter (optional auch durch einen Tiler) gekachelt und im Datenformat ASPRS LAS Version 1.2 mit.laz-komprimierung ausgegeben Verarbeitung XYZ-Daten Für Stuttgart stehen die Punktdaten im ASCII-Format zur Verfügung, mit je fünf Dateien je 1x1 km-kacheln, in welchen die unterschiedlich klassifizierten Punkte enthalten sind. Der Workflow PktWolkeXYZ.fmw ist auf der DVD gespeichert und in Abb. 24 ersichtlich. Die einzelnen Punkte werden getrennt nach Klassifizierung jeweils mit einem Space Delimited XYZ-Files-Reader eingelesen und durch AttributeCreators mit dem Klassifizie- Abb. 24: FME-Workflow PktWolkeXYZ 47

48 Workflow mit ATKIS- und Baumkatasterdaten rungsattribut versehen. Dann werden sie als FME-Punktwolkengeometrie zusammengeführt und anschließend gekachelt ausgegeben. Da für Stuttgart für diese Untersuchung kein aktuelles und genaues DGM zur Verfügung steht, werden die LiDAR-Punkte nicht mit DGM-Punkten ergänzt oder ausgetauscht D-Daten aufbereiten Die Aufbereitung des Basis-DLMs als Eingangsdatensatz für 3dfier erfolgt auf Grundlage des in Kap von der TU München erhaltenen Tessellations-Workflows. Dieser wird bearbeitet und ergänzt. Zuvor müssen noch die Gebäudeumringe geprüft und aus ihnen die LoD2-Gebäudemodellen extrahiert werden, um als Eingangsdaten für die Tessellation dienen zu können Prüfung der LoD2-Gebäudemodelle Vor der Extraktion der Gebäudeumringe aus den LoD2-Gebäudemodellen von Niedernhall und Stöckach werden diese mit dem CityDoctor Validation Tool geprüft. Bei der Prüfung des LoD2-Gebäudemodells Niedernhall mit dem CityDoctor Validation Tool ergeben sich Fehler in 2413 Gebäuden (Abb. 25, Tabelle der Prüfungen des CityDoctor Validation Tool im Anhang). Abb. 25: Fehlerstatistik aus dem Prüfbericht des CityDoctor Validation Tool zum LoD2-Gebäudemodell Niedernhall Die meisten Fehler sind für die weitere Bearbeitung und Erstellung der 3D-DLM nicht hinderlich. Nur in dem Fall, das durch Fehler im Gebäudemodell auch fehlerhafte Gebäudeumringe abgeleitet werden, müssen diese Gebäudeumringe korrigiert werden. Aus diesen Fehlern kann nicht direkt auf resultierende Fehler in den extrahieren Gebäudeumringen geschlossen werden, deshalb werden diese Fehler nicht weiter be- 48

49 Workflow mit ATKIS- und Baumkatasterdaten trachtet, sondern am Ende des nächsten Unterkapitels direkt die Fehler in den Gebäudeumringen behandelt Extrahieren der Gebäudeumringe Da die von 3dfier erzeugten LoD1-Gebäudemodelle in einem Postprozess durch die amtlichen LoD2-Gebäudemodelle ersetzt werden sollen, müssen deren Gebäudeumringe zuvor aus dem Gebäudemodell extrahiert werden. Bei der Verwendung anderer Gebäudeumringe, z.b. aus ALKIS-Daten, kann es zu lage- und zeitmäßigen Diskrepanzen kommen. Lagemäßige Diskrepanzen können auftreten, da die ALKIS-Daten durch das LGL mit der BWTA2017 nach UTM transformiert wurden, die Gebäudemodelle, die LAZ-Daten und das ATKIS-Basis-DLM jedoch mit BeTA2007. Für das Testgebiet Niedernhall werden die Differenzen zwischen den Gebäudeumringen an einigen Stellen gemessen, es ergeben sich lineare Abweichungen im Bereich zwischen fünf und zehn Zentimetern. Darüber hinaus ergeben sich grobe Abweichungen, wenn einzelne Gebäude aufgrund der Aktualität in einem Datensatz vorhanden sind, im anderen aber nicht. Da die LoD2-Gebäudemodelle lage- und zeitmäßig am besten zu den LiDAR-Daten passen und somit die geringsten Diskrepanzen zu erwarten sind, werden die LoD2- Gebäudeumringe vor der Tessellation extrahiert und als Eingangsdatensatz für die Tessellation verwendet. Der Workflow ist auf der DVD gespeichert und in Abb. 26 dargestellt. Abb. 26: FME-Workflow zum Extrahieren und Transformieren der Hausumringe des Gebäudemodells Stuttgart-Stöckach Mittels eines CityGML-Readers wird das Gebäudemodell eingelesen. Der SurfaceFootprintReplacer ermittelt anhand der Gebäudegeometrie den Grundriss des Gebäudes. Nach der Koordinatentransformation werden die Gebäudegrundrisse in eine Shape- Datei geschrieben. Hintergrund der Verwendung des SurfaceFootprintReplacer ist der, das nicht alle Buildings in allen Gebäudemodellen eine durchgängige GroundSurface besitzen. Im Testgebiet Stuttgart-Stöckach hatten nur 136 von 2214 alle Buildings eine durchgängige GroundSurface. In den anderen Fällen ist die GroundSurface nicht für das gesamte Building, sondern für die BuildingParts modelliert. Mit dem SurfaceFootprintReplacer 49

50 Workflow mit ATKIS- und Baumkatasterdaten ist eine einheitliche Methode gewährleistet, um aus allen alle Buildings und Building- Parts die benötigten Grundrisse zu extrahieren. Ein weiterer Unterschied zwischen den Workflows von Niedernhall und Stuttgart- Stöckach ist der, das für Niedernhall keine Transformation der Gebäudeumringe mehr erforderlich ist, da diese bereits im EPSG (UTM Zone 32 ohne Zonenkennung) vorliegen. Im Reprojector kann jede benötigte und in FME hinterlegte Koordinatentransformation eingestellt oder der Reprojector aus dem Workflow gelöscht werden, wenn keine Koordinatentransformation erforderlich ist. Bei der folgenden Tessellation fallen einige Gebäudeumringe im FME-Transformer AreaOnAreaOverlayer als fehlerhaft heraus und werden z.b. nicht von Straßen freigestellt. In Niedernhall handelt es sich um vier Gebäudeumringe, siehe ausführlichen Bericht Prüfung der fehlerhaften Gebäudeumringe auf der DVD. In Stuttgart handelt es sich um einen von 3438 Gebäudeumringen (Abb. 27). Der Gebäudeumring ist hier mit zwei äußeren Ringen definiert, was in FME nicht der Definition eines Polygons entspricht. Daher fällt er bei der Verschneidung im AreaOnAreaOverlayer als nicht gültiges Polygon heraus. Abb. 27: Fehlerhafter Gebäudeumring ( Stadtmessungsamt Stuttgart) Da der CityDoctor und der GeometryValidator in FME diese Fehler nicht automatisch erkennt und repariert, werden die fehlerhaften Gebäudeumringe manuell in ArcMap bearbeitet, dann stehen die Gebäudeumringe als Eingabedatei für die Tessellation zu Verfügung Tessellation An dem im Kap vorgestellten Tessellations-Workflow der TU München (Marx 2018) werden einige Änderungen vorgenommen. Die Vorgehensweise erfolgt hierbei so, dass der Workflow zunächst für das Testgebiet Niedernhall durchgeführt wird, da hier die benötigten Daten bereits zur Verfügung stehen. Es werden die notwendigen Änderungen durchgeführt, damit die Tessellation für Niedernhall korrekt abläuft. Dann wird der Niedernhaller Workflow für Stuttgart-Stöckach getestet und weiter optimiert. Anschließend erfolgt in einem iterativen Prozess die weitere Optimierung anhand der Daten der beiden Testgebiete. Der fertige Tessellations-Workflow ist auf der DVD gespeichert. Da in beiden Testgebieten keine Flächen der Objektart Flugverkehr vorhanden sind, kann diese nicht berücksichtigt werden. Die Objektklassen Gleise und flächenhafte Brücken treten nur in Stuttgart-Stöckach auf. 50

51 Workflow mit ATKIS- und Baumkatasterdaten Die wichtigsten Änderungen im Überblick: Ausschneiden-Funktion Durch diese Funktion werden alle Polygone am Gebietsrand scharf abgeschnitten. Dies ist für die Erstellung nur begrenzter 3D-DLMs notwendig, im Gegensatz zum Workflow der TUM, welcher Tessellationen mit gewissen Überlappungsbereichen ermöglichen soll. Der Anwender muss im Creator oben links das gewünschte Gebiet und das richtige Koordinatensystem einstellen, dann werden alle Objekte an der Gebietsgrenze abgeschnitten bzw. außerhalb liegende Objekte entfernt. Abfangung spezieller Attributwerte o Bahnlinien im Bau (Zustand ZUS=4000) o Unterirdische Bahnflächen (Gleisflächen und Haltestellen) o Wegflächen über Gleisflächen (ohne Brücken) o Straßentunnel und Tunnel im Bau o Weiterhin unberücksichtigt bleiben: Durchlässe Anstatt der Objektklasse Wald aus dem Basis-DLM können jetzt auch aus dem Baumkataster generierte Flächen als Eingangsdatensatz dienen Straßenflächen werden von Gebäuden, Gleisen, Gewässern freigestellt Wegflächen werden von Gebäuden, Wegen, Gleisen, Gewässern freigestellt Gewässer werden optional von Gebäuden freigestellt (Schleuse im Neckar) Vereinfachung der üblichen Kombination von Transformatoren zur Freistellung einer Objektart von einer anderen (Abb. 28) Abb. 28: Übliche Kombination von Transformatoren zur Freistellung einer Objektart von einer anderen Anstatt bisher vier sind nur noch drei Transformatoren nötig. Der Datensatz, von welchem Flächen abgezogen werden, muss nur noch einmal eingehen, was zur Übersichtlichkeit und Fehlervermeidung beiträgt. Die Funktionsweise ist wie folgt: 1. Verschneidung der Flächen (z.b. Gebäude- und Straßenflächen) 2. Herausfiltern der Flächen, welche sich überlappen. 3. Von den nicht überlappenden Flächen werden die nicht benötigten Flächen (hier die Gebäude) wieder herausgefiltert (die Gebäude werden in ihrer Prozesskette verarbeitet und dann in eine 51

52 Workflow mit ATKIS- und Baumkatasterdaten Datei geschrieben, nicht hier in der Straßen-Prozesskette weiterverarbeitet). Daher sind am Ende der Transformer-Kette nur noch Straßenflächen ohne Gebäudeflächen enthalten. Im Anschluss erfolgt die Betrachtung der einzelnen Objektklassen. Zum besseren Verständnis wird empfohlen, den Workflow parallel in FME oder mit dem PDF (s. DVD) zu betrachten. Für die meisten Objektklassen erfolgen zunächst die Beschreibung der durchgeführten Änderungen im Vergleich zu Marx (2018) und die Überlegungen, welche im Hinblick auf Runder Tisch GIS (2018 a) getroffen wurden. Alle Objektklassen werden an den Gebietsrändern abgeschnitten, da sauber abgegrenzte 3D-DLMs für begrenzte Bereiche erstellt werden sollen. Gebäude Für die Gebäude existieren zwei Varianten: In Variante 1 werden keine Veränderungen am Workflow von Marx (2018) vorgenommen. Wie bereits vom Runden Tisch GIS (2018) beschrieben, werden die Gebäudeumringe der LoD2-Gebäude in der Tessellation mit berücksichtigt, damit der 3dfier bei der Triangulation die Nachbarschaftsbeziehungen korrekt berücksichtigt. Die Gebäudemodelle des 3dfier werden dann im Postprozess durch die amtlichen LoD2-Gebäudemodelle ersetzt. Die extrahierten LoD2-Gebäudeumringe werden eingelesen und am Gebietsrand ausgeschnitten. Die Gebäude erhalten das Attribut abs_hoehe=0. Nach diesem Attribut können sie im Tessellations-Workflow eindeutig als Gebäude identifiziert und somit gefiltert werden, außerdem dient es als height-field für den 3dfier. Diese Vorgehensweise hat den Nachteil, dass am Rand und in kleinsten Lücken zwischen den Gebäudeumringen Artefakte entstehen. Auch fehlerhafte Vermaschungen neben Gebäuden können auftreten (Abb. 29). Werden die Gebäudeflächen nicht aus dem Terrain ausgeschnitten und die Gebäude im 3dfier nicht berücksichtigt (Variante 2), kommt es vor, dass kleinere Gebäude in stark geneigtem Gelände teilweise unter der durch 3dfier erzeugten Geländeoberflä- Abb. 29: Artefakte (links) und fehlerhafte Vermaschungen neben Gebäuden bei Freistellung der Gebäude vom Terrain (rechts). Testgebiet Niedernhall, Gebäude ausgeblendet ( LGL) 52

53 Workflow mit ATKIS- und Baumkatasterdaten che verschwinden (Abb. 30). Dafür treten weitaus weniger Artefakte auf, das Modell ist insgesamt homogener. Da bei einer möglichen landesweiten 3D-DLM-Erstellung laut Runder Tisch GIS (2018 a) das Terrain aus 3dfier nicht verwendet wird, sondern dieses aus dem DGM abgeleitet werden soll, tritt das Problem dort nicht auf. Brücken Abb. 30: Kleine Gebäude in stark geneigtem Gelände verschwinden unter Terrain, wenn Gebäude nicht freigestellt werden. Testgebiet Stuttgart ( LGL) Bei der Verarbeitung der Brücken wurden keine weiteren Veränderungen am Workflow von Marx (2018) vorgenommen. Linienhafte- und flächenhafte Bauwerke, Anlagen und Einrichtungen für den Verkehr -Objekte (ver06_f, ver06_l) werden getrennt eingelesen. Beide werden anschließend nach der Objektart gefiltert, um nur Bauwerke im Verkehrsbereich zu erhalten. Diese werden wiederum nach der Bauwerksfunktion gefiltert, um nur Brücken zu erhalten. Dann werden diese am Gebietsrand ausgeschnitten und mit dem height_fld = 1 für den 3dfier versehen. Die linienhaften Brücken werden anschließend alle einheitlich um drei Meter gepuffert, da eine Angabe zur reellen Breite fehlt. Nach der Pufferung werden Flächen am Gebietsrand abgeschnitten und anschließend in eine Shape-Datei geschrieben. Gewässer Aufgrund der starken Abhängigkeit des 3dfier-Ergebnisses von der Tessellation werden nachfolgend drei Varianten der Tessellation vorgestellt. Für alle Varianten gilt: Linienund flächenhafte Gewässer werden getrennt eingelesen und am Gebietsrand ausgeschnitten. Die linienhaften Gewässer werden nach dem Attribut HDU_X = 0 gefiltert und anschließend nach der Breite des Gewässers gepuffert. Nach der Pufferung werden sie erneut ausgeschnitten. In Variante 1 wird der Workflow von Marx (2018) unverändert übernommen. Darin werden die linienhaften Ge- Abb. 31: Oben: Überlagerungen nach dem Tessellations-Workflow von Marx (2018). Rechts: Resultierende treppenartige Struktur bei schmalen Bächen in steilem Gelände. Testgebiet Niedernhall ( LGL) 53

54 Workflow mit ATKIS- und Baumkatasterdaten wässer nur gepuffert, Überlappungen zwischen den einzelnen Flächen nicht behoben. Dadurch ergeben sich bei steilen Bächen und Gräben treppenartige Gewässer (Abb. 31). Im Testgebiet Stuttgart ergeben sich mit dieser Variante Probleme mit den Schleusengebäuden am Neckartor, weil diese nicht von den Gewässerflächen freigestellt werden. In Variante 2 wird der Workflow von Marx (2018) deshalb dahingehend geändert, dass Gebäudeflächen von den Gewässerflächen ausgeschnitten werden, was das Problem mit der Schleuse am Neckar beseitigt. Durch das Ausschneiden entsteht unter dem Gebäude im Gewässer eine Terrainfläche und es ergeben sich weniger Fehler im 3dfier. Durch den AreaOnAreaOverlayer, welcher die Gebäudeflächen aus den Gewässerflächen ausschneidet, werden auch die Überlappungen zwischen den Gewässerflächen aufgelöst. Dadurch entstehen kleine Kreisflächen, welche in der Tessellation zu Artefakten führen, da für die kleinen Flächen zu wenige Punkte mit Höheninformationen vorhanden sind (Abb. 32). Daher ist Variante 2 nicht empfehlenswert, um ein 3D-DLM mit 3dfier zu erstellen. Abb. 32: Durch den Einsatz des AreaOnAreaOverlayer in der Tessellation entstehen Kreise, welche zu Artefakten im 3D-DLM führen. Testgebiet Stuttgart ( LGL) Bei Variante 3 werden nach der Beseitigung der Überlagerungen alle Objekte mit derselben OBJID mittels eines Dissolver zu einem Objekt zusammengefasst. Hier ergeben sich im steilen Gelände tiefe Gräben und hohe Anhäufungen, da sehr lange Objekte entstehen (Abb. 33). In Stuttgart liegen keine Gewäs- Abb. 33: Tiefe Gräben und hohe Anhäufungen bei linienhaften Gewässern in steilem Gelände. Testgebiet Niedernhall ( LGL) 54

55 Workflow mit ATKIS- und Baumkatasterdaten ser an steilen Hängen vor, sodass Variante 3 mit dem Zusammenfassen der Objekte genutzt werden kann. Für Niedernhall ist die Variante 1 ohne AreaOnAreaOverlayer sinnvoll, da hier keine Gebäudeflächen aus den Gewässerflächen ausgeschnitten werden müssen. Bei Straßen und Wegen ist der Algorithmus nicht so fehleranfällig, da diese über das Terrain gelegt werden und somit keinen Zwangsbedingungen unterworfen sind. Daher können Straßen und Wege gleicher OBJID problemlos zusammengefasst werden. Es muss festgehalten werden, dass die Workflows, um bestmögliche Ergebnisse mit dem 3dfier zu erzielen, nicht mehr beliebig räumlich übertragbar sind, sondern an das Testgebiet angepasst werden müssen. Hinsichtlich einer landesweiten automatischen Generierung wäre also die 3dfier- Software zu optimieren oder eine andere Software (z.b. novafactory) für die Erstellung der linienhaften Gewässerobjekte zu nutzen. Wald Durch einen Shape-Reader werden wahlweise die Waldflächen aus dem ATKIS-Basis- DLM (ver02_f) oder die durch ein Baumkataster erzeugten Vegetationsflächen (Kap ) eingelesen. Die eingelesenen Flächen werden nacheinander von Gebäuden, Gewässern, Gleisen, Straßen und Wegen freigestellt. Die Kleinflächenfilterung wird dahingehend geändert, dass die tatsächliche Fläche der Objekte berechnet wird und so die Filterung über eine reelle Quadratmeterzahl möglich ist. Landwirtschaftliche Flächen Die landwirtschaftlichen Flächen werden von Gebäuden, Gewässern, Gleisen, Straßen und Wegen freigestellt. Da keine Überlappungen zwischen Wald- und landwirtschaftlichen Flächen vorhanden sind, ist eine solche Freistellung nicht notwendig. Die Kleinflächenfilterung wird wie bei der Objektklasse Wald auf eine Filterung nach Quadratmetern umgestellt. Straßen Im Unterschied zu Marx (2018) werden nicht grundsätzlich alle Straßenbereiche mit HDU_X=1 (Brücken und Tunnel) herausgefiltert, sondern eine genauere Unterscheidung der einzelnen Objekte vorgenommen. Dies hat den Zweck, diese Daten bei einer späteren, umfassenderen 3D-DLM-Erstellung, bei der weitere Objektklassen wie z.b. Tunnel oder unterirdische Haltestellen berücksichtigt werden sollen, direkt als Eingangsdatensätze verwenden zu können. Im Gegensatz zur Anmerkung im Abschlussbericht des Runden Tisch GIS (2018) werden Straßenflächen an Brücken unterbrochen. Werden Straßenflächen nicht an Brücken unterbrochen, werden diese durch 3dfier unter die Brückenfläche gelegt, oftmals mit deutlich sichtbarem Abstand, was für die Anwendung der Visualisierung in Niedernhall 55

56 Workflow mit ATKIS- und Baumkatasterdaten sehr ungünstig wäre. Daher werden alle Straßenflächen über Gewässern oder anderen Straßen entfernt. Dies hat den Vorteil, dass die Straße unter der Brücke bis zum Gewässerrand oder dem Rand der anderen Straße verläuft und dort endet. Im Bereich der Gewässer bildet 3dfier dann bei ausreichendem Abstand zwischen Gelände und Brücke senkrechte Wände, welche als Wiederlager der Brücke aufgefasst werden können. Zunächst werden die linienhaften Straßen ver01_l und die linienhaften Bauwerke, Anlagen und Einrichtungen für den Verkehr ver06_l eingelesen. Dies ist notwendig, da sich mache für die 3D-DLM-Erstellung benötigten Attribute nicht beim Layer der Straßen befinden, sondern bei den Bauwerken, Anlagen und Einrichtungen für den Verkehr. Aus dem den Straßen zugeordneten Attribut HDU_X geht nicht hervor, ob es sich um einen Tunnel oder eine Brücke handelt (Abb. 34). Abb. 34: Tunnel und Brücken (markiert) haben beide den Attributwert HDU_X = 1. Testgebiet Stuttgart ( LGL) Für die Generierung eines 3D-DLM mit dem 3dfier könnten grundsätzlich alle Tunnelund Brückenflächen über dieses Attribut ausgeschlossen werden, so wie im Workflow der TUM (Abb. 35, Marx 2018). 56

57 Workflow mit ATKIS- und Baumkatasterdaten Abb. 35: Tunnel werden in der Tessellation nicht berücksichtigt. Straßen enden am Tunneleingang (roter Pfeil). Testgebiet Stuttgart ( LGL) Für eine künftige Modellerstellung, welche auch die Objektart Tunnel berücksichtigen soll (z.b. mit novafactory), ist jedoch auch die Betrachtung dieser Objekte von Bedeutung. Daher wird in der Tessellation ein Ansatz gezeigt, wie zwischen Brückenflächen und Tunnelflächen unterschieden werden kann und wie unterirdische Haltestellen von Straßentunneln zu trennen sind. Diese so separierten Objektarten können dann als Eingangsdaten für novafactory zur Erzeugung geeigneter 3D-Geometrien dienen. Im 3dfier können sie jedoch nicht berücksichtigt werden. Die Bauwerke, Anlagen und Einrichtungen für den Verkehr werden nach Tunneln gefiltert. Die Tunnel werden mit dem height_fld = -1 versehen. Anschließend sorgt ein LineOnLineOverlayer dafür, dass die Tunnel- mit den Straßenlinien verschnitten werden. Dann werden alle Straßenabschnitte, welche auch Tunnel sind, herausgefiltert, sodass im Folgenden nur noch linienhafte Straßen verarbeitet werden, welche oberirdisch sind und nicht exakt über Tunneln verlaufen. Dann werden diese noch nach dem Zustand (ZUS=4000) gefiltert. Damit fallen noch im Bau befindliche Straßen heraus. Vor der weiteren Betrachtung der linienhaften Straßen müssen die flächenhaften Straßen betrachtet werden, da die linienhaften und flächenhaften Elemente an diesem Punkt miteinander verschnitten werden würden. Bei den flächenhaften Straßen müssen zunächst die flächenhaften Bauwerke, Anlagen und Einrichtungen für den Verkehr verarbeitet werden. Diese werden zunächst nach Tunneln inkl. unterirdischer Bahnhaltestellen gefiltert. Parallel dazu wird der Datensatz auch nur nach unterirdischen Bahnhaltestellen gefiltert. Dann werden diese Flächen miteinander verschnitten und so gefiltert, dass nur noch Straßentunnel enthalten sind. Diese Straßentunnel werden mit den flächenhaften Straßen verschnitten und gefiltert, so das nur noch oberirdische Straßenflächen vorhanden sind. Von diesen werden noch die Straßenbegleitflächen (FKT 2312) herausgefiltert. 57

58 Workflow mit ATKIS- und Baumkatasterdaten Dann werden die linienhaften (noch nicht gepufferten) und flächenhaften Straßen miteinander verschnitten. Hierbei gehen zusätzlich zu den oberirdischen Straßen auch die unterirdischen Straßenflächen (Tunnel) ein, um auch linienhafte Straßen, welche in flächenhafte Tunnel führen, auszuschließen. Im Wesentlichen dient dieser Line- OnAreaOverlayer aber dazu, linienhafte Straßen, welche in flächenhafte Straßen hineinragen, auszuschneiden. Im Folgenden werden dann nur noch diese linienhaften Straßen bearbeitet, die flächenhaften Straßen stoßen später wieder zur Verarbeitung dazu. Für die linienhaften Straßen wird geprüft, ob das Attribut Breite der Fahrbahn (BRF) belegt ist. Ist es unbelegt, werden die Straßen mit dem Betrag 1,5 m gepuffert. Ansonsten werden die Straßen entsprechend dem Wert des Attributs gepuffert. Durch einen AreaOnAreaOverlayer werden jeweils getrennt die Überlappungsbereiche der bekannten BRF und der unbekannten BRF verschnitten, anschließend Straßenstücke mit gleicher OBJID wieder zusammengefasst. Überlappungsbereiche treten im Bereich von Kreuzungen und am Anfang- und Ende von linienhaften, jetzt gepufferten Straßenelementen auf. Der Vorgang des wiederholt sich noch einmal, um auch die Überlappungsbereiche im Kreuzungsbereich zwischen Straßen mit bekannter und mit unbekannter BRF sowie flächenhaften Straßen aufzulösen. Anschließend werden Gebäudeflächen, Gleisflächen, und Gewässerflächen von den Straßenflächen abgezogen. Anschließend werden die Straßenflächen nochmals an den Gebietsrändern abgeschnitten, da durch die Pufferung der Linien neue Flächen entstanden sind. Räumlich getrennte Flächen, welche allerdings als ein (zusammengesetztes) FME-Polygon geführt werden, werden mittels eines Deaggregator getrennt. Dann werden die Straßen in eine Shape-Datei geschrieben. Wege Im Gegensatz zu Marx (2018) werden die Wege nach dem Ausschneiden am Gebietsrand von den Gebäuden, Gleisen, Straßen und Gewässern freigestellt. Somit werden Überlappungen, welche im 3dfier zu Problemen führen, vermieden. Vor der Freistellung werden die Weglinien entsprechend dem Wert im Attribut Breite des Verkehrswegs (BRV) gepuffert und Überlappungen zwischen den einzelnen Wegobjekten selbst beseitigt. Gleise Der Workflow von Marx (2018) wird bei den Gleisen dahingehend ergänzt, dass Bahnstrecken im Bau abgefangen und nicht mehr berücksichtigt werden. 58

59 Workflow mit ATKIS- und Baumkatasterdaten Terrain In den AreaOnAreaOverlayer_Gelaende gehen alle resultierenden Flächen der einzelnen Objektklassen ein, außer den Brücken. Brücken gehen nicht ein, da unter ihnen Terrain gebildet werden soll, sofern keine anderen Flächen vorhanden sind. Zusätzlich geht das Gebietsgrenzen-Polygon in den AreaOnAreaOverlayer_Gelaende mit ein. Für alle Flächen, an welchen keine Überlappungen zwischen dem Gebietsgrenzen-Polygon und mindestens einer anderen eingehenden Objektklasse bestehen, werden Terrain-Polygone gebildet. Damit ist gewährleistet, dass die Daten als Eingangsdaten für den 3dfier lückenlos vorliegen. Die Terrain-Polygone werden noch mit einer OBJID und dem rel_hoehe = 0 versehen und dann in das Shapefile geschrieben. Weitere Objekte In den Testgebieten sind Objekte vorhanden, welche aus der Tessellation heraus erkannt und verarbeitet werden können, deren Verarbeitung in 3dfier aber nicht möglich ist: Straßen- und Schienentunnel Unterirdische Haltestellen Des Weiteren gibt es Objekte, welche im Basis-DLM auftreten, aber in der Tessellation nicht berücksichtigt werden können: Durchlässe von Gräben oder Bächen unter Straßen und Wegen (ohne Brücken), welche als Rohre zu modellieren wären. Fußgängerstege über Gleisflächen, bei denen das zugehörige Brückenobjekt fehlt (Fußgängerstege über S21-Baustelle am Hauptbahnhof) dfier Die Anwendung des 3dfier erfolgt wie im Kap. 5.2 beschrieben. Die verwendeten Optionen können der Konfigurationsdatei auf der DVD entnommen werden. 7.4 Mapping Wie bereits in Runder Tisch GIS (2018 a) beschrieben wird, ist nach der Anwendung des 3dfier das semantische Mapping als weiterer FME-Prozess erforderlich. Hierbei werden die vom 3dfier erzeugten Klassen auf die CityGML-Objektklassen und die AT- KIS-Attribute in die CityGML-Codelisten überführt. Gleichzeitig finden in diesem Prozess alle weiteren notwendigen Anpassungen in den Datensätzen statt (Runder Tisch GIS 2018 a). 59

60 Workflow mit ATKIS- und Baumkatasterdaten Mapping nach CityGML-Schema Der Mapping-Workflow vom Marx (2018), siehe Kap , wurde nur geringfügig geändert, deshalb werden nur die durchgeführten Änderungen beschrieben, nicht erneut der gesamte Workflow. Dieser ist auf der DVD gespeichert. Aus zwei Gründen werden für die beiden Testgebiete unterschiedliche Reader benötigt: Da in Stuttgart keine Waldflächen aus dem Basis-DLM, sondern aus dem Baumkataster abgeleitete Vegetationsflächen verwendet werden, unterscheiden sich hier die einzulesenden Attribute. In Niedernhall existieren keine Gleise, deshalb fehlen im Reader Road die Attribute dieser Klasse, während sie in Stuttgart vorhanden sind. Im Mapping-Prozess existieren nicht jeweils einzelne Reader für jede Objektklasse, sondern jeweils ein Reader für die Datei. Dies hat den Vorteil, dass der Reader und der Dateipfad zur Eingabedatei nur einmal definiert werden müssen. Bei der Tessellation liegen im Gegensatz dazu viele Eingabe-Shape-Dateien vor, welche über unterschiedliche Reader eingelesen werden. Entscheidend bei der Definition eines neuen Reader im Mapping-Workflow ist, in den Reader-Parametern die Einstellung Ignore xsi:schemalocation in Dataset auf Yes zu setzen. Der Leser ignoriert dann die Schemadateien, welche im Datensatz angegeben sind (Safe Software 2017 a). Wird diese Einstellung nicht gesetzt, bricht das Einlesen der Objekte mit einem XML Parser error ab, da keine Schemadateien gefunden werden. Ist die Einstellung korrekt gesetzt, werden alle Objekte aus der CityGML-Datei einzeln eingelesen und der Nutzer kann festlegen, welche Objektklassen der Reader importieren soll. Im Fall von Stuttgart sind dies z.b. Bridge, WaterBody, PlantCover, Road (enthält Straßen, Wege, Gleise), LandUse (Terrain) und Building (Gebäude und Sportanlagen). Für die Vegetationsflächen aus dem Baumkataster werden zunächst das Koordinatensystem angepasst und mehrfach vorhandene OBJIDs abgefangen. Anschließend werden die minimale und maximale Höhe sowie der Flächeninhalt berechnet und in Attribute geschrieben. Die CityGML-Geometrieeinstellungen werden gesetzt und die OBJID in gml_id umbenannt. Nach dem Reader Road wird ein TestFilter eingebaut, welcher mittels der Objektart die Straßen und Wege von den Gleisen trennt und sie zur korrekten Weiterverarbeitung weiterleitet. 60

61 Workflow mit ATKIS- und Baumkatasterdaten Bezeichnungen nach ATKIS-Objektartenkatalog für Webanwendung Niedernhall Für die Visualisierung in der Webanwendung Niedernhall sollen keine CityGML-Codes als Attributwerte und keine CityGML-Attributbezeichnungen verwendet werden. Stattdessen sollen Nutzer- und bürgerfreundlicher die Bezeichnungen aus dem ATKIS- Objektartenkatalog (AdV 2008) verwendet werden (Abb. 36). Anstatt CityGML- Attribute werden generische Attribute verwendet. Abb. 36: Umwandlung der ATKIS-Codes in ATKIS-Bezeichnungen mit dem AttributeValueMapper 7.5 3DCityDB Mit der 3DCityDB werden die erzeugten 3D-DLM zunächst validiert. Anschließend wird der Austausch von Objektarten durchgeführt, indem nur die jeweils benötigten Objektarten in die DB importiert werden, z.b. werden die Gebäude des 3dfier nicht importiert, sondern die amtlichen LoD2-Modelle. Der Austausch der Objektarten könnte grundsätzlich auch über einen FME-Prozess realisiert werden Validierung Nach dem Mapping können die 3D-DLM mit der Validierungsfunktion des 3DCityDB Importer Exporter validiert werden. Für kleinere Dateien bis ca. 300 MB kann dies auch mit der Software XMLSpy erfolgen. Nach dem Mapping sind die in dieser Arbeit erzeugten 3D-DLM alle valide. Im Folgenden wird auf Fehler in den Eingangsdaten eingegangen, welche dazu führen, dass die Dateien nicht valide sind. Grundsätzlich sollten alle Eingabedateien vor dem Import validiert werden, um Fehler vorab zu erkennen. Das Vorhandensein mehrfacher gml_ids wird im FME-Mapping-Prozess abgefangen. Der Fehler kann jedoch auftreten, wenn Datensätze aus anderen Quellen importiert werden, z.b. die LoD2-Gebäude. Ein möglicher Fehler, welcher durch die FME-Prozesse nicht abgefangen wird, ist der, dass in den 2D-Eingabedateien Attributwerte mit Zeichen vorhanden sind, welche in UTF-8 nicht kodiert sind (é, ) und durch den 3dfier dann in andere Zeichenketten übertragen werden. Auch können in den Attributwerten Zeichen vorhanden sein, die in 61

62 Workflow mit ATKIS- und Baumkatasterdaten CityGML Steuerzeichen sind (&, <, >, /). Bei den Basis-DLM-Daten besteht dieses Problem nicht, da diese Daten keine solchen Zeichen aufweisen. Bei anderen Datensätzen wie z.b. OpenStreetMap können solche Zeichen vorhanden sind. Diese werden beim Import dann falsch umgesetzt und sollten zuvor durch die Validierung erkannt und dann beseitigt werden. Die entsprechende Fehlermeldung bei der Validierung lautet: [15:14:43 ERROR] Invalid content at [ ,42]: Auf "&" in der Entityreferenz muss umgehend der Entityname folgen. Mit der Software PilotEdit kann der Inhalt in Zeile , Spalte 42 gesucht und anschließend mit ArcMap der Fehler in den Attributtabellen der Eingangsdaten behoben werden. Hierbei kann die Funktion Suchen und Ersetzen eingesetzt werden, um alle unerwünschten Zeichen zu finden Import und Austausch Objektarten Vor dem Import von Objekten in eine PostgreSQL-DB ist selbige mit dem pgadmin4 und der Datei Create_DB.bat anzulegen und die Verbindung zu ihr herzustellen. Weitere Informationen hierzu finden sich in 3DCityDB (2016). Beim Import können verschiedene Einstellungen getroffen werden, z.b. dass nur Objekte innerhalb eines bestimmten Gebiets importiert werden. Für den Austausch der Objektarten ist am wichtigsten, dass nach verschiedenen Objektklassen gefiltert werden kann. Aus dem 3D-DLM des 3dfier werden die Klassen Bridge, LandUse, Transportation und WaterBody eingelesen. Die Vegetationsobjekte stammen aus einem ArcGIS- und FME- Prozess (s. Kap. 9.3) und werden als Vegetation importiert, die LoD2-Gebäudemodelle als Buildings. Beim Import großer Einzelobjekte, wie sie z.b. bei LandUse vorkommen kann es passieren, dass der zugewiesene Arbeitsspeicher nicht ausreicht, um die Objekte in die Datenbank zu schreiben. Die LOG-Konsole gibt dann folgende Fehlermeldung aus: Exception in thread "citygml_parser_pool 1" java.lang.outofmemoryerror: Java heap space Ist dies der Fall, muss die Anzahl der Objekte, welche gleichzeitig in die Datenbank geschrieben werden, in den Import-Voreinstellungen reduziert werden. Das gekachelte Importieren der Objekte hilft nicht dies Problem zu umgehen, da es sich um einzelne, sehr große Objekte handelt, welche z.t. aus mehreren Millionen Dreiecken bestehen. Abb. 37 zeigt die Einstellungen, welche den Import aller erzeugten 3D-DLM auf dem verwendeten Laptop (s. Anhang) erlauben. 62

63 Workflow mit ATKIS- und Baumkatasterdaten Abb. 37: Voreinstellungen zum CityGML-Import im 3DCityDB Importer Exporter Für Niedernhall werden zwei Datenbanken angelegt und einmal das Modell mit Attributen nach CityGML-Codelisten, einmal das Modell mit ATKIS-Bezeichnungen importiert. Für Stuttgart wird nur eine DB erstellt Export Beim Export nach CityGML können wie beim Import Einstellungen getroffen werden, um nur bestimmte Gebiete oder Objektarten auszugeben. Für die Übernahme in die Webanwendung Niedernhall werden nur die Objektarten Bridge, LandUse, Vegetation, Transportation und WaterBody exportiert, da die Gebäude bereits in der Webanwendung enthalten sind. 63

64 Workflow mit OpenStreetMap-Daten 8 Workflow mit OpenStreetMap-Daten Zum Vergleich mit den 3D-DLM aus ATKIS-Basis-DLM und LiDAR-Daten und um zu zeigen, dass die gewählte Vorgehensweise auch auf anders strukturierte Datensätze übertragbar ist, sollen auch mit OpenStreetMap-Daten (OSM-Daten) 3D-DLM erstellt werden. Der Workflow ist in Abb. 38 dargestellt. Abb. 38: Workflow zur Erstellung von 3D-DLM mit OpenStreetMap- und LiDAR-Daten 8.1 2D-Daten aufbereiten Vorbetrachtung der OSM-Daten Die OSM-Daten können auf der Website unter dem Reiter Export heruntergeladen werden. Hierbei ist darauf zu achten, dass die Kachel ausreichend groß gewählt wird, da nur überwiegend im Ausschnitt liegende Objekte exportiert werden. Insbesondere sehr große Objekte, welche weit aus dem Ausschnitt herausragen, werden nicht mit exportiert. Die Daten liegen im Format.osm vor. Dieses ist xml-basiert und somit menschenlesbar. Ein offizielles Anwendungsschema wie für CityGML wurde laut OSM Wiki (2016 und 2017 a) nie definiert. Nur die Grund-Elemente des konzeptuellen Datenmodells von OSM werden definiert: nodes (Knoten), ways (Kanten und Flächen) sowie relations, welche die Beziehungen zwischen einzelnen Elementen beschreiben (vergl. OSM Wiki 2017 b). Trotzdem können die Daten in FME importiert und z.b. in Shape-Dateien konvertiert werden. Die Prüfung der Daten ergibt, das Brücken und Tunnel in den Daten nicht durch Attributwerte markiert sind. In Abb. 39 ist ein Brückenabschnitt im Straßennetz von Nie- 64

65 Workflow mit OpenStreetMap-Daten dernhall markiert. Anhand der OSM-Daten ist es aber nicht ersichtlich, dass es sich um eine Brücke handelt. Abb. 39: Layer highway_line im FME Data Inspector. Brücken (markiert) und Tunnel sind nicht durch Attributwerte identifizierbar ( ODbL) Vor der Tessellation müssten die Daten also manuell vorverarbeitet werden und allen Straßen- und Tunnelabschnitten die entsprechenden Attribute zugeordnet werden. Alternativ könnten die Straßen- und Wegeflächen über Gewässerflächen in der Tessellation als Brücken definiert werden. Dann stellt sich das Problem, das bei Brücken über anderen Straßen nicht automatisiert geklärt werden kann, welche Straße oberhalb welcher verläuft und welche somit eine Brücke ist. Eine Internetrecherche ergibt, dass von Firmen weiterverarbeitete OSM-Daten ebenfalls kostenlos verfügbar sind. Auf können veredelte OSM-Daten Kontinent-, Land-, Bundesland oder Regierungsbezirksweise kostenfrei als Shapefile heruntergeladen werden. Die Daten sind unter der Creative Commons Attribution-ShareAlike 2.0 Generic (CC BY-SA 2.0)-Lizenz verfügbar und dürfen somit u.a. auch für kommerzielle Zwecke genutzt werden. Im Layer roads sind im Vergleich zu den originalen OSM-Daten zusätzliche Attribute enthalten, welche u.a. definieren, ob es sich beim gewählten Straßenstück um eine Brücke oder einen Tunnel handelt (Abb. 40). 65

66 Workflow mit OpenStreetMap-Daten Abb. 40: Layer roads der OSM-Geofabrik-Daten mit zusätzlichen Attributen, markiert ist eine Brücke (bridge=t [true]) ( Geofabrik-Daten: CC BY-SA 2.0) Es kann festgehalten werden, dass für die Übertragbarkeit des Workflows auf andere Datensätze gewisse Mindestanforderungen erfüllt sein müssen, was den Inhalt der Daten betrifft. Alle im 3D-DLM benötigten Objekte und Attribute müssen vorhanden sein. Da der 3dfier die UTF-8-Zeichenkodierung verwendet, ist darauf zu achten, das alle Eingabedateien UTF-8-kodiert sind und in den Eingabedateien nur Zeichen enthalten sind, welche mit UTF-8 codiert werden können. Bei den Daten aus dem ATKIS-Basis- DLM ist dies der Fall, bei den OSM-Daten, auch den Daten der Geofabrik, nicht. In den Attributtabellen vieler Layer finden sich spezielle Zeichen, welche entweder nicht UTF- 8 codiert sind oder als xml-steuerzeichen die Dateistruktur beeinflussen. Dies führt dazu, dass die mit 3dfier erzeugten CityGML-Dateien invalide sind und nicht in FME, FZK Viewer oder 3DCityDB importiert werden können. Die in den Testgebieten auftretenden unzulässigen bzw. störenden Zeichen sind: &, é, ( ) / Weitere xml-steuerzeichen welche auftreten und Probleme verursachen können sind: < > (Aufführungszeichen, um leere Attributwerte zu kennzeichnen) Einige Beispiele finden sich in nachfolgender Liste: S&D Backshop Simic Café Martinskirche (Nord) Außenbecken 20 C In ArcGIS kann in den Attributtabellen der Layer automatisch nach den problematischen Zeichen gesucht und diese durch andere ersetzt werden (z.b. & durch u.). Die Umlaute Ä,Ö,Ü,ä,ö,ü und das ß-Zeichen werden korrekt verarbeitet und können belassen werden. 66

67 Workflow mit OpenStreetMap-Daten Tessellation Der Tessellations-Workflow ist ähnlich zu dem der LGL-Daten, daher werden hier nur die Unterschiede beschrieben. Grundsätzlich werden alle Datensätze der Geofabrik vom WGS84-System (EPSG:4326) nach ETRS89/UTM (EPSG:25832) transformiert. Der originale OSM-Datensätz barrier_line muss nicht mehr transformiert werden, da die Transformation bereits bei der Konvertierung von.osm nach.shp mit den Quick Translator erfolgt ist. Alle Datensätze werden am Gebietsrand abgeschnitten. Stadtmauern und Mauern Im Gegensatz zu den LGL-Daten gibt es bei den OSM-Daten einen eigenen Layer barrier_line u.a. für Mauern und Stadtmauern, welche als linienhafte Objekte vorliegen und gepuffert werden, bevor sie gemeinsam mit den Gebäuden in ein Shapefile geschrieben werden. Gebäude Bei den Gebäuden ist zusätzlich die Betrachtung des Layers POIS (Points of Interest) erforderlich, da viele Points of Interest Gebäude sind. Neben öffentlichen Gebäuden sind dies auch private Unternehmen und Geschäfte. Die POIS-Gebäude werden extrahiert und zusätzlich zu den normalen Buildings in das Shapefile Gebauede_OSM geschrieben. Die POIS, welche keine Gebäude sind, werden zur Weiterverarbeitung in den Abschnitt POIS weitergeleitet. Points of Interest Ein Problem des landuse-layers sind die vielen Überlagerungen, welche innerhalb dieses Layers auftreten. Daher müssen alle Klasse der Landnutzungen einzeln verarbeitet und die Überlagerungen aufgelöst werden. Beispielhaft ist dies für die Klassen point of interest und forest erfolgt. Die Klasse point of interest enthält neben öffentlichen Gebäuden auch sonstige Objekte von Interesse, wie z.b. den Stuttgarter Schlosspark, Spielplätze und Schwimmbecken. Aus der gemeinsamen Verarbeitung mit den Gebäuden heraus werden in die Point of Interest-Verarbeitungskette die Points of Interest weitergeleitet, welche keine Gebäude sind. Diese werden von Gewässern, Gleisen und Straßen freigestellt. Damit sich die Point of Interest-Flächen nicht mit den Waldflächen überlagern, werden diese in der dortigen Prozesskette freigestellt. Wald Anhand der fclass=forest werden zunächst alle Wald-Objekte aus den landuse- Elementen extrahiert. Dann werden diese von Gebäuden, Gewässern, Gleisen, Straßen und point of interest-flächen freigestellt. Sind im Datensatz sehr große Waldgebiete 67

68 Workflow mit OpenStreetMap-Daten vorhanden, wird ein geringer simplification-grad im 3dfier genutzt und ist beabsichtigt diese Objekte mit dem 3DCityDB Importer Exporter in eine DB zu schreiben, ist es erforderlich, die Waldelemente mit dem Tiler zu kacheln. Ansonsten bricht der Datenbankimport aufgrund der zu großen Einzelelemente mit einem Java Heap Space ab. Gleise Im Gegensatz zu den ATKIS-Daten ist in den OSM-Daten jeder Schienenstrang als eine Gleislinie modelliert, zweigleisige Strecken also durch zwei Linien. Somit kann jede Gleislinie auf die Standard-Spurweite von m gepuffert werden. Dann werden Überlappungen zwischen den entstehenden Flächen aufgelöst, Gebäude- und Gewässerflächen ausgeschnitten. Bei den Gleisen fehlen im Gegensatz zu den Straßen die Attribute welche ausdrücken dass es sich um Brücken oder Tunnel-Elemente handelt, sodass dies nicht berücksichtigt werden kann. Gleise enden in dieser Tesselation also immer vor Gewässern und Gleisbrücken über Gleise werden als Kreuzung der Gleise modelliert. Für die Gleiselemente welche sich mit Gewässerflächen überlagern könnten automatisch Brückenflächen erzeugt werden. Dies wäre dort falsch, wo es sich um keine Eisenbahnbrücke, sondern um ein Aquädukt handelt. Gewässer Die Gewässer befinden sich in den Layer water (flächenhaft) und waterway (linienhaft). Bei den linienhaften Gewässern ergibt sich die Besonderheit, dass auch einige unterirdische Leitungen bzw. Bachverdolungen als Gewässer modelliert sind. Da es sich hierbei jedoch nicht um Objekte an der Erdoberfläche handelt, sollen diese nicht als offene Gewässer im 3D-DLM modelliert werden. Es ist jedoch kein Attribut vorhanden, welches ausdrückt, dass es sich um unterirdische Leitungen handelt. Der Fehler ist nur im Zusammenhang mit anderen Layern erkennbar, wenn die linienhaften Gewässer mitten durch Gebäude verlaufen (Abb. 41), oder alternativ im Luftbild zu sehen. 68

69 Workflow mit OpenStreetMap-Daten Abb. 41: Fehlerhafte Modellierung in den OSM-Daten: Beim Störzbach handelt es sich im markierten Abschnitt um eine unterirdische Leitung, was jedoch durch kein Attribut ausgedrückt wird( OSM-Daten: ODbL, Geofabrik-Daten: CC BY-SA 2.0) Daher werden diese Gewässerabschnitte bei beiden Testgebieten vor der Tessellation manuell in ArcMap bearbeitet. Die fclass wird in drain (Drainage) geändert. Dann können in der Tessellation alle Gewässer mit dem Attributwert drain herausgefiltert werden. Im weiteren Prozessverlauf werden die linienhaften Gewässer mangels anderer Informationen einheitlich um 2 m gepuffert, mit den flächenhaften Gewässern verschnitten und Gebäudeflächen ausgeschnitten. Brücken Wie im Abschnitt Gleise erwähnt, sind Schienenbrücken im OSM-Datensatz nicht modelliert. Für Straßenbrücken existiert ein entsprechendes Attribut. Die Straßen werden nach Brücken und Tunneln gefiltert. Die Brücken werden in dieser Prozesskette weiterverarbeitet, für die Tunnel könnte z.b. mit novafactory eine geeignete Modellierung erfolgen. Die Elemente, welche keine Brücken und Tunnel sind, werden zur Prozesskette Straßen weitergeleitet (siehe Abschnitt Straßen). Die Brücken werden entsprechend ihrer Straßenkategorie in unterschiedlichen Breiten gepuffert und mit dem height_fld = 1 für den 3dfier versehen. Straßen Im Gegensatz zu den LGL-Daten sind bei OSM auch die Wege im Layer road enthalten, sodass für die Wege keine extra Verarbeitung erfolgt. Die Straßen kommen bereits gefiltert ohne Brücken und Tunnel aus der Prozesskette Brücken (siehe Abschnitt Brücken). 69

70 Workflow mit OpenStreetMap-Daten Die Straßen werden entsprechend ihrer Straßenkategorie gepuffert. Im Gegensatz zu den LGL-Daten entsprechen die Straßenkategorien in OSM aber ausdrücklich nicht der amtlichen Klassifizierung der Straßen (Bundesautobahn, Bundesstraße, Landesstraße/Staatsstraße, Kreisstraße, Gemeindestraße, ), sondern der tatsächlichen Verkehrsbedeutung und dem Ausbauzustand des Straßenabschnitts (OSM Wiki 2017 c). Nach der Pufferung um eine mittlere Breite je Straßenkategorie werden die entstehenden Überlagerungen miteinander verschnitten, dann erfolgt die Freistellung von Gebäuden, Gewässern und Gleisen. Terrain Die Bildung der Restfläche erfolgt wie beim LGL-Workflow, indem alle Klassen bis auf die Brücken mit der Gebietsgrenze verschnitten werden und somit dort wo noch keine Flächen vorhanden sind Terrain-Flächen erzeugt werden. Beim Entstehen sehr großer Terrain-Elemente kann es sinnvoll sein diese mit einem Tiler zu Kacheln, damit diese nach dem 3dfier in die 3DCityDB importiert werden können (siehe auch Abschnitt Wald) dfier Die Anwendung des 3dfier erfolgt wie bei den ATKIS-Basis-DLM-Daten beschrieben. Für die Anwendung mit den OSM-Daten sind lediglich die Dateinamen der 2D- Eingangsdaten in der Konfigurationsdatei anzupassen. Es werden dieselben Punktwolken und Einstellungen wie bei den LGL-Daten verwendet. 8.3 Mapping Der Mapping-Workflow von Marx (2018) kann in weiten Teilen übernommen werden. Wesentliche Änderungen sind bei der Übertragung der OSM-Attributwerte auf CityGML-Codes notwendig. Außerdem ist die Klasse Sport, Freizeit, Erholung durch die Klasse Gebäude zu ersetzen, da die OSM-Gebäude aus 3dfier erhalten bleiben sollen. Ein Beispiel für das sog. Value Mapping ist in Abb. 42 zu sehen. Hier ist deutlich zu erkennen, dass sich die OSM-Bezeichnungen nicht immer 1:1 auf CityGML-Attribute übertragen lassen. Wo dies der Fall ist, werden zusätzlich zu den CityGML-Codes die originalen OSM-Attribute als generische CityGML-Attribute mit übernommen, um Informationsverluste zu vermeiden. 70

71 Workflow mit OpenStreetMap-Daten Abb. 42: Übertragung von OSM-Attributwerten in CityGML- Codes mit dem AttributeValueMapper in FME 8.4 3DCityDB Mithilfe der 3DCityDB können die erzeugten 3D-DLMs validiert und in die Datenbank importiert werden. In ländlichen Gebieten mit sehr großen zusammenhängenden Terrain- oder Waldgebieten ist es notwendig, diese Gebiete bereits in der Tessellation zu kacheln oder im 3dfier den simplification-grad zu erhöhen, damit keine zu großen Einzelobjekte (mit mehreren Millionen Dreiecken) entstehen, welche zu einem Java Heap Space beim DB-Import führen. Zu beachten ist, dass auch eine nicht valide Datei zu einem Java Heap Space beim Datenbankimport führen kann, ohne dass dies an der Fehlermeldung ersichtlich ist. Deshalb sollten nur zuvor erfolgreich validierte Dateien importiert werden. Wurden die Eingangsdaten nicht wie in Kap. 8.1 beschrieben von nicht UTF-8- konformen Zeichen bereinigt, fällt dies bei der Validierung durch entsprechende Warnungen auf: 71

72 Workflow mit OpenStreetMap-Daten [15:14:43 ERROR] Invalid content at [ ,42]: Auf "&" in der Entityreferenz muss umgehend der Entityname folgen. [15:14:43 ERROR] Failed to validate CityGML file: Auf "&" in der Entityreferenz muss umgehend der Entityname folgen. Bei FME-Mapping-Prozess kommt beim Einlesen der Objekte mit diesem Fehler diese Fehlermeldung, aus welcher das eigentliche Problem nicht eindeutig hervorgeht: XML Parser error. Error in input datastet Angabe Dateipfad- Angabe Zeilennummer- Angabe Spaltennummer- message: expected entity name for reference 72

73 Workflow für Windsimulation 9 Workflow für Windsimulation Wie in Kap. 6.3 beschrieben, ist für die spezielle Anwendung der Windsimulation eine gesonderte Betrachtung der Erstellung von 3D-DLM erforderlich. In diesem Kap. werden zunächst weitere Versuche mit 3dfier beschrieben, geeignete 3D-DLM für die Windsimulation zu erstellen. Da dies nicht gelingt, erfolgt die Erstellung der für die Windsimulation benötigten zusätzlichen Objektarten (Rauhigkeitsgrenzen und Vegetationskörper) auf andere Weise. 9.1 Weitere Tests mit 3dfier zur Erzeugung geeigneter Vegetationskörper Bei diesen Tests wird geprüft, ob durch geänderte Einstellungen mit 3dfier nicht doch geeignete Geometrien für die CDF-Windsimulation erstellt werden können Wald als Gebäude Abb. 43: Mit 3dfier erzeugte LoD1-Building-Solids als Wald-Repräsentation. Die Höhen der oberen ebenen Abschlussflächen sind nur bei nicht zu stark geneigtem Gelände korrekt ( LGL) Werden die Gebäudepunkte aus der Punktwolke entfernt, die Vegetationspunkte als Gebäudepunkte klassifiziert und die Waldflächen aus dem Basis-DLM mit der lifting: building-option in 3dfier berücksichtigt, ergeben sich LoD1-Solids, welche den Wald repräsentieren. Die Solids haben eine obere ebene Abschlussfläche für je ein Ausgangs-Polygon. Bei geneigtem Gelände ergeben sich große Modellierungsfehler in der Höhenlage der Objekte, die absolute Höhe des Baumbestandes entspricht an manchen Stellen der Geländehöhe (Abb. 43). Des Weiteren ergeben sich Lücken zwischen einzelnen Vegetationskörpern. Als Notlösung wäre diese Vorgehensweise für die Windsimulation brauchbar, um die Lage der Vegetationsobjekte zu kennzeichnen. Die Höhe der Objekte muss dann in ANSYS Academic von Hand angepasst werden, die Lücken im Modell durch geeignete Werkzeuge geschlossen werden. Aufgrund der beschriebenen Fehler kann diese Methode nicht als allgemeingültige Methode zur Erstellung von geeigneten Vegetationskörpern angesehen werden. Not- 73

74 Workflow für Windsimulation wendig wäre eine Änderung des Quellcodes von 3dfier, um in der Klasse forest die Möglichkeit zu bieten, Solids mit stark vereinfachter, triangulierter oberer Abschlussfläche zu erhalten. Auf der Website der TU Delft ist aktuell (Stand Juli 2018) eine Masterarbeit zum Thema 3dfier Erweiterungen ausgeschrieben. Es soll u.a. die Möglichkeit geschaffen werden, in einem Postprozess zu 3dfier eine parametrische Baumdarstellung zu erzeugen (TU Delft o.d.). Zum aktuellen Stand der CFD-Windsimulation an der HFT Stuttgart wäre auch diese nicht geeignet, da hier jeder Einzelbaum modelliert wird, keine flächendeckenden PlantCover-Objekte erzeugt werden Wald ohne Bodenpunkte Werden im Waldbereich alle Bodenpunkte durch eine Änderung des FME-Workflows zur Punktwolkenvorverarbeitung gelöscht und für forest ein simplification-grad von 90 eingestellt, ergibt sich eine Vermaschung, welche am Rand der Höhe des Terrains, im Waldinneren der Höhe der Baumkronen entspricht (Abb. 44). Es handelt sich jedoch um MultiSurfaces und nicht um Solids. Außerdem ergeben sich immer noch zu viele spitzwinklige Dreiecke. Abb. 44: Vermaschung des Waldes ohne Verwendung von Bodenpunkten und mit hohem Wald- Vereinfachungsgrad (forest simplification) ( LGL) Aufgrund dieser Erkenntnisse mit 3dfier soll ein Weg gefunden werden, geeignete Vegetationskörper ohne 3dfier zu erzeugen. 9.2 Rauhigkeitsgrenzen für die CFD-Windsimulation Die Rauhigkeitsgrenzen können entweder manuell direkt in ANSYS Academic erstellt werden, oder vorab in einem GIS-Programm. Die Erstellung direkt in ANSYS Academic bietet den Vorteil, dass keine weiteren Konvertierungsschritte notwendig sind. Bei Erstellung z.b. in ArcMap ist vorteilhaft, dass neben den Gebäuden noch weitere Ob- 74

75 Workflow für Windsimulation jekte wie Vegetation, Brücken und Gewässerflächen bei der Anlegung der Rauhigkeitsgrenzen mit berücksichtigt werden können. Nachfolgend wird die Erstellung der Rauhigkeitsgrenzen mit ArcMap beschrieben. In ArcCatalog wird eine neue FeatureClass mit dem Geometrietyp Polygon angelegt, dann in ArcMap die entsprechenden Polygone gezeichnet bzw. im Fall von großen Flächen diese in den Layer übernommen. Dies kann ausgehend von der Tessellation (Kap , Abb. 45) oder direkt auf Grundlage des Basis-DLMs oder OSM-Daten erfolgen. Die so erzeugten Shape-Dateien können mit dem FME Quick Translator ins OBJ-Format konvertiert und in ANSYS Academic eingelesen werden. Dort werden die Flächen dann Abb. 45: Rauhigkeitsgrenzen in ArcGIS ( LoD2-Gebäude: Stadt Stuttgart, Basis- DLM-Daten: LGL) auf das verwendete Terrain projiziert und die Rauhigkeitswerte den Flächen zugewiesen. 9.3 Teilautomatisiert mit ArcGIS und FME In Coors et al. (2016) wird ein Workflow vorgestellt, um aus Basis-DLM und LiDAR- Daten teilautomatisiert 3D-Vegetationskörper zu erstellen. Dieser Workflow dient als Grundlage, um einen vollautomatisierten FME-Workflow zu erstellen. Die Bearbeitung findet zunächst mittels eines ModelBuilder-Prozesses statt (Abb. 46). Abb. 46: V.l.n.r: Model-Builder-Prozess, anschließend auszuführender FME-Workflow und Ergebnis-3D- Vegetationsobjekte (Coors et al. 2016) 75

76 Workflow für Windsimulation Darin werden das DOM und das DGM subtrahiert, um die Höhen der Vegetationsobjekte zu berechnen. Dann werden diese Rasterdatensätze durch die Gehölz- und Waldflächen aus dem Basis-DLM ausgeschnitten. Somit sind nur noch die relevanten Flächen im Raster der Höhendifferenzwerte enthalten. Aus diesen werden wahlweise die maximalen oder mittleren Differenzwerte berechnet und den 2D-Flächen mit dem Werkzeug Oberflächeninformationen hinzufügen als neue Attribute hinzugefügt (Coors et al. 2016). In ArcScene werden die 2D-Datensätze in den Layer-Einstellungen auf die Basishöhe des DGMs gelegt und um die Attributwerte der im Model-Builder-Prozess hinzugefügten Höheninformation extrudiert. Dann werden die 3D-Objekte mit dem Werkzeug 3D- Layer in Feature-Class exportiert (Coors et al. 2016). Der anschließende FME-Prozess dient dazu, die CityGML-Geometrie als Solids festzulegen und die geeigneten Attribute zu erzeugen (Coors et al. 2016). Mit diesen Workflow werden für die Testgebiete Niedernhall und Stöckach die Vegetationsgeometrien erzeugt und mit der 3DCityDB gegen die Plant-Cover-Objekte des 3dfier ausgetauscht (Kap ). Für Stöckach kommen die 2D-Flächen nicht aus dem Basis-DLM, sondern werden aus dem Baumkataster abgeleitet (s. Kap ), da das Basis-DLM in Stöckach keine Vegetationsflächen aufweist. Da die oberen und unteren Abschlussflächen nicht planar sind, eignen sich diese Vegetationskörper nur zur Visualisierung, nicht zur Simulation. Damit noch vor der Erstellung der automatischen FME-Prozesse erste Tests mit der CFD-Windsimulation durchgeführt werden können, wird der Workflow etwas abgeändert. Abb. 47: Baumstandorte aus dem Baumkataster in Stuttgart- Stöckach ( Baumkataster und LoD2-Gebäude: Stadt Stuttgart, Basis-DLM: LGL) 76

77 Workflow für Windsimulation Aus den Baumstandorten (Abb. 47) und dem Orthophoto werden zunächst in ArcMap manuell Vegetationsflächen erstellt. Mit diesen Flächen und dem oben beschriebenen Workflow werden 3D-Vegetationskörper erstellt. Dabei wird in ArcScene die Einstellung getroffen, die obere Abschlusshöhe als planare Fläche auf die maximale Höhe innerhalb des Baumbestandes festzulegen. Diese Geometrien werden über den FZK- Viewer ins STEP-Format exportiert und in der Windsimulation verwendet. Im Folgenden werden diese Geometrien als von Hand erstellte bezeichnet. Ihre Eignung für die Windsimulation wird in Kap bewertet. 9.4 Automatisiert mit FME Die weiteren Bemühungen zielen darauf ab, den Automatisierungsgrad bei der Erstellung der Vegetationskörper zu erhöhen. Der bisher gefundene Prozess lässt sich zusammenfassend in vier Schritte gliedern: 1. 2D-Flächen: Aus Baumkataster und Orthophoto von Hand zu erstellen oder Fläche aus Basis-DLM/OSM verwenden 2. 3D-Extrudierung: Teilautomatisiert mit Model-Builder-Prozess und mit ArcScene durchzuführen 3. Erzeugung CityGML-Solid-Geometrien: Automatisierter FME-Prozess 4. Konvertierung ins STEP-Format Da die Schritte drei und vier bereits automatisiert ablaufen, finden die Änderungen an den ersten beiden Prozessschritten statt. Die Erstellung und Optimierung der Workflows erfolgt in einem iterativen Prozess. Dabei werden die Ergebnisse mehrmals zur Begutachtung und Bewertung durch Fr. Deininger vorgelegt, um die optimale Eignung für die Windsimulation zu gewährleisten. Vor der Abgabe der Geometrien an Fr. Deininger erfolgt jeweils ein Test mit ANSYS Discovery Live Student, durch welchen bereits einige Probleme erkannt und behoben werden können. Da in der Geometrie-Optimierung sowie dem abhängig von der Fragestellung optimalen CFD-Setup aktuell [Stand Juli 2018] noch viel Grundlagenforschung stattfindet (Deininger 2018), können nicht alle erzeugten Geometrien sofort durch Fr. Deininger getestet werden. Um dies zu berücksichtigen, werden 2D-Flächen in zwei verschiedenen Detailierungsstufen und Höheninformationen mit drei verschiedenen Höhen angeboten: Maximale Höhe innerhalb eines Baumbestandes Mittlere Höhe eines Baumbestandes Maximale Höhe innerhalb einer 10x10 m-kachel. Die 2D-Flächen in unterschiedlichen Genauigkeiten und die drei Höhenstufen lassen sich beliebig kombinieren, sodass insgesamt sechs verschiedenen Repräsentationen der Waldobjekte erzeugt werden können (bei Verwendung von Basis-DLM- oder OSM- 77

78 Workflow für Windsimulation Flächen drei). Die Ergebnisse werden künftig im Rahmen des i_city-projekts weiter untersucht und validiert D-Flächen aus Baumkataster Es werden zwei Workflows anhand des Testgebiets Stuttgart entwickelt, um aus den Baumkatasterstandorten mittels eines FME-Prozesses Vegetationsflächen abzuleiten, welche als Eingangsdatensatz für den nächsten Schritt, die 3D-Extrusion dienen. Ein Workflow erzeugt stark vereinfachte Geometrien ( LoD1 ), die im Wesentlichen den von Hand erzeugten Flächen entsprechen. Der andere Workflow erzeugt detailliertere Geometrien ( LoD2 ), welche zu einem späteren Zeitpunkt für die Windsimulation getestet werden können. Zwar ist laut Löwner et al. (2014), von diesen nach Benner et al. (2013) die Definition unterschiedlicher Level of Detail nur in den CityGML-Objektklassen Building, Bridge und Tunnel sinnvoll, da nur hier ausreichend unterschiedliche Modellierungsformen notwendig und sinnvoll sind. Zu Vereinfachung wird hier dennoch von LoD1 und Lod2- Geometrien im Zusammenhang mit PlantCover-Objekten gesprochen. Für die spezielle Anwendung der Windsimulation bietet sich die Nutzung unterschiedlicher LoDs auch für Vegetationsobjekte an. So können unterschiedlich genaue Modellierungen unterschieden und auf ihre Eignung in der CFD-Simulation getestet werden. Im LoD1-Workflow werden die Baumkatasterpunkte zunächst an der im Creator eingestellten Gebietsgrenze ausgeschnitten (Abb. 48 u. Abb. 49). Abb. 48: Arbeitsschritte des Workflows zur Erstellung von LoD1 -Vegetationsflächen am Beispiel mittlerer Schlossgarten in Stuttgart. Links: Gepuferte und zusammengefügte Punkte. Mitte: Ersetzung durch äußere Hülle. Rechts: Endgültige Flächen (lila Flächen ) und ursprüngliche Baumstandorte (Punkte) ( Baumkataster: Stadt Stuttgart) 78

79 Workflow für Windsimulation Abb. 49: LoD1 -FME-Workflow zur Ableitung von Vegetationsflächen aus dem Baumkataster Dann werden alle Punkte kreisförmig gepuffert und nahe beieinander liegende Flächen zusammengeführt. Sich überlappende Flächen werden aufgelöst, sich berührende Geometrien zusammengefasst. Dann werden Kleinflächen ausgefiltert. Im nächsten Schritt werden die Geometrien durch eine vereinfachende äußere Hülle ersetzt und neu entstehende Überlappungen bereinigt. Mit dem SpikeRemover werden spitze Winkel in den Flächen entfernt. Da sich hierbei die Fläche mancher Objekte ändert, wird nochmals nach Kleinflächen gefiltert. Da sich durch das Herausnehmen spitzer Winkel die Geometrie geändert hat, werden die Verarbeitungsschritte mit dem Ersetzen der Geometrie durch die äußere Hülle wiederholt. Abschließend wird die endgültige Fläche berechnet, diese als Attribut den Objekten hinzugefügt und jeder Baumbestand erhält eine OBJID. Beim LoD2-Workflow werden die Flächen wesentlich weniger stark generalisiert. Die Flächen sind wesentlich realistischer, aber auch deutlich komplexer als beim LoD1- Workflow (Abb. 50 u. Abb. 51). Abb. 50: LoD2-FME-Workflow zur Ableitung von Vegetationsflächen aus dem Baumkataster 79

80 Workflow für Windsimulation Abb. 51: Arbeitsschritte des Workflows PktTo2DVegLoD2 am Beispiel mittlerer Schlossgarten in Stuttgart. Links: Flächen nach Pufferung, Zusammenfassung und Filterung von Kleinflächen. Mitte: Nach Generalisierung mit Thin no Point-Algorithmus. Rechts: Endgültige Flächen und ursprüngliche Baumstandorte (Punkte) ( Baumkataster: Stadt Stuttgart) Realisiert wird dies, indem anstatt die äußeren Hüllen der einzelnen Baumbestände zu bilden, die Flächen lediglich mit einem Generalizer mittels des Thin no point- Algorithmus generalisiert werden. Dieser entfernt Punkte aus dem Umring, welche weniger weit von einem benachbarten Punkt entfernt sind als die Toleranzgrenze (Safe Software 2017 b). So wird sichergestellt, dass die Geometrien nicht zu komplex und die resultierenden Luftraumzellen in der CFD-Simulation nicht zu klein sind. Mit dem SpikeRemover werden anschließend Winkel kleiner als 25 bereinigt. Im Gegensatz zum LoD1-Workflow ist der Kleinflächenfilter hier auf 400 m² anstatt 1000 m² eingestellt D-Extrusion Im FME-Workflow 2Dto3D-Shape werden die eingelesenen LiDAR-Punkte zunächst nach ihrer Klassifikation gesplittet und nur Vegetationspunkte weiterverarbeitet. Aus den Vegetationspunkten wird ein 10 m Vegetations-Raster erzeugt. Im RasterCellCoercer werden die einzelnen Rasterzellen zu Polygonen und auf die Höhe ihres Zellwerts angehoben (Abb. 52). Abb. 52: Links: Oberflächenraster aus Vegetationspunkten. Rechts: Vektorisiertes Raster mit 2D- Polygonen in der Höhe gemäß Rasterzellenwert ( Baumkataster: Stadt Stuttgart, LiDAR-Daten: LGL) 80

81 Workflow für Windsimulation Diese Polygone werden dann anhand der Vegetationsflächen ausgeschnitten. Hier können wahlweise LoD1 oder LoD2-Flächen als Eingangsdatensatz dienen. Mit dem ElevationExtraktor wird die Höhe jedes Polygons diesem als Attribut hinzugefügt. An dieser Stelle teilt sich der Workflow in drei verschiedene Möglichkeiten. In Variante eins - uneinheitliche Höhen, eine Höhe je 10 m-rasterzelle - wird jedes Polygon um seine Höhe nach unten extrudiert, sodass ein 3D-Körper entsteht, welcher von der Höhe null bis zur Höhe des Polygons ragt (Abb. 53). Abb. 53: Baumbestand mit gekachelter oberer Abschlussfläche je 10 x 10 m- Rasterzelle ( Baumkataster: Stadt Stuttgart, LiDAR-Daten: LGL) Abschließend wird die minimale und maximale Höhe extrahiert und als Attribut geschrieben. Die Rasterweite lässt sich bis auf 1 m reduzieren und bis zu einer gewissen Grenze auch erhöhen. Bei einer zu großen Rasterweite können den einzelnen Baumbeständen ihre jeweiligen Höhen nicht mehr zugeordnet werden. In Variante zwei - einheitliche Höhe, durchschnittliche Höhe je Baumbestand - wird die trianguliere Oberfläche aus dem Dissolver zunächst mit einem 2DForcer in eine 2D- Fläche transformiert. Da durch den Dissolver die mittlere Höhe jedes Baumbestandes als Attribut mitgegeben wird, können im nächsten Schritt die 2D-Flächen um die mittlere Höhe des Baumbestandes extrudiert werden. Es entstehen also 3D-Solids, die von der Höhe null bis zur mittleren Höhe innerhalb des Baumbestandes reichen. In Variante drei - einheitliche Höhe, maximale Höhe je Baumbestand - wird die im Dissolver erzeugte Liste aller Höhenwerte eines Baumbestandes genutzt, um die maximale Höhe des Baumbestandes zu extrahieren. Anschließend werden die 2D-Flächen um diese Höhen extrudiert. Die 3D-Solids reichen daher von der Höhe null bis zur maximalen Höhe innerhalb des Baumbestandes (Abb. 54). 81

82 Workflow für Windsimulation Abb. 54: Baumbestand mit maximaler Höhe innerhalb eines Baumbestandes ( Baumkataster: Stadt Stuttgart, LiDAR-Daten: LGL) Nach der 3D-Shape Erstellung wird mittels des Workflows 3DVegToCityGMLSolid die CityGML-Geometrie erzeugt. Dieser Workflow entspricht dem in Coors et al. (2016) vorgestellten FME-Workflow (Kap. 9.3). Die erzeugten CityGML-Solids werden mit dem FZK Viewer geöffnet und dann ins IFC- (Industry Foundation Classes)-Format exportiert. Nach dem Import der IFC-Datei lässt sich diese dann als STEP-Datei exportieren. Dabei ist darauf zu achten, dass die standardmäßig aktivierte Funktion Export Solids as Surface Geometry deaktiviert wird. Durch die Konvertierungsschritte wird die Datei in ein automatisch festgelegtes lokales Koordinatensystem überführt. Außerdem wird die Einheit von Meter in Millimeter geändert. Der FZK Viewer bietet keine Einstellungen, um dies zu ändern. In ANSYS Academic ist deshalb beim Import der Skalierungsfaktor 1000 zu wählen. Die untere Abschlussfläche der Objekte wird auf die Höhe null gesetzt. Die lagemäßige Einpassung erfolgt manuell mit einem mitgelieferten Screenshot aus dem FZK-Viewer, welcher neben den erzeugten Vegetationsgeometrien auch die in der Simulation verwendeten Gebäude darstellt. Die Konvertierung kann für kleine Dateien (z.b. >10 MB) auch über kostenlos verfügbare Online-Converter erfolgen. Die Konvertierung mit dem Programm FreeCAD funktioniert nur für sehr kleine Dateien (> 2 MB) (Schneider o.d.). Die erzeugten STEP-Dateien können mit dem kostenlosen Programm STP-Viewer (Abb. 55) oder einem Texteditor betrachtet werden. 82

83 Workflow für Windsimulation Abb. 55: Erzeugte STEP-Datei Veg3D_MaxH mit den Vegetationskörpern im STP-Viewer ( Baumkataster: Stadt Stuttgart, LiDAR-Daten: LGL) Die Übertragung kann nicht über das OBJ-Format erfolgen, da dieses nur Flächen, keine Körper definiert (Heckner und Wirth 2014). 83

84 Evaluation der Ergebnisse 10 Evaluation der Ergebnisse In diesem Kapitel werden die erzeugten 3D-DLM auf ihre Eignung hin bewertet und miteinander verglichen. Hierbei ist es erforderlich, die unterschiedlichen Anwendungen der 3D-DLM zu berücksichtigen. Der Runder Tisch GIS e.v. trifft auf der 2018 die Aussage: Entscheidend ist, dass abhängig vom Anwendungszweck jeweils andere Ausprägungen und Inhalte der Daten erforderlich sind (Runder Tisch GIS e.v b). Diese Untersuchung kommt zu dem Schluss, das für die spezielle Anwendung der Windsimulation die Modellierung der Landschaftsobjekte, wie sie in 3dfier erzeugt wird, nicht geeignet ist. Die Geometrien erfüllen nicht die Anforderungen der Windsimulation. Für andere Anwendungen, z.b. der Visualisierung, ist die Modellierung geeigneter, wenn auch nicht optimal. Somit kann die Aussage des Runden Tisch GIS e.v. hinsichtlich der beiden Anwendungszwecke der Windsimulation und der Visualisierung bestätigt werden Qualitätsprüfung Nach dem Export aus der 3DCityDB werden die fertigen 3D-DLM visuell und mit der CityDoctor-Erweiterung geprüft Prüfung der 3D-DLM aus ATKIS- und Baumkatasterdaten Die CityDoctor-Erweiterung überprüft neben den Buildings auch die Objektklassen LandUse, WaterBodies, Bridges, Transportation und PlantCover. Sie sollte mit einer 64-bit-Version von Java betrieben werden, da dem Programm dann mehr Arbeitsspeicher zugewiesen werden kann, als dies bei der 32-bit (x86)-version der Fall ist. Bei zu geringem Arbeitsspeicher und zu großen Einzelobjekten wird das Programm mit einem Java Heap Space-Error beendet. Die Gesamtgroße der prüfbaren Datei ist nicht besonders relevant, da die einzelnen Objekte mit einer streaming-funktion nacheinander eingelesen und geprüft werden. Die einzige Begrenzung ist, dass der erzeugte PDF-Bericht nicht mehr als ca Seiten hat (Betz 2018). Die Einstellungen vor Programmstart erfolgen mit der testconfig.properties-datei. Diese wird per Texteditor bearbeitet und so u.a. Ein- und Ausgabedateiname sowie die durchzuführenden Prüfungen eingestellt. Bei der Prüfung des 3D-DLM Niedernhall bleibt das Programm bei der Prüfung eines Gebäudes in einer Endlosschleife stehen, wie auch das Healing Tool bei diesem Gebäude bereits stehen geblieben ist. Laut Aussage von Hr. Betz handelt es sich um einen Fehler im Programm, der noch behoben werden soll. 84

85 Evaluation der Ergebnisse Um das Modell dennoch prüfen zu können, wird mit der 3DCityDB ein Modell ohne Gebäude ausgegeben und dieses geprüft. Die Fehlerstatistik ist in Abb. 56 zu sehen. Abb. 56: Fehlerstatistik der CityDoctor-Erweiterung zum 3D-DLM Niedernhall Es ergibt sich, dass alle Vegetationsobjekte fehlerhaft sind, da sie eine nicht planare obere und untere Abschlussfläche besitzen. Dies resultiert daraus, dass alle Vegetationsobjekte für die Visualisierungs-3D-DLM in Niedernhall und Stöckach mit dem Workflow nach Coors et al (s. Kap. 9.3) erzeugt werden. Durch diesen Workflow werden Vegetations-Solids mit nicht planarer oberer und unterer Abschlussfläche erzeugt. Die Triangulierung der Flächen ist in diesem Workflow nicht vorgesehen, da der Fehler für die Visualisierung nicht weiter störend ist und die Triangulierung in FME nicht auf einfache Weise erzeugt werden kann. Beim Testgebiet Stuttgart-Stöckach löst jeweils einer der erzeugten Vegetationskörper, ein Gebäude und ein LandUse-Objekt eine Endlosschleife aus. Deshalb wird ein Datensatz nur mit den Brücken, Straßen, Wegen und Gewässern geprüft (siehe DVD). Resultat ist, das es sich bei vielen Fehlern um Fehler handelt, welche bereits in den 2D- Eingangsdaten durch die Verschneidungen entstehen. Die Versuche, diese Fehler in FME mit Transformern wie dem SliverRemover oder dem SpikeRemover zu beheben, führten jedoch zu einer Verschlimmbesserung, da so Lücken in der Tessellation erzeugt werden. Dadurch entstehen in den 3D-DLM Löcher und Artefakte, welche wesentlich schlimmer sind als die zu bereinigenden Fehler. Zum Vergleich: Die aus OSM-Daten erzeugten 3D-DLM können ohne Probleme geprüft werden (s. Kap ). Allerdings ist die Struktur der LGL-3D-DLM mit LoD2-Solid- Gebäuden und Vegetations-Solids auch deutlich komplexer als die der OSM-3D-DLM. 85

86 Evaluation der Ergebnisse Prüfung der 3D-DLM aus OSM-Daten Mit der CityDoctor Erweiterung werden die erzeugten 3D-DLM geprüft. Im Gegensatz zu den LGL-3D-DLM können alle Objekte geprüft werden, kein Objekt sorgt für Endlosschleifen im Programm. Allerdings ist die Struktur der Gebäude als LoD1-Solids und der Vegetationsobjekte als Multi-Surfaces wesentlich einfacher als bei den LGL-3D-DLM. Häufigste Fehler sind doppelte Punkte und Selbstüberschneidungen. Die Prüfberichte sind auf der DVD gespeichert, die Statistiken zur Fehlerverteilung nach Objektklassen in Abb. 57 ersichtlich. Auffallend ist, dass fast alle Gebäude korrekt modelliert sind. Bei den Brücken, welche in der Tessellation nicht mit anderen Flächen verschnitten werden, ergeben sich ebenfalls sehr wenige Fehler. Abb. 57: Fehlerstatistiken aus den Prüfberichten der CityDoctor-Erweiterung für die 3D-DLM Niederhall OSM (links) und Stuttgart OSM (rechts) Visuelle Betrachtung der 3D-DLM aus ATKIS-/Baumkatasterdaten Bei der visuellen Betrachtung können einige Aussagen zur Anfälligkeit des 3dfier für Fehler bei bestimmten Eingangsdaten gemacht werden, welche in allen Testgebieten und bei allen Datensätzen (LGL und OSM) auftreten. Gründe, weshalb Lücken im 3D-DLM auftreten sind: Ungünstige Vermaschungen (langgezogene Dreiecke) am Rand von Objekten (z.b. zwischen Terrain und Gebäuden). Gründe für Artefakte sind: Zu kleine Flächen, denen zu wenige Punkte für eine Höhenberechnung zugeordnet werden können. Überlappungen zwischen Flächen oder fehlende Punkte in der Punktwolke (unter Brücken, Vegetation). Kleinflächen in Straßen und Wegen sind nicht so fehleranfällig wie Kleinflächen bei linienhaften Gewässern (Bächen und Gräben). Es entstehen wesentlich weniger Löcher und Artefakte. 86

87 Evaluation der Ergebnisse Im FZK Viewer In Abb. 58 ist die Gesamtansicht des 3D-DLM Stuttgart-Stöckach zu sehen. Die Objektarten PlantCover und Buildings (Vegetation und Gebäude) des 3dfier sind durch andere PlantCover-Objekte bzw. durch die LoD2-Gebäudemodelle der Stadt Stuttgart ersetzt. Abb. 58: 3D-DLM Stuttgart-Stöckach. Wald und Gebäude nicht aus 3dfier ( Basis-DLM und LiDAR-Daten: LGL, Baumkataster und LoD2-Gebäude: Stadt Stuttgart) Aufgrund der im Testgebiet Stöckach eingesetzten Tessellations-Variante, die Objekte mit gleicher OBJID zusammenzufassen (Kap , Abschnitt Gewässer), werden die Straßen-, Wege- und Gewässerflächen zusammengefasst. Durch die gewählte runde Linienende-Pufferung ergeben sich keine Lücken mehr zwischen den einzelnen Straßenabschnitten. Durch die Wahl der Variante, Gebäudeflächen aus dem Terrain auszuschneiden, ergeben sich mehr Artefakte an schmalen Terrain-Elementen neben Gebäuden. Dafür werden Garagen am Hang nicht mehr durch das Terrain überdeckt (Abb. 59). Abb. 59: Links: Zusammengefasste Straßenelemente; größere Artefakte neben Gebäuden aufgrund der Freistellung. Rechts: Garagen in stark geneigtem Gelände werden aufgrund der Freistellung im Gelände nicht mehr durch Terrain überdeckt. Testgebiet Stuttgart ( Basis-DLM und LiDAR-Daten: LGL, Baumkataster und LoD2-Gebäude: Stadt Stuttgart) 87

88 Evaluation der Ergebnisse Unterhalb von Brücken kommt es aufgrund der fehlenden Punktwolkeninformation zu Lücken. Linienhafte Gewässer sind bis auf kleine Löcher neben den Gewässern weitestgehend korrekt, da in Stuttart keine steilen Gewässer vorhanden sind (Abb. 60). Abb. 60: Links: Fehlende Punktwolkeninformationen unter Brücke und Vegetation. Rechts: Nur kleine Lücken neben linienhaften Gewässern.Testgebiet Stuttgart ( Basis-DLM und LiDAR-Daten: LGL, Baumkataster und LoD2-Gebäude: Stadt Stuttgart) Im Bereich der Neckarbrücke ergeben sich große Artefakte, da die Punktwolkeninformationen fehlen. Da die Brücken alle mit einheitlicher Breite gepuffert werden, die Straßen aber mit unterschiedlicher Breite je Straßenkategorie, kann es trotz der Tatsache, dass die Straßen extra unter den Brücken mitgeführt werden dazu kommen, dass Vegetationselemente die Brücken durchdringen (Abb. 61). Abb. 61: Links: Fehlende Punktwolkeninformation unter Brücke führt zu Artefakten. Rechts: Vegetationskörper ragen in Brückenfläche hinein. Testgebiet Stuttgart ( Basis-DLM und LiDAR-Daten: LGL, Baumkataster und LoD2-Gebäude: Stadt Stuttgart) Dies würde sich ändern, wenn anstatt der Straße unter den Brücken Terrainelemente erzeugt würden. Allerdings würden große Brücken über bewaldeten Tälern dann darunter befindliche Wälder im 3D-DLM verdrängen. Abb. 62 zeigt das 3D-DLM Niedernhall aus Basis-DLM und LiDAR-Daten. Auch hier wurden die entsprechenden 3dfier Objekte durch die in einem separaten Workflow erzeugten Vegetationskörper und die LoD2-Gebäudemodelle des LGL ersetzt. 88

89 Evaluation der Ergebnisse Abb. 62: 3D-DLM aus Basis-DLM und LiDAR-Daten, Wald und Gebäude nicht aus 3dfier. Testgebiet Niederhall ( LGL) Ein kleines Loch unter der Brücke (im Gelände) entsteht aufgrund der dort fehlenden Punktdaten. Durch die gewählte Variante der Tessellation, Objekte gleicher OBJID nicht zusammenzufassen und durch die starken Neigungen im Gelände entstehen nur geringe Differenzen in der Höhenlage zwischen eigentlich ineinander mündenden linienhafte Gewässern. Bei einer Zusammenfassung der Gewässerelemente mit gleicher OBJID ergeben sich sehr viel größere Höhendifferenzen. Dies hat hoch aufgewölbte bzw. noch tiefer eingeschnittene linienhafte Gewässer zur Folge (Abb. 63 oben). Abb. 63: Gewählte Tessellations-Variante führt zu wenigen Fehlern (oben links). Andere Varianten führen zu stark aufgewölbten linienhaften Gewässern (o.r.), zu Artefakten neben Gebäuden (u.l., Gebäude ausgeblendet) und zu fehlerhaften Vermaschungen neben Gebäuden (u.r., Gebäude ausgeblendet). Testgebiet Niedernhall ( LGL) 89

90 Evaluation der Ergebnisse Im gesamten Modell ist nur ein kleines Artefakt enthalten. Dafür verschwinden kleine Gebäude (Garagen) an steilen Hängen z.t. unter dem Gelände, da die Tessellations- Variante gewählt wurde, die Gebäude nicht freizustellen. Werden die Gebäude vom Gelände ausgeschnitten, ergeben sich deutlich mehr Artefakte direkt neben den Gebäuden. Diese entstehen aufgrund schmaler Vermaschungen, für welche zu wenige Punkte mit Höheninformationen zur Verfügung stehen. Außerdem treten grob fehlerhafte Vermaschungen auf, auch wenn eigentlich keine Ursache dafür auszumachen ist (Abb. 63 unten rechts, Gebäude sind ausgeblendet). Webanwendung Niedernhall Das 3D-DLM Niedernhall wird in die Webanwendung zum SmartCity-Projekt übernommen. Der Import erfolgt durch Fr. Blessing beim LGL über den virtualcitypublisher. Dieser ermöglicht es, Standardfarben für die Objektklassen festzulegen, sodass in den CityGML-Dokumenten kein Appearance-Modul notwendig ist (Abb. 64). Außerdem kann das 3D-DLM mit einem Höhenoffset versehen werden. Abb. 64: Ansicht aus der Webanwendung Niedernhall mit texturierten Gebäuden und 3D-DLM ( LGL) Durch Klick auf die 3D-DLM-Objekte erhält der Anwender die Attribute zu diesem angezeigt (Abb. 65). Die Verwendung des DGMs mit einem Höhenoffset eignet sich insbesondere, wenn das 3D-DLM gemeinsam mit dem DGM 2 m betrachtet werden soll. Das DGM 2 m kann aber auch ausgeblendet werden, um das 3D-DLM in Originalhöhe ohne Überlappungen zu betrachten. Für die Überlappungen gibt es verschiedene Ursachen. 90

91 Evaluation der Ergebnisse Abb. 65: Screenshots aus der Webanwendung Niedernhall mit eingeblendetem 3D-DLM und Objektinfo zu einem Straßenobjekt ( LGL) Das DGM stammt aus den Jahren , während die LiDAR-Daten aus dem Jahr 2017 stammen. In den mehr als zehn Jahren dazwischen haben sich natürliche und künstliche Änderungen der Erdoberfläche ergeben. Als künstliche Änderung kann z.b. die Anlegung eines Retentionsbeckens aufgeführt werden (Abb. 66). Abb. 66: Differenzen zwischen 3D-DLM aus LiDAR-Daten und DGM 2 m ( LGL) Andere Überlagerungen ergeben sich aufgrund der Generalisierung des Basis-DLMs z.b. bei Straßen und Wegen an steilen Hängen. Diese werden in 3dfier bei der Vermaschung anders berücksichtigt als das umliegende Gelände. Im 2 m-dgm sind keine derartigen Bruchkanten enthalten. Durch Aktivierung des Inhalts Info 3D-Landschaftsmodell erscheint ein Info-Button über der Altstadt von Niedernhall. Wird dieser betätigt, öffnet sich ein Infofenster mit 91

92 Evaluation der Ergebnisse einem Link zu einer Beschreibung der Masterarbeit und des 3D-DLM (Abb. 67), sowie einem kurzen Video zur Windsimulation (Abb. 68). Abb. 67: Infobox zum 3D-DLM mit Video zur Windsimulation ( LGL) Info und Video geben dem Anwender einen Einblick in eine weitere Anwendungsmöglichkeit von 3D-DLM. Es wird verdeutlicht, dass neben der Visualisierung auch Simulationen mit diesen Daten durchgeführt werden können. Die Windsimulation wurde mit der Software ANSYS Discovery Live Student erzeugt und mit dem Free Screen Video Recorder aufgezeichnet. Abb. 68: Info zur Masterarbeit, zum 3D-DLM und zur Windsimulation ( LGL) 92

93 Evaluation der Ergebnisse Visuelle Betrachtung 3D-DLM aus OSM-Daten In Stuttgart fehlen große Flächen der Vegetation, insbesondere im Schlosspark. Die wenigen vorhandenen Vegetationsobjekte durchdringen die Brücken, da Straßen nicht unter Brückenflächen verlaufen. Dies könnte geändert werden, zum Vergleich mit den Abb. 69: Screenshots aus dem 3D-DLM Stuttgart aus OSM-Daten. Links: Vegetationsobjekte durchdringen Brücke. Rechts: Zahlreiche, z.t. sehr große Artefakte ( LiDAR-Daten LGL, OSM-Daten: ODbL, Geofabrik-Daten: CC BY-SA 2.0) LGL Daten aber so belassen. Insgesamt enthält das 3D-DLM viele, zum Teil sehr große Artefakte (Abb. 69). Straßen welche in Tunnel führen werden zur Oberkante des Berges, durch welche der Tunnel führt, hochgezogen. Linienhafte Gewässer sind in Ordnung, da relativ flach. Es treten nur kleine Löcher neben diesen auf, keine Artefakte (Abb. 70 links). Die größten Probleme treten im Bereich der Neckarbrücke auf. Diese ist in OSM ungünstig modelliert. Anstatt flächenhaft werden nur die linienhaften Straßenbrücken berücksichtigt, die Schienenbrücken gar nicht. Aufgrund fehlender Punkte unter der Brücke kommt es zu sehr großen Löchern (Abb. 70 rechts). Abb. 70: Links: Linienhafte Gewässer in flachem Gelände korrekt modelliert, Straßen am Tunneleingang nach oben gezogen. Rechts: Ungünstig modellierte König-Karls-Brücke und große Artefakte im Bereich der Brücke ( LiDAR-Daten LGL, OSM-Daten: ODbL, Geofabrik-Daten: CC BY-SA 2.0) Flächenhafte Brücken sind in einen extra Layer ausgelagert, bei welchem die Zuordnung, ob es sich um eine Straßen-, Schienen-, oder Gewässerbrücke handelt, nicht möglich ist. Gleichzeitig sind aber auch alle linienhaften Straßenabschnitten mit einem entsprechenden Attribut versehen. Hier wären weitere Optimierungen in der Tessellation notwendig, um anstelle der linienhaften die flächenhaften Brückenbereiche zu berücksichtigten. 93

94 Evaluation der Ergebnisse Die Garagen im Hang sind in OSM nicht modelliert, nur die eigentlichen Gebäude. Abgesehen von kleinen Löchern zwischen Gebäuden und Terrain sind diese weitestgehend korrekt modelliert, auch wenn es negative Ausnahmen gibt (Abb. 71). Abb. 71: Links: Garagen in OSM nicht vorhanden. Rechts: Neben langestreckten schmalen Anlagen entstehen Artefakte im Terrain ( LiDAR-Daten LGL, OSM-Daten: ODbL, Geofabrik-Daten: CC BY-SA 2.0) Gleise und Hauptbahnhof sind sehr gut modelliert, jedoch treten wieder sehr große Artefakte zwischen den langestreckten, schmalen Gleisobjekten auf. Im Testgebiet Niedernhall treten drei Artefakte nach unten auf. Außerdem ergeben sich drei nach oben unmittelbar neben Gebäuden und Straßen, zwischen welchen ein schmales Terrain-Objekt liegt, sowie weitere unmittelbar neben Seen und linienhaften Gewässern. Kleine Fehler in der Tessellation können zu großen Artefakten führen. Diese Fehler entstehen bei der Verschneidung der Flächen (Abb. 72). Abb. 72: Kleine Fehler in der Tessellation (links) können zu großen Fehlern im 3D-DLM (rechts) führen. ( LiDAR-Daten LGL, OSM-Daten: ODbL, Geofabrik-Daten: CC BY-SA 2.0) 94

95 Evaluation der Ergebnisse 10.2 Eignung der 3D-DLM aus 3dfier für die Visualisierung In Tab. 5 sind die aus Basis-DLM und aus OSM-Daten erzeugten 3D-DLM jeweils für die beiden Testgebiete anhand eines Punktesystems bewertet. Punkte werden vergeben für die Anzahl und Größe der auftretenden Artefakte, die Homogenität des Gesamtmodells und die Übereinstimmung mit dem Luftbild bzw. die Plausibilität der modellierten Objekte. Außerdem wird die Korrektheit der Modellierung einzelner Objektarten bewertet. Da in Niedernhall die Objektklasse Gleise nicht vorhanden ist, können hier maximal 92 anstatt 100 Punkte erreicht werden. Anhand des Punkteschemas können folgende Schlüsse gezogen werden: 3dfier liefert für weniger komplexe Regionen mit weniger unterschiedlichen Objektklassen, geringerer Objektdichte, geringerer Geländeneigung und weniger Sonderobjekten (z.b. Schleusen) bessere Ergebnisse. Durch die Ergänzung der LiDAR-Punkte mit Punkten aus hochaufgelösten DGMs kann das resultierende 3D-DLM deutlich verbessert werden. Wenn dies nicht erfolgt, muss mit Artefakten und fehlerhaften Vermaschungen insbesondere unter Brücken gerechnet werden. Die Daten des amtlichen Basis-DLMs sind besser als die OSM-Daten zur Generierung eines allgemeinen 3D-DLM geeignet, da die Datenstruktur- und modellierung einheitlicher ist. Dass die Datenstruktur nicht einheitlich definiert ist, trägt auch dazu bei, dass Tab. 5: Bewertung der 3D-DLM aus Basis-DLM und OSM-Daten 95

96 Evaluation der Ergebnisse durch unterschiedliche Nutzer ähnliche Objekte verschieden modelliert werden, was es erschwert, ein homogenes 3D-DLM zu erstellen. Fehlerhaft modellierte oder positionierte Objekte in OSM gehend direkt in das 3D-DLM ein. Ein Beispiel für einen fehlerhaft positionierten Weg ist in Abb. 73 zu sehen. Abb. 73: Beispiel für einen in den OSM-Daten ca. 9 m falsch positionierten Weg (rosa) im Vergleich zu Luftbild und ATKIS-Basis-DLM ( LiDAR und Basis-DLM-Daten: LGL, OSM-Daten: ODbL, Geofabrik-Daten: CC BY-SA 2.0) Des Weiteren müssen spezielle in den OSM verwendete Zeichen, welche nicht UTF-8- konform sind oder Einfluss auf die CityGML-Struktur nehmen, in einem zusätzlichen Bearbeitungsschritt ausgetauscht werden. Die Korrektheit der Modellierung der einzelnen Objektarten wurde bereits in den Kap und behandelt. Zusammenfassend lässt sich sagen, das in den Ausgangsdaten flächenhafte vorliegende Brücken beim derzeitigen Stand der Tessellations- Workflows aus den Basis-DLM-Daten besser modelliert werden, ursprünglich linienhafte Straßenbrücken besser aus den OSM-Daten. Straßen und Wege enthalten in OSM mehr semantische Information, sind aber z.t. falsch kartiert. Fehlerhafte OSM-Daten treten vor allem in Gebieten mit wenigen OSM-Nutzern auf. Linienhafte Gewässer in OSM müssen manuell um unterirische Leitungen gefiltert werden, wie auch bei den Basis-DLM-Daten stehen keine Informationen zur Gewässerbreite zur Verfügung. In Stuttgart-Stöckach weist das Basis-DLM keinen Wald aus. In OpenStreetMap sind die Vegetationsbereiche in diesem Testgebiet nur sehr unvollständig modelliert. Gleise sind in OSM zwar eindeutiger modelliert, da jeder Schienenstrang als eine Linie modelliert ist, jedoch sorgen die vielen eng nebeneinanderliegenden lang gestreckten Objekte in den 3D-DLM aus 3dfier für große Artefakte. 96

97 Evaluation der Ergebnisse 10.3 Eignung der 3D-DLM aus 3dfier für die Windsimulation Eignung für ANSYS Discovery Live Student Wird in 3dfier die Ausgabe auf das Format OBJ umgestellt, können die generierten 3D- DLM direkt in ANSYS Discovery Live Student (s. Kap ) importiert werden. Beim Import werden alle Flächen zu einer facettierten Oberfläche zusammengefügt. Zur Simulation ist die Größe des Strömungskanals, die Windrichtung und -geschwindigkeit einzustellen. Dann erzeugt der Solver innerhalb weniger Sekunden eine Lösung. Bei dieser Lösung bleiben jedoch alle Lücken im Modell sowie alle, im Verhältnis zum vier Quadratkilometer großen Gelände, kleinen Objekte wie Gebäude und Wälder unberücksichtigt (Abb. 74). Daran ändert sich auch nichts, wenn die Vegetationsobjekte gegen anderweitig erzeugte Solid-Vegetationskörper ausgetauscht werden. Ein Video zu einer solchen Simulation ist in der Webanwendung Niedernhall zu sehen. Abb. 74: Windsimulation in ANSYS Discovery Live Student mit 3D-DLM aus 3dfier Als Einschränkung der Studentenversion können aus ANSYS Discovery Live Student keine Daten exportiert werden (ANSYS 2018). Eine Visualisierung der Simulationsergebnisse ist in einer Webanwendung ist hiermit also nicht möglich. Aufgrund dessen und der nur ungenauen Simulation ist das Programm somit nicht geeignet, die wissenschaftlichen Fragestellungen des i_city-projekts zu lösen. Im Folgenden wird daher nur noch auf die Eignung für CFD-Simulationen in ANSYS Academic eingegangen. 97

98 Evaluation der Ergebnisse Eignung für ANSYS Academic Die von 3dfier erzeugten PlantCover-Objekte eignen sich nicht die CFD-Windsimulation mit ANSYS Academic. Sie erfüllen nicht die in Kap definierten Anforderungen. Bei den erzeugten Objekten handelt es sich um Multisurfaces- bzw. durch Flächen beschriebene Geometrien anstatt der benötigten Solid-Volumenkörper. Die Form der Geometrie mit extrem vielen kleinen, spitzwinkligen Dreiecken ist für die CFD- Simulation ungeeignet (Abb. 75). Abb. 75: Durch 3dfier erzeugte PlantCover-Geometrien im Testgebiet Niedernhall ( LGL) In Tests konnten die erzeugten Geometrien, ins STL oder STEP-Format konvertiert, nicht oder nur mit sehr langen Ladezeiten in ANSYS Academic importiert werden. Die Weiterverarbeitung ist nicht möglich, da es sich nicht um Volumenkörper handelt und durch ANSYS keine gebildet werden können. Das von 3dfier erzeugte Terrain kann grundsätzlich für die Simulation verwendet werden, da Terrain-Elemente in ANSYS keine Volumenkörper sein müssen. Grundsätzlich eignen sich auch die durch 3dfier erzeugten LoD1-Solids für die Windsimulation. Dies ist jedoch nur für Gebiete hilfreich, bei denen Laserscandaten, aber keine Gebäudemodelle und keine DGMs zur Verfügung stehen. Auf die Möglichkeit, mit 3dfier für künftige Gebiete der Windsimulation 3D-DLM zu erzeugen, wird in Kap. 11 eingegangen. Die praktisch zu lösende Aufgabe, die Erstellung von geeigneten Vegetationsgeometrien für das Testgebiet Stöckach, kann also mit den Standardeinstellungen im 3dfier nicht erreicht werden. Neben der ungeeigneten Modellierung durch 3dfier kommt erschwerend hinzu, dass das Basis-DLM im Testgebiet Stöckach keine Wald- oder Gehölzflächen aufweist. 98

99 Evaluation der Ergebnisse Da mit dem Baumkataster allerdings ein 2D-Datensatz mit Baumstandorten zur Verfügung steht, aus welchem Vegetationsflächen abgeleitet werden können (Kap. 9) wird zunächst geprüft, ob durch geänderte Einstellungen im 3dfier geeignete Geometrien erzeugt werden können. Die mit 3dfier erzeugten 3D-DLM eignen sich zur Windsimulation, wenn als 2D- Eingangsdaten nur Gebäudeumringe und Terrainflächen, als 3D-Eingangsdaten nur Gebäude- und Bodenpunkte verwendet werden. Da in Baden-Württemberg allerdings LoD1/LoD2-Gebäudemodelle und DGM flächendeckend zur Verfügung stehen, ist die Erstellung mit 3dfier nicht mehr notwendig. Die Vegetationsobjekte des 3dfier sind für die Windsimulation in ANSYS Academic nicht geeignet. Als Eingangsdaten für die Modellierung von Vegetationskörper mittels automatisierter FME-Prozesse sind die folgenden Datensätze wie folgt geeignet: Testgebiet Stöckach o Basis-DLM: Völlig ungeeignet, keine Vegetationsflächen vorhanden o OSM: Ungeeignet, Vegetationsflächen zum Großteil nicht vorhanden o Baumkataster: Geeignet, 2D-Flächen generierbar Testgebiet Niedernhall o Basis-DLM und OSM-Daten geeignet (nur geringfügige Unterschiede in Waldflächen) o Baumkataster: nicht vorhanden Für die automatisierte Erzeugung sind zusätzlich zu den 2D-Daten die klassifizierten LiDAR-Punktwolkendaten erforderlich. Sind keine LiDAR-Daten vorhanden, besteht die Möglichkeit, die Vegetationsobjekte auf andere Weise zu extrudieren, z.b. mittels eines Attributs oder durch eine einheitliche Höhe. Da mit dem 3dfier kein einheitliches 3D-DLM erstellt werden kann, welches für die Windsimulation geeignet ist, wird im Kap. 11 ein Plan zur Erzeugung künftiger Testgebiete für die CFD-Windsimulation vorgestellt Eignung der Vegetationsgeometrien Alle erzeugten Geometrien werden durch Fr. Deininger betrachtet und auf ihre Eignung hin bewertet. Für die von Hand erstellten Flächen, welche auf die maximale Höhe innerhalb eines Baumbestandes extrudiert sind, wird zusätzlich ein erster Vergleichstest durchgeführt, welcher nachfolgend beschrieben wird. Weitere Tests, auch mit den automatisch erzeugten Geometrien, sind im Rahmen des i_city-projekts geplant. Die Ergebnisse der Simulation sollen auch mit gemessenen Geschwindigkeiten validiert werden. 99

100 Evaluation der Ergebnisse Eignung der manuell erzeugten Geometiren Um die Eignung der manuell erzeugten Geometrien (Kap. 9.3) zu demonstrieren und einen ersten Eindruck von ihrem Einfluss zu erhalten, werden durch Fr. Deininger zwei Testfälle angelegt: Einer mit und einer ohne die Vegetationskörper. Dabei handelt es sich, aus windsimulationstechnischen Gründen, noch um eine sehr vereinfachte Modellierung des Windes und der Geometrie mit einigen Gebäudeblöcken von Stuttgart-Stöckach. Es handelt sich um ein worst case -Szenario, da die Baumvolumen scharfkantig modelliert sind, der maximalen Höhe innerhalb eines Baumbestandes entsprechen und physikalisch wie eine Wand, also vollkommen luftundurchlässig, in die Simulation eingehen (Deininger 2018). Als Einlassrandbedingungen wird ein ABL (parabolisches Windprofil) mit 1.5 m/s auf 10 m Höhe verwendet. Die Windrichtung ist 190. Windrichtung und -geschwindigkeit sind typisch für Stuttgart nach Messungen an der Schwabengalerie und auf der HFT. Die Bodenrauhigkeit wird im gesamten Rechengebiet mit "Stadt/Wald" (Parameter: 0.7) approximiert (Deininger 2018). Erstes Ergebnis der Simulationen ist, dass es in verschiedenen Straßenzügen (roter und gelber Pfeil in Abb. 76, bei der Feinstaubmessstation und hinter dem Gebäude vor dem die Messstation steht) einerseits zur Erhöhung (Kanalwirkung durch Umlenkung des Windes in einen speziellen Straßenzug) und andererseits zur Verringerung der Geschwindigkeit (keine Kanalwirkung durch nicht vorhandene Bäume) kommt (Deininger 2018). Abb. 76: Erste Testsimulation rechts mit, links ohne die erzeugten Vegetationskörper. Angabe der berechneten Windgeschwindigkeiten an zwei ausgewählten Punkten (nach Deininger 2018, bearbeitet) ( Baumkataster und LoD1- Gebäudemodell: Stadt Stuttgart, LiDAR-Daten: LGL) An diesem Beispiel eines Windfeldes ist ein deutlicher Einfluss der Baumvolumen auf die Windgeschwindigkeit erkennbar, sodass weitere Forschungsarbeit zur optimalen Berücksichtigung der Bäume notwendig ist (Deininger 2018). 100

101 Evaluation der Ergebnisse Da an der Geometrie-Optimierung sowie dem abhängig von der Fragestellung optimalen CFD-Setup aktuell noch viel Grundlagenforschung stattfindet, ist dieses Simulationsergebnis als exemplarisch zu bewerten (Deininger 2018). Grundsätzlich ist zu erwarten, dass sich bei anderen Testgebieten mit weniger Vegetation oder bei exakterer Modellierung der Vegetationskörper ein anderer Einfluss auf die Windgeschwindigkeiten ergibt. Genauere Analysen von Fragestellung für das gewählte Gebiet werden im Laufe des i_city Projekts entstehen und, soweit möglich, validiert werden (Deininger 2018) Bewertung der automatisch erzeugten Geometrien Die automatisch erzeugten Geometrien wurden (Stand Juli 2018) noch nicht in der Windsimulation getestet. Es wurde bisher nur nachgewiesen, dass der Import in ANSYS funktioniert und die Objekte zur Modellierung des Luftraumvolumens eingesetzt werden können. In Abb. 77 ist dies beispielhaft mit einem Teil der LoD2-Vegetationskörper zu sehen. Abb. 77: Modellierung des Luftraumvolumens durch Subtraktion der LoD2- Vegetationskörper vom Gesamt-Luftraumvolumen (Deininger 2018) ( Baumkataster: Stadt Stuttgart, LiDAR-Daten: LGL) Im Rahmen des i_city-projekts werden weitere Untersuchungen mit diesen Geometrien stattfinden. Neben der Verwendung der unterschiedlichen automatisch erzeugten Geometrien sollen hier auch Tests durchgeführt werden, den Grad der Winddurchläs- 101

102 Evaluation der Ergebnisse sigkeit von Vegetationsobjekten mittels der Blattflächendichte (englisch Leaf area density, LAD) zu modellieren (Abb. 78). Diese ist u.a. abhängig von der Baumart und bei Laubbäumen auch von der Jahreszeit (IHCP o.d.). Abb. 78: Berücksichtigung der Blattflächendichte (englisch Leaf area density, LAD) (IHCP o.d.) 102

103 Vorgehensweise zur Erzeugung künftiger 3D-DLM für Windsimulation 11 Vorgehensweise zur Erzeugung künftiger 3D-DLM für Windsimulation Für die Erstellung künftiger Modelle für die Windsimulation wird folgende Vorgehensweise vorgeschlagen (Abb. 79): Abb. 79: Workflow zur Erzeugung der benötigten Objekte für künftige Windsimulationsgebiete Gebäude in LoD1 wie bisher aus städtischen oder LGL-Datenbeständen. Vereinfachung von Hand oder mittels spezieller Algorithmen. Alternativ: Erzeugung LoD1-Modelle mit 3dfier als CityGML-Solids, Konvertierung ins STEP-Format Terrain: Digitale Geländemodelle aus Stadtmodellen oder DGM, vereinfacht mit speziellen Algorithmen. Alternativ: Tessellation nur mit Gebäudeumringen und Terrain. Verwendung des 3dfier mit hohem simplification-grad, Konvertierung des Terrains ins STL-Format Vegetationskörper: Werden in vier Schritten erzeugt: (1) 2D-Flächen wahlweise aus (a) Baumkataster: Workflow PktTo2DVegLoD1 oder PktTo2DVegLoD2 (b) Basis-DLM oder OSM-Daten: Übereinstimmung mit der Realität anhand von Luft- oder Satellitenbildern prüfen, insbesondere in urbanen Gebieten mit Parkanlagen. Ansonsten keine Bearbeitung notwendig 103

104 Vorgehensweise zur Erzeugung künftiger 3D-DLM für Windsimulation (2) 3D-Extrusion wahlweise (a) mit LiDAR-Daten über den Workflow 2Dto3DShape (b) über ein Attribut (c) manuell um einen einheitlichen Betrag (3) CityGML-Solid Geometrie: Workflow 3DVegToCityGMLSolid (4) Konvertierung nach STEP (a) FZK Viewer (Screenshot gemeinsam mit Gebäuden zur lagemäßigen Einpassung in ANSYS Academic) (b) Online Konverter (Datei <10 MB) (c) FreeCad (Datei <2 MB) (d) Künftig evtl. z.b. virtualcitysystems STEP exporter/virtualcitywarehouse CityGML converter (virtualcitysystems 2016) Import in ANSYS Academic und manuelle Einpassung: Untere Abschlussfläche auf Höhe null setzen. Lageeinpassung mit mitgeliefertem Screenshot der die 2D-Vegetationsflächen und die in der Simulation verwendeten Gebäudeumringe enthält. Rauhigkeitsflächen a) Manuell in ArcGIS aus Basis-DLM/OSM-Daten. Screenshot zur lagemäßigen Einpassung in ANSYS Academic. Konvertierung mit FME Quick Translator ins STL-Format. b) Manuelle Erstellung in ANSYS Academic nur anhand der Gebäude Diese vier Objektearten als Eingangsdaten der Windsimulation werden in vier verschiedenen Dateien abgegeben, damit sie separat bearbeitet werden können und ihre Bedeutung klar ist, d.h. z.b. unterschieden werden kann, ob es sich um Gebäude oder Vegetation handelt. 104

105 Zusammenfassung und Ausblick 12 Zusammenfassung und Ausblick 12.1 Zusammenfassung In der Untersuchung wurde festgestellt, dass die von 3dfier erzeugten Geometrien aufgrund der speziellen Anforderungen der Simulationssoftware nicht für die CFD- Windsimulation in ANSYS Academic geeignet sind. Für andere Anwendungen, z.b. der Visualisierung in der Webanwendung Niedernhall, sind die Geometrien geeignet, wenn auch nicht optimal. Hier besteht Bedarf an weiterer Optimierung des 3dfier (Brücken mit Neigung und Dicke, geeignetere Waldrepräsentation) und der Eingangsdaten (Straßen, Wege, Gleise, Gewässer, Brücken als nicht generalisierte Daten mit realen Breiten). Es wurde gezeigt, dass auch andere Datensätze (OpenStreetMap) für die Erzeugung von 3D-DLM eingesetzt oder ergänzend eingesetzt werden können (Baumkataster). Für diese Datensätze ist eine zusätzliche Vorverarbeitung notwendig, dann können im Wesentlichen dieselben Workflows verwendet werden. Die Anforderungen der CFD-Windsimulation an die Geometrie von Vegetationskörpern können mit selbst erstellten Geometrien erfüllt werden. Diese Geometrien können in FME-Prozessen automatisiert aus verschiedenen 2D-Datenquellen und LiDAR-Daten erzeugt werden. Hier ist zunächst keine weitere Optimierung mehr notwendig, die weiteren Untersuchungen zur CFD-Windsimulation im Rahmen des i_city-projekts sind abzuwarten. Für die Vegetationsobjekte beziehen sich diese Untersuchungen auf die Verwendung unterschiedlich genauer Geometrien und die Möglichkeit, einen gewissen Luftdurchdringungsgrad der Vegetationsobjekte mittels des LAD zu modellieren. Außerdem sollen die berechneten Windgeschwindigkeiten mit gemessenen Windgeschwindigkeiten validiert werden. Dann lässt sich auch eine Aussage darüber treffen, ob und wie stark die Vegetationsgeometrien zur Verbesserung der CFD- Windsimulation beitragen. Für künftige CFD-Windsimulationsgebiete kann der in Kap. 11 erstellte Vorschlag zur Erzeugung von Vegetationsgeometrien und Rauhigkeitsgrenzen, zusätzlich zu bereits bisher verwendeten Terrain- und Gebäudeobjekten eingesetzt werden. Für die Bedienung der FME-Workflows sind lediglich Grundkenntnisse in diesem Programm erforderlich. Es sind in FME nur die Eingabe- und Ausgabedateinamen, das Koordinatensystem und die Gebietsgrenze auszuwählen. Die zu Beginn der Untersuchung aufgestellte Hypothese, dass 3D-DLM automatisiert erzeugbar und für Windsimulationen nutzbar sind, muss wie folgt korrigiert werden: Für Anwendungen wie z.b. die Visualisierung lassen sich 3D-DLM mit FME und 3dfier hochgradig automatisiert aus verschiedenen Datensätzen erstellen. Die- 105

106 Zusammenfassung und Ausblick se beinhalten aber nicht alle Objekte aus dem Basis-DLM (z.b. Tunnel), bei der Modellierung der Objekte gibt es noch Optimierungsbedarf. Für die CFD-Windsimulation können keine geeigneten vollständigen 3D-DLM, aber die weiteren in der Windsimulation benötigten Objekte neben Gebäuden und Terrain (Vegetationskörper und Rauhigkeitsflächen) automatisiert bzw. teilautomatisiert erzeugt werden. Für die Hypothese der [für die Erstellung der 3D-DLM] zu erarbeiteten Workflow ist auf andere Gebiete (räumlich) und andere Datensätze (Datenstruktur) übertragbar gilt: Die Workflows sind räumlich übertragbar, nur bei besonderer Berücksichtigung von Einzelfällen, welche automatisiert abgefangen werden, gilt dies nicht mehr. Hier können verschiedene Varianten eines Tessellationsworkflows nützlich sein, um optimalere 3D-DLM zu erhalten. Die Workflows sind auf Datensätze mit anderen Datenstrukturen übertragbar, sofern diese gewisse Mindestanforderungen erfüllen (Kap. 8.1) 12.2 Ausblick Die Methoden um mit novafactory 3D-DLM zu erzeugen werden zum Vergleich der 3D-DLM aus dem 3dfier und der mit FME-Workflows erzeugten Vegetationsgeometrien genutzt. Da das Programm derzeit (Stand Juli 2018) an der HFT Stuttgart noch nicht einsatzbereit ist, kann die Betrachtung der Möglichkeiten nur theoretisch erfolgen. novafactory wird über eine Web-Oberfläche bedient, die dort ausgelösten Befehle werden auf einem Server ausgeführt. Die Speicherung der Daten erfolgt über ArcGIS- Server in einer relationalen SDE-Datenbank. CityGML-Dateien werden dagegen getrennt in einem eigenen relationalen Datenbankschema, der 3DCityDB (Kap ), gespeichert (M.O.S.S. 2017). Als wichtige Importformate für die Erstellung von 3D-DLM werden u.a. folgende Datenformate unterstützt: Shape, LAS, CityGML, XYZ (DGM-Punkte). Vor dem Import ist ein Produkt anzulegen (z.b. 3D-DLM) und diesem sind eine oder mehrere geeignete Ebenen hinzuzufügen. Als Ebenen für die 3D-DLM-Erstellung sind z.b. auch die Ergebnisse der Tessellation und die Gebäudemodelle des LGL oder einer Stadt, aber auch bisher unberücksichtigte Elemente denkbar: 3D-Modelle: Gebäude (CityGML) 2D-Tessellationsflächen: Wald, Straßen, Wege, Gleise, Gewässer, Brücke (Shape) Weitere Basis-DLM-Elemente: Leitung, Mast, Turm, Seilbahn, Tunnel, Durchlass (Shape) Digitales Geländemodell (XYZ) 106

107 Zusammenfassung und Ausblick LiDAR-Daten (LAS) Zur Definition des Koordinatensystems und des Blattschnitts ist dem Produkt zusätzlich eine Blatteinteilung zuzuordnen. Für die 3D-DLM könnte das Koordinatensystem ETRS89/UTM definiert und als Blattschnitt die Grenze des Testgebiets gewählt werden. Mit dem Modul 3D GDI können z.b. einem CityGML-Modell Geländemodelle hinzugefügt oder LoD2-Gebäude zu LoD1 generalisiert werden. Die eigentliche 3D-DLM- Erstellung findet mit Hilfe des Exportformats Feature3D statt. Hiermit können aus 2D bzw. 2,5D-Geometrien (2D-Daten mit Höheninformationen, z.b. DGM-Punkte oder 2D- Objekte mit Höhenattribut) 3D-Geometrien erzeugt werden (vergl. M.O.S.S. 2017). Je Vektorebene wird der Export über eine.to3d.xml-konfigurationsdatei gesteuert. Die einzelnen Modelle können wieder zu einem Gesamtmodell zusammengefügt werden. Zur 2D-3D-Anhebung besteht eine Vielzahl von Möglichkeiten. Generell können alle 2D Punkte, Linien oder Flächen auf das DGM projiziert werden. Dabei können verschiedene Einstellungen getroffen werden, wie die untere und obere Abschlussfläche modelliert werden soll. Für Vegetationsobjekte ist es z.b. möglich, die obere Abschlussfläche in einer konstanten Höhe über dem DGM verlaufen zu lassen (Abb. 80). Die Verwendung von LiDAR-Daten zur vollautomatisierten Bestimmung von Objekthöhen ist im derzeitigen Softwarezustand nicht vorgesehen (M.O.S.S. 2017). Abb. 80: Waldpolygone mit DGM verschnitten und um 25 m extrudiert (M.O.S.S. 2017, bearbeitet) 107