Deutsche Version auf Grundlage einer Übersetzung mit deepl.
Die OSMF hat kürzlich die Auswahl an Kartenebenen auf der OpenStreetMap-Website erweitert. Da jedoch keines der Kartendesigns der beiden neuen Ebenen in meiner letztjährigen Übersicht über den Stand des Kartendesigns in OpenStreetMap behandelt wurde, halte ich es für notwendig, meinen Lesern diesbezüglich etwas Hintergrundwissen zu vermitteln. Die Ankündigung der OSMF in ihrem postfaktischen US-PR-Stil ist in dieser Hinsicht wenig hilfreich.
Hier eine tabellarische Darstellung der aktuellen Kartenebenen:
Kartenebenen auf osm.org mit dem Status von Ende Juli 2025
Fußnoten:
- Die aktive Entwicklung des Humanitarian-Stils ist beendet, der Stil ist nun archiviert.
- Maptiler verwendet bei niedrigen Zoomstufen (bis zu z6) Nicht-OSM-Daten (Natural Earth) für die physische Geografie (Küstenlinien, Gewässer, Gletscher) – diese basieren größtenteils auf mehr als 50 Jahre alten Informationen.
Einige Erläuterungen zu den Spalten:
- OSM Website label ist das Label, das auf der OSM-Website für die betreffende Kartenebene verwendet wird.
- Style ist der tatsächliche Name des Stils, der zur Erstellung der Karte verwendet wird. Hinweis: Bei clientseitig gerenderten Karten hat der Stil nur begrenzten Einfluss auf die Darstellung der Karte – wie bereits zuvor erläutert.
- Commercial/Community – gibt an, ob der Kartenstil kommerziell entwickelt wurde oder ob seine Entwicklung durch Freiwillige in einem Community-Projekt erfolgt ist. Grundsätzlich handelt es sich hierbei nicht um eine strikte Zweiteilung – es gibt beispielsweise auch eine ganze Reihe von Kartenstilen, die von einzelnen Designern ohne kommerziellen Hintergrund entwickelt wurden. Für die Kartenebenen auf der OSM-Website funktioniert diese Zweiteilung jedoch – diese gehören alle eindeutig zu einer der beiden Kategorien.
- Open Source – gibt an, ob die Stildefinition vollständig für andere unter einer offenen Lizenz verfügbar ist.
- Hosting – gibt an, wer das Hosting der serverseitigen Infrastruktur dieser Kartenebene übernimmt.
- Data Update Frequency – gibt an, wie oft die angezeigten Daten aktualisiert werden, gegebenenfalls getrennt für niedrige/hohe Zoomstufen.
- Tech Stack – gibt den Software-Stack hinter der Kartenebene an. CartoCSS+Mapnik bedeutet, dass der Kartenstil in CartoCSS geschrieben ist (in der Regel zur Verarbeitung durch Carto in Mapnik XML) und mit Mapnik gerendert wird. Maplibre bedeutet, dass der Stil in Maplibre JSON (oder einer YAML-Darstellung derselben Datenstruktur) geschrieben ist.
Über die Informationen in der Tabelle hinaus ist natürlich noch zu beachten, dass es sich bei drei Ebenen um Spezialkarten (öffentlicher Nahverkehr, Radfahren) handelt, während die übrigen Ebenen als allgemeine Karten ohne engen thematischen Fokus klassifiziert werden können.
Ich möchte in diesem Beitrag weder auf die neu hinzugefügten Ebenen noch auf die gesamte Auswahl der vorgestellten Ebenen näher eingehen. Aber ich denke, es ist klar, warum keiner der neu hinzugefügten Stile in meiner Analyse des Zustands des Kartendesigns in OpenStreetMap im letzten Jahr erwähnt wurde – einer davon ist einer der unzähligen einfachen kommerziellen Google/Mapbox-Lookalikes, die ich dort beiläufig erwähnt habe. Einer, der natürlich Open Source ist, aber ansonsten nicht wirklich bemerkenswert.
Der andere ist einer der OSM-Carto-Lookalikes, die versuchen, das Design von OSM-Carto in gewisser Weise zu imitieren. Auch diese habe ich letztes Jahr beiläufig erwähnt. Bemerkenswert ist hier zusätzlich, was ich in der Fußnote oben erwähnt habe – dass hier sehr minderwertige Nicht-OSM-Daten bei z0-z6 verwendet werden.
Was die Entwicklung des Kartendesigns in der OSM-Community angeht, gibt es hier also nichts wirklich Neues. Dennoch wird es interessant sein zu beobachten, wie sich dies weiterentwickelt. Es ist mittlerweile sehr deutlich, dass innerhalb der OSMF ein breiter (wenn auch öffentlich nicht ausdrücklich artikulierter) Konsens darüber besteht, OSM-Carto abschaffen zu wollen. Es gibt jedoch auch ganz klar keine Strategie, wie dies erreicht werden soll.
In gewisser Weise ist die Situation beim Kartendesign in der OpenStreetMap-Community das Gegenteil von der Situation bei verschiedenen Kernsoftwareprojekten, die ich kürzlich in einem Beitrag angesprochen habe. Bei diesen scheint das vorherrschende Interesse innerhalb der OSMF konservativer Natur zu sein – den Status quo zu erhalten und bei Bedarf (mit Geld und personellen Ressourcen) zu investieren, um sicherzustellen, dass die alten Tools zumindest kurzfristig weiter funktionsfähig bleiben. Beim Kartendesign scheint das vorherrschende Interesse darin zu bestehen, den Status quo abzuschaffen, ohne dass klar ist, was ihn ersetzen soll.
Der Hauptvorteil für die OSM-Community besteht derzeit darin, dass sie nun über eine leicht zugängliche Schnittstelle verfügt, um klassische serverseitig gerenderte Karten und clientseitig gerenderte Karten direkt zu vergleichen. Dies wird wahrscheinlich in gewissem Maße das Bewusstsein für die Auswirkungen der verlustbehafteten Datenkomprimierung schärfen, die allen clientseitig gerenderten Kachelkarten innewohnt. Wenn das zu einer mehr faktenbasierten Betrachtung der technischen Seite der Produktion von Karten führt, dann ist dies sicher ein Fortschritt.
Update: Tippfehler in der Tabelle korrigiert (Maptiler -> MapTiler OMT)
3. August 2025 um 14:06 Uhr
Ich bin nicht alzu technisch versiert und nicht in der Community up to date, aber schätze Carto schon ziemlich, sodass mich eine Abschaffung schon wundern würde.
Ich kann mit den neuen Vektordarstellungen bisher wenig anfangen. In meinem Standardbrowser funktionieren sie nicht, weil dort Web-GL aus Datenschutzgründen ausgeschaltet ist. Weiche ich auf einen anderen Browser aus, um zu testen, erlebe ich eine viel langsamere Performance als bei Kacheldarstellungen. Wird letzteres besser werden? Schon bisher konnte man ja mit dem “Daten anzeigen”-Menüpunkt alles als Vektor anzeigen lassen und auch das braucht ewig zum Laden.
4. August 2025 um 07:28 Uhr
Danke für den Kommentar.
Was die Abschaffung von OSM-Carto angeht – das ist eine etwas ungenaue Übersetzung ins Deutsche – im Original schreibe ich “get rid of”. Damit ist natürlich kein ad-hoc-Abschalten gemeint. Der Prozess ist – wie zum Beispiel bei den Kommunikationskanälen auch – ein allmählicher. Entscheidend ist, dass dies ohne einen strategischen Konsens erfolgt, dahinter stehen ganz unterschiedliche Interessen und Wunschdenken. Und im Gegensatz zu den Kommunikationskanälen ist die Funktion von OSM-Carto viel zentraler für das grundsätzliche Funktionieren von OSM. Das wird also massive Auswirkungen auf die OSM-Community haben.
Was Web-GL angeht – mein (nicht sehr tief gehendes) Verständnis ist, dass derzeit für die Nutzung der neuen Ebenen kein Web-GL erforderlich ist. Und das entspricht auch meiner persönlichen praktischen Erfahrung. Allerdings gibt es schon ganz klar Bestrebungen, das zu ändern. Dass damit die Kartennutzung auf osm.org deutlich exklusiver wird ist da mit eingepreist. Und dass die Performance von der Nutzer-Seite bei auf dem Client gerenderten Kacheln schlechter ist, liegt in der Natur der Sache.
4. August 2025 um 18:20 Uhr
Wenn Sie im Rotfuchs die OSM-Hauptseite aufrufen, die Entwickler-Konsole öffnen (Shift-Ctrl-K) und dann auf Shortbread umschalten, werden Sie von einem „WebGL warning: texImage: Alpha-premult and y-flip are deprecated for non-DOM-Element uploads.“ begrüßt. Also doch, MapLibre ist um WebGL herum gebaut und funktioniert nur, wenn WebGL verfügbar ist. (Sie können auch in der größten der heruntergeladenen JavaScript-Dateien nachschauen.)
Was die von Ihnen verknüpfte Seite sagt: zurzeit wird die MapLibre-API über einen ML-Leaflet-Interface-Layer genutzt; dadurch sind nur die Funktionen von MapLibre nutzbar, die Leaflet kennt. Wir können also nicht alle Möglichkeiten von MapLibre nutzen, müssen aber nichtsdestotrotz alle Anforderungen von MapLibre erfüllen.
Obige Warnung ist leider ein Symptom für den Zustand von MapLibre. Wenn Sie die Issues anschauen, sehen Sie dort kaum große Probleme, sondern eine Vielzahl kleinerer: hier klemmt es, da quietscht es, dies funktioniert nicht dem, das funktioniert nicht mit jenem, wenn x größer als y ist, flackert es, verwenden Sie jenes zusammen mit solchem, bricht die Performance zusammen, und wenn a größer als b ist, stürzt es ab.
M.E. brauchte MapLibre eine Konsolidierungsphase, in der diese Konflikte aufgelöst werden und ein solides Fundament gegossen wird für alles, was kommen mag. Stattdessen schaut es eher nach Vorwärtspeitschen mit „Mut zur Lücke“ aus. Ich bin gespannt, ob und welchen Einfluss die Nutzung auf der OSM-Hauptseite auf diese Strategie hat.
Unabhängig von MapLibre an sich, ist möglicherweise dieser Faden (4½ Jahre alt) auf Github für Sie interessant:
https://github.com/maplibre/maplibre-gl-js/issues/50
Er zeigt, dass das Client-seitige Rendern einer Karte nicht nur den von Ihnen beschriebenen Einfluss auf die kartografische Qualität hat, sondern dass man technisch alle Paketabhängigkeiten (hier: Harfbuzz) des Server-seitigen Karten-Renderers auf den Client-seitigen Karten-Renderer kopiert.
5. August 2025 um 11:17 Uhr
Wie schon gesagt, mein Verständnis den technischen Details der Darstellung im Browser ist nicht sehr detailliert. Ich bekommen beim Testen widersprüchliche Ergebnisse und oft ist das Problem, dass der Layer-Switcher nicht funktioniert und ich deshalb vorsichtig mit der Aussage bin, on WebGL erforderlich ist oder nicht, denn es könnte sich auch um eine Fehlannahme von Seiten eines Entwicklers handeln, dass gewisse Browser-Versionen gewisse Funktionen generell unterstützen. Die Fragen, ob WebGL erforderlich ist und ob es – wenn verfügbar – genutzt wird, sind zwei unterschiedliche.
Unabhängig davon und in Verteidigung von MapLibre und den OSM-Website-Entwicklern: Die Schnapsidee, Webseiten über den Browser direkten Zugriff auf die Hardware des Computers zu erlauben, ist keine Erfindung von denen. Falls die OSM-Webseite nur noch für Leute nutzbar ist, die diese Schnapsidee offen aufnehmen, wäre dies natürlich bedauerlich, gliedert sich aber in einen breiteren Trend ein.
Und das Problem, dass Werkzeuge zum Client-seitigen rendern ein gewaltiges Spektrum von computergrafischer Basis-Funktionalität, wofür anderswo bereits bewährte und hochwertige Komponenten existieren, neu implementieren müssen (und dabei oft schon bei elementaren Dingen scheitern – siehe hier) ist seit den Anfängen vor über zehn Jahren bekannt.
Das eigentlich interessante ist – und das deutet Ihr Kommentar nur an – dass in der öffentlichen Wahrnehmung MapLibre als modern, auf dem Stand der Zeit und mit einer positiven Zukunfts-Perspektive wahrgenommen wird, während zum Beispiel Mapnik als obsolet, veraltet und ohne Zukunftsperspektive wahrgenommen wird. Und das, obwohl von der technischen Seite Mapnik ganz klar in einem besseren Zustand ist als Maplibre. Würde man auch nur die Hälfte des Budgets, welches in den letzten Jahren in Maplibre geflossen ist, in Mapnik stecken, wäre man in wenigen Jahren was Qualität und Leistungsfähigkeit in der Darstellung angeht Lichtjahre vor den Fähigkeiten der Client-seitigen Renderer. Das soll nicht heißen, dass ich empfehle, jetzt in Mapnik zu investieren, sondern soll nur illustrieren, wie groß die Diskrepanz zwischen öffentlichen Wahrnehmung und technischer Realität ist. Und die Anschluss-Frage ist natürlich, wie weit die Investoren und Entwickler von Maplibre sich dieser Umstände bewusst sind.
6. August 2025 um 07:25 Uhr
Ich zitiere nicht, sondern beziehe mich auf die Absätze.
Ad 1: WebGL wird nicht nur genutzt, wenn es da ist, sondern ist erforderlich (in der aktuellen Entwicklungsversion sogar WebGL2). (a) Eine vernünftige 3D-Darstellung z.B. ist nur damit möglich. CSS unterstützte zwar affine Abbildungen, man müsste aber die Fläche in extrem viele Trapeze oder Dreiecke aufteilen, damit Berge nicht wie Polyeder aussehen, und ich denke, das killt den Browser. (b) MapLibre verwendet Fonts auf der Basis von Signed Distance Fields; auch diese sind realistisch nur mit WebGL zu nutzen. (c) Ich habe mir den Code angeschaut.
Ad 2: Wenn MapLibre nicht WebGL nutzen würde, wäre es nicht MapLibre, sondern Leaflet oder OpenLayers. Ob und wie sicherheitskritisch WebGL ist, weiß ich nicht, aber in den sauren Apfel muss man beißen. Ich arbeite auf alten Rechnern ohne Grafikprozessor, und interessanterweise läuft MapLibre auch ohne Hardwarebeschleunigung flüssig, stellt also keine übermäßigen Ansprüche.
Andererseits hoffe ich, dass die OSMF weiterhin normale Karten-Tiles bereitstellt; ansonsten wäre es das Ende für leicht zu verstehende kleine PHP/GD-Tools (z.B. Anfahrskizze zum als Grafik herunterladen) oder meine zoom- und pan-bare Karte ohne JavaScript.
Ad 3: Natürlich war für Sie klar, dass sehr viel Code portiert werden muss; ich aber hatte darüber noch nie nachgedacht. Am angesprochenen Issue stört mich besonders, dass MapLibre auf der einen Seite mit einem CoC hausieren geht, andererseits aber die Inder seit 4½ Jahren hängen lässt. (Wobei das MapLibre-CoC die Diskriminierung nach Sprache zulässt.)
Ad 4: MapLibre ist (leider) in einem gruseligen Zustand. Das wissen die Maintainer auch, wie man an den „Bounty direction“-Issues sehen kann, die zusammengenommen nach einmal komplett durchpflügen oder sogar Teile neu schreiben aussehen:
https://github.com/maplibre/maplibre/issues?q=is%3Aissue%20label%3A%22bounty%20direction%22
Wie viel Geld in MapLibre steckt, weiß ich nicht; ich sehe aber, dass Geld alleine nicht reicht: Obwohl mit einem 3000 $(!)-Bounty versehen, ist das Devanagari-Issue wegen der Gesamtkomplexität nach 4½ Jahren immer noch nicht gefixt.
Bei Ihrem 10-Punkte-Plan erscheint mir das Verhältnis von Aufwand (von mir geschätzt, ich bin da aber Amateur und hab insbesondere noch nie in den Mapnik-Code geschaut) zur erreichbaren Verbesserung nicht besonders gut. M.E. müsste man für einen wirklichen Durchbruch endlich mit automatisierter Generalisierung beginnen; und weil man da bei null startet, ist das eher kein Freizeitprojekt. Ich würde wohl die Punkte 2a und 8a einfügen: Daten in eine leicht manipulierbare Form bringen, zum Beispiel einen geplätteten Graphen, und dann einen Haufen Bachelor- und Master-Arbeiten vergeben.
Gruß Wolf
Nachtrag: Ich will ML keinesfalls schlechtreden. ML ist eine der Möglichkeiten für ein neues Frontend der Historic.place, und dafür hab ich schon ein knappes Dutzend Controls gebaut. Es gibt auch einen Fix für das Devanagari-Problem; den reiche ich aber nicht ein, zum einen, weil wegen der unübersichtlichen Struktur von ML ich die Nebenwirkungen nicht abschätzen kann, und zum anderen, weil mir widerstrebt, den Unit-Test zu bauen. Bei uns ist Standard, dass niemand Tests für eigenen Code schreibt.
Ich mag MapLibre wegen der 3D-Darstellung. Ich bin grünblind, dadurch leidet die „Farbtiefe“ von Karten, und die 3D-Darstellung gleicht das ein wenig aus. Deshalb gefällt mir auch die OpenTopo besser als OsmCarto. Allerdings ist die 3D-Darstellung von MapLibre (noch) nicht wirklich schön, es ist halt eine „normale“ Karte auf ein tiefgezogenes Relief aufgeklebt. Was unter anderem dazu führt, dass alle Bäume sowie Seilbahnstrecken auf dem Boden liegen und Straßen und Bäche durch einen Hang eine Querneigung haben.🤪
6. August 2025 um 09:38 Uhr
Ich möchte noch mal daran erinnern, dass das hier kein Diskussionsforum ist. Die Kommentare sollten einen engen Bezug zum Beitrag haben. Umfangreichere Meinungen und Diskussionen zu lediglich benachbarten Themen bitte anderswo publizieren. Verweise zu solchen erweiterten Diskussionen nehme ich gerne auf.
6. August 2025 um 14:57 Uhr
Mir ist beim Lesen nach dem Abschicken aufgefallen, dass ich off topic geworden bin. Sie können den Beitrag gerne entfernen; ich hab den Text gesichert, da geht also nichts verloren.
7. August 2025 um 10:50 Uhr
Da ist kein Bedarf, wenn ich den Kommentar nicht akzeptabel gefunden hätte, dann hätte ich ihn nicht freigeschaltet. Das war nur eine Erinnerung für zukünftige Kommentare.
6. August 2025 um 10:09 Uhr
Additional note on the Maplibre Budget – you can find a breakdown of that here: https://opencollective.com/maplibre#category-ABOUT
6. August 2025 um 14:53 Uhr
Wow. Now I understand why you’re angry.
Your new toolchain could easily have been built with these sums, and there would have been plenty of money left over to program the basic functions required for generalisation, including the cartographer(s) on whose cooperation the programmers depend. It’s a shame.
7. August 2025 um 11:35 Uhr
(auf deutsch, denn dies ist ja die deutsche Version des Beitrags – ich hatte irrtümlicherweise auf Englisch kommentiert)
Um das klar zu sagen: Auch wenn ich einen Vergleich zwischen den Budgets von Maplibre und Mapnik angestellt habe, bedeutet das nicht, dass ich der Meinung bin, dass Geld, welches in Maplibre geht bei Mapnik (oder anderswo) fehlt. Man sollte solche Budget-Fragen nicht als Nullsummen-Spiel begreifen, denn das entspricht nicht der tatsächlichen wirtschaftlichen Situation.
Wenngleich es – wie schon gesagt – eine interessante Frage ist, in wie fern sich Investoren und Entwickler bei Maplibre der Situation des Projektes bewusst sind, ist auch vollkommen klar, dass zwischen den Investitionen in Produkte für den akuten Bedarf wie Maplibre und langfristigen strategischen Investitionen in innovative Methoden und Ansätze kaum Berührungspunkte bestehen. Ich hatte das in meinem FOSSGIS-Kommentar schon angedeutet. Das selbe gilt übrigens auch für den Entwickler-Pool. Zwischen den Entwicklern, für welche die Arbeit an Produkten wie Maplibre attraktiv ist und denjenigen, welche für die Umsetzung langfristiger strategischer Projekte qualifiziert und motiviert sind, bestehen nur wenig Überlappungen.
Um den Bogen zurück zum Blogbeitrag zu schlagen: Für die OSM-Community sind all dies natürlich Fragen von erheblicher Bedeutung. Das positive an der aktuellen Entwicklung ist, dass die sich abzeichnenden Entwicklungen zunehmend auch für den nicht involvierten Beobachter klarer werden und damit auch die Tatsache, dass sich das Zeitfenster allmählich schließt bezüglich der Weichenstellung, ob OpenStreetMap ein selbstständiger Akteur mit eigener Gestaltungs- und Innovations-Macht bezüglich Karten-Produktion und Karten-Gestaltung bleibt, oder ob man was Karten-Produktion angeht vollständig abhängig wird von einem bestimmten Segment wirtschaftlicher Interessen.