Deutscher Text auf Grundlage einer maschinellen Übersetzung mit deepl.

Das Thema dieses Beitrags ist etwas, mit dem ich mich schon seit einiger Zeit beschäftige – das Problem des systematischen Testens beim Kartendesign. Um zu verdeutlichen, worum es hier geht, muss ich ein wenig den größeren Zusammenhang erklären.

Traditionelles Testen bei der Kartengestaltung

Der traditionelle Weg, regelbasierte Kartenstile zu entwerfen, insbesondere im OpenStreetMap-Kontext, ist es, dies auf der Grundlage einer Testdatenbank zu tun, die eine Auswahl von tatsächlichen Kartendaten enthält. Die meisten Kartendesigner verfügen über eine Testdatenbank, die in der Regel entweder einen Auszug (z. B. von der Geofabrik oder mit der Overpass API erstellt) aus ihrem Interessengebiet oder eine Reihe von Gebieten aus verschiedenen Teilen der Welt enthält. Einen Eindruck vom Inhalt meiner Testdatenbank kann man sich in der ac-style Beispielgalerie verschaffen.

Für die Arbeit an der Gestaltung eines bestimmten Objekttyps sucht man sich ein oder mehrere Vorkommen dieses Objekttyps in Ihrer Testdatenbank und untersucht die Auswirkungen der Änderungen auf diese Vorkommen. Häufig verwendete Design-Tools – wie TileMill in den ersten Tagen oder Kosmtik (im Falle von CartoCSS-Stilen) und andere Tools, wie Maputnik, im Falle von JSON-basierten Styling-Sprachen – sind speziell für diesen Arbeitsablauf konzipiert.

Viele Beispiele für die Verwendung dieses Ansatzes bei der Stilentwicklung finden sich in OSM-Carto – wie hier.

Diese Arbeitsstrategie hat mehrere Vorteile

• Sie ist relativ unkompliziert und erfordert keinen großen Arbeitsaufwand vom Designer, um loszulegen.
• Sie testet das Design in genau dem Kontext, für den es gedacht ist, nämlich der Darstellung von tatsächlichen Kartendaten.

Aber sie bringt auch gewisse Nachteile mit sich

• Man testet das Design nur in den Kontexten, die man zufällig als Beispiele ausgewählt hat. Das deckt in der Regel weder alle relevanten Situationen ab, in denen das Design verwendet werden soll, noch ist es repräsentativ für die gesamte Vielfalt der Orte, an denen das Merkmal auftritt.
• Es ist sehr schwierig, irgendeine Art von systematischen Tests durchzuführen. Selbst der Vergleich zwischen verschiedenen Zoomstufen ist schwierig, da sich der geometrische Kontext beim Wechsel der Zoomstufe verändert.

Synthetische Tests

Aufgrund dieser Probleme haben die OSM-Carto-Entwickler seit langem damit begonnen, zusätzlich zu den traditionellen Tests auf der Grundlage von realen Testdaten synthetische Tests durchzuführen. Ich kann nicht mit Sicherheit sagen, wann dies das erste Mal gemacht wurde, aber hier sind zwei Beispiele:

Normalerweise werden solche Tests in JOSM entworfen, durch osmium renumber laufen gelassen und dann in eine Testdatenbank importiert.

Diese Art von Test ist vor allem für etwas erfahrenere Kartendesigner nützlich, die bereits im Voraus abschätzen können, in welchen Kontexten eine bestimmte Änderung besonders kritisch zu begutachten ist.

Ich würde sogar so weit gehen zu sagen, dass Änderungen des Straßenrenderingsystems von OSM-Carto, die oft in vielen verschiedenen Designkontexten funktionieren müssen, ohne den Einsatz synthetischer Tests fast unmöglich zu entwickeln sind. Das Rendering von unbefestigten Straßen, das es kürzlich endlich in OSM-Carto geschafft hat, ist ein gutes Beispiel dafür:

So nützlich diese Art des Testens auch ist, sie birgt immer auch die Gefahr, dass sich Kartendesigner vollständig auf synthetische Tests konzentrieren und das Testen mit realen Daten vernachlässigen. Das ist natürlich keine gute Idee. In der praktischen Kartengestaltung sind Tests mit realen Daten immer notwendig und wichtig.

Ein weiteres Problem besteht darin, dass bei dieser Art von handgezeichneten synthetischen Tests die Vergleichbarkeit zwischen verschiedenen Zoomstufen immer noch eingeschränkt ist.

Automatisierte Skalierung von Tests

Diese Einschränkung hat mich vor einigen Jahren dazu veranlasst, einen Ansatz zur automatischen Skalierung synthetischer Testdatensätze zu entwickeln, um eine bessere Vergleichbarkeit über Zoomstufen hinweg zu erreichen. Ich habe in diesem Blog bereits mehrfach Beispiele für diesen Ansatz gezeigt. Durch die Skalierung der Testdaten auf die gewünschte Zoomstufe werden die Rendering-Ergebnisse über verschiedene Zoomstufen hinweg viel besser vergleichbar. Dies ist besonders nützlich, um sicherzustellen, dass die Entwicklung von Designparametern über die verschiedenen Zoomstufen hinweg (z. B. Linienbreiten oder Beschriftungsgrößen) gut funktioniert.

Systematisches Testen

Sobald die automatische Skalierung von Tests funktioniert, ist es nur noch ein kleiner zusätzlicher Schritt, die Rendering-Ergebnisse systematisch in verschiedenen Zoomstufen und mit verschiedenen Kombinationen von Attributen zu testen. Dies ermöglicht zwei Dinge:

• das formale Testen des Kartendesigns in allen verschiedenen Varianten, in denen es funktionieren soll.
• die Funktionen eines Kartenstils umfassend zu dokumentieren.

Den zweiten Anwendungsfall habe ich schon vor einiger Zeit in TagDoc demonstriert:

In letzter Zeit habe ich das ganze Konzept des systematischen Testens von Kartenstilen zu einem Werkzeug weiterentwickelt, das ich im nächsten Blogpost vorstellen werde.