Civil Engineering Reference
In-Depth Information
Abb. 22.5
KML im Überblick
mit einem gobalen LookAt versehen, da sich die Position der gesamten Baustelle über
die Zeit nicht verändert. Jeder Baustellenzustand wird mit all seinen verschiedenen Pla-
cemarks in jeweils einem Folder Element untergebracht, dem wiederum ein Zeitstempel
gegeben wird. So muss ein Zeitstempel nur einmal pro Zustand definiert werden und ist
für alle Unterelemente gültig. In Abb.
22.5
ist das nach den Bedürfnissen unseres Modells
spezifizierte Gerüst des KML Dokuments nochmal verdeutlicht. Elemente mit dem In-
dex 1 müssen dabei genau einmal vorkommen, Elemente mit Index
+
müssen mindestens
einmal vorkommen und solche mit
∗
können beliebig oft oder gar nicht vorkommen.
22.4.3 Konzeptionelle Architektur
Für die Architektur eignet sich eine Client Server Architektur, bei der die Daten- und An-
wendungslogik im Server, die Präsentationslogik jedoch im Client abgewickelt wird. Die
Anwendungslogik im Server wird den Anforderungen entsprechend die zwei wesentlichen
Funktionen Speicherung und Einbettung und Visualisierung der Daten mit einem GIS be-
reitstellen. Der Workflow für letztere wurde bereits im vorherigen Abschnitt beschrieben.
Zur Speicherung können Planer über den Upload Screen einzelne MMC auf den Server
hochladen, die dort im Dateisystem gespeichert werden. Die Anwendungslogik wird nun
mittels eines Parsers die benötigten räumlichen und zeitlichen Baustelleninformationen
aus den MMCs extrahieren, prüfen und, falls diese den technischen Vorgaben entsprechen,
persistent in einer Datenbank speichern, andernfalls wird eine Fehlermeldung zurückge-
geben. Die Kommunikation mit der Datenbank wird über eine eigene Zugriffschicht reali-
siert, damit die zugrundeliegende Datenbasis flexibel ausgetauscht werden kann.
Jedes Bauprojekt, das in der Datenbank gespeichert wird, bekommt eine eigene ID
zugewiesen. Für die Visualisierung sendet der Server auf Anfrage des Clients, diesmal in
der Managerrolle, zunächst eine Liste aller in der Datenbank befindlichen Multimodelle
an diesen zurück. Aus den Baustellenmodellen wird eines ausgewählt und dessen ID an
den Server gesendet, damit dieser es in das GIS Plugin eingebettet wieder an den Client
zurücksendet, um es zu rendern. Der Ablauf aus Sicht der Managerrolle ist in Abb.
22.6
dargestellt.
Die Kommunikation zwischen Client und Server wird über eine REST Schnittstelle ab-
gewickelt. Der Client verwendet die http POST Methode zum Speichern eines MMCs und
die GET Methode zum Senden einer ID. Die Anfragen werden vom Server entgegenge-
nommen und an die Anwendungsschicht weitergegeben. Nach der serverseitigen Verarbei-
