Webbasierte 3D-Visualisierung städtebaulicher Planungen
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Fachbereich Architektur, Facility Management und
Geoinformation
Institut für Geoinformation und Vermessung
Webbasierte 3D-Visualisierung
städtebaulicher Planungen
Untersuchung aktueller Methoden
zur Visualisierung dreidimensionaler Daten im Internet
unter Berücksichtigung des Geodienstes 3D Portrayal Service
Masterarbeit
im onlinegestützten Fernstudiengang Geoinformationssysteme
zur Erlangung des akademischen Grades
Master of Engineering (M. Eng.)
Eingereicht von: Janine Pantzer (Dipl.-Ing.)
Geboren am: 25. Februar 1978
Erstprüfer: Prof. Dr.-Ing. Lothar Koppers, Hochschule Anhalt
Zweitprüfer: Prof. Dr.-Ing. Volker Coors, HFT Stuttgart
Düsseldorf, Mai 2018
Bibliographische Beschreibung
Pantzer, Janine: Webbasierte 3D-Visualisierung städtebaulicher Planungen - Untersuchung
aktueller Methoden zur Visualisierung dreidimensionaler Daten im Internet unter Berücksich-
tigung des Geodienstes 3D Portrayal Service
Hochschule Anhalt, Fachbereich Architektur, Facility Management und Geoinformation,
Institut für Geoinformation und Vermessung, Masterarbeit, Mai 2018
83 Seiten, 80 Abbildungen, 5 Anlagen
Abstract
Die webbasierte 3D-Visualisierung städtebaulicher Planungen gewinnt aufgrund steigender
Ansprüche in den Bereichen „Transparenz beim kommunalen Handeln“ und „Internetmobili-
tät“ immer mehr an Bedeutung. Das Ziel dieser Arbeit ist daher die Untersuchung aktueller
Methoden zur Visualisierung von 3D-Geländedaten, 3D-Gebäudedaten und 3D-Planungsda-
ten im Internet. Im theoretischen Teil dieser Arbeit erfolgt neben der Vorstellung der hierfür
notwendigen Datenformate b3DM, 3D Tiles und glTF die Erarbeitung verschiedener Visuali-
sierungskonzepte unter Einbeziehung des für 3D-Daten entwickelten Geodienstes 3DPS.
Durch den Aufbau mehrerer Testumgebungen und die Erzeugung von internetgeeigneten
Datensätzen mithilfe verschiedener Konverter werden im Anschluss die Konzepte in die Pra-
xis überführt. Den Abschluss dieser Arbeit bildet die Schritt-für-Schritt-Entwicklung einer We-
banwendung und die damit einhergehende visuelle Zusammenführung von 3D-Geländeda-
ten, 3D-Gebäudedaten und 3D-Planungsdaten im Internet.
I
Eidesstattliche Erklärung
Hiermit erkläre ich, dass die von mir eingereichte Masterarbeit selbstständig unter Benutzung
der angegebenen Literatur sowie Hinweisen der Betreuer angefertigt wurde.
Bezüglich der Masterarbeit wird der Hochschule Anhalt, insbesondere dem Institut für Geoin-
formation und Vermessung, sowie der Fakultät Vermessung, Informatik und Mathematik der
HFT Stuttgart ein einfaches Nutzungsrecht eingeräumt.
Düsseldorf, den 24. Mai 2018
____________________________________
Janine Pantzer
II
Danksagung
An dieser Stelle möchte ich mich bei all denen bedanken, die mir beim Entstehen dieser Arbeit
in vielfältiger Art und Weise Unterstützung entgegengebracht haben.
Ich danke meinen Gutachtern Herrn Prof. Dr.-Ing. Lothar Koppers von der Hochschule Anhalt
und Herrn Prof. Dr.-Ing. Volker Coors von der HFT Stuttgart für die hilfreiche Betreuung wäh-
rend der Anfertigungsphase dieser Masterarbeit.
Ein weiteres Dankeschön gilt Herrn M.Sc. Athanasios Koukofikis von der HFT Stuttgart und
Herrn M.Sc. Ralf Gutbell vom Frauenhofer-Institut für Graphische Datenverarbeitung IGD für
die aufgebrachte Hilfe und wichtigen Hinweise bei der technischen Umsetzung dieser Arbeit.
Zu guter Letzt möchte ich ein ganz großes Dankeschön an meine Familie und meine Freunde
aussprechen. Ohne ihren moralischen Beistand und ihre Unterstützung jeglicher Art hätte ich
diese Masterarbeit nicht erstellen können.
Gendererklärung
Aus Gründen der besseren Lesbarkeit wird in dieser Masterarbeit die Sprachform des generi-
schen Maskulinums angewendet (z.B. Nutzer). Es wird an dieser Stelle darauf hingewiesen,
dass die ausschließliche Verwendung der männlichen Form geschlechtsunabhängig verstan-
den werden soll.
III
Inhaltsverzeichnis
Bibliographische Beschreibung ...............................................................................................I
Abstract ...................................................................................................................................I
Eidesstattliche Erklärung ........................................................................................................II
Danksagung ..........................................................................................................................III
Gendererklärung ...................................................................................................................III
Inhaltsverzeichnis ................................................................................................................. IV
Abbildungsverzeichnis .......................................................................................................... VI
Abkürzungsverzeichnis ...................................................................................................... VIII
Einleitung ...............................................................................................................................1
Stand der Entwicklung und Wissenschaft ........................................................................4
3D-Webviewing ........................................................................................................4
1.1.1 Allgemein ..........................................................................................................4
1.1.2 Visualisierungsprozess .....................................................................................5
1.1.3 3D Portrayal Service .........................................................................................7
3D-Stadtmodelle ....................................................................................................10
3D Tiles ..................................................................................................................12
Geländedarstellung im virtuellen Globus ................................................................17
Web-Visualisierung von Planungsdaten .................................................................22
Konzept .........................................................................................................................24
Visualisierung von Geländedaten ...........................................................................24
Visualisierung von Bestandsdaten .........................................................................25
2.2.1 Variante 1: 3D Portrayal Service .....................................................................25
2.2.2 Variante 2: 3D Tiles.........................................................................................26
2.2.3 Variante 3: Kombination von 3D Portrayal Service und 3D Tiles .....................27
Visualisierung von Planungsdaten .........................................................................29
Evaluation .....................................................................................................................30
Geländedaten ........................................................................................................30
Bestandsdaten .......................................................................................................31
3.2.1 Variante 1: 3DPortrayal Service ......................................................................31
IV
3.2.2 Variante 2: 3D Tiles.........................................................................................36
3.2.3 Variante 3: Kombination von 3D Portrayal Service und 3D Tiles .....................42
3.2.4 Vergleich und Beurteilung der Varianten .........................................................44
Planungsdaten .......................................................................................................49
3.3.1 Modellierung ...................................................................................................49
3.3.2 Datenupload....................................................................................................51
3.3.3 Visualisierung ..................................................................................................51
Aufbau der Webanwendung ..........................................................................................54
HTML-Seite ............................................................................................................54
JavaScript-Datei .....................................................................................................55
Zusammenfassung ........................................................................................................64
Ausblick.........................................................................................................................67
Anlagen ................................................................................................................................68
Literaturverzeichnis
V
Abbildungsverzeichnis
Abb. 1: Visualisierungsprozess in drei Schritten .....................................................................5
Abb. 2: Client-Server-Architekturen beim Visualisierungsprozess ..........................................6
Abb. 3: Schnittstelle des 3D Portrayal Service als UML-Klassendiagramm ............................8
Abb. 4: Detaillierungsstufen (Level of Details) ......................................................................11
Abb. 5: Aufbau einer b3dm-Datei .........................................................................................12
Abb. 6: Beispiel des Abschnitts "properties" einer JSON-Datei.............................................13
Abb. 7: Aufbau des "root"-Abschnitts innerhalb der JSON-Datei ..........................................14
Abb. 8: Beispiel eines klassischen Quadtrees ......................................................................15
Abb. 9: Beispiel eines k-d-Baumes .......................................................................................15
Abb. 10: Beispiel eines Multi-way-k-d-Baumes mit n=4 ........................................................15
Abb. 11: Beispiel eines Octrees............................................................................................16
Abb. 12: Beispiel eines überlappenden Rasters ...................................................................16
Abb. 13: Quadtree eines hierarchischen LOD-Modells .........................................................17
Abb. 14: Geländedarstellung in unterschiedlichen LODs ......................................................18
Abb. 15: Geländebeschreibung als Raster (links) und TIN (rechts) ......................................18
Abb. 16: Darstellung der VertexData-Struktur.......................................................................19
Abb. 17: Repräsentation zweier Dreiecke im GeoJSON- und Quantized-mesh-1.0-Format..20
Abb. 18: exemplarische Übersicht der glTF-Verwendung .....................................................23
Abb. 19: Visualisierung von Geländedaten, schematische Darstellung.................................24
Abb. 20: Visualisierung von Bestandsdaten – Variante 1, schematische Darstellung ...........25
Abb. 21: Visualisierung von Bestandsdaten – Variante 2, schematische Darstellung ...........26
Abb. 22: Visualisierung von Bestandsdaten – Variante 3, schematische Darstellung ...........27
Abb. 23: Darstellung verschiedener BoundingBox-Abfragemöglichkeiten .............................28
Abb. 24: Visualisierung von Planungsdaten, schematische Darstellung ...............................29
Abb. 25: Geländedarstellung der Zugspitze ..........................................................................30
Abb. 26: Zugriff auf die PostGIS-DB mittels 3D City Database Importer/Exporter .................31
Abb. 27: Start der Serverumgebung .....................................................................................32
Abb. 28: Code zum Aufruf des Webviewers .........................................................................32
Abb. 29: Wiedergabebild beim Start der Webanwendung.....................................................33
Abb. 30: Code zum Button "Send Request", Schritt 1 ...........................................................33
Abb. 31: Code zum Button "Send Request", Schritt 2 ...........................................................34
Abb. 32: Code zum Button "Send Request", Schritt 3 ...........................................................34
Abb. 33: Visualisierung von Bestandsdaten .........................................................................35
Abb. 34: Gegenüberstellung: Anzahl der Gebäude - Dauer ..................................................35
Abb. 35: Datenstruktur der Geo-Toolbox ..............................................................................36
Abb. 36: Befehl zur Erstellung eines 3D Tilesets durch die Geo-Toolbox .............................36
VI
Abb. 37: Ergebnis des Konvertierungsprozesses mit der Geo-Toolbox ................................37
Abb. 38: Definition des Ein- bzw. Ausgangsdatensatzes ......................................................37
Abb. 39: FME - Konvertierungsprozess ................................................................................38
Abb. 40: Metadaten der FME-Tilesets ..................................................................................38
Abb. 41: Programmcode zum Aufruf des 3D Tilesets in einer Webanwendung ....................39
Abb. 42: Visualisierung des mit der Geo-Toolbox erzeugten Tilesets ...................................40
Abb. 43: Visualisierung des von VCS erstellten Tilesets .......................................................40
Abb. 44: Visualisierung eines mit der FME erstellten Tilesets nach einer Minute Ladezeit ...41
Abb. 45: Programmcode der Anfrage an den 3DPS-Dienst ..................................................42
Abb. 46: Antwort des 3DPS-Dienstes ...................................................................................43
Abb. 47: Aufruf zur Darstellung von 3D Tiles ........................................................................43
Abb. 48: Visualisierung von 3D Tiles durch eine 3DPS-Anfrage ...........................................43
Abb. 49: Absprünge von Usern im Web................................................................................44
Abb. 50: detaillierte Darstellung der Antwortzeit eines Downloaddienstes ............................45
Abb. 51: Analysemöglichkeit über die Browserkonsole .........................................................46
Abb. 52: Ladezeiten der Variante 2 ......................................................................................46
Abb. 53: Ladezeiten der Variante 3 ......................................................................................46
Abb. 54: Bewertung der Varianten........................................................................................48
Abb. 55: Darstellung eines Planungsdatensatz ....................................................................49
Abb. 56: Aufruf des glTF-Exporters in der Software SketchUp .............................................49
Abb. 57: COLLADA/obj to glTF – Konverter .........................................................................50
Abb. 58: Code zum Einfügen der Planungsdaten .................................................................52
Abb. 59: Darstellung der Planungsdaten aus dem „COLLADA/obj to glTF“-Konverter ..........52
Abb. 60: Darstellung der Planungsdaten aus SketchUp .......................................................53
Abb. 61: HTML-Seite der Webanwendung ...........................................................................54
Abb. 62: Darstellung beim Start der Webanwendung ...........................................................55
Abb. 63: Definition des Viewers ............................................................................................55
Abb. 64: Einblenden von 3D Tiles ........................................................................................56
Abb. 65: Deklaration globaler Variablen ...............................................................................57
Abb. 66: Event Handler Mouse_Move ..................................................................................57
Abb. 67: Ergebnis des Event Handlers Mouse_Move ...........................................................57
Abb. 68: EventHandler Left_Click .........................................................................................58
Abb. 69: Ergebnis des Event Handlers Left_Click ................................................................58
Abb. 70: Definition der Funktion info.....................................................................................59
Abb. 71: Anzeige von Gebäudeattributen .............................................................................59
Abb. 72: Definition der Funktion hide....................................................................................59
Abb. 73: ausgeblendetes Objekt...........................................................................................59
VII
Abb. 74: Definition der Funktion plan_a ................................................................................60
Abb. 75: Ergebnis der Funktion plan_a.................................................................................60
Abb. 76: Definition der Funktionen createModel und load ....................................................61
Abb. 77: Ergebnis der Funktion load ....................................................................................61
Abb. 78: Definition einer EventHandler-Kombination ............................................................62
Abb. 79: Ergebnis der EventHandler-Kombination ...............................................................62
Abb. 80: Definition der Funktion reset ..................................................................................63
Abkürzungsverzeichnis
3D dreidimensional
3DPS 3D Portrayal Service
API Application Programming Interface
b3DM Batch-3D-Modell
CAD Computer-Aided Design
CORS Cross-Origin Resource Sharing
FME Feature Manipulation Engine
glTF Graphics Libary Transmission Format
GML Geography Markup Language
HTML Hypertext Markup Language
HTTP Hypertext Transfer Protocol
JSON JavaScript Object Notation
LOD Level Of Detail
OGC Open Geospatial Consortium
OSM OpenStreetMap
PHP PHP: Hypertext Preprocessor
SIG3D Special Interest Group 3D
SOP Same-Origin-Policy
TMS Tile Map Service
URL Uniform Resource Locator
WebGL Web Graphics Library
WFS Web Feature Service
WMS Web Map Service
WMTS Web Map Tile Service
XML Extensible Markup Language
VIII
Einleitung
Einleitung
Städtebauliche Planungen und Architekturwettbewerbe sind gängige Hilfsmittel der Stadtpla-
nung, um eine nachhaltige städtebauliche Entwicklung der Städte und Gemeinden zu erzielen.
Bei diesen Verfahren werden mehrere Entwürfe der zukünftigen Bebauung vorgestellt und
hinsichtlich der sozialen, wirtschaftlichen und ökologischen Anforderungen, die an die Stadt-
planung gestellt werden, untersucht. Immer mehr Kommunen nutzen hierfür dreidimensionale
Entwürfe, sogenannte Planungsmodelle, um sie in die Bestandsdaten eines 3D-Stadtmodells
einzufügen. So können zum Beispiel Nachbarschafts-, Sichtbarkeits- und Verschattungsana-
lysen durchgeführt werden.
Ein weiterer Vorteil der Einbindung zukünftiger Planungsmodelle in ein 3D-Stadtmodell liegt in
der „neutralen“ Vergleichbarkeit der Modelle. Gerade bei Architekturwettbewerben sind neben
den technischen Unterlagen auch fotorealistische Bilder und 3D-Animationen der zukünftigen
Planung Bestandteil der Entwürfe. Hierbei handelt es sich meist um interaktionslose Hoch-
glanzprodukte, deren Aufgabe es ist, die Vorteile des Entwurfes „ins rechte Licht“ zu rücken
und durch gestalterische Effekte Emotionen beim Betrachter zu wecken. Eine sachliche und
fachliche Beurteilung des Entwurfes anhand dieser Bilder und Animationen wird damit er-
schwert. Wenn die Planungsmodelle jedoch in ein 3D-Stadtmodell eingebunden werden, ste-
hen Navigationsmöglichkeiten zur Verfügung, die es dem Betrachter erlauben, den Entwurf
aus jedem Blickwinkel zu betrachten, um auch mal „um die Ecken“ zu schauen. Zudem bleibt
bei dem Verzicht gestalterischer Effekte das Augenmerk auf dem Entwurf selbst, was einer
sachlichen Beurteilung dessen zugutekommt.
In der Gesellschaft erwächst immer mehr der Anspruch, dass kommunales Handeln bürger-
näher und transparenter wird. Daher gehen Kommunen zunehmend dazu über, die Meinungen
und Ideen der Bürger bei kommunalen Entscheidungsprozessen zu berücksichtigen. So auch
bei städtebaulichen Planungen und Wettbewerben, durch die frühzeitige Präsentation der Ent-
würfe. Damit die Bürger die Entscheidungen der Kommunen nachvollziehen und sich selbst
eine Meinung bilden können, ist es sinnvoll, ihnen die Planungsmodelle in der neutralen Um-
gebung eines 3D-Stadt- und Landschaftsmodells zu präsentieren. Die Internetmobilität ist ein
weiterer, stetig wachsender Anspruch der Gesellschaft. Daher stehen die Kommunen vor der
Herausforderung, die Planungsmodelle webbasiert, interaktiv und ohne Einschränkung von
Navigationsmöglichkeiten zu präsentieren. Diese beiden Ansprüche begründen die Motivation
dieser Arbeit.
Seite 1Einleitung
Die webbasierte Darstellung dreidimensionaler Daten ist in der Geschichte des Internets ein
noch recht junges Thema. Erst durch die technischen Entwicklungen der letzten Jahre ist es
möglich, 3D-Daten ohne zusätzliche Installation von Software-Erweiterungen, sogenannten
Plug-ins, im Internet zu präsentieren. Für die Realisation dessen werden zwei wesentliche
Bestandteile benötigt – eine Webanwendung, in der Interaktionen und das Navigieren möglich
sind, sowie visualisierbare Daten, die den Inhalt der Anwendung darstellen.
Die Programmierung von Webanwendungen erfolgt heutzutage oftmals durch die Einbettung
von JavaScript-Code in eine Webseite. Wenn der Nutzer diese HTML-Seite aufruft, dann wird
die JavaScript-Programmierung zum Browser gesendet und ausgeführt [Jav17]. Die Program-
miersprache selbst kennt keine 3D-Funktionalitäten. Erst mit der Einbindung spezieller Funk-
tionssammlungen, sogenannten Bibliotheken, wird die Programmierung von Webanwendun-
gen für dreidimensionale Daten mit JavaScript ermöglicht.
Als Dateninhalt werden im Fall des beschriebenen Szenarios zur webbasierten Präsentation
von Stadtplanungsentwürfen drei verschiedene Arten von Daten benötigt – 3D-Geländedaten,
3D-Gebäudedaten und 3D-Planungsdaten. Letztere werden von den Architekten selbst gelie-
fert oder können entsprechend der Entwurfsunterlagen modelliert werden. Die beiden zuerst
genannten Datentypen liegen den meisten großen Kommunen vor. Kleineren Kommunen feh-
len hingegen oft die finanziellen und personellen Ressourcen, um diese Daten vorzuhalten
und zu pflegen. Sie bedienen sich, wenn nötig, an den von den Landesbehörden zur Verfü-
gung gestellten Daten und Geodiensten.
Geodienste sind Webservices, die es ermöglichen, Geodaten zu nutzen, ohne diese selbst
vorhalten zu müssen. Die Dienste sind bei der datenhaltenden Stelle installiert, greifen auf die
Datenbestände zu und verteilen diese via Internet an die Nutzer [Geo18]. Ein Web Map Ser-
vice (WMS) für Luftbilder zum Beispiel liefert diese Daten in einem Rasterformat, die im Brow-
ser oder einer geodienstfähigen Software des Nutzers zur Anzeige gebracht werden. Der Web
Feature Service (WFS) hingegen liefert Raster- oder Vektordaten, zum Beispiel die der amtli-
chen Liegenschaftskarte, die für eine lokale Weiterverarbeitung auf dem Rechner gespeichert
werden können. Diese Dienste gelten jedoch nur für den 2D-Bereich. Für dreidimensionale
Daten wurde in jüngster Zeit der 3D Portrayal Service entwickelt. Dieser Dienst ermöglicht die
Darstellung und Weiterverarbeitung von dreidimensionalen Daten, wie zum Beispiel den Daten
eines 3D-Stadtmodells [Ope171]. Durch den Einsatz dieses Dienstes können auch Kommu-
nen, die keine eigenen 3D-Daten besitzen, diese benutzen und in einer Webanwendung in-
tegrieren.
Ganz gleich, ob ein Geodienst eingesetzt wird oder eigene 3D-Daten verwendet werden, die
webbasierte Visualisierung dreidimensionaler Daten erfordert spezielle Datenformate, wie
Seite 2Einleitung
zum Beispiel das „Batch-3D-Modell“-Format (b3DM) oder 3D Tiles. Die gängigen Datenhal-
tungsformate sind für Darstellungen im Internet nicht geeignet und müssen daher in die ent-
sprechenden Formate konvertiert werden.
Ausgehend von der Schilderung der verschiedenen Problematiken und Anforderungen hat
diese Arbeit die Beantwortung folgender Fragestellungen zum Ziel:
• Welche Datenformate sind für die webbasierte Darstellung dreidimensionaler Daten
erforderlich und wie erfolgt die Konvertierung in diese Formate?
• Wie erfolgt mit und ohne Unterstützung von Geodiensten die Einbindung dreidimensi-
onaler Daten in eine Webanwendung?
• Wie und mit welchen Bibliotheken ist eine Webanwendung, die die Visualisierung drei-
dimensionaler Daten im Fokus hat, zu programmieren?
Der Aufbau dieser Arbeit gestaltet sich folgendermaßen:
Das erste Kapitel widmet sich dem Stand der Entwicklung und Wissenschaft im Bereich 3D-
Webviewing. Hierbei wird zum einen der Visualisierungsprozess erklärt und auf den Geodienst
3D Portrayal Service eingegangen. Zum anderen werden die verschiedenen, zur webbasierten
Darstellung benötigten Daten und deren Formate vorgestellt.
Im Zuge dieser Arbeit wurden verschiedene Methoden und Varianten entwickelt, wie die tech-
nische Umsetzung erfolgen muss, um unterschiedliche dreidimensionale Daten im Internet zu
visualisieren. Die hierzu erstellten Konzepte werden im zweiten Kapitel vorgestellt und erläu-
tert.
Die praktische Umsetzung der Konzepte mithilfe verschiedener Softwareprodukte, Serverin-
stallationen und Testumgebungen erfolgt im dritten Kapitel durch die Darlegung der hierfür
notwendigen Arbeitsschritte und die Beurteilung der gewonnenen Ergebnisse.
Kapitel 4 widmet sich der Programmierung einer Webanwendung unter Verwendung von
HTML5, JavaScript und der 3D-Bibliothek Cesium. Verschiedene Funktionalitäten werden
hierbei anhand des Programmcodes vorgestellt.
Den Abschluss dieser Arbeit bilden die Zusammenfassung und der Ausblick.
Seite 3Stand der Entwicklung und Wissenschaft - 3D-Webviewing
Stand der Entwicklung und Wissenschaft
3D-Webviewing
1.1.1 Allgemein
Lange Zeit war die Visualisierung von 3D-Modellen im Webbrowser nur durch eine nachträg-
liche händische Installation von Software-Erweiterungen, sogenannten Plug-ins, wie zum Bei-
spiel dem Flash Player oder das Java-Plug-in, möglich. Erst die Entwicklung der Web Graphics
LibraryTM (WebGLTM) im Jahr 2011 durch die Khronos GroupTM bietet Möglichkeiten, rechen-
intensive Grafiken Plug-in-frei im Webbrowser darzustellen. WebGLTM ist eine 3D-Grafik-Pro-
grammierschnittstelle (engl. Abkürzung: API), die das 3D-Rendering im HTML-Zeichen-Ele-
ment „canvas“ per JavaScript ermöglicht [Khr17]. Daraufhin haben sich verschiedene Ja-
vaScript-Bibliotheken entwickelt, die die Darstellung von dreidimensionalen Daten unterstüt-
zen, wie zum Beispiel die Bibliotheken three.js und Babylon.js [Seg17].
Eine weitere browserbezogene Entwicklung auf Basis von WebGLTM stellen virtuelle Globen,
wie Cesium, WebGL Earth, OpenWebGlobe und OpenGlobus dar. Diese Globen ermöglichen
dem Nutzer, sich frei in einer virtuellen Umgebung zu bewegen, jeden beliebigen Punkt darauf
anzusteuern, den Blickwinkel zu ändern und über verschiedene Zoomstufen den Detailgrad
zu verändern. Im Vergleich mit realen Globen haben virtuelle Globen den Vorteil, dass sie viele
unterschiedliche Darstellungen der Erdoberfläche ermöglichen [Bal17].
Die Entwicklung der virtuellen Globen hat auch bei der webbasierten Visualisierung von 3D-
Stadt- und Landschaftsmodellen nicht Halt gemacht [Krä15]. Immer mehr Internetanwendun-
gen und Webviewer setzen die offenen und Plug-in-freien Globen ein. Zum Beispiel wird der
OpenWebGlobe [Fac17], der eine Entwicklung der Fachhochschule Nordwestschweiz ist, bei
der Stadt Stuttgart [Sta17] sowie beim Landesamt für Vermessung und Geobasisinformation
Rheinland-Pfalz [Lan17] eingesetzt.
Der derzeit verbreitetste virtuelle Globus ist Cesium [Ana17]. Das von Analytical Graphics, Inc.
und Bentley Systems gegründete Cesium Consortium hat es sich zur Aufgabe gemacht, „to
create the leading 3D globe and map for static and time-dynamic content, with the best pos-
sible performance, precision, visual quality, platform support, community, and ease of use“
[Ces17]. Als Beispiele für die Visualisierung von 3D-Stadtmodellen mit Cesium seien das flä-
chendeckende 3D-Gebäudemodell Nordrhein-Westfalens [vir17] und die 3D-Visualisierung
von New York City [Ces171] genannt.
Seite 4Stand der Entwicklung und Wissenschaft - 3D-Webviewing
1.1.2 Visualisierungsprozess
Um sich 3D-Stadtmodelle webbasiert betrachten zu können, muss der Nutzer (Client) heutzu-
tage lediglich einen entsprechenden Webviewer aufrufen. Das 3D-Modell wird ihm daraufhin
umgehend angezeigt. Diese Art der Präsentation scheint augenscheinlich nur ein Mausklick
zu sein. Jedoch handelt es sich hierbei um einen Visualisierungsprozess zwischen einem Ser-
ver und dem Client, der aus drei aufeinander aufbauenden Arbeitsschritten besteht, dem Fil-
tern, dem Mappen und dem abschließenden Rendern. (Abb. 1).
Abb. 1: Visualisierungsprozess in drei Schritten
Abbildung adaptiert von [Coo16]
Grundsätzlich ist davon auszugehen, dass die Rohdaten von einem Server abgerufen werden
und die Anzeige des Modells beim Client erfolgt. Im ersten Arbeitsschritt, dem Filtern, werden
die Daten ausgewählt, die später beim Client dargestellt werden sollen. Dies erfolgt durch die
Definition einer Bounding Box und der Angabe von Filterparametern. Im Anschluss erfolgt das
Mappen. Dieser Arbeitsschritt beinhaltet die Erstellung einer „Szene“ und deren Ausgabe in
ein für die Visualisierung optimiertes Datenformat. Als „Szene“ wird eine virtuelle Welt verstan-
den, die mit einer Theaterbühne verglichen werden kann. Neben den Akteuren, in dem Fall
den ausgewählten Daten, enthält eine Szene auch Informationen zu den Lichtquellen, der Po-
sition und Blickrichtung des Betrachters sowie zum Verhalten einzelner Objekte. In Abhängig-
keit zur Position des Betrachters können Objekte unterschiedlich abstrakt definiert werden. Je
weiter sich ein Objekt im Hintergrund der Szene befindet, desto kleiner wird es dargestellt und
desto weniger Details sollten zu seiner Beschreibung verwendet werden [Coo16]. Im letzten
Arbeitsschritt, dem Rendern, wird aus der dreidimensionalen Szene eine Rasterdatei erzeugt,
um diese letztendlich auf der zweidimensionalen Bildebene des Computerbildschirmes dar-
stellen zu können. Eine 3D-Grafik auf einem Bildschirm ist nur scheinbar dreidimensional. Tat-
sächlich ist die angezeigte Darstellung das Ergebnis einer zweidimensionalen Projektion einer
Szene auf den Computerbildschirm. Für diese Projektion gibt es verschiedene Verfahren, wel-
che insgesamt unter dem Begriff Rendering zusammengefasst werden [Pra13].
Seite 5Stand der Entwicklung und Wissenschaft - 3D-Webviewing
Grundsätzlich werden bei internetbasierten Anwendungen die durchzuführenden Arbeits-
schritte bzw. Aufgaben zwischen dem Server und dem Client verteilt. Je nach Anforderung
und Erfordernis sind verschiedene Verteilungen möglich und ergeben verschiedene Client-
Server-Architekturen.
Bezogen auf den Visualisierungsprozess von 3D-Daten sind drei Aufgabenteilungen zwischen
dem Server und dem Client möglich: die geodatenbasierte, die szenenbasierte und die bildba-
sierte Verteilung (Abb. 2).
Abb. 2: Client-Server-Architekturen beim Visualisierungsprozess
Abbildung adaptiert von [Coo16]
Bei der geodatenbasierten Verteilung werden alle Aufgaben bis auf das Filtern, welches
immer serverseitig erfolgt, an den Client übergeben. Die Datenübertragung der originären 3D-
Geodaten, zum Beispiel im CityGML-Format, erfolgt im Allgemeinen über einen Web Feature
Service (WFS) oder ein Downloadportal, wie z. B. das Portal Berlins [Ber17] oder das des
Freistaates Thüringen [Fre17]. Die Umwandlung der übersandten Daten in ein für die Visuali-
sierung geeignetes Format (Mappen) und das anschließende Rendern erfolgt clientseitig. Für
diese arbeitsintensiven Aufgaben bedarf es Endgeräte mit hoher Rechen- und Grafikleistung.
Daher eignet sich die geodatenbasierte Verteilung vorrangig, wenn die originären Daten beim
Client zur Analyse weiter genutzt werden [Coo16].
Eine ausgewogene Arbeitsteilung zwischen Server und Client liegt bei der szenenbasierten
Verteilung vor. Das Filtern und Mappen der Szene erfolgt serverseitig. Die Szene wird an-
schließend an den Client übertragen, der das Rendering übernimmt. Um eine performante
Visualisierung beim Client zu erzielen, bedarf es auch hierfür Endgeräte mit hoher Rechen-
und Grafikleistung.
Seite 6Stand der Entwicklung und Wissenschaft - 3D-Webviewing
Bei der bildbasierten Verteilung liegt eine Fat Server/Thin Client-Architektur zu Grunde. Die
Verarbeitung der 3D-Daten und das Rendering erfolgen vollständig serverseitig. Bei einem
optimal ausgestatteten Server lassen sich somit auch große 3D-Modelle in hoher Qualität per-
formant verarbeiten und rendern. Im Anschluss erfolgt die Datenübertragung an den Client.
Hierbei werden keine 3D-Daten, sondern die auf dem Server erzeugten Bilddaten gesandt.
Die Übertragung und die Visualisierung im Client hängen dadurch nicht mehr von der Komple-
xität der 3D-Daten ab, sondern im Wesentlichen von der Größe des übertragenen Bildes. Dies
ermöglicht die Visualisierung von qualitativ hochwertigen 3D-Darstellungen auch auf Client-
Geräten mit geringer Rechen- und Grafikleistung [Coo16].
Die szenen- bzw. bildbasierte Verteilung kann mit Hilfe des 3D Portrayal Services, einem Geo-
dienst zur Visualisierung von dreidimensionalen Daten, realisiert werden.
1.1.3 3D Portrayal Service
Der 3D Portrayal Service (3DPS) ist ein 3D-Darstellungsdienst und bildet die interoperable
Schnittstelle zur Darstellung von 3D-Daten. Mit diesem Dienst werden zum einen die Bereit-
stellung geometrischer Szenendaten (szenenbasierte Verteilung) und zum anderen das ser-
verseitige 3D-Szenen-Rendering (bildbasierte Verteilung) unterstützt. Der 3DPS selbst defi-
niert oder verlangt für die Übertragung der Daten keine bestimmten Formate. Durch diese
Nicht-Bindung ist der Service verschiedenartig einsetzbar und, im Hinblick auf zukünftige Ent-
wicklungen im Bereich des 3D-Webviewings, leicht anpassbar.
Die Entwicklung des 3DPS basiert auf verschiedenen vorangegangenen Entwürfen und Ent-
wicklungen. Mit ihm werden die wesentlichen Teile des szenenbasierten Web 3D Service
(W3DS) sowie des bildbasierten Web View Service (WVS) in einer gemeinsamen Schnittstelle
kombiniert. Am 08. Mai 2016 wurde der 3D Portrayal Service in der Version 1.0 vom Open
Geospatial Consortium (OGC) als Standard definiert1. Das Konsortium ist eine gemeinnützige
Organisation, die zum Zweck der Interoperabilität von Geodaten allgemeingültige Standards
festlegt.
Die 3DPS-Schnittstelle (Abb. 3) besitzt folgende Operatoren, die von einem Client aufgerufen
und vom 3DPS-Dienst ausgeführt werden können [Ope171]:
• GetCapabilities - Mit diesem Operator kann ein Client Informationen zu den angebote-
nen Funktionen des 3DPS-Servers und Szeneninformationen anfordern.
• AbstractGetPortrayal - Dies ist eine abstrakte Operation, die die Grundlage für die
3DPS-Operatoren GetScene und GetView bildet und gemeinsame Parameter bereit-
stellt.
1 Die Spezifikation ist unter http://www.opengeospatial.org/standards/3dp abrufbar.
Seite 7Stand der Entwicklung und Wissenschaft - 3D-Webviewing
• GetResourceById (optional) - Mit dieser Operation kann ein Client beliebige Ressour-
cen anfordern, die vom 3DPS angegeben werden.
• GetScene - Mit diesem Operator kann ein Client eine 3D-Szene abrufen, die mit 3D-
Geometrien und Texturdaten dargestellt wird und mittels eines Szenegraphs und / oder
eines räumlichen Indexes organisiert ist.
• GetView - Mit diesem Vorgang kann ein Client eine 3D-Ansicht einer Szene als Bild
abrufen.
• AbstractGetFeatureInfo - Dies ist eine abstrakte Operation, die die Basis für die Get-
FeatureInfo-Operatoren bildet, die es einem Client ermöglichen, mehr Informationen
über die angeforderten Features abzurufen.
• GetFeatureInfoByRay - Mit diesem Vorgang kann ein Client Informationen zu Features
abrufen, die mittels eines virtuellen Strahls ausgewählt wurden.
• GetFeatureInfoByPosition - Mit dieser Operation kann ein Client Informationen zu Fea-
tures abrufen, die basierend auf dem Standort ausgewählt wurden.
• GetFeatureInfoByObjectId - Mit diesem Vorgang kann ein Client Informationen zu Fea-
tures abrufen, die über Identifikatoren ausgewählt wurden.
Abb. 3: Schnittstelle des 3D Portrayal Service als UML-Klassendiagramm
Quelle: [Ope171]
Mit der für alle OGC WebServices verpflichtenden GetCapabilities-Anfrage wird nach den Fä-
higkeiten des 3DPS gefragt. Als Antwort wird ein XML-Dokument mit Metainformation an den
Client zurückgeschickt. In diesem Dokument finden sich zum Beispiel Angaben darüber, wel-
cher Visualisierungsansatz (bild- und/oder szenenbasiert) unterstützt wird, welche Art von Da-
Seite 8Stand der Entwicklung und Wissenschaft - 3D-Webviewing
ten auf dem Server bereitliegen, welche Koordinatensysteme unterstützt werden sowie in wel-
chen Formaten die Daten an den Client gesandt werden können. Durch diese Informationen
erfährt der Client, ob die angebotenen Daten in ihrer Ausprägung (Layer, LOD, Format, Visu-
alisierungsansatz, …) seinen Anforderungen genügen und ob die Daten clientseitig überhaupt
verarbeitet werden können. Letztlich kann aus den Informationen der GetCapabilities-Antwort
abgeleitet werden, wie die Anfrage an den Server zur Datenübermittlung erfolgen muss, um
beispielsweise nur einen Teildatensatz zu nutzen [Coo16].
Mit dem AbstractGetPortrayal-Operator wird spezifiziert, wie der Client Daten vom Server ab-
fragen kann. Die Anfragen zwischen dem szenenbasierten Ansatz und dem bildbasierten An-
satz unterscheiden sich nur im Detail. Viele Anfrageparameter sind in beiden Fällen gleich und
werden im AbstractGetPortrayal-Operator festgelegt. Die Operatoren GetScene und GetView
sind Spezialisierungen des AbstractGetPortrayal-Operators. Sie übernehmen die bei ihm fest-
gelegten Parameter und spezifizieren selbst nur noch jene Anfrageparameter, die ausschließ-
lich sie selbst benötigen.
Neben der visuellen Darstellung können dem Client durch verschiedene GetFeatureInfo-Ope-
ratoren weitere Informationen zu einem „Feature“ (engl. für Fachobjekt, Merkmal) interaktiv
zur Verfügung gestellt werden. Die Auswahl des Features erfolgt durch eine Interaktion, wie
beispielsweise ein Mausklick. Wie beim AbstractGetPortrayal-Operator werden auch im
AbstractGetFeatureInfo-Operator alle gemeinsamen Parameter spezifiziert. Wesentliches Un-
terscheidungsmerkmal der verschiedenen GetFeatureInfo-Varianten ist, wo berechnet wird,
welches Feature durch die Interaktion ausgewählt wurde. Bei dem GetFeatureInfoByRay-Ope-
rator geschieht dies serverseitig. Ein durch die Bildschirmposition und der virtuellen Kamera-
orientierung definierter Strahl wird hierfür an den Server gesendet, der dann ermittelt, welches
Feature als erstes von diesem Strahl getroffen wird. Auch beim GetFeatureInfoByPosition-
Operator erfolgt die Berechnung serverseitig. Clientseitig wird eine Koordinate bestimmt, zum
Beispiel durch die Bildschirmposition des Mauszeigers, und an den Server übergeben. Dort
erfolgt die Bestimmung des Features, dass sich an dieser Position befindet. Die serverseitige
Auswahl eines Features eignet sich hauptsächlich für den bildbasierten Ansatz, kann aber
auch beim szenenbasierten Ansatz genutzt werden. Clientseitig kann mit dem GetFeatureIn-
foByObjektId-Operator ein Feature durch Auswahl des Objekt Identifikators ausgewählt wer-
den [Coo16].
Die Einrichtung eines 3D Portrayal Services setzt nicht die Implementierung aller Operatoren
voraus. Es genügt, wenn zum Beispiel nur der bildbasierte Ansatz und eine der drei Feature-
Abfragen durch den 3DPS unterstützt werden. In der Spezifikation sind hierfür sogenannte
Konformitätsklassen definiert. Sie geben vor, welche Operator-Konstellationen bei der Imple-
mentierung des 3DPS gültig sind [Coo16].
Seite 9Stand der Entwicklung und Wissenschaft - 3D-Stadtmodelle
3D-Stadtmodelle
Die Entwicklung der 3D-Stadtmodelle begann in etwa zur Jahrtausendwende. Zu diesem Zeit-
punkt war die Computertechnik soweit ausgereift, dass die Modellierung und Visualisierung
der dritten Dimension möglich wurde. Es entstanden, explizit für bestimmte Einsatzgebiete
oder Infrastrukturen entwickelt, erste 3D-Anwendungen. Die Einbindung dieser Daten in an-
dere Softwareumgebungen war jedoch kaum möglich, da es an einheitlichen Austausch-
schnittstellen mangelte. Somit standen diese 3D-Modelle nur einem geringen Nutzerkreis zur
Verfügung.
2002 bildete sich die SIG3D, eine Gruppe Interessierter aus Wirtschaft, Wissenschaft und öf-
fentlicher Verwaltung, die es sich zur Aufgabe gemacht hat, ein Datenmodell zu schaffen, das
alle Kriterien einer Stadttopographie vereint und die Wiederverwendung der gleichen Daten in
verschiedenen Anwendungsbereichen ermöglicht. Dies war der Startschuss für die Entwick-
lung von CityGML, einem Anwendungsschema für die Geography Markup Language Version
3.1.1 (GML3), dem erweiterbaren internationalen Standard für den Geodatenaustausch, der
vom OGC und der ISO TC211 herausgegeben wurde. Hierbei handelt es sich um ein offenes
Datenmodell und XML-basiertes Format für die Speicherung und den Austausch von virtuellen
3D-Stadtmodellen. Es ermöglicht die Modellierung wesentlicher Stadt- und Landschaftsob-
jekte, hinsichtlich ihrer Geometrie, Topologie, Semantik und visuellen Erscheinung. CityGML
selbst ist seit 2008 ein Standard beim OGC. 2012 wurde die Version 2.0.0 verabschiedet
[Ope17].
CityGML beinhaltet ein Geometriemodell und ein thematisches Modell. Das Geometriemodell
ermöglicht die konsistente und homogene Definition von geometrischen und topologischen
Eigenschaften räumlicher Objekte in 3D-Stadtmodellen. Das thematische Modell von CityGML
verwendet das Geometriemodell für verschiedene Themenfelder wie Digitale Geländemodelle,
Standorte (z. B. Gebäude, Brücken und Tunnel), Vegetation, Landnutzung, Gewässer, Ver-
kehrsanlagen und Stadtmöbel. Darüber hinaus können Erweiterungen des CityGML-Daten-
modells für bestimmte Anwendungsbereiche mit den Application Domain Extensions (ADE)
realisiert werden [ZFV17].
CityGML unterscheidet fünf Detaillierungsstufen (engl. Level of Detail, LOD), die ein reales
Objekt annehmen kann. Mit zunehmender LOD-Stufe werden die geometrischen und thema-
tischen Ausprägungen detaillierter abgebildet (Abb. 4). Dadurch wird eine effiziente Visualisie-
rung und Datenanalyse von 3D-Stadtmodellen für unterschiedliche Anwendungsanforderun-
gen ermöglicht.
Seite 10Stand der Entwicklung und Wissenschaft - 3D-Stadtmodelle
Abb. 4: Detaillierungsstufen (Level of Details)
Quelle: [Bil17]
Die gröbste Detailstufe LOD0 ist im Wesentlichen ein digitales Geländemodell (DGM), auf das
ein Luftbild oder eine Karte projiziert werden kann. Gebäude werden im LOD0 durch zweidi-
mensionale Footprint- oder Dachkantenpolygone dargestellt. Objekte im LOD1 werden als
Block- oder Klötzchenmodell bezeichnet und durch prismatische Gebäude mit flachen Dach-
konstruktionen repräsentiert. Im Gegensatz dazu haben Gebäude im LOD2 generalisierte
Dachstrukturen und thematisch unterscheidbare Grenzflächen (roof-, wall-, groundsurface).
LOD3 kennzeichnet Architekturmodelle mit detaillierten Wand- und Dachstrukturen, die Tür-
und Fenstergeometrien beinhalten können. LOD4 vervollständigt ein LOD3-Modell durch Hin-
zufügen von innenliegenden Konstruktionen, wie Zimmer, Innentüren, Treppen und Möbel. In
allen LODs können Darstellungsinformationen, wie hochauflösende Texturen, auf die Struktu-
ren abgebildet werden [Bil13, S. 15].
Das hier beschriebene LOD-Konzept wurde in einer frühen Phase des heutigen CityGML-
Standards entwickelt, in der wenige Erfahrungen mit umfassenden Datensätzen und den An-
forderungen an ein umfassendes LOD-Konzept vorhanden waren. Dies ist der Grund, warum
das derzeitige LOD-Konzept Mängel aufweist [Löw14]. Bei der Neuauflage des CityGML-Stan-
dards in der Version 3.0 ist daher ein neues Konzept der Detaillierungsgrade in Vorbereitung.
Dieses ermöglicht etwa die Repräsentation von Innenraumelementen in allen Detailierungs-
stufen. Anwendungsfelder, wie die Innenraumnavigation oder auch die Annäherung an das
Building Information Modelling (BIM) werden dadurch ermöglicht. Die zweidimensionale Re-
präsentation des Innenraums ist zudem die Grundvoraussetzung für die Einführung eines
Stockwerkskonzepts in CityGML, eine Anforderung, die seit Längerem besteht. Die Neudefi-
nition des Konzeptes, das derzeit der OGC Standard Working Group zur Entscheidung vor-
liegt, erweitert das Anwendungsspektrum von CityGML gegenüber der jetzigen Version, ohne
die Bedürfnisse nach Rückwärtskompatibilität zu vernachlässigen [Löw17].
Durch Beschluss der Arbeitsgemeinschaft der Vermessungsverwaltungen (AdV) sind seit
2013 3D-Stadtmodelle im LOD1 bundesweit verfügbar. Der Detaillierungsgrad LOD2 befindet
sich im Aufbau und soll 2019 bundesweit erreicht sein [AdV16].
Seite 11Stand der Entwicklung und Wissenschaft - 3D Tiles
3D Tiles
Bei 3D-Stadtmodellen, Punktwolken, 3D-Vektordaten sowie dreidimensionalen Baummodel-
len handelt es sich um riesige heterogene 3D-Geodatensätze. Die hierbei verwendeten Da-
tenhaltungsformate sind für Webvisualisierungen jedoch nicht geeignet. Hingegen wird ein
Format benötigt, mit dem ein schnelles Streamen im Web möglich ist. Mit 3D Tiles wurde eine
auf Techniken aus der Grafikforschung sowie der Film- und Spieleindustrie basierende Open
source – Datenspezifikation entwickelt, die für 3D-Visualisierungen konzipiert und für schnel-
les Streamen und Rendern optimiert wurde [Ces15].
Das Format wurde von Analytical Graphics, Inc. (AGI) entwickelt und im August 2015 vorge-
stellt. Die Akzeptanz und Verwendung des Formats seitens der Anwender ist seit seiner Ein-
führung sehr groß. Um 3D Tiles trotz ihrer bisher kurzen Existenz als Standard-Format für die
Visualisierung massiver heterogener 3D-Geodaten festzuschreiben, wird derzeit ein OGC
Community Standard-Prozess durchgeführt [Ces174].
Ein 3D Tiles-Datensatz (engl. tileset) ist eine Gruppe von Kacheln im b3dm-Format, die in
einer räumlichen Datenstruktur organisiert ist. Die Dateierweiterung .b3Dm steht für „Batch-
3D-Modell“. Dieses Format ermöglicht eine Offline-Stapelverarbeitung heterogener 3D-Mo-
delle zum effizienten Streamen und Rendern. Weiterhin sind durch dieses Format Interaktio-
nen mit den 3D-Modellen möglich, wie zum Beispiel Verbergen und Einfärben einzelner Mo-
delle oder die Abfrage der Modelleigenschaften. Gemäß der 3D Tiles-Spezifikation werden die
in den Kacheln abgelegten 3D-Modelle als „Feature“ (engl. für Fachobjekt, Merkmal) bezeich-
net [Ces175].
Eine b3dm-Datei besteht aus zwei Abschnitten, dem Header und dem Body (Abb. 5).
Abb. 5: Aufbau einer b3dm-Datei
Quelle: [Ces175]
Seite 12Stand der Entwicklung und Wissenschaft - 3D Tiles
Im Header sind die Metadaten zur Datei, wie zum Beispiel die Version des Formates und An-
gaben zum Dateiinhalt, zu finden. Der Body enthält die 3D-Modelle im binären glTF-Format.
Dieses Format spielt nicht nur bei der Visualisierung von gekachelten Daten eine wesentliche
Rolle, sondern auch bei der Darstellung von Einzelmodellen, wie zum Beispiel Planungsdaten.
Daher wird im Abschnitt 1.5 Web-Visualisierung von Planungsdaten näher auf dieses Format
eingegangen. Neben den binären Modelldaten können weitere Informationen im Body abge-
legt werden. Im featureTable-Bereich werden Eigenschaften zur Position und zum Erschei-
nungsbild jedes Features beschrieben. Der batchTable-Bereich hingegen enthält die spezifi-
schen Attribute und Eigenschaften der 3D-Modelle, wie zum Beispiel die Gebäudehöhe, das
Baujahr und die GML-ID [Ces175].
Neben dieser Gruppe von b3dm-Dateien besitzt jedes Tileset eine Datei im JSON-Format,
mittels derer die 3D Tiles in Webanwendungen aufgerufen werden können. Die JSON-Datei
besteht aus den vier Abschnitten „asset“, „properties“, „geometricError“ und „root“. Der Ab-
schnitt „asset“ enthält Metadaten zum gesamten Datensatz, wie zum Beispiel die Versions-
nummer des 3D Tile-Formates. Im Abschnitt „geometricError“ ist eine nicht negative Zahl an-
gegeben. Dieser Wert definiert einen Fehler in der Einheit Meter, der eingeführt wird, um zur
Laufzeit den „screen space error“ (SSE) zu bestimmen. Der SSE beschreibt die Abweichung
von der Position des Betrachters zur Position der darzustellenden Kachel. Je nach Höhe der
Abweichung wird der 3D Tiles-Datensatz dargestellt oder nicht. Unter dem Abschnitt „proper-
ties“ sind alle Attribute und Eigenschaften der 3D-Modelle, die sich in den Kacheln befinden,
mit ihren minimalen und maximalen Ausdehnungen aufgelistet (Abb. 6).
Abb. 6: Beispiel des Abschnitts "properties" einer JSON-Datei
Seite 13Stand der Entwicklung und Wissenschaft - 3D Tiles
Im Abschnitt „root“ sind die Metadaten der einzelnen 3D-Kacheln in einer Baumstruktur, ent-
sprechend der Abb. 7, abgelegt.
Abb. 7: Aufbau des "root"-Abschnitts innerhalb der JSON-Datei
Quelle: [Ana18]
Der Abschnitt beginnt mit der Definition einer Hauptkachel, der sogenannten „root“-Kachel,
durch die Angabe eines umgrenzenden Volumens, gefolgt von der erneuten Angabe eines
geometrischen Fehlers. Hier bezieht sich der Wert aber auf die definierte Kachel und nicht auf
den kompletten Datensatz. Der Hauptkachel wird zudem in der Eigenschaft „refine“ mitgeteilt,
ob beim Hereinzoomen in eine Szene die Hauptkachel durch untergeordnete Kacheln ersetzt
werden soll oder ob letztere zusätzlich dargestellt werden. Im „content“-Abschnitt wird durch
die Angabe einer URL auf die b3dm-Datei verwiesen, in der sich die zu visualisierenden Geo-
metrien befinden. Durch die Angabe „children“ wird eine weitere Ebene der Baumstruktur ab-
gebildet, die wiederum die soeben beschriebenen Kacheldefinitionen enthält [Ana18].
Das Aussehen der Baumstruktur selbst ist abhängig von der jeweiligen Methode zur Erstellung
einer räumlichen Datenstruktur (engl. spatial index) [Sam90]. Neben dem Quadtree, der
gleichförmigen Unterteilung einer Kachel in vier untergeordnete Elemente (Abb. 8), sind k-d-
Bäume, Octrees oder Grids weitere Möglichkeiten einer räumlichen Datenstruktur.
Seite 14Stand der Entwicklung und Wissenschaft - 3D Tiles
Abb. 8: Beispiel eines klassischen Quadtrees
Quelle: [Ana18]
Ein k-d-Baum wird erstellt, wenn jede Kachel zwei untergeordnete Elemente hat, die durch
eine Teilungsebene parallel zur X-, Y- oder Z-Achse getrennt sind (Abb. 9).
Abb. 9: Beispiel eines k-d-Baumes
Quelle: [Ana18]
Hierbei muss keine einheitliche Unterteilung wie bei einem typischen 2D-Kachelschema ein-
gehalten werden. Dadurch wird ein ausgeglichenerer Baum für spärliche und nicht gleichmä-
ßig verteilte Datensätze erstellt. 3D-Kacheln hingegen ermöglichen sogar Variationen des k-
d-Baumes, indem an jedem Knoten mehrere Teilungen entlang einer Achse auftreten können.
Anstatt zwei untergeordneter Kacheln, können an diesen Multi-way-k-d-Bäumen n-Kacheln
erstellt werden (Abb. 10).
Abb. 10: Beispiel eines Multi-way-k-d-Baumes mit n=4
Quelle: [Gos12]
Seite 15Stand der Entwicklung und Wissenschaft - 3D Tiles
Die räumliche Baumstruktur des Octrees stellt eine Erweiterung des Quadtrees dar. Durch die
Verwendung von drei orthogonalen Teilungsebenen wird eine Kachel in acht untergeordnete
Kacheln unterteilt. Auch hier sind bei der Kachelung von 3D-Daten Variationen erlaubt, wie
eine ungleichmäßige Unterteilung, enge Begrenzungsvolumina und überlappende Kacheln
(Abb. 11).
Abb. 11: Beispiel eines Octrees
Quelle: [Ana18]
Eine weitere räumliche Datenstruktur, die bei der Erstellung von 3D Tilesets möglich ist, sind
einheitliche, nicht einheitliche und überlappende Raster (Abb. 12).
Abb. 12: Beispiel eines überlappenden Rasters
Quelle: [Ana18]
Seite 16Sie können auch lesen
