Nachdem ich im ersten Teil dieser kurzen Serie einen Blick auf die Geschichte des digitalen Kartendesigns im Allgemeinen und im zweiten Teil auf die aktuelle Situation des Kartendesigns in OpenStreetMap geworfen habe, werde ich nun in diesem letzten Teil speziell darauf eingehen, was die OpenStreetMap Foundation derzeit auf diesem Gebiet zu verfolgen scheint und in welche Richtung das wahrscheinlich gehen wird.
Die Geschichte der Bereitstellung von Karten durch die OSMF
Die OSMF hat seit einiger Zeit einen recht erratischen Kurs in Bezug auf das Rendering und die Bereitstellung von Karten für die OSM-Gemeinschaft verfolgt. In der Vergangenheit wurde ein erheblicher Anteil der IT-Ressourcen des OSMF in das Rendering der Standard-Kartenebene auf openstreetmap.org gesteckt. Und obwohl es Diskussionen gab und schließlich eine Richtlinie entwickelt wurde, wer diesen Kacheldienst unter welchen Bedingungen nutzen darf, hat die OSMF nie wirklich einen klaren Zweck für diesen Dienst oder die Bedingungen für die Wahl von OpenStreetMap Carto als Stil dafür festgelegt. Es gibt eine Reihe von Anforderungen für die Aufnahme von Kartenebenen in osm.org – die größtenteils extern gehostet werden -, aber bis heute ist nicht definiert, was OSM-Carto als Stil qualifiziert, in den die OSMF beträchtliche Ressourcen für die Darstellung als Karte investiert. Ich habe als einer der OSM-Carto-Maintainer dieses Versäumnis immer wieder kritisiert, weil es auch bedeutet, dass die OSMF keine Verantwortung für die Entscheidung übernimmt, dies zu tun.
Im Jahr 2021 hat der OSMF-Vorstand in einer Umfrage unter der OSM-Gemeinschaft die Frage nach der Zukunft der von der OSMF angebotenen Kartendienste gestellt und damit der OSM-Gemeinschaft zum ersten Mal zu verstehen gegeben, dass in diesem Bereich Änderungen in Erwägung gezogen werden. Die Frage war sehr vage und unklar formuliert (was ich schon damals kritisierte) und die Antworten waren dementsprechend nicht eindeutig. Der Begriff vector tiles war damals schon zu einem magischen Wort ohne genau definierte Bedeutung geworden, in das jeder seine Hoffnungen und Träume zu projizieren schien.
Später im Jahr kündigte die OSMF an, dass sie – auf operativer Ebene – einige Tests in diesem Bereich durchführen würde. Aber selbst auf Nachfrage wurde keine Gesamtstrategie genannt, in die diese Initiative eingebettet wäre, und es wurde klar, dass es sich um eine Initiative aus dem operativen Bereich handelte und nicht um einen Teil einer größeren Strategie des OSMF zu jener Zeit. Das Interessante daran ist, dass es sich bei dieser Ankündigung zwar nur um eine relativ kleine operative Investition in die Erprobung handelte, bei der überhaupt kein Geld im Spiel war, dass es aber ziemlich schnell Reaktionen von wirtschaftlich interessierten Parteien gab, die sich dafür einsetzten, dass ihre Lieblingstools auch von der OSMF berücksichtigt wurden.
Lange Rede, kurzer Sinn: Im Jahr 2021 war klar, dass (a) die OSMF keine substanzielle Strategie für die Zukunft der vom OSMF angebotenen Kartendienste hatte, (b) es bereits eine Menge Leute gab, die ihre Hoffnungen in das vage Konzept der vector tiles projizierten und lautstark forderten, dass das OSMF diese Hoffnungen auf magische Weise erfüllen solle, während die ganze Angelegenheit weiter politisiert wurde, weil wirtschaftlich interessierte Parteien die Chance zu profitieren sahen und begannen, beim OSMF Lobbyarbeit zu betreiben, um die Pläne zu ihren Gunsten zu ändern – und (c) dass das eigentliche Kartendesign in dem ganzen Prozess nicht einmal am Rand eine Rolle spielen würde. Danach gab es für einige Zeit keine öffentlich sichtbaren Fortschritte mehr. Der im Juli 2021 beschlossene Strategieplan sah lediglich eine Entwicklungsplattform für Vektorkacheln durch Freiwillige vor – was wohl die Interpretation der Umfrageergebnisse durch den Vorstand zu diesem Zeitpunkt widerspiegelt, das Thema Initiativen aus der Community überlassen.
Irgendwann im Jahr 2022 änderte sich etwas. Im November wurde die Angelegenheit in einem der Sitzungsprotokolle kurz erwähnt. Von da an lässt sich aus den Protokollen ein bemerkenswerter zeitlicher Ablauf der Diskussionen und Entscheidungen rekonstruieren, der ein recht reichhaltiges Sittengemälde des Innenlebens des OSMF zeichnet. Obwohl dies für das Thema dieses Blog-Beitrags wenig relevant ist, empfehle ich den Lesern, sich die Zeit zu nehmen und das alles durchzulesen.
- November 2022
- Februar 2023
- April 2023
- Mai 2023
- Juni 2023
- Juli 2023: Teil 1 Teil 2
- September 2023: Teil 1 Teil 2 Teil 3
- November 2023
- Dezember 2023:
Alle Beschlüsse der Sitzung vom 11.12.2023 wurden nachträglich entfernt – einschließlich des Beschlusses über die Ausgabe von 40k EUR, eine kurze Zusammenfassung findet sich in der Protokollliste. Man beachte – unter anderem – dass die Sitzung während der Vorstandswahl 2023 stattfand und Angelegenheiten besprochen wurden, die die Eignung eines der Vorstandskandidaten bei dieser Wahl betrafen. - Januar 2024
Die für das Thema dieses Beitrags bedeutsame Information ist, dass die OSMF, als sie Paul Norman mit der Arbeit beauftragte, die sich nun dem Ende zuzuneigen scheint, offenbar noch keine eigene Strategie für die Kartendienste der OSMF hatte. Und es ist unklar, ob sie de facto das, was Paul in seinem Vorschlag skizziert hat (der hier veröffentlicht wurde und der in Bezug auf die strategischen Ziele eher vage ist), als De-facto-Strategie der OSMF übernommen haben oder ob sie in der Zwischenzeit eine andere Art von Plan entwickelt haben. Was jedoch ziemlich offensichtlich ist, ist, dass sie sicherlich die Ergebnisse der Ausgabe von 42k EUR in irgendeiner Form praktisch nutzen wollen. Und das ist es, worauf ich die folgenden Überlegungen stützen werde, ich mache keine weiteren Annahmen darüber hinaus.
Der Prozess der Kartenproduktion
Was ich hier tun werde, ist zu diskutieren, was das wahrscheinlich für die OSM-Community bedeutet. Um das zu erklären, hier zunächst, wie der aktuelle Aufbau der Standard-Kartenebene auf openstreetmap.org abläuft (basierend auf OSM-Carto):

Der praktische Ablauf der Kartenproduktion und des Feedback-Kreises für die mapper mit OSM-Carto (oder ähnlichen Stilen) – Link führt zu einer größeren Version
Ich habe dargestellt, welche Teile dieses Prozesses von wem kontrolliert werden: Das graue Rechteck mit der Überschrift Map design wird von den OSM-Carto Kartendesignern und Maintainern kontrolliert. Die Mapper, die die Karte benutzen, entscheiden, welche Teile sie ansehen und was sie kartieren wollen, und die OSMF (Operations) kontrolliert die OSM-Datenbank und die Rendering-Kette, bis die gerenderten Kacheln an den Kartennutzer geliefert werden. Einige werden vielleicht irritiert sein, weil ich den Rendering-Prozess mit tile data (internal only) aufgeteilt habe, um den Prozess besser mit dem unten gezeigten vector-tiles-Prozess vergleichbar zu machen. Diese Aufteilung ist für den Betrieber nicht sichtbar, sie existiert nur intern in Mapnik. Sie ist jedoch für den Kartendesigner sichtbar, der die Abfrage zur Erzeugung der Kacheldaten und die Regeln zum Zeichnen der Kacheln aus diesen Daten, wie sie im CartoCSS-Code formuliert sind, separat entwickelt.
Wichtig ist, dass die Rendering-Datenbank im Falle von OSM-Carto bewusst generisch gehalten ist. Dies ermöglicht es, mehrere völlig unterschiedliche Stile aus der gleichen Datenbank zu rendern, nahezu beliebige Stiländerungen vorzunehmen, ohne die Rendering-Datenbank neu zu laden, und es vereinfacht auch das systematische Testen des Stils als Ganzes, da der Datenbankimport nicht Teil solcher Tests sein muss.
Im Falle von OSM-Carto sind die Prozesse im Bereich des Kartendesigns relativ einfach. Zum Vergleich: So sieht das mit dem Alternative-Colors-Stil aus.
Wie viele andere Kartenstile erweitert der AC-Style die Rendering-Datenbank um einige stilspezifische Daten. In meinem Fall sind dies einige SQL-Funktionen, hauptsächlich für die Interpretation von Tags und die geometrische Verarbeitung, sowie die Baumsymbolik (die in der Datenbank enthalten sein muss, um die Einschränkungen von Mapnik zu umgehen – siehe den Blogbeitrag über das Rendering von Bäumen). Dies sind jedoch statische Daten, die sich nicht ändern, wenn sich der Inhalt der Hauptdatenbank ändert.
Hier ist nun, wie sich der gesamte Prozess ändern würde, wenn Pauls Arbeit in der entwickelten Form umgesetzt würde (basierend auf meinem Verständnis dessen, was kommuniziert wurde – ich habe dieses Setup nicht selbst getestet).

Der erwartete Kartenrendering-Prozess und die Mapper-Feedback-Schleife mit minütlich aktualisierten Vektorkacheln (wie sie derzeit von der OSMF geplant werden) – Link führt zu einer größeren Version
Von der operativen Seite her bedeutet dies – kurz gesagt – dass der letzte Teil der traditionellen Rendering-Kette, wie oben für OSM-Carto gezeigt, abgeschnitten und an den Kartennutzer ausgelagert wird. Dies reduziert den Ressourcenbedarf für die Bereitstellung der Kacheln erheblich und erlaubt gleichzeitig die Betrachter-spezifische Anpassung des eigentlichen Renderings der Kacheln, ohne dass dafür zusätzliche Ressourcen benötigt werden.
Das ist – kurz gesagt – die ganze Magie der Vektorkacheln. In der Realität ist es natürlich nicht ganz so einfach – aus mehreren Gründen.
Erstens: Damit die Auslagerung des Renderings an den Kartennutzer funktioniert, müssen Sie die übertragene und am Rendering beteiligte Datenmenge massiv reduzieren. In den gezeigten Diagrammen habe ich große Datenmengen mit den breiten roten Pfeilen gekennzeichnet. Und die von Mapnik intern verarbeiteten Kacheldaten sind typischerweise sogar wesentlich größer als die in der Rendering-Datenbank (die bei einem vollständigen Planet-Import mehrere hundert GB groß ist), weil die Abfragen Geometrieverarbeitung betreiben, die häufig zusätzliches Datenvolumen erzeugt. Im Falle der clientseitig gerenderten Vektorkacheln muss dieses Volumen mit Hilfe von verlustbehafteter Datenkompression massiv reduziert werden. Und trotz dieser Bemühungen (und ihrer negativen Nebeneffekte) sind die Bandbreitenanforderungen für die Anzeige eines dieser Stile in der Regel viel höher als für eine herkömmliche, auf Rasterkacheln basierende Karte.
Zweitens: Die Rendering-Datenbank ist nicht mehr generisch. Das ist zwar nicht unvermeidlich, aber ich kenne praktisch keine clientseitig gerenderte Vektor-Kachel-Konfiguration, die eine generische Rendering-Datenbank verwendet.
Drittens: Das Kartendesign als eine Domäne, die Teile des gesamten Prozesses kontrolliert, ist verschwunden. Das erfordert natürlich eine ausführlichere Diskussion.
Oben habe ich erklärt, dass eines der Hauptversprechen von clientseitig gerenderten Vektorkacheln darin besteht, dass das tatsächliche Rendering für jeden Kartenbetrachter angepasst werden kann. Aber die Möglichkeit, das eigentliche Rendering anzupassen, bedeutet nicht, dass man auch das Kartendesign vollständig anpassen kann. In der Realität werden die meisten Entscheidungen über das Kartendesign schon bei der Generierung der Vektorkacheln getroffen, zum Teil aufgrund der Notwendigkeit, die Kachelgrößen klein zu halten. Diese bedeutet, dass alles, was für das gewählte Kartendesign nicht notwendig ist, aus den Daten entfernt werden muss. Oder andersherum gesehen: Der Versuch, selbst ein kleines Maß an Generizität des Kartendesigns in clientseitig gerenderte Vektorkacheln einzubringen, hat oft massive Auswirkungen auf die Bandbreitenanforderungen.
Praktisch alle clientseitig gerenderten Karten, die ich bisher gesehen habe, weisen eine Trennung zwischen den Personen/Organisationen auf, die für die Generierung der Vektorkacheln zuständig sind, und denjenigen, die den clientseitigen Teil des Kartendesigns entwickeln (den ich im Diagramm als Style Design bezeichnet habe). Und die Generierung der Vektorkacheln unterliegt in der Regel der Kontrolle von Softwareentwicklern und nicht von Kartendesignern – daher habe ich diesen Teil als software development bezeichnet. In dem von Paul entwickelten System ist dieser Teil in mehrere Komponenten aufgeteilt, die von verschiedenen Personen kontrolliert werden.
Das bedeutet, dass Kartengestalter in einem solchen System an den Rand gedrängt würden und nur noch ein bisschen mit Farben, Linienbreiten und Punktsymbolen spielen dürfen. Die eigentliche Kontrolle über das Kartendesign läge bei den Softwareentwicklern, die das Schema und die Produktion der Vektorkacheln kontrollieren und deren Hauptanliegen nicht das Kartendesign, sondern die betriebliche Effizienz und die Begrenzung der Größe der Vektorkacheln ist – die technokratische Richtung wie ich sie in meiner Diskussion über OSM-Carto beschrieben habe. Theoretisch, so könnte man argumentieren, könnte man die Stildesigner hierarchisch über die Softwareentwickler stellen, die das Schema der Vektorkacheln kontrollieren, und von letzteren verlangen, dass sie sich an die Wünsche der Ersteren halten. In der heutigen OSMF wäre dies jedoch völlig unrealistisch, wie die Tatsache beweist, dass Anforderungen des Kartendesigns bei der Entwicklung dieses Systems überhaupt keine Rolle gespielt haben. Wie ich in der Diskussion über OSM-Carto geschrieben habe, wäre aus meiner Sicht der einzige Weg für einen nachhaltigen Fortschritt in der Kartengestaltung die Zusammenführung der technokratischen und der künstlerischen Richtung in einem einzigen kooperativen Projekt mit klaren gemeinsamen Zielen, denen sich alle verbunden fühlen.
Jenseits der Magie
Was bleibt also von der Magie der Vektor-Kacheln und ihren Versprechen angesichts dieser Tatsache? Der geringere Ressourcenbedarf für den Betrieb eines Kachelservers ist ein realer Vorteil. Aber nur, wenn man es rein aus der mikroökonomischen Perspektive des Kachelserver-Betreibers betrachtet. Aus makroökonomischer Sicht ist der Ressourcenbedarf in der Summe sogar höher, da das eigentliche Rendering für jeden Kartennutzer separat erfolgt. Clientseitige Vektorkacheln sind nicht Tiles@home.
Aber verstehen Sie mich nicht falsch, es gibt natürlich auch Vorteile von clientseitig gerenderten Karten. Einer der wichtigsten ist die Möglichkeit, interaktivere Karten auf der Grundlage der an den Client übertragenen semantischen Daten zu erstellen. Und wenn Sie die Bandbreite investieren, um zusätzliche Daten in die Kacheln aufzunehmen, kann die individuelle Anpassung der Karte ein echter Vorteil sein. Aber es gibt hier keine Magie, das alles ist mit Kosten verbunden.
Die eigentliche Frage ist aber, was das für die Kartengestaltung bedeutet. Wenn ich die organisatorische Trennung zwischen Stildesign und Vektor-Kachelerzeugung für den Moment beiseite lasse, bleibt die Frage, was sich ändert, wenn man für einen clientseitigen Renderer entwirft, im Vergleich zu einer Mapnik-basierten Rendering-Kette. Ich fürchte, da gibt es noch einige wirklich große Probleme. Ich habe diese bereits in meinem Beitrag über die Anforderungen, die das regelbasierte Kartendesign an die verwendeten Werkzeuge stellt, näher erläutert.
Jetzt kommt aber das vermutlich für manche Leser Überraschende: All dies bedeutet nicht, dass das OSMF etwas falsch gemacht hat, indem sie in die Implementierung einer Toolchain für minütlich aktualisierte Vektorkacheln investiert hat. Natürlich abgesehen davon, dass der Vorstand im Beschaffungsprozess auf so vielen verschiedenen Ebenen episch versagt hat. Wenn ich das für den Moment ignoriere, dann ist die Investition in diese Toolchain eine absolut vernünftige Entscheidung. Client-seitig gerenderte Vektorkacheln sind – unabhängig von ihrer praktischen Bedeutung für die OSM-Gemeinschaft – derzeit unter kommerziellen Kartenanbietern die wichtigste Technik zur Erstellung interaktiver Webkarten. Und diese kommerziellen Akteure haben zwar erheblich in die Toolchains für diese Art der Kartenerstellung investiert, haben aber nur ein sehr geringes Interesse an minütlichen Aktualisierungen. Diese sind ein relativ einzigartiges Interesse der OSM-Gemeinschaft. Daher ist es eine vernünftige Idee, dass das OSMF sich einbringt, um diesen speziellen Bedarf zu decken.
Wenn die OSMF nun das Gefühl hat, dass diese Argumentation nicht ausreicht, um das Projekt zu rechtfertigen, und stattdessen das Bedürfnis verspürt, einen billig zusammengestückelten postmodernen OpenMapTiles/Mapbox-Klon mit minutlichen Updates als Hauptkarte auf openstreetmap.org herauszubringen, wäre das bedauerlich. Aber im Großen und Ganzen würde es nicht wirklich viel bedeuten. Es würde sicherlich nicht die strukturellen Probleme im praktischen Kartendesign in und um die OSM-Gemeinschaft lösen, die ich im vorigen Beitrag erläutert habe.
Deutsche Version dieses Textes auf Grundlage einer automatischen Übersetzung mittels deepl.