GOAT: Open-Source-WebGIS als Grundlage für den Digitalen Tisch

Die Lösung setzt auf GOAT auf, einer quelloffenen WebGIS-Plattform für die integrierte Stadt- und Mobilitätsplanung. Auf dem Digitalen Tisch läuft sie als Webanwendung im Vollbild, ohne lokale Installation. Möbel und Touchscreen bleiben erhalten, verändert wird die Software.

Wesentlich sind zwei Nutzungsebenen der Plattform auf derselben Datenbasis:

Der Expertenmodus stellt den vollen Funktionsumfang bereit. Fachanwenderinnen und Fachanwender binden eigene Daten ein, führen räumliche Analysen durch, visualisieren die Ergebnisse und teilen sie. Gerade in Expertensituationen am Tisch ist das der Mehrwert: Eine im Gespräch aufkommende Frage kann direkt gerechnet werden, etwa eine Erreichbarkeit oder ein Einzugsgebiet, statt auf einen späteren Termin verschoben zu werden.

Der Dashboard-Builder erzeugt aus denselben Daten anwendungsfallspezifische Oberflächen, ohne Programmierung: Karten in Kombination mit dynamischen Diagrammen, je nach Zielgruppe unterschiedliche Visualisierungsformen und Detailtiefen. Entscheidend für diesen Anwendungsfall:

Mit wenigen Klicks lassen sich mehrere spezialisierte Anwendungen nebeneinander anlegen. In der Stadtentwicklung gibt es nicht die eine Fragestellung, sondern viele, und der Tisch kann so dynamisch mit unterschiedlichsten Themen bespielt werden, ohne für jedes Thema ein neues Produkt zu beschaffen. Umgesetzte Beispiele für solche Oberflächen sind die Verkehrsinformationszentrale Baden-Württemberg, das Stadtklimadashboard des Bundesinstituts für Bau-, Stadt- und Raumforschung sowie unsere Map Gallery.

Daraus folgt der Kern des Ansatzes: Der Digitale Tisch wäre keine Sonderentwicklung, sondern eine mit vorhandenen Mitteln gebaute Oberfläche auf einer erprobten Plattform. Die Tisch-Ansicht entsteht im Builder, die inhaltliche Arbeit im Expertenmodus, beide greifen auf denselben Datenstand zu.

Das bedeutet ausdrücklich keine Standardoberfläche von der Stange: Erscheinungsbild und Bedienelemente sind weitreichend anpassbar und vollständig white-labelfähig, dazu mehr im Feld „Interaktion".

Bezogen auf die in der Challenge genannten Nutzungssituationen, wobei wir hier die Situation beschreiben und die konkrete Nutzerführung im Feld „Interaktion":

• Einstieg in Gespräche auf Messen und Veranstaltungen: Eine Person der Auftraggeberin führt, zwei bis fünf Personen stehen um den Tisch. Gebraucht wird ein Bild, das in Sekunden Orientierung gibt, nicht ein Werkzeug, das erklärt werden muss.

• Gemeinsame Exploration: Die Reihenfolge folgt dem Gespräch, nicht einer Präsentationsdramaturgie. Die Anwendung antwortet auf Nachfragen, statt einen Ablauf abzuspielen.

• Gezielte Vertiefung einzelner Themen: Reicht die vorbereitete Tiefe im Gespräch nicht aus, ist der Wechsel in den Expertenmodus am selben Datenstand möglich, inklusive Analysen.

• Vergleich von Optionen: Varianten liegen als Szenarien auf derselben Datengrundlage und werden im Gespräch gegeneinander gestellt, was Entscheidungen belastbarer macht als die Betrachtung einer Variante allein.

• Interne Vorbereitung von Gesprächen: Im Expertenmodus stellt das Team der Auftraggeberin die benötigten Ebenen, Szenarien und Einstiege zusammen und gibt sie für den Tisch frei. Die Vorbereitung eines Termins ist damit redaktionelle Arbeit und kein Entwicklungsvorgang.

• Selbsterkundung im Infocenter: Besucherinnen und Besucher bedienen den Tisch ohne Begleitung, dafür ist eine eigene, stärker geführte Variante derselben Inhalte vorgesehen.

Zur Mehrpersonen-Interaktion trennen wir offen, was heute verfügbar ist und was Entwicklungsgegenstand wäre.

Heute verfügbar ist eine Oberfläche, die eine Karte mit mehreren gleichzeitig sichtbaren Elementen verbindet, etwa dynamischen Diagrammen, Legenden und Objektinformationen. Mehrere Personen betrachten damit gleichzeitig zusammenhängende Inhalte, zeigen darauf und bedienen abwechselnd.

Zu erweitern wären zwei Punkte. Erstens ist die Darstellung mehrerer Karten nebeneinander derzeit nicht möglich. Zweitens verarbeitet die Anwendung keine gleichzeitigen, voneinander unabhängigen Touch-Eingaben mehrerer Personen, weil Webanwendungen Touch-Ereignisse standardmäßig als einen Eingabestrom mit gemeinsamem Anwendungszustand behandeln. Uns ist wichtig, das klar zu benennen: Für einen großen Teil der Anforderungen bringt GOAT die Komponenten bereits mit, für die volle Funktionsfähigkeit im Sinne der Challenge müsste Bestehendes erweitert werden. Der Ansatz ist damit weder ein fertiges Produkt noch eine Neuentwicklung, sondern ein Ausbau auf erprobter Grundlage.

Diese Punkte würden wir früh auf der Zielhardware klären statt konzeptionell, mit einer Vorstufe auf dem vorhandenen Tisch im realen Gespräch mit dem Team der Auftraggeberin. Nach unserer Erfahrung reicht häufig eine Karte mit begleitenden Elementen bei abwechselnder Bedienung, die Entscheidung sollte aber auf einer Beobachtung beruhen und nicht auf einer Annahme.

Leitgedanke ist direkte Manipulation der Karte anstelle von Menühierarchien. Der Bedienumfang im Gespräch bleibt auf fünf Handlungen begrenzt: Verschieben, Zoomen, Antippen eines Objekts, Umschalten von Thema oder Ebene und Vergleichen von Varianten. Alles Weitere gehört in die Redaktionsansicht und nicht auf den Tisch.

Konkrete Elemente der Nutzerführung:

• Themeneinstiege statt Startkarte. Vorgesehen ist ein Ausgangszustand mit einer begrenzten Zahl klar benannter Themen. Niemand muss wissen, welche Ebene wo liegt, um zu beginnen.

• Gespeicherte Kartenansichten. Ein vorbereiteter Einstieg soll mit einem Antippen Ausschnitt, Zoomstufe, Ebenenkombination und Legende gemeinsam setzen. Das ersetzt das fehleranfällige manuelle Rekonstruieren einer Ansicht im laufenden Gespräch.

• Objektinformationen ohne modalen Dialog. Die Plattform unterstützt beide Formen, das Popup direkt am angetippten Objekt und das seitliche Panel, auch in Kombination. Für den Tisch ist diese Wahlmöglichkeit wichtig, weil die Leserichtung von der Position am Tisch abhängt: Das Popup bleibt räumlich zugeordnet, das Seitenpanel nimmt mehr Inhalt auf, ohne die Karte zu verdecken. Vorgesehen ist daher die Kurzinformation am Objekt und die Detailtiefe im Panel, in beiden Fällen ohne das Gespräch zu unterbrechen.

• Rücksprung in den Ausgangszustand. Vorgesehen ist ein jederzeit erreichbarer Rücksprung, der Startausschnitt, Startebenen und geöffnete Informationsfenster in einem Schritt wiederherstellt, im unbeaufsichtigten Betrieb zusätzlich automatisch nach einer Leerlaufzeit. Die Anforderung ergibt sich aus dem Einsatzort: Nach einem längeren Gespräch ist die Karte hineingezoomt und mit mehreren Ebenen belegt, während die nächste Gruppe bereits am Tisch steht. Beides ist heute nicht Bestandteil der Plattform, aber eine klar umrissene Ergänzung auf dem vorhandenen Zustandsmodell.

• Dauerhaft sichtbare Legende. Die Legende lässt sich dauerhaft einblenden. Bei mehreren Personen um den Tisch kann nicht davon ausgegangen werden, dass alle die Einführung mitbekommen haben, deshalb muss die Kartenlegende ohne zusätzlichen Bedienschritt lesbar sein.

Die Challenge nennt als Anforderung, dass die Anwendung das Gespräch unterstützt und nicht dominiert, dabei aber eigenständige Erkundung zulässt. Wir übersetzen das vor allem in Verzicht: kein Startbildschirm, der Aufmerksamkeit einfordert, keine Animationen, Hinweisfenster oder Benachrichtigungen, kein Ablauf, der abgearbeitet werden will. Gegenstand bleibt die Karte, die Bedienoberfläche tritt zurück. Beides zusammen ermöglicht die zugespitzte Tisch-Ansicht: Sie zeigt wenige Einstiege, hinter denen die Inhalte frei erkundbar bleiben, statt Erkundung durch Führung zu ersetzen.

Ein Teil der Arbeit ist ausdrücklich Gestaltung. Die GOAT-Oberfläche ist heute für Desktop-Arbeitsplätze mit Maus optimiert. Für einen Tisch von 173 cm Breite, der im Stehen von mehreren Seiten bedient wird, braucht es größere Trefferflächen und Schriftgrade, Bedienelemente in Armreichweite an den Rändern statt am oberen Bildschirmrand und den Verzicht auf Hover-Effekte.

Damit verbunden: Auch wenn der Tisch keine Sonderentwicklung wäre, entsteht keine Standardoberfläche von der Stange. Die Anwendung ist weitreichend anpassbar und vollständig white-labelfähig, also Erscheinungsbild, Aufbau und Bedienelemente nach dem Gestaltungskonzept der Auftraggeberin, bis zum Betrieb unter eigener Domain ohne sichtbaren Anbieterbezug. Für einen Tisch im Gemeinschaftsmessestand der Freien und Hansestadt Hamburg ist das Grundvoraussetzung und keine Option, möglich durch den offenen Quellcode. Insgesamt ist es Gestaltungs- und Frontend-Arbeit auf bestehender Architektur, keine Neuentwicklung.

Technisch stabile Nutzung in Gruppensituationen ist eine eigene Anforderung, nicht nur eine Frage der Geschwindigkeit. Die Anwendung läuft im Browser, ohne lokale Installation und ohne lokalen Zustand auf dem Tischrechner, was Ausfälle durch die Tischhardware selbst unwahrscheinlich macht.

Verzögerungsfreie Darstellung wird über die Technologiebasis erreicht: Vector Tiles und GPU-gestütztes Rendering mit MapLibre sorgen für flüssiges Zoomen und Verschieben auch bei großen Datenmengen. Rechenintensive Auswertungen werden vorab über Workflows berechnet und liegen als fertige Ebenen vor, sodass die Reaktionszeit im Gespräch unabhängig von der Komplexität der Auswertung bleibt.

Derzeit arbeiten wir an einem KI-Agenten, der mit der Karte gekoppelt ist: Eine natürlichsprachliche Anfrage wie „zeige die Bauphasen 2028 im Grasbrook" setzt den Kartenzustand unmittelbar, ohne dass ein Bedienweg bekannt sein muss. Für die Anforderung einer Nutzung ohne Schulung ist das der weitestgehende Ansatz, weil die Bedienoberfläche als Hürde entfällt. Wir benennen dies als Entwicklungsperspektive und nicht als heute verfügbaren Funktionsumfang.

Die Inhalte werden in drei Stufen geordnet: Thema, Ebene und Objekt. Ein Thema bündelt fachlich zusammengehörige Ebenen samt passendem Ausschnitt und Legende, etwa Nutzungen, Erschließung, Freiraum oder Bauphasen. Innerhalb eines Themas sind einzelne Ebenen zu- und abschaltbar. Ein angetipptes Objekt liefert Attribute, Bilder und erläuternde Texte.

Nach unserem Verständnis werden am bestehenden Tisch auch Dokumente geöffnet. Das ist heute nicht Teil der Plattform, ließe sich aber als weiterer Inhaltstyp neben Karten und Diagrammen ergänzen, sodass etwa ein Bebauungsplan oder ein Exposé am Objekt hinterlegt und aus derselben Oberfläche heraus aufgerufen werden kann.

Der Wechsel zwischen Überblick und Detail erfolgt auf zwei Wegen, die sich ergänzen: maßstabsabhängig und über Sprungmarken. Maßstabsabhängig wächst die Detailtiefe mit der Zoomstufe: von der Einordnung im Stadtgebiet über das Quartier und das Baufeld bis zum einzelnen Gebäude, wobei Ebenen und Beschriftungen je Zoomstufe gezielt ein- und ausgeblendet werden, damit die Darstellung in keinem Maßstab überladen wirkt. Ergänzend führen Kartenlesezeichen direkt an eine definierte Stelle mit definierter Ebenenkombination, was im Gespräch schneller ist als navigierendes Zoomen.

Varianten und Szenarien werden über die Szenariofunktion der Plattform abgebildet. Alternativen liegen als eigene Zustände auf derselben Datengrundlage vor und werden an derselben Stelle der Karte gegeneinander umgeschaltet, bei gleichbleibendem Ausschnitt und gleichbleibender Legende. Der direkte Vergleich zweier Zustände ist in Planungsgesprächen erfahrungsgemäß aussagekräftiger als die Betrachtung einer Variante allein. Eine Darstellung zweier Karten nebeneinander ist derzeit nicht möglich und wäre Entwicklungsgegenstand, siehe Feld „Nutzungsszenarien".

Kontextabhängige Kombination. Ebenen sind nicht fest an ein Thema gebunden. Innerhalb einer Ansicht lassen sich Ebenen verschiedener Themen zusammenschalten, etwa Bauphasen mit Freiraum und Erschließung, wenn eine Frage im Gespräch quer zur vorbereiteten Gliederung liegt. Die Themen sind damit ein Angebot für den Einstieg und keine Grenze.

Orientierung in komplexen Zusammenhängen. Damit im Detail der Bezug zum Ganzen nicht verloren geht, soll der räumliche und thematische Kontext dauerhaft ablesbar bleiben: die aktuelle Lage im Gesamtgebiet, die Benennung des geöffneten Themas und der aktiven Ebenen sowie ein sichtbarer Weg zurück in den Überblick. An einem Tisch, an dem Personen mitten im Gespräch dazutreten, muss auf einen Blick erkennbar sein, wo man sich befindet und was gezeigt wird.

Zur Mehrsprachigkeit: Die Anwendung liegt vollständig in Deutsch und Englisch vor, und zwar sowohl die Bedienoberfläche als auch die Inhalte. Zweisprachigkeit ist damit kein Zusatzmodul, sondern Bestandteil der Plattform. Fachinhalte werden über zweisprachige Attributfelder geführt, also je Datensatz getrennte Spalten für die deutsche und die englische Bezeichnung und Beschreibung. Ein Sprachschalter wirkt gleichzeitig auf Oberfläche, Ebenennamen, Legenden und Objektinformationen. Der aktuelle Kartenzustand bleibt beim Umschalten erhalten, es wird also nicht zum Startbildschirm zurückgesprungen, was im laufenden Gespräch mit internationalen Gästen entscheidend ist. Die Pflege der Übersetzungen erfolgt in derselben Datenquelle wie die deutschen Inhalte, es gibt keine zweite, separat zu pflegende englische Anwendung.

Grundsatz: Der Tisch hält keine eigene Datenkopie, sondern ist eine Sicht auf die bestehenden Datenquellen. Damit entfällt der übliche Pflegeaufwand von Präsentationssystemen, bei denen Inhalte für den Auftritt gesondert aufbereitet werden und anschließend gegenüber dem Fachstand veralten. Änderungen in der Quelle erscheinen ohne Zwischenschritt auf dem Tisch.

Anbindung an eine zentrale Datenquelle. GOAT verfügt über native Konnektoren zu PostgreSQL/PostGIS und ist API-First aufgebaut (FastAPI). Fachdatenbanken werden direkt angebunden, GeoJSON und JSON werden verarbeitet. Wo eine direkte Datenbankanbindung nicht gewünscht ist, erfolgt die Anbindung über Dienste.

Offene Standards. Die Plattform unterstützt konsequent OGC-Standards, insbesondere OGC API Features, OGC Processes, Vector Tiles sowie WMS und WFS. Damit sind bestehende Dienstelandschaften einschließlich GeoServer unmittelbar nutzbar, und zwar in beide Richtungen:

Vorhandene Dienste werden eingebunden, und in GOAT erzeugte Ergebnisse können als standardkonforme Layer in die bestehende Plattformlandschaft zurückgegeben werden. Über diese Schnittstellen ist die Lösung auch an das Masterportal und damit an die darauf aufbauenden Hamburger Werkzeuge anschlussfähig, sodass keine Doppelstrukturen entstehen.

Bezug zu Hamburg. Plan4Better setzt GOAT seit 2025 im Vorhaben LOOPED für den Landesbetrieb Straßen, Brücken und Gewässer (LSBG) ein. Dort wird ein datengetriebenes Bedarfsmodell zur Priorisierung des barrierefreien Umbaus von rund 3.700 Haltepunkten umgesetzt. Die Umsetzung folgt OGC-Standards, insbesondere OGC Processes, und sichert damit die Interoperabilität mit der Geodateninfrastruktur Hamburgs. Integriert wurden unter anderem Daten der HVV-Haltestellenbank und des ROADS-Systems. Die Entwicklung erfolgt transparent als Open Source im GOAT-Repository. Der Weg, Fachdaten der Freien und Hansestadt Hamburg standardkonform anzubinden und Ergebnisse in die städtische Infrastruktur zurückzuführen, ist damit für diesen Kontext bereits erprobt und nicht neu zu erfinden.

Einbettung in Urban-Data-Plattformen. Derzeit entsteht ein Plugin, mit dem GOAT als Addon in CIVITAS/CORE betrieben werden kann, einer quelloffenen, containerbasierten Urban-Data-Plattform mit gemeinsamer Nutzerverwaltung. Wo eine solche Plattform vorhanden ist oder aufgebaut wird, kann der Digitale Tisch dieselbe Datenbasis, Authentifizierung und Betriebsumgebung nutzen wie die übrigen städtischen Fachanwendungen.

Fachliche Strukturen. Das Ebenen- und Attributmodell wird an die Fachlogik der Auftraggeberin angepasst, also an Projektgebiete, Baufelder, Bauphasen und Nutzungsarten. Die Plattform gibt keine feste inhaltliche Struktur vor.

Lizenz. GOAT steht vollständig unter einer Open-Source-Lizenz (GPLv3). Datenmodell, Schnittstellen und Quellcode sind offen, wodurch keine Bindung an einen einzelnen Anbieter entsteht und Weiterentwicklungen auch durch Dritte möglich sind.

Die Pflege erfolgt vollständig in der Browseroberfläche und ohne Programmierung. Redaktionell Zuständige der HafenCity Hamburg GmbH können Datensätze hochladen oder verknüpfen, Darstellung und Legenden festlegen, Ebenen zu Themen gruppieren, Kartenlesezeichen anlegen, Texte und Bilder hinterlegen sowie Szenarien erstellen. Die Bedienlogik entspricht der einer Web-Anwendung mit No-Code- und Low-Code-Oberflächen, nicht der eines Desktop-GIS.

Für den laufenden Betrieb sind zwei Aktualisierungswege vorgesehen, die sich kombinieren lassen:

1. Direkte Anbindung an die Fachquelle. Ebenen, die aus einer Datenbank oder einem Dienst gespeist werden, sind ohne redaktionelles Zutun aktuell. Für Fachdaten ist dies der Regelfall und reduziert die Pflege auf null.
   
   

2. Geplante Aktualisierung über Workflows. Aufbereitungsschritte werden als wiederholbare, zeitgesteuerte Workflows abgelegt. Damit bleibt die Methodik konsistent und nachvollziehbar, auch wenn sich die Datengrundlage ändert oder Zuständigkeiten wechseln.
   
   

Redaktionell gepflegt werden damit im Wesentlichen die erzählenden Inhalte, also Texte, Bilder, Themenzusammenstellungen und Einstiege, und genau das sind die Inhalte, die im Kommunikationsalltag ohnehin bei der HafenCity Hamburg GmbH liegen.

Ein Rollen- und Rechtemodell trennt Redaktion und Lesezugriff, sodass Inhalte vorbereitet und geprüft werden können, bevor sie auf dem Tisch erscheinen. Das ist bei Messeauftritten mit Vorlauf und Abstimmungsbedarf relevant. Kurzfristige Änderungen bleiben dabei jederzeit möglich: Ein Thema, ein Text oder ein Einstieg lässt sich auch am Vorabend eines Termins oder direkt am Stand anpassen, ohne Release und ohne Beteiligung eines Dienstleisters.

Die Challenge fragt ausdrücklich nicht nur nach Pflege, sondern auch nach eigenständiger Weiterentwicklung. Diese ist über den Dashboard-Builder abgedeckt: Neue Themen, neue Ansichten und ganze zusätzliche Anwendungen entstehen mit wenigen Klicks, ohne Beauftragung. Der Funktionsumfang wächst zusätzlich über die Plattform selbst. So arbeiten wir derzeit an einer räumlichen Kommentierfunktion, mit der Hinweise direkt an einem Ort in der Karte hinterlegt werden, statt in Protokollen zu landen. Für den Digitalen Tisch wäre das der Schritt von der Darstellung zur Rückkopplung: Anmerkungen aus einem Gespräch am Stand oder aus einer internen Abstimmung bleiben verortet und werden ohne Medienbruch für die weitere Planung nutzbar.

Zur ausdrücklich gestellten Frage der Unabhängigkeit von einem externen Dienstleister unterscheiden wir inhaltliche Pflege und technischen Betrieb. Die inhaltliche Pflege liegt nach Einweisung vollständig bei der Auftraggeberin, hier ist kein Dienstleister erforderlich. Für den technischen Betrieb bestehen zwei gleichwertige Wege: Betrieb durch Plan4Better als gehostete Lösung oder Eigenbetrieb durch die Freie und Hansestadt Hamburg, etwa in einem städtischen Rechenzentrum oder innerhalb einer Urban-Data-Plattform. Weil die Plattform Open Source ist, ist der Eigenbetrieb kein Sonderfall und keine Verhandlungsfrage. Dass ein solcher Übergang in der Praxis funktioniert, zeigt ein vergleichbarer Fall aus unserem Portfolio: Bei der Anwendung Navi4All hostet die Stadt Kaiserslautern die Lösung nach geordneter Übergabe seit 2025 selbst.

Soweit für den Tisch codeseitige Anpassungen nötig sind, folgen wir einem Entwicklungsmodell, das langlebige Forks vermeidet. Erweiterungen werden von Beginn an so entworfen, dass sie an den Hauptzweig der Plattform anschlussfähig bleiben und dort aufgenommen werden können, statt als Sonderstand daneben weiterzuleben. Dieser Punkt entscheidet über die Kosten der späteren Jahre: Ein abgespaltener Sonderstand ist der häufigste Grund, warum individuell angepasste Software nach einiger Zeit teuer wird, weil sich Sicherheitsupdates und neue Funktionen der Basis nicht mehr einspielen lassen, ohne die Anpassungen jedes Mal erneut einzuarbeiten. Bleibt die Erweiterung im Hauptcode, profitiert die Lösung dagegen dauerhaft von der laufenden Entwicklung. Sehr spezifische Anforderungen, die sich fachlich nicht verallgemeinern lassen, werden über die plugin-basierte Architektur der Plattform umgesetzt. Sie bleiben damit vom Kern getrennt, ohne ihn zu verändern, und stehen einer Aktualisierung der Basis ebenfalls nicht im Weg.

Für die langfristige Wirtschaftlichkeit ergibt sich daraus: Das vorhandene Möbel und der Bildschirm bleiben erhalten, es entsteht keine Lizenzabhängigkeit von einem proprietären Präsentationssystem, der Betreiberwechsel bleibt jederzeit möglich, und die Anwendung profitiert von der laufenden Weiterentwicklung des GOAT-Ökosystems, das derzeit von über 50 Städten und Regionen genutzt wird. Zur Übergabe gehören Dokumentation und eine kurze Einweisung der redaktionell Zuständigen.

Siehe geschützte Angaben.