Hinter der Karte liegt die eigentliche Arbeit – Full-Stack-Entwickler Jonny über das Kulturkataster Berlin

Mehr als 2.350 Kulturorte stehen im Kulturkataster Berlin. Die Anwendung macht sie nach Bezirk und Kategorie auffindbar. Zusätzlich lassen sich thematische Kartenebenen einblenden, etwa um Kulturorte im Stadtraum besser einzuordnen. Für den Projektabschluss hat das Team Digital Services ein Feinkonzept für ein Content-Management-System (CMS) erarbeitet. Kulturbetreibende sollen ihre Stammdaten so künftig selbst pflegen können. Im Interview erklärt Full-Stack-Entwickler Jonathan Haudenschild, welche technische Arbeit hinter der Karte steckt und was gute Datenpflege mit Kulturplanung zu tun hat.

Räume für Kunst und Kultur sind in Berlin knapp – viele sind in den letzten Jahrzehnten verloren gegangen, andere an ihrem Standort gefährdet. Das Kulturkataster Berlin macht die kulturelle Vielfalt der Stadt erstmals systematisch sichtbar und schafft damit eine Datengrundlage für den Schutz und die Planung von Kulturräumen. Entwickelt hat es die Technologiestiftung Berlin im Auftrag der Kulturraum Berlin gGmbH.

Das Kulturkataster wirkt auf den ersten Blick wie ein Stadtplan von Berlin. Was musste technisch passieren, damit daraus mehr wird als eine Visualisierung der Kulturorte?

Jonny:  Die Karte ist nur die sichtbare Schicht. Darunter greifen Datenmodell, API-Schnittstellen, Suche, Filterlogik, Rollenverwaltung und Datenpflege ineinander. Als Fullstack-Framework bildet Next.js die technische Grundlage der Webanwendung, während Supabase unter anderem Datenbank und Authentifizierung bereitstellt. Für die Kartendarstellung kommt OpenLayers in Verbindung mit MapTiler zum Einsatz. Ein Kulturort wird dabei als strukturierter Datensatz mit Adresse, Kategorien, Kontaktinformationen, Status und weiteren Angaben abgebildet. Je nach Rolle sind diese Informationen öffentlich sichtbar, redaktionell bearbeitbar oder geschützt.

Wir mussten deshalb zwei Blickrichtungen zusammenführen: Gäst:innen sollen Kulturorte leicht finden. Die Redaktion braucht ein System, um Kulturdaten zu prüfen und zu verwalten. Auf Grundlage der von Kulturraum Berlin bereitgestellten Ansichten haben wir die Anwendung gebaut, erweitert und für die redaktionelle Arbeit vorbereitet.

Wo wurde es technisch knifflig: bei der Karte, bei den Daten oder bei der Verbindung von beidem?

Jonny: Bei der Verbindung, ganz klar. Eine Karte sieht ruhig aus, aber darunter treffen Geodaten, Bedienoberfläche und Rechteverwaltung ineinander. Die Geodaten müssen korrekt projiziert und im Browser schnell geladen werden. Für mich war überraschend, wie viele Projektionen und Darstellungsvarianten es gibt.

Gleichzeitig braucht die Oberfläche eine klare Logik für Nutzer:innen und die Redaktion. Wer welche Kulturorte sehen, ändern oder neu anlegen darf, musste technisch sauber abgebildet werden. Dazu kommen reale Daten: Adressen fehlen, Kategorien ändern sich, Kontakte sind veraltet oder uneindeutig. Gemeinsam mit Kulturraum Berlin haben wir Regeln erarbeitet, wie die Anwendung mit solchen Unschärfen umgeht.

Kulturorte verändern sich. Wie wurde das geplante CMS gedacht, damit Kulturbetreibende ihre Stammdaten künftig selbst pflegen können?

Jonny: Ein einfaches Formular hätte nicht gereicht. Kulturbetreibende sollen eigene Stammdaten einsehen und Änderungen einreichen können. Die Redaktion muss nachvollziehen, wer etwas geändert hat, und entscheiden, was veröffentlicht wird.

Dafür haben wir einen Workflow mit Rollen, Gruppen und Freigaberechten entworfen – eben ein Rechte- und Rollenkonzept, das auf die Bedürfnisse aller Kulturschaffenden in Berlin zugeschnitten ist. Der klassische Ablauf sieht so aus: Eine kulturschaffende Person kann neue Kulturorte einreichen oder Angaben ändern. Die Redaktion prüft diese Einträge und gibt sie frei. Weil die Anforderungen während des Projekts gewachsen sind, haben wir das Rollenmanagement dynamisch angelegt. Berechtigungen hängen nicht starr an einzelnen Personen, sondern an Rollen und Gruppen. Die Redaktion kann beispielsweise beliebige Rollen und Gruppen erstellen, die sich nach Kultursparten, Bezirken und sonstigen Eingruppierungen richten. Da dieses Rollenmanagement eine gewisse Komplexität aufweist, mussten wir potenzielle Schwachstellen ermitteln und Penetrationstests durchführen.

Wie sicher ist die öffentlich zugängliche Anwendung, und welche Rolle spielen dabei Schwachstellen- und Penetrationstests?

Jonny: Eine Anwendung mit öffentlichen Formularen, Schnittstellen und Login-Bereich muss mehr leisten als funktionierende Eingaben. Sie muss sicherstellen, dass Fehlverhalten nicht zu unbefugten Zugriffen führt. Und Penetrationstests prüfen genau das: Sind Formulare geschützt? Greifen Berechtigungen? Kann jemand Daten sehen oder ändern, die außerhalb der eigenen Rolle liegen?

Die Tests haben insgesamt unseren Blick auf die Anwendung verändert. Statt nur in Funktionen zu denken, haben wir vor allem auch Angriffsflächen, Protokolle und Wartung betrachtet und die Anwendung systematisch nach gängigen Sicherheitsprinzipien und Best Practices analysiert.

Welche Erfahrung aus dem Kulturkataster sollte in künftige Karten- und Datenprojekte der Technologiestiftung einfließen?

Jonny: Ein Kartenprojekt wirkt auf den ersten Blick schnell überschaubar. Tatsächlich steckt aber viel Arbeit im Datenmodell. Wir haben es mehrfach überarbeitet, weil Anforderungen erst im Laufe des Projekts klarer wurden. Für künftige Projekte würde ich früher auf ein dynamischeres Datenmodell setzen.

Außerdem lohnt sich wiederverwendbare Technik. Suche, Filter, Geodaten, Rollen, Exporte, Datenpflege und Barrierefreiheit tauchen in vielen Projekten wieder auf. Wenn diese Bausteine sauber angelegt sind, spart man auch bei späteren Anwendungen Zeit. Außerdem bleiben sie besser wartbar. Offene Standards machen Austausch und Nachnutzung einfach leichter.

Das Projekt steht kurz vor dem Abschluss: Die Anwendung ist öffentlich unter kulturkataster.berlin erreichbar. Mit dem Feinkonzept für das Content-Management-System liegt zudem der Bauplan für den nächsten Schritt vor – ein mehrstufiger Redaktionsworkflow mit individuellen Rollen, Gruppen und Freigaben, über den Kulturbetreibende ihre Stammdaten künftig selbst pflegen können. Weil die Anwendung auf offenen Standards basiert und Open Source veröffentlicht wird, ist sie übertragbar: auf jede Stadt, die ihre Kulturdaten nutzen möchte, um Kultur vor Ort sichtbar zu machen und politische Entscheidungen mit einer soliden Datengrundlage zu unterstützen.

Berliner Kulturkataster