VersaTiles - freie Karten für alle

Hier ist das politopia-magazin, euer gesellschaftspolitisches Magazin bei Radio X, dem Frankfurter Bürgerradio. Schön, daß ihr dabei seid, schön, daß ihr zuhört. Ihr erinnert euch noch an die topografischen Karten? 1 zu 50.000 oder 1 zu 25.000? Die hatten so ein grünes Deckblatt, waren aber auch in Schwarz-Weiß.

Die waren natürlich immer super praktisch, wenn man auf einer Wanderung war oder wissen wollte, wie es in der Stadt oder in der Umgebung aussieht, konnte man da ziemlich genau nachgucken, wie die Landschaft ist und konnte auch herausfinden, ob es da jetzt eine Abkürzung gibt oder nicht. Die Karten sind inzwischen abgelöst, die gibt es in der neuen Fassung. Da sind die ein bisschen bunter geworden, aber viel entscheidender, heutzutage machen wir das ja alles elektronisch.

Auf dem Smartphone zum Beispiel gibt es Apps, da habt ihr Satellitenbilder, auf dem Computer habt ihr Karten oder Satellitenbilder in 3D mit Gebäudenarstellung. Also wirklich sehr viel mehr Informationen sind verfügbar, das sind aber dann oft Angebote, die von kommerziellen Dienstleistern, also von Firmen erbracht werden, die, wenn ihr die selber auch einsetzen wollt, naja unter Umständen dann auch Geld kosten. Es gibt Versuche, das Ganze auch mit freiwilligen Aktivitäten selber aufzubauen, zum Beispiel auf dem Streetmap ist da ein Projekt, das relativ bekannt ist.

Da gibt es auch immer Fürs und Widers, manchmal ist das nicht ganz so einfach umzusetzen, wie man das vielleicht haben möchte. Wir haben heute einen Vortrag, den wir uns anhören, und zwar von Michael Greil, den hat er gehalten bei den Datenspuren 2024. Und es geht darum, dass er ein Projekt aufgebaut hat, das eine Lösung bieten möchte, dass man einen Kartenservice anbieten kann, und zwar auf der Basis von offener Software.

Das Projekt heißt Versatiles, freie Karten für alle. Wir hören uns jetzt seinen Vortrag an und hören mal, wie das Ganze funktionieren soll. Eine kurze Einführung für die Leute, die nicht wissen, wie heutzutage sozusagen interaktive Karten im Web funktionieren.

Im Kern ist die Idee, Kartenmaterial ist sehr groß und umfangreich, das sind viele Gigabyte, die passen jetzt nicht in einen Webbrowser. Und man zerlegt einfach die Karte in solche Kacheln, die dann Nummern haben, sozusagen Zeilen- und Spaltenwerte. Und man kann dann einfach sozusagen scrollen und es werden dann die entsprechenden Karten dann einfach nachgeladen.

Und wenn man nicht näher reinzoomt, wird dann jede Kachel durch jeweils höher aufgelöste Versionen ersetzt. Und so kann ich im Prinzip eine Karte vorbereiten, in vielen kleinen quadratischen Kartenausschnitte zerlegen und kann das dann halt benutzen. Wozu braucht man Karten? Ich habe ein paar Beispiele mitgebracht.

Links oben zeigt der Tagesspiegel, wie sieht es gerade an der Front zwischen Ukraine und Russland aus. Rechts oben zeigt online die Ergebnisse der Bundestagswahlen. Hier ist das DLR mit dem Potenzial für Solarzellen auf Dächern.

Rechts unten sind Nitratwerte im Grundwasser vom Umweltbundesamt. Die Sensor Community hat Messdaten über zum Beispiel Feinstaub als Karte dargestellt. Rechts oben aus aktuellem Anlass Stadtplan Dresden, was sind die potenziellen Überschwemmungsgebiete je nach Wasserstandshöhe.

Links unten Freifunkkarte und rechts unten noch, wer war das, weiß ich nicht mehr, aber auf jeden Fall der Zustand der Wälder genau vermessen. Und was man halt sieht ist, dass viele dieser Karten oder eigentlich fast alle dieser Karten, gar nicht die Karte an sich im Zentrum hat, sondern Karten im Hintergrund verwenden. Man hat Informationen, die geobezogen sind und man legt sie auf so einer Karte obendrauf, sozusagen unterschiedliche Formen der Visualisierung.

Das ist auch eines der häufigsten Szenarien, die man braucht bei solchen Kartenanwendungen. Normalerweise nutzt man dafür kommerzielle Anbieter. Kommerzielle Anbieter haben aber ein Problem oder führen zu einem Problem.

Das ist ein relativ komplexes Thema. Ich habe jetzt mal nur ein einziges Beispiel rausgegriffen, um das mal zu zeigen, was hier das Problem ist. 2017 hat ein Entwickler die Hoodmaps gebaut.

Das ist ein ganz lustiges Projekt. Das ist im Prinzip eine Karte und da kann man wie so mit einem Pinsel einmalen, wo in meiner Stadt wohnen eher die Hipster und wo sind eher die Touristen, die reichen Leute, Büros und so weiter. Da kann man auch so Labels reinmachen mit, keine Ahnung was.

Also sozusagen so eine kollaborative Kartenanwendung. Und die war ganz witzig und das haben auch ein paar Leute benutzt. Und dann ist sieben Jahre lang nichts passiert und aus irgendwelchen Gründen, und ihr wisst ja wie das Internet funktioniert, ist das Ding mit einmal viral gegangen.

Im November letzten Jahres, mit einmal waren 1,2 Millionen Menschen da, 4,5 Millionen Page Impressions und da kam natürlich der Kartenanbieter, der dahinter ist, Mapbox, der sozusagen eigentlich im Rahmen eines Premium Modells sagt, ja du kannst das hier kostenlos nutzen, erst ab einer bestimmten Hürde, kam dann mit einer Rechnung von 11.000 Dollar. Und das ist halt sozusagen das Kernproblem, wenn ich als NGO, als Community Projekt oder sonst wer, solche Premium Modelle von kommerziellen Anbietern nutze, da kann ich gut mit laufen, aber ich werde bestraft, wenn mein Projekt mit einem erfolgreich wird. Wäre ich jetzt ein Pizzalieferdienst, der beispielsweise eine Karte in seiner Website hat, habe ich kein Problem damit, weil wenn jetzt eine Million Leute bei mir für 20 Euro eine Pizza bestellen, dann kommt das Geld schon irgendwie wieder rein, um die Karte zu betreiben.

Aber wann immer ich einen Cashflow von unter einem Cent pro Nutzer habe, das kann zum Beispiel ein Medium sein oder wie gesagt ein Open Source Projekt, dann kann mir sowas halt auch einfach das Genick brechen. Statt kommerziellen Anbietern gibt es natürlich auch Open Source Lösungen und ich versuche das ein bisschen vorsichtig zu sein, weil ich sie nicht kritisieren möchte, aber ich kann sagen, sie sind technisch extrem komplex, da gibt es viele verschiedene Komponenten dazu, eine Menge Stolperfallen, da braucht man auch viel Know-How, die zu kennen, um einfach viel Erfahrung. Viele Open Source Projekte haben auch oft einen anderen Use Case, als jetzt mal eine Karte für sein eigenes Projekt zu erstellen und sie wirken oft unprofessionell und ich schreibe extra ran, wirken unprofessionell.

Ich gebe mal hier ein Beispiel, die Freifunkkarte, da sieht man einen Überblick, wo es Freifunkknoten gibt und das hat man auf einer OpenStreetMap Karte draufgelegt und eine OpenStreetMap Karte hat eigentlich die Aufgabe, alle Daten, die in der OpenStreetMap sind, in dieser Karte darzustellen. Das heißt, diese Karte ist total vollgepackt mit Informationen, damit ich dann sozusagen jede Eintragung von OpenStreetMap drinnen sehen kann und wenn ich jetzt eine Karte habe, die jetzt mit so viel Farben und so viel Information arbeitet und ich dann nochmal oben drauf Informationen drauflege, habe ich einfach einen Overflow an visuellen Informationen. Das heißt, die OpenStreetMap Karte ist nicht unprofessionell, aber sie ist halt eigentlich nicht geeignet dafür, dass ich die verwende, um dort zusätzliche Informationen darzustellen.

Ansonsten bin ich großer Verfechter von Open Source, aber ich glaube, hier ist im Bereich Geodaten so ein bisschen was nicht gesund gelaufen und letztes Jahr habe ich mich entschieden, eine Lösung zu entwickeln, wie wir jetzt einfach mal Karteninfrastruktur als frei und offen durchdenken können und dabei diese ganzen Probleme lösen können. Und da ist das Projekt Versatiles daraus entstanden. Die Idee von Versatiles ist, dass es nicht irgendwie eine monolithische Architektur, eine große Software ist oder sowas, sondern ich fand den Ansatz des Internets, ein Referenzmodell zu haben, dass das Problem Internetinfrastruktur in ISO-OSI in unterschiedliche Layers zerlegt.

Den Ansatz fand ich extrem charmant und genau das ist es im Prinzip auch. Versatiles ist eine Art Referenzmodell wie ISO-OSI und das Problem Karte wird in sozusagen vier Abschnitte zerlegt. Erstens Teil generieren, Teil Server, dann die ganze Network-Problematik und zum Schluss das Frontend.

Das ist die ganze Idee dabei. So, jetzt könnte der Vortrag zu Ende sein, aber wir gehen natürlich die ganzen Teile mal durch. Wichtig ist zu verstehen, wir mussten jetzt die bestimmte technische Entscheidung treffen, wie wir das eine oder andere lösen.

Und ich gehe davon aus, dass Leute, die in dem Bereich schon gearbeitet haben, nicht der gleichen Meinung sein werden. Nein, das müssen wir ganz anders machen. Aber das Schöne ist, es ist sozusagen ein Referenzmodell.

Ihr könnt jederzeit ausbrechen. Wenn ihr nicht unser Frontend nutzen wollt, sondern irgendwas anderes, könnt ihr das gerne machen. Dann könnt ihr sozusagen Teil 4 austauschen, aber 1, 2, 3 weiterhin nutzen.

Genau, das heißt also, als offene Architektur ist es sozusagen extrem flexibel. Erster Teil Generator. So, der klassische Ansatz ist, wie zum Beispiel bei OpenStreetMap, dass ich Raster-Kartenkarren verwende.

Das heißt, ich generiere Bilder, in denen schon alle Daten und Geoinformationen und Labels usw. drin sind. Das hat aber das Problem, dass wenn ich zum Beispiel reinzoome oder rauszoome, dass ich dann sozusagen feste Schritte habe und die Labels immer verschwinden und woanders sind.

Da sind natürlich Vektorkarten viel geiler. Ich meine, guckt euch das an. Man kann einfach superflüssig reinzoomen.

Wenn genug Platz ist, erscheinen dann die nächsten Labels, die dann sozusagen reingebendet werden können, wenn dann Platz dafür ist. Ich habe mal so ein paar Features gezeigt. Wenn ich hier zum Beispiel so eine Karte in Deutsch habe, kann ich nachträglich die Sprache auf Englisch umschalten.

Nur im Frontend. Als Frontend-Entwickler kann ich sozusagen die Karte verändern. Ich kann da aber auch die Labels ausblenden oder das Ding in schwarz-weiß machen oder eine Farbe einfärben.

Das heißt, Vektortiles sind technisch da wirklich in ganz vielen Faktoren überlegen gegenüber Raster-Teils. Ich habe selber mit Leaflet 15 Jahre lang gearbeitet und es ist ein großartiges Framework, aber es ist leider jetzt veraltet, weil Vektortiles, das Hot-New-Shit, statt Open-Map-Tiles, um das mal kurz zu erklären, wenn ich jetzt solche Vektorkarten-Kacheln habe, ist das sozusagen ein Binär-Blob, ein Binär-File, in dem die ganzen Vektordaten, Straßen, Labels usw. reingepackt sind und dafür gibt es einen Standard, der heißt Open-Map-Tiles.

Da gibt es das Schema dazu, da wird das beschrieben. Das ist in der Zwischenzeit auch schon Version 3.15. Die Firma dahinter heißt MapTiler, die das entwickelt hat und sie veröffentlicht das unter der Lizenz CC BY. Und das bedeutet, jede Karte, die ich damit veröffentliche, muss ich unten heranschreiben, Urheberrecht, also sozusagen Copyright, Open-Map-Tiles.

Das heißt, auch wenn ich von denen gar nicht die Daten verwende oder sonst irgendwas. Aber nur weil jetzt ein kleines Teilchen davon deren Spezifikation verwendet, muss ich jetzt immer diese CC BY-Lizenz unten heranschreiben. Und wenn man sich das ein bisschen auch anguckt und auch die Webseite von Open-Map-Tiles genau anschaut, hat man auch das Gefühl, dass es eigentlich mehr eine Art SEO-Kampagne für diese Firma ist, als dass es wirklich ein freier Standard ist.

Dafür gibt es jetzt ein neuer Hotshit, der heißt jetzt Shortbread. shortbread.minus-tiles.org ist die Seite dazu. Wurde ursprünglich entwickelt bei der Geofabrik und ist unter komplett CC 0. Auf shortbread.tiles.org findet man auch sozusagen das kleine Board.

Da sind so Open-Street-Map-Entwickler, Leute, die aus dem Geoinformatik-Bereich sind. Ich bin auch dabei. Und da haben wir sozusagen so ein kleines Board, das diesen Standard weiterentwickeln wird.

Nächstes Ding, der klassische Stack. Wenn ich jetzt einen Open-Street-Map-Server normalerweise aufsetze, muss ich das ja alles installieren. Ich brauche PostgreSQL, PostGIS, OSM2P-SQL, GDAL, um irgendwie Geodaten noch zu konvertieren, MAPNIC zum Rendern, Apache, Python und den ganzen Kram.

So sieht normalerweise ein Server aus. Und das ist ein Riesenproblem mit all den Dependencies und das Rumkonfigurieren an dem Ding. Wenn ich jetzt Open-Street-Map darauf aufsetzen möchte, muss ich halt den kompletten Open-Street-Map-Planeten importieren.

Das kann Tage oder sogar eine Woche dauern, bis ich sozusagen meinen Kartenserver fertig habe. Das in eine Datenbank zu packen, ist ein gutes Ding für die Open-Street-Map-Community an sich, weil sie dann zum Beispiel, wenn an Open-Street-Map Änderungen vorgenommen werden, innerhalb von Minuten das Update in der Datenbank drin ist und dann sozusagen auch die Karte online aktualisiert ist. Aber das ist nicht ein Use-Case, den wir haben.

Also wenn ich jetzt eine Karte nutze, die ist drei Monate alt, ich sehe überhaupt gar keinen Unterschied. Deswegen, statt einer Datenbank setzen wir lieber auf einen Container. Das heißt, die 300 Millionen Kacheln weltweit berechnen wir vor.

Sagen Sie, die komplette Erde bis runter auf Häuser-Ebene. Alle Kacheln sind vorkomprimiert. Die kommen in einen Container, der ist dann 50 Gigabyte groß.

Da ist sozusagen die gesamte Erde drin. Genau, da gibt es ein GitHub-Repository. Da steht drin, wie wir es gemacht haben.

Und falls euch das alles nicht interessiert, könnt ihr es auch einfach fertig runterladen bei download.versutiles.org. Da gibt es sozusagen schon alles fertig. Wenn, dann tun wir das mit TileMaker. Damit sind wir auch zu 99 Prozent zufrieden.

Ein paar Sachen müssen wir uns noch überlegen. Wie sieht der Container aus? Der Klassiker ist, hat der eine oder andere von euch schon mal gesehen, eine MB-Teils-Datei. Das ist so eine Art Datenbank.

Da steht dann pro Kartenkachel drin, welches Zoom-Level, Spalte und Zeile das hat. Und dann die letzte Spalte ist das Tiledata. Da ist dann zum Beispiel ein JPEG drin mit eineratellitenaufnahme oder sonst irgendwas.

Das ist aber kein gutes Format, weil es halt eine SQLite-Datenbank ist. Da habe ich dann wieder eine Dependency. Das muss eine Datei sein, die lokal liegt.

Die Spezifikation ist auch ein bisschen einschränkend. Was wir natürlich gemacht haben, ist das Rad neu zu erfinden und haben ein neues Container-Format entwickelt. Das heißt Versatiles.

Das ist in einigen Aspekten auch sehr stark an PM-Tiles aufgebaut. Das ist ein simples File-Format, das super simpel zu dekodieren ist. Da haben wir jetzt auch mehrere Implementationen, auch in JavaScript drin usw.

Und es ist komplett frei und unabhängig. Auch hier ist die Spezifikation als Repo erhältlich. Und das Geile an dem Format ist, und das zeige ich euch nachher noch, ich kann sozusagen die ganzen Kartenkacheln, die gespeichert sind, die Datei dazu kann entweder auf meinem Rechner liegen, die kann aber auch ganz woanders liegen.

Die kann zum Beispiel auf einem Google-Bucket oder einem HTTP-Server oder sonst was liegen und kann sozusagen von fern aus ausgelesen werden. Oder erlaubt sogar Spatial Extracts und das zeige ich euch gleich, was das bedeutet. Hier ist auf jeden Fall download.versatiles.org Da seht ihr, quartalsweise aktualisieren wir das.

3,53,7 Gigabyte. Da ist alles drin, was ihr braucht, um eine weltweite Karte anzubieten. Wir haben auch ein Tool gebaut mit Versatiles.

Der Repo kommt nachher noch. Da kann man sehen, dass ich sozusagen die unterschiedlichen Container-Formate konvertieren kann. Da kann ich auch filtern.

Ich will eine bestimmte Zoom-Stufe haben oder einen bestimmten Bounding-Box. Ich will die Kompression ändern usw. Da sind ganz viele Sachen drin.

Hier kann man mal sehen, was man damit machen kann. Ich habe hier zum Beispiel die URL von dem Container und sage die Bounding-Box, das ist jetzt ungefähr eine Bounding-Box rund um Dresden, laden wir das runter, benutzen aber diese Bounding-Box und speichern wir das als Dresden.Versatiles. Das heißt, ich muss jetzt nicht die gesamte Erde runterladen, wenn ich jetzt zum Beispiel nur Kartenanwendungen für Dresden baue, sondern ich kann mir das einfach extrahieren. Dazu, ganz heißer Shit noch, Versatiles Pipeline-Language gebaut.

Das sieht ein bisschen wie Bash aus. Kommt gleich. Das hat einen Operator-Name und dann kommen die Attribute hinten dran.

In dem Fall zum Beispiel, lade einen Container, der heißt Gitter.Versatiles, das speichere ich als VPL-Datei ab und dann kann ich das auch als Kartenquelle benutzen. Aber was das Ding kann ist, ich kann das, was da rauskommt, pipen in Update-Properties. Das heißt, ich kann zum Beispiel in dem Fall Gitter.Versatiles, das sind zum Beispiel Gitter, Rechtecke und die kann ich dann mit Eigenschaften füllen, mit Properties füllen, die aus der CSV-Datei kommen.

Das heißt, ich kann zum Beispiel nehmen wir mal eine Gemeindekarte von Deutschland und dann sage ich, okay, ich möchte jetzt gerne alle Gemeinden noch Zahlen reinschreiben mit, keine Ahnung, wie wurde dort gewählt oder irgendwie sowas. Dann steht das sozusagen mit in den Vektordaten drin und kann im Frontend die dann halt darstellen. Das läuft in einem GitHub-Workflow produktiv.

Zeige ich euch nachher, wie es aussieht. Genau, da kann ich auch unterschiedliche Datenquellen miteinander merken. Da bauen wir gerade noch dran rum, dass man da zum Beispiel auch Bildkacheln verarbeiten kann, die einfärben kann, Satelliten- und Luftbildaufnahmen kombinieren kann und so weiter.

Und es läuft super performant auf allen Kernen gleichzeitig. Das war jetzt im Schnelldurchlauf, wie man Kartenkacheln generieren kann. Wie gesagt, die könnt ihr auch alle runterladen.

Jetzt der Versatile Server. Wir benutzen das gleiche Tool. Das war sehr cool, das habe ich in WASD geschrieben.

Sorry, falsche Folie. Das habe ich in WASD geschrieben. Wer es noch nicht angefasst hat, also wer länger in C++ gebaut hat, dem kann ich empfehlen, mal WASD anzuschauen.

Das ist eine Befreiung. Und da haben wir ein fertiges Tool. Das Repo ist auch online.

Da kommen auch als Binarys regelmäßig released für Linux, sowohl für GLibc als auch für Muzzle kompiliert. Für macOS Windows. Das läuft auf ARM64 und x86.

Unter anderem hat es drei Funktionen. Kartenkacheln konvertieren, Serve ist sozusagen Server und Probe ist so ein Ding, um nicht mehr Statistiken ausgeben zu lassen, was ist die größte Kartenkachel und so weiter. Wir unterstützen einen Haufen von Containerformaten.

Und wenn ich jetzt zum Beispiel mal Versatile Serve und dann mache ich jetzt Paris.Versatile, zack, läuft ein Server, der die Kartenkacheln ausliefert. Der liefert das dann unter tilslash paris aus, hat einfach den filename genommen. Ich kann übrigens auch so eckige Klammern ranmachen, damit ich halt das tilslash osm, also unter anderem url veröffentlichen kann.

Da gibt es auch den Parameter-s slash web, da nimmt er einfach das verzeichnete Web und liefert die Dateien, die da drin sind noch zusätzlich als statische Dateien. Wenn da irgendwie HTML, JavaScript oder keine Ahnung was. Das heißt, ich habe dann sofort einen Karten-Server verbunden mit einen Datei-Server.

Und weil wir so frisch dabei waren, haben wir das nicht nur in WASD gemacht, sondern auch nochmal in Node.js geschrieben. Da gibt es so ein NPM-Modul, in dem ich dann auch solche Versatile Container lesen kann, kann mit den Header extrahieren, einzelne Kartenkacheln extrahieren und sie dann hier zum Beispiel mal schreiben oder auch ausliefern. Natürlich gibt es auch ein fertiges Node-Modul, wo dann einfach ein kompletter Karten-Server in Node.js ist, in TypeScript geschrieben, falls es einen da mal umhacken will, weil manchmal gibt es skurrile Ideen, wo ich mit einmal einen Karten-Server einbauen möchte.

Genau, jetzt ist es sozusagen super einfach. Ich kann mal ein Beispiel geben, wo wir das genutzt haben. Ein Projekt, das war da war die Idee, das als Google Cloud Run Service zu bauen.

Man startet es einfach, indem man ein Google Bucket angibt und was ich dann machen kann, ist alle Dateien, die im Bucket liegen, einfach dann sozusagen von außen mir ausgeben zu lassen. Außer wenn ich eine Versatiles-Datei aufrufen will, dann kann ich die nicht runterladen, sondern dann sagt er mir, Achtung, ich brauche einen Get-Parameter. Das heißt, wenn ich jetzt zum Beispiel Karte.Versatiles? Preview ranmache, zeigt er mir ein komplettes Frontend, um die Karten-Daten mir dann online darzustellen.

Oder ich kann damit zum Beispiel eine einzelne Kartenkache runterladen.

Habt ihr noch Energie? Wir sind halb durch. Der Netzwerkteil, wir haben explizit den Server gesplittet, wir kümmern uns nicht um TLS usw. Auch aus Securitygründen.

Was wir gerade machen, ist eher CDNs zu testen. Produktiv läuft es halt bereits hinter einem Google und hinter einem Akamai CDN. Mit Bunny und Blazing CDN haben wir noch ein bisschen Schwierigkeiten.

Die können keine komprimierten Daten auswerfen, warum auch immer. Die anderen CDNs müssen wir mal testen. Der Klassiker ist aber, dass wir das hinter einen Nginx packen, sozusagen als Reverse-Proxy.

Dann machst du einen RAM-Disk als Cache, TLS. Es gibt einen fertigen Docker-Compose mit Let's Encrypt. Wir setzen das sogar schon, auch als Repo kann man sich das angucken, wir setzen das bis jetzt auch produktiv ein.

Und hier kommt der Punkt für alle Leute, die bis jetzt keinen Bock drauf hatten. Es gibt einen freien Kartenserver, teils.verso, teils.org, der am DKIX hängt. Aus dem CCC-Umfeld, komplett kostenlos betrieben wird, sehr performant ist.

Und es ist nach meiner Kenntnis der erste freie Vektorkarten-Server der Welt. Den könnt ihr nutzen. Das heißt, wenn ihr das nächste Mal irgendein Projekt habt und überlegt, ihr braucht jetzt irgendwie einen Kartenanbieter, nutzt jetzt OpenStreetMap, ihr könnt den benutzen.

Und wie gesagt, Anmieter-Traffic, die Kosten sind alle übernommen. Jetzt möchten wir natürlich einen Frontend draufpacken. Da setzen wir sehr stark auf MapLibre.

MapLibre ist ein Fork aus Mapbox. Unter github.com findet man alles. Und da gibt es fertige Frontends für Web.

Wenn ihr das in Android oder IOS, gibt es native Module für. Es läuft auch nativ auf Linux, macOS, Windows. Braucht aber immer GPU.

Und Node.js Binding gibt es dafür auch. MapLibre ist supergeil. Es kann natürlich nicht nur Vektordaten, sondern es kann auch z.B. Satellitendaten, also die klassischen Rasterkarten kacheln.

Es kann 3D-Kram, Gebäudehöhe oder hier mal ein Screenshot mit Elevation-Daten, dass ich da Gebirge darstellen kann. Es läuft super performant auf der Grafikkarte, bedeutet aber, dass bestimmte Sachen vorbereitet werden müssen, wie z.B. Schriftarten. Haben wir aber schon für euch erledigt.

Wir haben jetzt mal 10 freie Schriftarten rausgepickt, die gut für Karten geeignet sind. Zu jeder Schriftart gibt es auch die unterschiedlichen Varianten wie Bold, Italic oder Condensed usw. Und unter Versatile Fonts findet ihr sie alle komplett als fertiges Paket zum Runterladen.

Müsst ihr nichts selber machen. Icons braucht man normalerweise auf einer Karte auch. Haben wir auch schon alle vorbereitet.

Da kommen aber noch mehr dazu. Styles braucht man auch. Haben wir auch schon vorbereitet.

Ein buntes, ein graues, ein dunkles und ein etwas blasseres. Wir haben irgendwann festgestellt, dass es super anstrengend ist, so einen Kartenstil selber zu entwickeln. Deswegen haben wir eine Art Templating Engine gebaut, wo man sozusagen die Farben und die Layer und die ganzen Attribute so ein bisschen voneinander trennt.

Und das hat so gut funktioniert, dass wir das sogar auch noch selber als JavaScript Library anbieten. Hier ist mal ein Beispiel. Wenn ich jetzt so eine Karte selber machen möchte, lege ich ein Diff-Element an mit dem Namen Map, hol ich mir Map, Libre, GL, JS und unser versatile Styles JavaScript und dann generieren wir einen Colorful Style.

Aber die Karten krachen letzte daher. Die Sprites möchte ich gerne, dass du meine nimmst. Nimm mal diese URL als Base URL.

Ich möchte aber gerne, dass die ganzen Labels in Deutsch sind. Die Labels sollen auch eine Farbe haben. Und dann experimentieren wir auch noch gerade mit Recolor, dass man also die komplette Karte noch nachträglich einfärben kann.

Also zum Beispiel heller, dunkler machen, invertieren, Gamma verändern und so weiter. Da basteln wir auch so ein bisschen noch dran rum. Genau, dann schmeißen wir den fertigen Style in Map, Libre, GL rein.

Fertig ist die Karte. Da basteln wir auch gerade so ein bisschen an Frontends rum in Form von Svelte-Modulen. Hier ist mal ein Modul, das haben wir schon fertig.

Wenn man eine einfache Bounding-Box zeichnen möchte, das kann man als Svelte-Modul runterladen. Da kommt aber noch mehr. Einfache Karten, Karte mit Punkt oder eine Karte, die ich nachträglich stylen möchte.

Den ganzen Kram haben wir auch spezifiziert in der Frontend-Spezifikation, damit genau klar ist, wo was in welchem Verzeichnis drin liegt, dass es nicht Kraut und Rüben ist, dass man also weiß, dass es Fonts heißt und nicht Font oder Styles und nicht Styles. Weil ihr kennt das ja, wenn man die Dinge unterschiedlich benahmt, dann friemelt man sich da zu Tode. Das Coole ist, wir bauen euch ein fertiges Frontend-Punktar.

Da ist komplett alles drin. Und wenn ihr jetzt Versatiles startet und sagt, holen wir die statischen Lateinen daraus, dann liefert ihr das aus. Das war Versatiles im Schnelldurchlauf.

Herzlichen Glückwunsch. Ihr habt den großen Brocken durchgestanden. Aber das war einfach mal so, um mal einen komplett breiten Überblick zu geben, was das eigentlich ist und was das Ding kann.

Den aktuellen Zustand würde ich mal als Rohbau bezeichnen. Der Vogel fliegt und das Flugzeug fliegt sogar sehr gut, aber wir haben noch keine Toiletten und Sitze eingebaut. Das heißt hier konkret bei Versatiles, es fehlt noch ganz viel Dokumentation, es fehlen noch ganz viele Features, gerade so im Entwicklerbereich, gerade Frontend entwickeln und so weiter.

Aber der Vogel fliegt und ich kann euch mal ein paar Showcases zeigen. Hier ist ein Tool, das hatte ich mal schnell gebaut. Wie setze ich den eigentlich Versatiles selber auf? Kann man sagen, welches Operating System man nutzt.

Möchte man mit einem Install Script installieren oder lieber selber von Code bauen? Möchte ich ein Frontend installieren und die Kartendaten, möchte ich die ganze Welt oder nur einen Teil davon? Da habe ich jetzt mal Dresden ausgewählt und dann gibt er dir zurück die ganzen Bash-Befehle, die du einfach kopieren musst. Ich habe euch das hier mal als Demo reinkopiert. Das sind die vier Befehle, drücke ich Enter, installiere Versatiles, Frontend herunterladen.

Jetzt extrahiert er Dresden. Der Server startet und ihr habt innerhalb von neun Sekunden einen Kartenserver von Dresden. Wir reden hier nicht mehr von Wochen, sondern von Sekunden.

Das ist extrem straff. Eingesetzt wird das beim SWR, die haben zum Beispiel im Sommer veröffentlicht, beim Herzinfarkt. Krankenwagen muss mich ins nächste Krankenhaus bringen.

Wie weit ist es denn eigentlich entfernt? Da sieht man so die roten Stellen, die dann über 30 Minuten brauchen. Das ist eine Deutschlandkarte. Ich habe jetzt mal nach Dresden reingezoomt.

Hier ist eine Karte vom Norddeutschen Rundfunk. Für die hatte ich Zensusgitterdaten visualisiert. Da kann man dann so reinzoomen und sich für 100x100 Meterwürfelchen angucken, was die Bevölkerung zahlen, durchschnittliche Mieten, was wird geheizt und so weiter.

Das ist ein Ding, das habe ich für die Taz gebaut. Da kann man die Windradabstände zu Gebäuden, Straßen und sonst was anschauen. Und dann gucken, wie die unterschiedlichen Abstandsregeln sich der unterschiedlichen Bundesländer auswirken würden.

Kann man sich auch für ganz Deutschland angucken. Hier ist noch eine Karte von der Berliner Morgenpost, von Funk Interaktiv, wo Kiffen überall verboten ist, weil man zu dicht an der Kita ist und so weiter. Da sind wir auch super happy dabei, dass die Medien, die damit anfangs rum zu experimentieren, auch feststellen, dass das nicht nur sehr, sehr gut funktioniert und performant ist, sondern dass sie halt einfach vorher Kosten von Tausenden Euro haben an Lizenzgebühren, an Mapbox und Co.

Und jetzt kriegen sie es für null Euro und haben vielleicht sogar noch Budget übrig, um damit Entwickler anzustellen, um dann eigene Frontends zu machen. Und damit haben wir endlich eine freie, offene Karteninfrastruktur für alle. Es gibt natürlich noch viel zu tun.

Aber ich habe euch hier nochmal alle Informationen zusammengetragen. Versatiles.org ist die Webseite. Versatiles-Org ist die GitHub-Organisation.

Da gibt es 29 Repositories. Da findet ihr bestimmt immer irgendwas, wo ihr ein Issue noch rankleben könnt. Ich bin für jede Hilfe dankbar.

Für nicht öffentliche Fragen gibt es noch Mail at versatiles.org. Mastodon und BlueSky-Accounts haben wir schon mal angelegt, aber noch nichts veröffentlicht. Und alle Vortragsfolien sind unter bit.ly.Versatiles-DS24. Vielen Dank. Querying nach Daten, also die Straße, an der eine Kreuzung und so weiter ist, das wird wahrscheinlich nicht gehen.

Also das macht man, also die Versatiles ist erstmal nur für das Darstellen von Daten zuständig. Querying und so weiter ist erstmal nicht dabei. Aber das ist ein Feature, dass wir auch jetzt, also wir arbeiten ja, wir essen unser eigenes Hundefutter die ganze Zeit.

Deswegen merken wir, das ist ein Feature, das relativ häufig gebraucht wird. Und da überlegen wir, ob wir da irgendwie, also was wir da nutzen, da gibt es Unterschiede. NovoNardem ist die klassische Antwort, aber es gibt noch andere Lösungen.

Und wir versuchen eine Lösung zu finden, dass wir es auch frei anbieten können, dass man das also auch für alle dann, für eure Kartenprojekte nutzen kann. Weitere Fragen? Ich verstehe, dass der Scope wahrscheinlich ein bisschen größer ist als ProtoMaps, aber gerade, also ich habe das Gefühl, das erfreut sich großer Beliebtheit, gerade wenn man zum Beispiel nur eine Deutschlandkarte oder nur Dresden kleine Kartenausschnitte hat. Wie ist VersaTiles da besser? Oder will es besser sein überhaupt? Wir haben uns auch von ProtoMaps ganz viele Sachen abgeschaut, insbesondere das Containerformat.

ProtoMaps hat als Kernidee, dass sie ohne Server auskommen, dass sie einfach ihre Kartendaten als große Datei irgendwo ablegen und alles sozusagen von Frontend-seitig gemacht wird. Das hat aber das Problem, dass ich relativ viele Latenzen habe. Das Ding muss drei, vier Anfragen stellen, um überhaupt die erste Kartenkachel, also es muss erst mal Indizes runterladen, Header und so weiter, das braucht ein Weilchen.

Ich kann auch gar kein Caching machen. Browser-Cache kann zum Beispiel nur Dateien ablegen, aber nicht irgendwie Range-Requests. Komprimierte Kartenkacheln sind ein Problem, da muss ich in JavaScript dann Gzip nachprogrammieren und so weiter.

ProtoMaps ist eine sehr, sehr coole und effektive Lösung, wenn ich Kartendaten habe, die ich einem kleinen Nutzerkreis darstellen möchte, vielleicht nur firmenintern oder meinen Kunden oder sowas. Aber jetzt eine skalierbare Infrastruktur, wo eine Million Leute hingehen wollen, mit einem CDN davor oder sowas, dafür ist ProtoMaps nicht geeignet. Und da haben wir sozusagen teilweise eher hin optimiert.

Hi, danke für den Vortrag. Kann man damit auch so Adressdaten look-up machen? Also, dass ich nach einer Adresse suche oder in die Karte klicke und die Adresse bekomme? Nein, nein. Wir beschäftigen uns nur mit dem Thema Darstellung, aber wie gesagt, Adresssuche ist eigentlich ein separates Problem.

Aber das müssen wir auch lösen und wir würden das dann, wie gesagt, frei anbieten für alle. Danke. Ich frage mich jetzt so ein bisschen, ich kann mir dann die Karte von Dresden oder irgendwas runterladen, aber wie kriege ich dann meine Daten, die ich jetzt sichtbar machen will, wie kriege ich die rein? Also, da gibt es jetzt grundsätzlich zwei Varianten.

Variante 1 ist, man liest sich sozusagen in dieses MapLibre-Framework rein und da ist der Klassiker so etwas wie ich habe einen GeoJSON beispielsweise mit einem Polygon oder sowas und das wird dann draufgelegt. Dann kann ich dem halt sagen, wie er es ausmalen soll und die Umrandung und so weiter, kann ich das ein bisschen stylen. Wenn ich sehr, sehr große und umfangreiche Daten habe, muss ich tatsächlich dann Vektorkarten-Kacheln generieren und diese Vektorkacheln, dafür gibt es fertige Tools wie TypicaNU, aber wir bauen halt auch mit dieser Versatile Pipeline Language diese Funktionen auf, dass ich also dann einen GeoJSON öffne, es generiert mir daraus Vektorkarten-Kacheln, die dann reingemerged werden, in die OpenStreetMap-Kacheln, dann sind da sozusagen weitere Layer mit reingepackt, dass das sozusagen serverseitig direkt gemacht wird und da würde ich noch sozusagen ein bisschen, also wir experimentieren damit gerade, was wie gesagt überraschend gut funktioniert, ist, dass es den GitHub-Workflow durchrendert, aber damit die Hirnen so weit runter sind, dass man da jetzt nicht Experte sein muss, um das selber machen zu können, da bauen wir jetzt sozusagen noch die Tools nach und die Dokumentation und so weiter, aber ich gehe davon aus, dass wir 2025 da dichter dran sind an unserem Ziel.

Ich weiß nicht, hast du schon gesagt, wie man dich abgesehen davon unterstützen kann oder euch, seid ihr eine Organisation, sucht ihr Menschen, die das tun oder irgendwie? Also es gibt explizit keine Organisation drum, ich versuche so ein bisschen die schützend die Hand drüber zu halten, dass es nicht eine GmbH oder sonst irgendwas wird, also wir wollen explizit keine geschäftlichen Interessen damit verfolgen, es soll mal gucken, irgendwie halt ein unabhängiges Projekt sein, müssen wir mal schauen, ob wir uns irgendwo randocken. Was wir aber auf jeden Fall brauchen können, ist erstens Leute, die es nutzen, Leute, die es testen, Leute, die Bugs finden, rummeckern, rumnörgeln, das sind Issues, in GitHub reinpacken und geil wäre natürlich, wenn Leute irgendwie Zeit haben und dann an irgendeinem Punkt irgendwie mithelfen und wenn es irgendwie Dokumentation verbessern ist, ja, also deswegen, ich kann euch empfehlen, also wir wollen das Projekt halt wie gesagt noch weiter pushen, ich glaube, das hat auf jeden Fall den Stand erreicht, dass man es selber nutzen kann und wenn man es selber nutzt, hat man immer die Möglichkeit da auch irgendwie Verbesserungen zu entwickeln und sie dann zu kontributieren. Nochmal vielen Dank, ich wollte fragen, wie, also wenn es jetzt keine Organisation gibt, wie du die mittel- oder langfristige Finanzierung dir vorstellst, geplant hast und ob es, also, ja, irgendwie, wenn, nehmen wir an, man benutzt es jetzt und hat ein Projekt und will darauf aufbauen und in fünf Jahren stellt sich raus, oh, versatile ist das mega aufwendig, ich mache das nicht mehr, ja, wie stellst du das vor? Also, jetzt haben wir auf jeden Fall erstmal eine Förderung, um es insbesondere in, für Redaktionen, Werkzeuge zu bauen, das hat den Vorteil, dass dann vielleicht auch viele Medienhäuser und auch die Datenjournalisten im Hause und die Entwickler im Hause das nutzen.

Ich glaube, also, die wichtigsten oder besten Entwicklerinnen und Entwickler sind ja nicht Leute, die irgendwie Langeweile haben, sondern, dass die Werkzeuge selber nutzen, also, du willst eine Community haben, die es selber benutzt und verbessern kann. Das heißt, mir ist es natürlich, kommt es sehr gelegen, dass sie halt sich Nutzerinnen und Nutzer finden. Medien sind halt super interessant, weil sie halt nicht viel Kohle haben, um halt Mapbox zu bezahlen und wenn sie dann eine Open-Source-Lösung nutzen und weiterentwickeln können, wäre es natürlich das Optimum.

Wie da jetzt aber die genaue Aufhängung in den nächsten zwei, drei Jahren aussieht, weiß ich halt auch noch nicht. Ich würde es aber ungern aus der Hand geben und kommerziellen Interessen oder eigenen Interessen unterwerfen. Das war jetzt der Vortrag von Michael Kreil, Versatiles, freie Karten für alle, ein Projekt von offener Software, das ermöglichen soll, dass man auch selber einen Kartenservice für andere Leute auch machen kann.

Unsere Sendungen könnt ihr nachhören auf unserer Webseite politopiamagazin.de. Dort haben wir die versammelt und in den Sendungsnotizen, also in den Shownotes, haben wir natürlich auch die Links versammelt, die Links zu dem Originalvideo beziehungsweise weiterführende Informationen. Das war das politopia-magazin. Schön, dass ihr dabei wart.

Schön, dass ihr zugehört habt. Wir hören uns jede Woche, Mittwoch 16 Uhr bei Radio X. Also dann, bis nächste Woche.