Deutscher Text auf Grundlage einer maschinellen Übersetzung mit deepl.
Im letzten Blogbeitrag habe ich die Idee des systematischen Testens im Kartendesign ein wenig vorgestellt und wie meine Arbeit daran – sozusagen als Nebenprodukt – zu den Rendering-Illustrationen geführt hat, die man auf TagDoc findet.
Aber es gibt noch ein weiteres Problem, mit dem die meisten automatisierten, regelbasierten Kartenrendering-Projekte konfrontiert sind und das durch systematisches Testen gelöst werden kann. Kartenstile, insbesondere komplexere wie OSM Carto, stehen vor dem Problem, dass es sehr schwierig ist, zu bestimmen, was der Stil tatsächlich rendert (d.h. welche Attributkombinationen in welcher Zoomstufe in einer bestimmten Weise gerendert werden), indem man sich den Code ansieht oder ihn analysiert. Der einzige zuverlässige Weg, dies zu tun, ist das tatsächliche Rendern von Dingen. Der einzige aussagekräftige Index oder Kartenschlüssel von OSM Carto, der bisher existiert, ist eine von Hand kuratierte Wiki-Seite, die von Menschen auf der Grundlage ihres Wissens über den Stil erstellt wurde.
Systematische Tests können dabei helfen, indem man den Stil mit verschiedenen Datenkombinationen füttert und prüft, welche davon zu einer spezifischen Darstellung führt. Wie Sie sich wahrscheinlich vorstellen können, würde dies eine unüberschaubare Anzahl von Tests erfordern, wenn man das ganz stupide ausprobieren würde. Aber durch die Verwendung geeigneter Heuristiken, um dies einzugrenzen, kann der Aufwand auf ein überschaubares Maß reduziert werden – auch wenn man im Falle eines Kartenstils wie OSM Carto immer noch bei über 100k Tests landet.
Und das ist es, was ich hier vorstellen möchte – StyleInfo ist ein neues Tool, das ich entwickelt habe und mit dem man sich ansehen kann, wie verschiedene Kartenstile OpenStreetMap-Daten darstellen – basierend auf einer Analyse des Stils, die heuristische, systematische Tests verwendet, um festzustellen, was der Stil in welcher Form wiedergibt, ohne dass man dafür vorab umfangreiche Informationen über den Stil benötigt,
StyleInfo ist ähnlich aufgebaut wie Taginfo, es erlaubt Ihnen, die verschiedenen Schlüssel und Tags des OSM-Tagging-Systems zu betrachten – aber anstatt zu zeigen, wie diese Tags in der Datenbank verwendet werden, zeigt es, wie diese Tags durch den ausgewählten Stil dargestellt werden.
Darüber hinaus können Sie auch sehen, wie der Stil die Tags nur auf einer bestimmten Zoomstufe darstellt.
All dies ist mit Querverweisen versehen, so dass Sie ganz einfach zwischen den verschiedenen Ansichten wechseln können. Ein paar Beispiele:
- Tags shop=* und wie sie in OSM Carto dargestellt werden.
- Rendering-Varianten von highway=motorway als primäres Tag in OSM-Carto v1.
- Darstellung von Varianten von highway=steps als primäres Tag auf linearen Elementen bei Zoomstufe 20 in OpenStreetMap FR Carto.
- Rendering-Varianten von natural=spring als primäres Tag in OSM-Carto-alternative-colors.
Die Informationen über den Kartenstil, die Sie auf diese Weise erhalten, sind insbesondere in zweierlei Hinsicht etwas eingeschränkt:
- Aus prinzipiellen Gründen kann nicht garantiert werden, dass die Ergebnisse vollständig sind. Ich habe bereits einige Tag-Kombinationen identifiziert, die in einigen Stilen in der Analyse fehlen, und werde deshalb Anpassungen an der Heuristik vornehmen müssen. Nichtsdestotrotz ist dies die bisher umfassendste Dokumentation von OSM Carto und abgeleiteten Kartenstilen.
- StyleInfo zeigt bisher Renderings von primären Tags und Kombinationen von primären Tags mit einem sekundären Tag. Weder Kombinationen aus mehreren primären oder sekundären Tags noch tertiäre Tags werden bisher behandelt. Was das genau bedeutet, werde ich im Folgenden noch genauer erläutern.
Das zugrunde liegende Tagging-Modell
OpenStreetMap verwendet prinzipiell ein Freiform-Tagging-System – ich habe das im Zusammenhang mit TagDoc näher erörtert. Praktisch alle OSM-basierten Kartenstile interpretieren dieses Tagging in einer etwas eingeschränkteren Art und Weise, und deshalb neigen Mapper auch dazu, Tags nach diesem etwas eingeschränkteren Tagging-Modell zu verwenden.
In diesem Modell (wie auf TagDoc dokumentiert) werden Tags grob unterteilt in
- primäre Tags – das sind Tags, die einem Merkmal eine semantische Bedeutung verleihen, auch wenn sie allein verwendet werden.
- sekundäre Tags – das sind Tags, die nur in Kombination mit einem primären Tag eine klar definierte Bedeutung haben.
Im Zusammenhang mit dem Kartenrendering und somit mit StyleInfo sind primäre Tags solche, die allein – wenn sie auf eine Geometrie angewendet werden – das Rendering-Ergebnis beeinflussen. Das wären z. B. Tags wie natural=water bei Polygongeometrien, highway=motorway bei linearen Geometrien oder amenity=pub bei Punkten. Sekundäre Tags sind Tags, die das Rendering eines primären Tags verändern. Beispiele hierfür sind name=* bei einem der zuvor genannten primären Tags oder bridge=yes bei highway=motorway.
In der Praxis gibt es einige Fälle in Stilen, die diesem Modell nicht folgen. Zum Beispiel werden Verwaltungsgrenzen von den meisten Kartenstilen nur dargestellt, wenn sie sowohl mit dem primären Tag (boundary=administrative) als auch mit einem admin_level=*-Tag (im Falle von OSM Carto mit admin_level zwischen 2 und 10) versehen sind. Dies erfordert die Einführung einer dritten Art von Tags in das Tagging-Modell:
- Qualifier-Tags – das sind sekundäre Tags, ohne die das primäre Tag vom Stil nicht interpretiert wird.
Neben dem erwähnten Beispiel der administrativen Grenzen ist das häufigste Qualifier-Tag das name-Tag bei Merkmalen, die ein Kartenstil nur mit einer Namensbeschriftung wiedergibt.
Beachten Sie, dass verschiedene Kartenstile unterschiedliche Annahmen darüber treffen, was primäre und was sekundäre Tags sind, was die Analyse zusätzlich erschwert. OSM Bright und auch OSM Carto in frühen Versionen interpretieren name=* als primäres Tag und geben Namensbeschriftungen für alles mit einem Namens-Tag wieder, auch wenn keine anderen Tags vorhanden sind.
Und wie gesagt – was StyleInfo bisher nicht abdeckt, sind Kombinationen aus mehreren verschiedenen primären und sekundären Tags – was interessant zu betrachten ist, weil manchmal Stile solche Kombinationen explizit darstellen (wie eine Straße mit einem Brücken-Tag und Zugangsbeschränkungen), während in anderen Fällen ein Tag ein anderes überschattet (wie in den meisten Fällen mit mehreren primären Tags). Was ebenfalls nicht behandelt wird, sind tertiäre Tags – d. h. Fälle, in denen eine Kombination aus drei Tags zu einem anderen Rendering-Ergebnis führt – wie in OSM Carto bestimmte Werte von denomination=* in Kombination mit religion=christian auf amenity=place_of_worship, wodurch sich das verwendete Symbol ändert.
Die wichtigsten Einschränkungen
Einige haben sich vielleicht schon über die Auswahl an Stilen gewundert, die derzeit in StyleInfo angeboten werden. Wie Sie am Beispiel des Map-Machine-Stils sehen können, ist die Analyse nicht auf CartoCSS/Mapnik-Stile beschränkt. Aufgrund der großen Anzahl von Tests, die durchgeführt werden müssen, ist es jedoch erforderlich, dass die Integrationstests der gesamten Rendering-Kette effizient auf Allzweck-Hardware in einer Headless-Konfiguration ausgeführt werden können. Und das ist bei all den postmodernen clientseitigen Renderingstilen, die heutzutage beliebt sind, schwierig. Wenn mir jemand einen Arbeitsablauf zeigen kann, der Maplibre/Mapbox JSON-Stile als Bilddateien auf Headless-Allzweck-Hardware rendert, ohne auf esoterischen Ballast wie npm oder docker angewiesen zu sein, könnte ich es versuchen.
Für OSM Carto und andere Stile mit einer Rendering-Datenbank, die das OSM-Tagging direkt widerspiegelt, ohne dass die Tags beim Import aufwändig uminterpretiert werden, kann die Analyse des Kartenstils erheblich beschleunigt werden, indem der Datenbankimport aus dem Test ausgeschlossen wird. Dies unterstreicht meine frühere Beobachtung, dass die Idee, Tag-Interpretationen beim Datenimport und nicht während des Renderings durchzuführen – eine Überlegung, die in letzter Zeit in der OSM-Gemeinschaft an Popularität gewonnen hat – aus Sicht des Kartendesigns eine schlechte Idee ist. Man gewinnt nichts Substanzielles (denn Tag-Interpretation ist billig), und der Kartendesigner muss entweder den Datenbankimport in seine Designarbeit und seine Tests integrieren (so wie ich es für die StyleInfo-Analyse tun muss) oder seinen Stil nicht für OSM-Daten, sondern für ein zwischengeschaltetes Datenmodell entwickeln, das sich seiner Kontrolle entzieht (wozu die meisten postmodernen clientseitigen Rendering-Stilentwicklungen tendieren – daher wahrscheinlich die Popularität dieser Idee).
Eine brauchbare Karten-Legende?
StyleInfo dokumentiert, wie ein Kartenstil OpenStreetMap-Daten und -Tagging in eine visuelle Darstellung übersetzt. Obwohl dies offensichtlich ein Schlüsselelement für die Erstellung eines brauchbaren Kartenschlüssels oder einer Legende ist, fehlt die Übersetzung zwischen den OpenStreetMap-Tags und der Semantik der realen Welt, um sich als solche zu qualifizieren. Dies ist – wie sich einige Leser vielleicht erinnern – das Ziel von TagDoc. StyleInfo und TagDoc sind Projekte, die sich gegenseitig ergänzen, und die Idee ist, dass diese beiden zusammen Schlüsselkomponenten sein könnten, um einem breiteren Publikum ein besseres Verständnis der Semantik von OpenStreetMap-Daten und von OpenStreetMap-basierten Kartenstilen zu vermitteln.
Tags interpretiert von OpenStreetMap Carto – Visualisierung von StyleInfo, Link öffnet die interaktive Version
