Harbour2025
Ein Projekt aus dem Master Informatik - vertrauenswürdige Systeme, Hochschule Bremerhaven, Wintersemester 2025/2026.
Geleitet von Prof. Dr.-Ing. Oliver Radfelder mit dem Projektteam:
Jonas Behling • Fode Abass Camara • Kajiman Chongbang • Zidane Kenfack Fouape • Domenic Graca • Johannes Heidtmann • Lesly Matchio Kuete • Vanelle Happi • Henrik Mittelhäußer • Levi Range • Philipp Schur • Lennart Steffen
Masterprojekt
Das Projekt Harbour2025 entstand im Rahmen des Masterprojekts im Studiengang Vertrauenswürdige Systeme und bietet eine interaktive 3D- Kartenanwendung die es ermöglicht, Bremerhaven gemeinsam und synchron im Web zu erkunden. Interaktionen wie das Verschieben, Zoomen und Fokussieren der Kartenansicht werden in Echtzeit zwischen mehreren Teilnehmenden geteilt, sodass alle dieselbe Perspektive auf die Stadt erleben. Ergänzend bieten "Points of Interest (POIs)" anklickbare Orte mit zusätzlichen Informationen, wodurch Harbour2025 als Plattform für digitale Stadtführungen, Storytelling und weitere Anwendungsszenarien dient.
Ideenfindung und Entscheidungsprozess
Auslöser und Rahmen
Der Ausgangspunkt unseres Masterprojekts war ein früher Austaush zwischen Oliver in der Projektleitung und dem DSM (Deutsches Schifffahrtsmuseum), von dem er uns im Vorlauf zum Projekt berichtet hat. Wir wollten diese Idee bewusst weitertragen und im Rahmen des Masterprojekts in eine umsetzbare Lösung überführen. In dem Gespräch wurde ein Vorhaben skizziert, welches realisiert werden sollte. Eine Webanwendung, mit der Interessierte Bremerhaven schon vor einem Besuch gemeinsam entdecken können, um Ausflüge zu planen, Orte vorab zu erkunden und sich einen Überblick zu verschaffen. Diese gemeinsame Entdeckung sollte über virtuelle Räume möglich werden, in denen die Stadt nicht nur beschrieben, sondern erlebbar wird.
Wichtig war von Beginn an der Gedanke des gemeinsamen Erkundens im Sinne eines Co Browsing. Das gemeinsame Erleben entsteht dabei nicht nur durch den gleichzeitigen Zugriff, sondern insbesondere durch eine Echtzeitkartensynchronisation. Nutzende können sich gegenseitig folgen und live die Kartenbewegungen der anderen sehen, wodurch sich das Erkunden wie eine gemeinsame Führung anfühlt. Technisch war der Rahmen klar. Eine Single Page Anwendung mit einem kartenbasierten Zugang als zentralem Interface. Dazu der Anspruch, nach einem Open Source Ansatz zu entwickeln, damit das Ergebnis transparent, nachnutzbar und erweiterbar bleibt.
Die erste Idee
Unsere erste Vision trug den Namen hARbour2025. Das AR stand bewusst im Fokus, weil Augmented Reality zunächst als zentrales Element gedacht war. Die Idee dahinter war, die Karte in 3D abzubilden und für Bremerhaven Points of Interest festzulegen, die bei Interaktion ein AR Erlebnis ermöglichen. Der Reiz lag in der Vorstellung, dass das gemeinsame Erkunden nicht nur informativ ist, sondern an ausgewählten Stellen einen zusätzlichen Erlebniswert bekommt.
Die Sackgasse
Sehr früh holte uns die technische Realität ein. AR im Web ist plattformübergreifend stark eingeschränkt. Während sich AR Ansätze im Browser auf Android eher praktikabel darstellen, ist die Umsetzung auf iOS deutlich limitiert. Alternative Wege hätten uns entweder in Richtung proprietärer Abhängigkeiten oder in Richtung einer anderen Projektlogik gedrängt, die nicht mehr zu unserem Open Source Anspruch und zur niedrigschwelligen Web Zugänglichkeit gepasst hätte. Damit war klar, dass AR als tragendes Element für unser Projekt nicht mehr realistisch ist.
Der Kurswechsel
Der Wendepunkt war nicht das Ende der Vision, sondern ihre Neuinterpretation. Wir konzentrieren uns seitdem vollständig auf die 3D Kartendarstellung, auf die fachlichen Inhalte der Points of Interest und auf eine stabile Performance, damit viele Nutzende gleichzeitig die Anwendung verwenden können. Das Ziel des gemeinsamen Erkundens blieb erhalten, nur der Weg dorthin wurde robuster und besser umsetzbar.
Ideenpool 2.0
Mit dem neuen Fokus wurde unser Ideenpool konkreter und pragmatischer. Für die 3D Darstellung wollten wir unbedingt mit öffentlich zugänglichen Daten arbeiten. In diesem Kontext haben wir uns mit Level of Detail Konzepten beschäftigt und gleichzeitig nach einer Datengrundlage gesucht, die schnell verfügbar ist und sich gut in eine webbasierte Karte integrieren lässt. Schließlich haben wir uns für OpenStreetMap als Grundlage entschieden, weil damit sowohl eine Kartenbasis als auch Gebäudedaten verfügbar sind, aus denen sich 3D Darstellungen ableiten lassen.
Parallel haben wir auch mit photogrammetrischen Ansätzen geliebäugelt, diese aber praktisch verworfen, weil das Erstellen eigener Aufnahmen im Hafenumfeld nicht zuverlässig möglich war. Zusätzlich haben wir Experimente mit Gaussian Splatting durchgeführt. Das blieb jedoch bewusst explorativ und wurde nicht zum Schwerpunkt.
Ergänzend haben wir parallel mit Blender gearbeitet, um zu zeigen, dass sich 3D Gebäude auf der OpenStreetMap Karte durch eigene Konstruktionen ersetzen lassen. Im Projekt lag darauf nicht unser Fokus, aber exemplarisch können wir das für das Hochschulgebäude Haus V abbilden und damit zeigen, dass einzelne Gebäude gezielt durch eigene Modelle ersetzt werden können.
Validierung
In der Validierung wurde vor allem deutlich, dass wir den Umfang konsequent fokussieren müssen. Die Hafengeschichte war zu Beginn als inhaltlicher Strang mitgedacht, wurde dann aber bewusst verworfen. Der Zeitraum von 14 Wochen und die begrenzte Datenlage hätten den Anspruch zu hoch werden lassen. Stattdessen haben wir uns auf das konzentriert, was wir in der Zeit sauber, stabil und nutzbar umsetzen konnten.
Ergebnis
Am Ende steht eine interaktive 3D Webplattform, die als Co Browsing Erlebnis genutzt werden kann, um Bremerhaven gemeinsam über eine 3D Karte und ausgewählte Points of Interest zu erkunden. Die Anwendung heißt nun harbour2025. Der frühere Name hARbour2025 passte nicht mehr, weil wir den AR Fokus im Projekt bewusst verworfen haben und die Lösung heute klar über 3D Karte, Inhalte und gemeinsame Nutzung definiert ist.
Architektur
Docker Container Orchestrierung
Die Anwendung ist als containerisierte Architektur konzipiert und wird mithilfe von "docker compose" orchestriert. Die einzelnen Container fungieren dabei als sogenannte Microservices, die in unserem Fall aus dem Backend, dem Frontend, der Datenbank und den WebSockets bestehen. Die Container selber agieren dabei als eigenständige Einheiten, die jedoch so zusammenarbeiten, dass sie die von uns gestellten Anforderungen erfüllen und die Anwendung laufen kann. Die Verteilung der verschiedenen Services in Containern bietet uns mehrere Vorteile, darunter zum Beispiel die Möglichkeit Änderungen an einer Komponente vorzunehmen, ohne dabei die Funktionen der anderen Microservices anpassen zu müssen. [1]
Die Verwaltung mit "docker compose" erfolgt auf Basis mehrer Compose-Dateien, die die unterschiedlichen Einsatzszenarien abbilden. Die Compose-Dateien sorgen dafür, dass dieselbe Architektur sowohl für die lokale Entwicklung als auch für die Produktivumgebung genutzt werden kann, ohne dabei mit Konfigurationsduplikaten zu arbeiten oder manuelle Anpassungen vornehmen zu müssen. Als Basis der Architektur dient die Datei "compose.yaml", welche die zentralen Services definiert und die Abhängigkeiten zwischen den einzelnen Containern verwaltet. Da sie das Grundgerüst für die Architektur darstellt, ist die "compose.yaml" unabhängig der Laufzeitumgebung einsetzbar.
Im Laufe des Projekts hat sich herausgestellt, dass wir unterschiedliche Umgebungen für unterschiedliche Szenarien benötigen, die folgend beschrieben sind.
Entwicklungsumgebung
Nachdem wir uns auf eine bestimmte Richtung des Projekts eingigen konnten, spielte die Entwicklungsumgebung im Prozess der Erstellung unserer Anwendung eine zentrale Rolle. Es gab noch keine Gesamtanwendung und dementsprechend keine funktionierenden Komponenten, weshalb vieles "on the fly" getestet und ausprobiert werden musste.
Es musste also eine Umgebung her, in der der Fokus auf diesen Aspekten lag, weshalb die Basis-Konfiguration durch die Datei "compose.override.yaml" ergänzt wurde, welche Anpassung für die lokale Entwicklung vornimmt. Dazu zählen unter anderem das Einbinden von Quellcode-Verzeichnissen als Volumes oder die Aktivierung von Hot-Reload-Mechanismen, durch die Änderungen am Code in laufenden Containern direkt sichtbar werden - eine Möglichkeit, einen schnellen Entwicklungsprozess zu etablieren.
Zur Sicherstellung einer konsistenten Codequalität ist der Entwicklungsprozess druch den Einsatz von "Git-Hooks" ergänzt. Die Hooks werden lokal vor jedem Commit ausgeführt und stellen sicher, dass der Code korrekt formatiert ist. Diese Maßnahme dient nicht nur als Mittel, um Änderungen im Code besser nachvollziehen zu können, sondern vor allem als frühe Qualitätssicherung und sorgt dafür, dass ein einheitlicher Code-Stil über das gesamt Projekt hinweg gewährleistet ist.
Testumgebung
Bei der Testumgebung lag das Hauptaugemerk darauf, eine einheitliche und vor allem realitätsnahe Umgebung aufzubauen, auf die alle Teammitglieder:innen Zugriff haben. Damit dies gewährleistet ist, haben wir eine Virtual Machine (VM) von der Hochschule zur Verfügung gestellt bekommen und diese gemeinsam eingerichtet. Zur Einrichtung zählt sowohl die Installation benötigter Abhängigkeiten und Services, als auch die Erstellung individueller Accounts, die jedem Teammitglied den Zugang über den jeweiligen Benutzernamen ermöglichen. Die VM bietet unter anderem den Vorteil, realitätsnahe Tests unter produktionsnahen Bedingungen laufen zu lassen, ohne dabei lokale Entwicklungsumgebungen voraussetzen zu müssen.
Wir mussten jedoch auch relativ schnell feststellen, dass sich eine mögliche Sicherheitslücke durch den Einsatz von Docker und dem Hinterlegen von SSH-Keys auf der VM auftut. Ein potentieller Angreifer hat zwar an sich nicht die Berechtigungen, in der VM auf die Home-Verzeichnisse der anderen User zuzugreifen (dort sind die SSH-Keys hinterlegt), jedoch haben alle User auf der VM die Möglichkeit einen Container zu starten. Hier haben wir ein potentielles Risiko erkannt, welches sich wie folgt äußert: Wenn ein Angreifer nun einen Container startet und das User-Verzeichnis der VM auf den gestarteten Container mountet, hat er innerhalb dieses Containers Root-Rechte. Diese Rechte ermöglichen es dem Angreifer so über Umwege an die Home-Verzeichnisse der einzelnen Benutzer:innen zu kommen und so eventuell sensible Daten, wie die angesprochenen SSH-Keys zu stehlen. Diese lücke umgehen wir, indem auf unser VM Docker nur im sogenannten "rootless-Mode" laufen lassen. Durch den rootless-Mode haben alle Mitglieder:innen noch die Möglichkeit einen Container zu konfigurieren und zu starten, haben jedoch keine Root-Rechte mehr im Container selbst. So wird verhindert, dass Nutzer:innen potenziell Zugriff auf sensible Systembereiche oder Daten von Anderen haben. [2]
Produktivumgebung
Der produktive Betrieb der Anwendung wird über die Datei "compose.prod.yaml" geregelt. In dieser Datei werden ausschließlich die für den Betrieb notwendigen Abhängigkeiten berücksichtigt. Die "compose.prod.yaml" sorgt so für eine schlanke und stabile Laufzeitumgebung, die besser für den Einsatz in produktiven Szenarien geeignet ist.
Backend
Das Backend der Single-Page-Webanwendung wurde mittels der Sprache Python implementiert und bildet die Kernlogik der Anwendung. Als Webframework haben wir uns für "Flask" entschieden, welches wir zur Bereitstellung einer JSON-basierten API nutzen. Das Backend bildet so fünf Endpunkte ab, welche folgende Abfragen an die Datenbank ermöglichen:
- alle Kategorien
- alle POIs
- alle Tags
- alle POIs zu einem ausgewähltem Tag
- POI mit allen seinen Tags
Zur Verwaltung der Python-Abhängigkeiten wurde der Package-Manager "uv" eingesetzt. Dieser ermöglicht eine schnelle und deterministische Installation der benötigten Pakete und eignet sich insbesondere für den Einsatz in automatisierten Build- und Deployment-Prozessen. Die Definition der Abhängigkeiten sowie deren Versionen erfolgt zentral über die Datei "pyproject.toml". Dadurch wird eine konsistente Laufzeitumgebung geschaffen und der Build-Prozess reproduzierbar gestaltet.
Um Daten persistent speichern zu können, nutzt das Backend eine relationale PostgreSQL-Datenbank. Die Datenbank wird beim Start des Backends mithilfe des zugrunde liegenden Datenbankschemas initialisiert. Das Schema modelliert dabei die Tabellen Points of Interest, Kategorien, Tags sowie deren Beziehungen in einer Hilfstabelle. Um die Bearbeitung der Tabellen zu vereinfachen, wurde ein Bash-Skript "csv2sql.sh hinterlegt, welches eine csv-Datei entgegen nimmt und diese in SQL-Befehle umwandelt, sodass die Datenbank mit Werten gefüllt werden kann. Die Query-Logik nutzt einfache SQL-Abfragen sowie JOIN-Operationen um zusammengehörige Informationen sinnvoll zusammenzufassen und als JSON bereitzustellen.
Frontend
Das User-Interface ist die zentrale Schnittstelle zwischen dem Nutzenden und dem System. Während bei der Entwicklung hauptsächlich technische Aspekte und Funktionalität im Vordergrund standen, ist ein professionelles Erscheinungsbild ein essenzieller Bestandteil der fertigen Endanwendung. Wir haben uns dafür entschieden, uns sowohl bei der Farbgestaltung als auch bei der Typografie an den Brand Design Guidelines der Hochschule Bremerhaven zu inspirieren.
Technisch basiert das Frontend auf klassischen Web-Technologien wie HTML, CSS und JavaScript. Den funktionalen Kern bildet MapLibre GL JS, das als Engine für die gesamte 3D-Kartendarstellung dient. MapLibre ermöglicht die Darstellung der 3D-Basiskarte sowie die Verwaltung von Layern, Markern und Kamerabewegungen. Für die Integration zusätzlicher 3D-Objekte wird MapLibre bei Bedarf mit Three.js kombiniert, wodurch eigene Modelle in die bestehende WebGL-Szene eingebettet werden können. Als Basiskarte verwenden wir eine frei verfügbare, auf OpenStreetMap basierende Liberty-Variante. Damit bleibt die Anwendung vollständig Open-Source-basiert und entspricht den zu Beginn definierten Projektvorgaben.
Für die Strukturierung der Benutzeroberfläche und die Verwaltung interner Zustände setzen wir auf Alpine.js. Das Framework ist bewusst leichtgewichtig gewählt und erlaubt es, reaktive Zustände direkt im HTML zu definieren. UI-Elemente wie Sidebar, Modals, Filteroptionen oder der Follow-Modus sind an zentrale States gebunden, etwa für den aktuellen Raumstatus, ausgewählte Tags oder verbundene Teilnehmende. Änderungen an diesen Zuständen wirken sich unmittelbar auf die Oberfläche aus, ohne dass explizite DOM-Manipulationen notwendig sind.
Das Styling basiert überwiegend auf Tailwind CSS, ergänzt durch eine eigene style.css, in der wiederkehrende Komponenten konsolidiert sind. Während Tailwind die schnelle und strukturierte Layoutgestaltung unterstützt, sorgt das eigene Stylesheet für ein einheitliches Erscheinungsbild von Panels und Bedienelementen.
Beim Initialisieren der Anwendung werden Points of Interest, Tags und Kategorien asynchron vom Backend geladen und im zentralen Frontend-State gespeichert. Wird ein Tag ausgewählt oder zurückgesetzt, aktualisiert sich der State, woraufhin die sichtbaren Marker auf der Karte neu gerendert werden. Beim Anklicken eines POIs werden Detailinformationen nachgeladen und in einem separaten Panel dargestellt.
Ein zentrales Ziel des Projekts war die kollaborative Nutzung der Karte. Nutzende können über die Sidebar einen Raum erstellen oder einem bestehenden Raum beitreten. Nach erfolgreicher Verbindung werden Raum-ID, Verbindungsstatus (online oder offline), eigener Anzeigename sowie eine Liste weiterer Teilnehmender angezeigt. Die Synchronisation der Kartenansicht erfolgt über WebSockets. Kamerabewegungen werden in definierten Intervallen übertragen, sodass alle Teilnehmenden dieselbe Perspektive einnehmen können. Über die Follow-Funktion kann die eigene Ansicht an eine andere Person gekoppelt werden. Greift die folgende Person manuell in die Kartensteuerung ein, wird die Kopplung automatisch aufgehoben. Dadurch wird verhindert, dass konkurrierende Eingaben zu inkonsistentem Verhalten führen.
Ein besonderer Fokus lag zudem auf der Responsivität der Anwendung. Die Stadt soll sowohl am Laptop als auch auf mobilen Geräten erkundet werden können. Auf Desktop-Geräten ist die Sidebar mit fester Breite dauerhaft sichtbar, während der Kartenbereich den verbleibenden Raum einnimmt. Auf kleineren Bildschirmen wird die Sidebar standardmäßig ausgeblendet und über ein Burger-Menü eingeblendet. Auch das Detail-Panel für POIs passt sich der Bildschirmgröße an und wird mobil als unteres Overlay dargestellt, während es auf größeren Displays seitlich eingebunden ist.
Websockets
Der Websocket-Standard ermöglicht eine bidirektionale Echtzeitkommunikation zwischen allen gängigen Webbrowsern (siehe [3]) und einer geeigneten Server-Komponente, und rückte daher frühzeitig als zentrale Technologie zwecks Umsetzung der Echtzeit-Synchronisation in den Fokus.
Als Serverkomponente stehen diverse freie Implementierungen zur Verfügung. Aus Gründen der Einfachheit wurde zunächst auf die durch das Python-Framework FastAPI bereitgestellte Abstraktion zurückgegriffen und die Funktionalität als Teil des Backends implementiert. Da die von uns entwickelte Architektur jedoch keinerlei Überschneidungen mit dem Backend erfordert, wurde die Websocket-Komponente später in eine eigenständige Komponente ausgelagert, welche auf der Python-Bibliothek "websockets" basiert.
Die so erhaltene alleinstehende Komponente erlaubt zudem eine horizontale Skalierung durch den Einsatz mehrerer parallel laufender Instanzen hinter dem Load-Balancer "Caddy". Die Kommunikation zwischen den Instanzen erfolgt über ein Redis-Pub/Sub-System, welches ebenfalls eine einfache horizontale Skalierung ermöglicht. Redis bezieht sich in diesem Kontext lediglich auf das Protokoll, zum Einsatz kommt die offene Implementierung "Valkey".
3D Modellierung
Im Prototyp wurden 3D-Modelle direkt aus OpenFreeMap verwendet. Die Modelle sehen in Ordnung aus, jedoch stellt sich die Frage, wie wir 3D-Modelle mit noch mehr Details erstellen können. Als Proof of Concept haben wir uns entschieden, einige Gebäude der Hochschule detailliert zu modellieren und in die Karte zu integrieren. Technologien wie 3D-Laserscanning und Photogrammetrie erfordern spezielle Hardware, z. B. Laserscanner, Kameras oder Drohnen. Photogrammetrie-Software wie Meshroom ist sehr ressourcenintensiv. 3D Gaussian Splatting ist in der Industrie noch relativ neu. Die Erstellung von 3D-Modellen mit Blender ist praktisch und technisch möglich, weshalb wir uns entschieden haben, Blender für unser Projekt zu nutzen.
Einführung in Blender
Blender ist eine kostenlose Open-Source-Software für 3D Modellierung, VFX, Animation sowie Videobearbeitung. Sie ist plattformübergreifend und auf allen drei großen Betriebssysteme verfügbar. Die Benutzeroberfläche (UI) ist in der Abbildung dargestellt. Oben befinden sich Workspaces wie Layout, Modeling, Shading oder Animation, die jeweils für unterschiedliche Aufgabenbereiche vorgesehen sind. Das Standard-Interface (Layout) besteht aus mehreren Bereichen: dem Outliner(1), dem 3D Ansichtsfenster(2), dem Eigenschaften-Fenster(3) sowie der Zeitleiste(4). Der Outliner dient als Übersicht aller Szenenobjekte(Meshes, Texte, Lichter, Kameras), die im 3D Ansichtsfenster werden die Objekte visualisiert und bearbeitet werden.
Blender Anwendungsoberfläche (UI)
Im Eigenschaften-Fenster können die Attribute der ausgewählten Objekte angepasst werden. Die Zeitleiste wird zur Steuerung und Bearbeitung von Animationen verwendet. 3D Ansichtsfenster hat verschiedene Modi abhängig vom ausgewählten Objekt. Dazu zählen unter anderem Objektmodus, Bearbeitungsmodus und Skulturmodus. Jeder dieser Modi verfügt über eigene Tools in der Toolbar. Zum Beispiel: Objektmodus hat Tools wie Verschieben, Rotieren, Skalieren, Transformieren. Bearbeitungsmodus enthält zusätzliche Tools wie Extrudieren, Fase(Bevel), Schleife Schneiden (Loop Cut), Messer usw, mit denen Knoten, Kanten und Flächen von 3D Objekte bearbeitet werden. Die meisten Modellierungsarbeiten finden im Bearbeitungsmodus statt.
Modellierung
Da wir nur einige Modelle der Hochschule erstellen wollten, haben wir das 3D-Modell des Gebäudes V komplett von Scratch modelliert. Blender Add-Ons wie BlenderGIS, BlenderOSM sowie das Programm OSM2World liefern lediglich Basis-Polygone und Texturen, die bei kleinen Modellierungsaufgaben schnell manuell in Blender ergänzt werden können. In diesem Fall waren diese Tools daher nur begrenzt hilfreich. Die Modellierung des Gebäudes V der Hochschule begint mit einem einfachen Würfel, einer grundlegenden Form eines Meshes. Die meisten Arbeiten erfolgen im Layout-Workspace im Objektmodus und Bearbeitungsmodus. Zusätzlich nutzten wir den Shading-Workspace sowie den Shader Editor für das Texturieren der Materialien. Die einzelnen Schritte sind in einem Timelapse-Video angezeigt.
Timelapse-Video
Ein zentrales Problem bestand darin, dass keine genauen Messungen der Gebäude verfügbar waren. In diesem Fall konnten die Hilfstools wie BlenderGIS, Blosm und OSM2World ebenfalls nicht helfen, da sie keine korrekten Messungen liefern. Die Messungen wurden zunächst grob geschätzt und anschließend durch Ausprobieren in OpenFreeMap kalibriert, um eine möglichst realistische Darstellung zu erreichen. Für zukünftige Entwicklungen wäre eine Zusammenarbeit mit der Hochschule und der Stadtverwaltung sinnvoll, um präzise Gebäudedaten zu erhalten.
Export
Das in Blender modellierte 3D-Modell des Hochschulgebäudes V wurde als glTF (Graphics Library Transmission Format) exportiert, damit es in anderen Umgebungen, wie beispielsweise der Webanwendung OpenFreeMap mit MapLibre und Three.js, integriert werden kann. Beim Export traten jedoch Probleme auf: In Blender sah das 3D-Modell sehr gut aus, nach dem Export im glTF-Format wurden jedoch einige komplexe prozedurale Texturen nicht korrekt übernommen. Als Lösung mussten die prozeduralen Texturen zunächst gebackt und als PNG-Dateien gespeichert werden. Diese gebackenen PNGs wurden anschließend als image-basierte Texturen im Modell verwendet.
Import
Das exportierte glTF-3D-Modell wurde mithilfe von Three.js in MapLibre Karte eingebettet. MapLibre GL JS bietet ein CustomLayerInterface, über das Three.js zum Import des 3D-glTF-Modells verwendet werden kann, indem der Renderer-Kontext von MapLibre GL JS in Three.js genutzt wird. Das Modell hatte eine Größe von etwa 15 MB. Für ein einzelnes Modell ist dies relativ groß, wodurch das Laden etwas Zeit nimmt. Bei einer zukünftigen Skalierung kann dies zu Performance-Problemen führen. Als Lösungen kommen zwei Techniken in Frage: Erstens das Konzept der Levels of Detail (LOD), bei dem nur sichtbare oder nahe Objekte in voller Detailstufe geladen werden, und zweitens die Nutzung eines 3D-Tileservers, um 3D-Modelle zu streamen.
3D-Modell in Blender
Integration in OpenFreeMap
3D-gedrucktes Modell
Nutzung offener LoD2-Gebäudemodelle
Im Rahmen des Projekts wurde weiterhin die Möglichkeit untersucht, auf offene, im Rahmen der INSPIRE-Richtlinie der EU [4] durch das Landesamt GeoInformation Bremen unter der Creative Common Namensennung 4.0 International veröffentlichte LoD2-Gebäudemodelle des Land Bremen [5] zurückzugreifen. Die im CityGML-Format vorliegenden Daten wurden hierbei mithilfe quelloffener Werkzeuge in den 3D-Tiles Standard [6] überführt und mittels des quelloffenen deck.gl-Framework gerendert, was eine nahtlose Einbindung in den Render-Prozess von MaplibreGL JS erlaubt. Das nachfolgende Bild zeigt die Unterschiede im direkten Vergleich und kann dynamisch angepasst werden.
Lasttests der Websockets
K6 Messarchitektur
Für eine Beurteilung des Resourcenbedarfs der Anwendung haben wir Lasttests
mit K6 durchgeführt. Dabei haben wir uns auf die Auslastung und Messung des
Websocket-Backends fokussiert. Wir gehen davon aus, dass das Ausliefern des
statischen Webcontents und die wenigen Datenbankanfragen kaum Ressourcen
benötigen.
K6 bietet eine eigene Websocket-API für Javascript mit der eine minimale Version unseres Websocket-Protokolls nachgebaut wurde. K6 erzeugt dann eine beliebige Anzahl Clients die mit dem Backend kommunizieren und Kamerabewegungen simulieren als wären es echte User.
Dabei werden Metriken wie die Dauer des Verbindungsaufbaus, die Anzahl der Nachrichten und die Verzögerung der Antworten mitgeschrieben und können später ausgewertet werden.
Websocket Backend V1
Websocket Backend V2
Durch die zuvor beschriebene horizontale Skalierung konnte die Kapazität der Anwendung nochmals erhöht werden. Mit einem Deployment von 16 Containern die, zusammen mit einer Redis Instanz, das Websocket-Backend bilden, kann die Last auf mehrere Prozesse und CPU Kerne verteilt werden. So lässt sich eine flüssige Kamerasynchronisation für bis zu 500 User in einem Raum gewährleisten.
Websocket Backend mit 16 Container
Referenzen
Literaturverzeichnis
- D. Jaramillo, D. V. Nguyen and R. Smart, "Leveraging microservices architecture by using Docker technology," SoutheastCon 2016, Norfolk, VA, USA, 2016, pp. 1-5, doi: 10.1109/SECON.2016.7506647.
- R. Rahmansyah, V. Suryani, F. Arif Yulianto and N. Hidayah Ab Rahman, "Reducing Docker Daemon Attack Surface Using Rootless Mode," 2021 International Conference on Software Engineering & Computer Systems and 4th International Conference on Computational Science and Information Management (ICSECS-ICOCSIM), Pekan, Malaysia, 2021, pp. 499-502, doi: 10.1109/ICSECS52883.2021.00097.
- https://caniuse.com/websockets
- https://www.imagi.de/Webs/IMAGI/DE/themen-und-projekte/INSPIRE/INSPIRE-node.html
- https://metaver.de/trefferanzeige?docuuid=226971C2-6677-4B79-95F3-C5311F1275C8
- https://www.ogc.org/standards/3dtiles/