Anknüpfend an meinen ersten Bericht von der SotM-Konferenz in Mailand möchte ich ein paar Dinge mehr im Detail diskutieren. Das erste davon ist das Thema Vektor-Kacheln auf osm.org.

Etwas Hintergrund dazu: Der Begriff Vektor-Kacheln (vector tiles) hat sich in der OSM-Community in den letzten Jahren zu einer Art weißem Elefanten entwickelt. Mir scheint dass diese über die Jahre als magische Lösung für so ziemlich jedes Problem bei der Kartenproduktion im OSM-Projekt vorgeschlagen wurde.

Wenn der Begriff mit Sinn und Verstand und nicht nur als leere Phrase verwendet wird, geschieht dies für zwei recht verschiedene Dinge:

• Für die Idee, die Ergebnisse von Abfragen in einem Framework zur gekachelten Darstellung von Karten zwischenzuspeichern. In einem klassischen Karten-Darstellungs-System wie OSM-Carto wird die Karte aus den Ergebnissen einer Reihe von Abfragen von Daten aus einer räumlichen Datenbank (meist Postgis) für das Gebet der jeweiligen Kachel generiert. Das Ergebnis dieser Abfragen wird gleich nach der Berechnung der Kachel weggeworfen. Indem man die Ergebnisse der Abfragen zwischenspeichert lassen sich verschiedene Varianten eines Kartenstils und verschiedene Gestaltungen – wie zum Beispiel verschiedene Sprachen bei den Beschriftungen oder verschieden Farb-Schemata oder Kacheln mit unterschiedlicher Auflösung – deutlich effizienter produzieren.
• Für die Idee, die eigentliche Darstellung auf dem Client (also dem Web-Browser) statt dem Server zu produzieren auf Grundlage von Vektor-Daten in Kachel-Form. Dies bringt die selben Vorteile mit sich wie der erste Ansatz, erlaubt es aber daneben vor allem dem Karten-Produzenten auch, die Karten-Darstellung und die dafür benötigte Computer-Kapazität an den Nutzer auszulagern.

Man kann sich vermutlich vorstellen, dass es erhebliche technologische Gemeinsamkeiten zwischen den Umsetzungen dieser beiden Ansätze gibt so dass die Verwendung eines gemeinsamen Begriffes dafür einen gewissen Sinn macht. Aber es ist dennoch wichtig, immer klar zwischen beidem zu unterscheiden, wenn man über Vektor-Kacheln redet.

Der erste Ansatz ist in der Praxis recht unproblematisch. Er wird heute weit verbreitet verwendet ohne dass dies für den Nutzer unbedingt erkennbar ist. Von den Karten, die auf openstreetmap.org ausgewählt werden können, verwenden mehrere diese Methoden und es gibt auch einen Port von OSM-Carto, welcher Vektor-Kacheln auf der Server-Seite verwendet. Der zweite Ansatz jedoch ist schwieriger, denn damit dies ohne erheblich Performance-Einbußen funktioniert dürfen die Vektor-Kacheln, welche zum Client übertragen werden, nicht viel größer sein als traditionelle Raster-Kacheln. Und dies ist extrem schwierig und wird praktisch kaum jemals erreicht. Anhand einer spezifischen Rendering-Aufgabe, der Darstellung von Polygonen in gleichförmiger Farbe, habe ich das vor einiger Zeit mal detaillierter diskutiert. Was Karten-Produzenten tun, um mit diesem Problem klar zu kommen, ist der Einsatz massiver verlustbehafteter Vektor-Daten-Kompression. Im Vergleich zu verlustbehafteter Kompression von Raster-Bildern, wo Jahrzehnte von Forschung in die Verfahren gegangen sind, die wir heute verwenden und wo es auch eine Vielzahl spezialisierter Verfahren für spezifische Anwendungen gibt (wie zum Beispiel die Kompression von Digitalkamera-Rohdaten) sind die hier verwendeten Methoden recht primitiv. Man kann dies eigentlich in allen Karten, welche auf dem Client aus Vektor-Kacheln berechnet werden, sehen, wo das Kartenbild primär durch die Anforderungen der Daten-Reduktion und weniger durch kartographische Erfordernisse definiert wird und wo ein erheblicher Teil der dem Nutzer durch die Karte kommunizierten Informationen Kompressions-Artefakte sind.

So viel zum allgemeinen Hintergrund. Was ich hier diskutieren und kommentieren möchte ist ein Vorschlag von Richard Fairhurst, ein Projekt zur Bereitstellung von Vektor-Kacheln für die Darstellung auf Client-Seite (der zweite Ansatz oben) auf OSMF-Infrastrukturen zu starten. Es gab ein paar Blogposts und Diskussionsbeiträge dazu und ein Spontan-Treffen bei der SotM-Konferenz zu dem Thema.

Ganz allgemein und wie zuvor schon erwähnt unterstütze ich die Initiative zur Vergrößerung der Vielfalt von durch die OSM-Gemeinschaft produzierten Karten. Aber dadurch, dass das Thema ein solcher weißer Elefant ist gibt es auch eine Menge blinden Enthusiasmus drumherum, der leicht dazu führen kann, dass man wichtige Dinge dabei vergisst. Ich möchte hier ein paar davon erwähnen – einige davon habe ich schon bei dem Treffen auf der SotM vorgebracht, andere sind neu.

1) Es ist im Moment vollkommen unmöglich, alle Funktionen des OSM-Standardstils für die OSM-Comunity mit einem Framework auf Grundlage von auf dem Client berechneten Vektor-Kacheln zu erfüllen. Dies mag vielleicht nicht sonderlich relevant erscheinen, da OSM-Carto ja im Moment ungünstigerweise auch viele der Anforderungen an die Karte oft ignoriert (siehe hier) – der fundamentale Unterschied ist jedoch, dass dies bei OSM-Carto jeweils nur eine schlechte Entscheidung ist, die man recht einfach ändern kann, mit auf dem Client dargestellten Vektor-Kacheln jedoch ist dies deutlich schwieriger.

Die meisten bei dem Treffen auf der SotM Anwesenden waren sich dieser Einschränkung durchaus bewusst, aber ich fürchte, dass das Bedürfnis, diesen Ansatz durchzudrücken, sehr stark ist und die Akzeptanz diese Tatsache im Wesentlichen dazu dient, potentielle Opposition zu beruhigen während manche im Grunde doch überzeugt davon sind, dass der weiße Elefant eine Lösung für alle Probleme ist. Deshalb hier noch mal ganz deutlich: Auf dem Client dargestellte Vektor-Kacheln sind derzeit fundamental ungeeignet, Karten zu produzieren, die die verschiedenen Kern-Funktionen des OSM-Standardstils alle erfüllen und es sind keine technologischen Innovationen am Horizont zu erkennen, die versprechen, dass sich dies ändert.

2) Es wäre meiner Meinung nach wichtig mal grundsätzlich zu diskutieren, ob die OSMF in diesem Bereich wirklich aktiv werden soll. Wenn man sich die OSMF-Ziele anschaut sieht man, dass die Bereitstellung von Karten für alle möglichen Zwecke nicht Teil der Ziele ist. Die Tatsache, dass der derzeitige OSM-Standardstil eine Reihe wichtiger Funktionen für die OSM-Community und das öffentliche Bild von OpenStreetMap erfüllt, ist allgemein akzeptiert (auch wenn man sich natürlich darüber unterhalten kann, wie gut der Stil diese Funktionen tatsächlich erfüllt). Ich denke also dass ein neues, zusätzliches Projekt zur Karten-Produktion, um eine umfangreiche Unterstützung durch die OSMF in Form von Computer-Infrastruktur zu rechtfertigen, darlegen müsste, was für wichtige Funktionen es erfüllen möchte und demonstrieren, dass es dazu auch im Sinne der OSMF-Mission in der Lage ist.

Mir scheint es nicht ganz unwahrscheinlich, dass solch ein Projekt von der Perspektive des Nutzers nicht viel mehr wäre als eine Kopie des OpenMapTiles-Projektes oder etwas ähnliches und in diesem Fall wäre es denke ich fair zu fragen, was es rechtfertigt, dass die OSMF Ressourcen in ein solches Projekt investiert.

3) Paul Norman hat in der Diskussion einen anderen wichtigen Punkt angeschnitten: Die Zahl der Entwickler in der OSM-Community mit der Fähigkeit und dem Interesse, produktiv an einem solchen Karten-Entwicklungs- und Karten-Gestaltungs-Projekt mitzuwirken, ist recht begrenzt. Das bedeutet, dass die Leute darüber letztendlich quasi mit den Füßen abstimmen werden. Das ist ähnlich wie das was ich letztes Jahr über OSM-Carto geschieben habe: Die Frage, die vermutlich über den Erfolg eines solchen Community-Projektes entscheidet (egal ob dieses OSMF-Infrastruktur nutzt oder nicht) ist ob es in der Lage ist, genügend kompetente und engagierte Entwickler anzuziehen, um tatsächlich seine Ziele zu erreichen.

Nicht dass dies sonderlich von Bedeutung ist (da ich eh nicht sonderlich qualifiziert wäre, beim Start eines solchen Projektes mitzuwirken) aber ich habe im Moment nur ein recht geringes Interesse in dieser Richtung, denn meine derzeitigen Interessen im Bereich durch die Community produzierter Karten liegt eher in den Bereichen, wo der Ansatz die Karten auf dem Client zu berechnen ungeeignet ist. Das ist jedoch keine unveränderliche Entscheidung, es ist durchaus möglich, dass andere Aspekte solch ein Projekt für mich interessant machen.

So weit zu den konkreten Plänen für einen zusätzlichen Typ von Karten auf osm.org welche ich wie gesagt als Beitrag zur Vergrößerung der Vielfalt an Community-produzierten Karten sehr begrüßen würde. Ich möchte jedoch auch noch etwas grundsätzlicheres zum Thema der Zukunft von OSM-Community-produzierten Karten generell sagen:

Der Beitrag von Richard beginnt mit einer zutreffenden Analyse davon, was OpenStreetMap von den großen kommerziellen Wettbewerbern unterscheidet. Der Visualisierungs- und Karten-Darstellungs-Teil von OpenStreetMap, also der Standardstil, hat historisch einen großen Anteil daran, dass sich OSM so entwickelt hat. OpenStreetMap hätte sich vermutlich deutlich anders entwickelt, wenn seine wichtigste Plattform zu Darstellung der Daten versucht hätte, Google Maps nachzuahmen. Stattdessen hat der Standardstil wie ich früher schon dargestellt habe, oft die Grenzen von dem was technisch und kartographisch machbar war erweitert und zwar in eine deutlich andere Richtung als wohin sich Google und andere bewegen. Und mir scheint, dass dies einen erheblichen Anteil daran hatte, dass sich OSM auf seine Kern-Werte konzentrieren konnte und nicht den kurzfristigen Trends gefolgt ist, die jeweils den größten kurzfristigen Erfolg versprochen haben. Dass dies in jüngerer Zeit in OSM-Carto deutlich weniger geworden ist, ist etwas was viele intensiv in OSM involvierte Leute spüren und dies hat vermutlich einen erheblichen Anteil daran, dass einige jetzt auf den weißen Elefanten setzen.

Aber zu versuchen, das Problem zu lösen indem man quasi unter die Flügel von Mapbox oder von anderen Konzernen schlüpft und das öffentliche Bild von OSM vollständig auf Technologie stützt, welche von kommerziellen Spielern entwickelt und kontrolliert wird, wäre meiner Meinung nach ein großer Fehler. Open Source oder nicht – die Erfahrung mit Mapnik und Carto hat recht gut demonstriert, dass OSM im Moment die Ressourcen und die Expertise fehlen, die Entwickung eines Karten-Rendering-Frameworks für die Bedürfnisse des Projektes unabhängig von entweder den großen kommerziellen OSM-Nutzern oder von der breiteren FOSS-Community voranzutreiben. OSM wird entweder in die Verbesserung dieser Fähigkeiten investieren müssen (was nicht wirklich realistisch ist, denn das Projekt hat nicht den Organisationsgrad und die Ressourcen dafür) oder man wird mit der FOSS-Community zusammenarbeiten müssen um die unabhängige Entwicklung von Werkzeugen zur Kartendarstellung im Sinne der aktuellen und zukünftigen Erfordernisse von OSM in technologischer und kartographischer Hinsicht voranzutreiben. Projekte in diesem Bereich gibt es schon eine ganze Menge (wie zum Beispiel Mapserver) aber sie werden derzeit vor allem für die Bedürfnisse kleinerer kommerzieller Nutzer und öffentlicher Einrichtungen entwickelt. Solche Projekte dazu zu bringen, Karten der OSM-Community als bedeutendes Anwendungsgebiet einzuschließen oder neue Projekte für die Bedürfnisse von OSM zusammen mit der FOSS-Community zu initiieren, wäre ein praktikabler Ansatz, um die Unabhängigkeit von OSM in Bezug auf die zukünftige Karten-Entwicklung sicherzustellen.

Und ja, Vektor-Kacheln (im generischen oben beschriebenen Sinn, weniger im Sinne eines spezifischen Dateiformates, welches von Mapbox kontrolliert wird) könnten recht wahrscheinlich Bestandteil solcher Entwicklungen sein. Sie sind jedoch nicht der weiße Elefant, auf den viele hoffen.