Art History

Projektaufbau

Im ersten Schritt des Projektes musste entschieden werden, wo die Website erreichbar sein soll und welche Strukturen für ihr Funktionieren benötigt werden. Das Projekt besteht aus drei Teilen: der öffentlichen Website (Frontend), einer Datenbank mit einer Schnittstelle für die Website (Backend und API) und einem Content Management System (CMS) für die Bearbeitung der Daten.

Frontend

Das Fundament der Website bildet das Frontend über statische HTML/CSS/JS-Dateien. Wie in einigen meiner anderen privaten Projekte werden diese in einem GitHub Repository von mir aufgeschaltet und verwaltet (github.com/piosteiner/art_history). Damit sind die Dateien Open Source und können von jeder Person nachvollzogen werden. Weiter bietet GitHub mit der Commit-Historie einen Changelog, sodass die Arbeit an der Website jederzeit nachvollzogen werden kann. Über GitHub Pages und einen DNS-Eintrag, der auf die eigene Domain verweist, werden alle statischen Daten auf der Zieladresse arthistory.piogino.ch aufgeschaltet.

Backend und API

Alle dynamischen Daten werden in einer Datenbank auf einem Server beziehungsweise einer virtuellen Maschine (VM) gespeichert. Die Besucher:innen der Website schicken über eine API Leseanfragen an die Datenbank. Sie sehen damit die Karte, die Zeitleiste, Künstler:innen, Kunstwerke, Kunsteinrichtungen, das Netzwerk der Beziehungen und alle Attribute zu den einzelnen Einträgen. Die API ist öffentlich und read-only. So können auch im Falle eines Bugs oder Exploits über die API keine Änderungen an der Datenbank vorgenommen werden. Die API ist über api.arthistory.piogino.ch erreichbar.

Von den Besucher:innen wird kein Login benötigt. Ein Login wäre ein mögliches Feature für ein längerfristiges Projekt, damit Besucher:innen ihre Sessions nicht nur lokal in ihrem Browser, sondern auf meinem Server speichern und damit von jedem Gerät und auch nach dem Löschen der Browserdaten weiterbearbeiten könnten. Zu Beginn wurden auch keine Sessions im Browser gespeichert, da dies eine zusätzliche Implementation benötigt hätte und noch nicht nötig war. Seit 2026-10-14 merkt sich die Website die letzte Auswahl auf der Startkarte lokal im Browser (localStorage), damit sie bei einem erneuten Besuch als "Continue" angeboten werden kann. Seit 2026-10-15 lässt sich zudem jede Auswahl als kurzer Link (/?v=<code>) teilen, ohne dass dafür ein Account nötig ist. Cookies setzt die Website keine. Eine Datenschutzerklärung nach dem Schweizer Datenschutzgesetz ist unter arthistory.piogino.ch/privacy aufgeschaltet.

Content Management System

Mit der API ist der Lesezugriff der Besucher:innen eingerichtet. Für die Bearbeitung der Datenbank braucht es zusätzlich einen Schreibzugriff, also ein CMS. Theoretisch hätte ein CMS am Anfang komplett ausgelassen und die Daten als Dateien über das GitHub Repository via Import-Script in Postgres geladen werden können. Da es aus meiner Sicht jedoch ein essenzieller Teil des Projekts ist und auch die Bearbeitung der Daten nachvollziehbarer macht, wird bereits zu Beginn des Projekts ein eigenes CMS erstellt. Das CMS ist über admin.arthistory.piogino.ch mit einem Admin-Account zugänglich (siehe Login und Sicherheit).

Daraus ergaben sich die folgenden konkreten Arbeitsschritte:

Die Bausteine des Backends

Das Backend benötigt im Grunde zwei Dinge: eine Schnittstelle zwischen Internet und Server-App, welche mit dem verbreiteten Webserver nginx gelöst wird, und ein Programm, welches die Daten zu Kunst, Künstler:innen, Orten und weiterem verwaltet. Hier bot sich eine Lösung mit MySQL an, welches bereits für andere Projekte auf meinem Server installiert ist, oder PostgreSQL (kurz Postgres), die für geografische Daten wohl beste Lösung, da PostgreSQL mit der Erweiterung PostGIS ein ausgereiftes System für Geodaten bietet. Ich habe mich für PostgreSQL entschieden.

Das Zusammenspiel der Bausteine lässt sich kurz so beschreiben:

Optionen für Landkarten

Es gibt verschiedene Optionen für Landkarten (folglich nur "Karten") für das Projekt. Bei der Entscheidung für die Kartendarstellung ist wichtig zu wissen, was die limitierenden Faktoren in diesem Projekt sind. Der zentralste Faktor sind die finanziellen Mittel. Für ein Projekt in diesem Rahmen, in welchem ich keine Projektmittel zur Verfügung habe und alle Kosten selbst tragen werde, versuche ich die Kosten so tief wie möglich zu halten. Das bedeutet, dass für das Projekt nach Möglichkeit keine weiteren Kosten anfallen sollen. Ich besitze bereits meine eigene Domain "piogino.ch" und auch den Server beziehungsweise die VM für das Backend. Beim Backend bin ich limitiert durch den geringen Speicherplatz meines Abonnements, folglich können keine grossen Datenmengen, wie sie bei Karten anfallen, auf der VM gespeichert werden. Das Frontend läuft über GitHub Pages. Eine Karte über das Frontend laufen zu lassen, ist keine Option, einerseits wegen der Limitierungen von GitHub, andererseits weil es kein sinnvoller Weg ist, die ganze Karte bei jedem Besuch über das Gerät der Besucher:innen zu laden. Die Kartenkacheln (Tiles) kommen deshalb von einem externen Anbieter.

Rendering Library für die Landkarte

Quelle 1: Map libraries popularity: Leaflet vs MapLibre GL vs OpenLayers Quelle 2: Self-Hosted Web Mapping Libraries: Leaflet vs OpenLayers vs MapLibre GL JS Compared

Leaflet ist wohl die bewährteste Lösung. Leaflet ist simpel, erprobt und hat ein riesiges Ökosystem. Damit ist Leaflet mindestens ein guter Startpunkt und bietet auch eine langfristige Lösung, wenn man nicht auf ein anderes System wechseln möchte. Die Einschränkung von Leaflet ist, dass es nicht vektorbasiert, sondern rasterbasiert ist (Raster Tiles). Das führt zu Limitationen in der Anpassbarkeit und weniger flüssigem Zoomverhalten auf der Karte. Die Lösung ist Open Source und kostenlos.

MapLibre GL JS ist ein Open-Source-Fork der ehemaligen JS Library von Mapbox. Es verwendet Vektorkacheln (Vector Tiles), was zu besserem Zoomverhalten, mehr Anpassungsmöglichkeiten und besserer Performance bei einer hohen Anzahl von Datenpunkten führt. Die Lösung ist Open Source und kostenlos.

Eine weitere Option ist OpenLayers, die sich für komplexe GIS eignet. OpenLayers bietet vermutlich die höchste Flexibilität, ist aber auch das komplexeste System.

Leaflet schliesse ich für die öffentliche Website aus, weil ich einerseits bereits Erfahrung mit Leaflet habe und gerne ein neues System lernen möchte, andererseits wirken die Vektorkacheln von MapLibre und OpenLayers auf mich deutlich attraktiver bei einem Projekt, bei dem sich Benutzer:innen viel über die Karte bewegen. Ein möglichst "smoothes" Verhalten der Karte ist hier aus meiner Sicht sehr wichtig. Verwendet wird MapLibre GL JS mit den Karten von MapTiler (Gratis-Kontingent). Der API-Schlüssel von MapTiler ist auf die Domain arthistory.piogino.ch beschränkt; ohne Schlüssel, etwa bei der Entwicklung, fällt die Karte auf die freien Kacheln von OpenFreeMap zurück. Im CMS dagegen wird Leaflet mit OpenStreetMap verwendet (siehe Karte im CMS).

Anpassung Server

Aufgrund der bereits laufenden Projekte und dem vermutlich recht grossen Ausmass des neu gestarteten Projektes habe ich mich dazu entschieden, den Server zu upgraden. Das Upgrade erfolgte in zwei Schritten: zuerst auf 2 CPUs und 40 GB Speicherplatz, danach auf 4 GB RAM (vorher 2 GB) und 60 GB Speicherplatz (ursprünglich 20 GB). Der Server läuft bei Infomaniak.