Dies ist der vierte Teil einer vierteiligen Serie von Blogbeiträgen über die Darstellung von Bäumen in Karten – siehe Teil 1 für eine Diskussion über die Darstellung von Bäumen in traditionellen Karten und Plänen, Teil 2 für die Erfassung von Bäumen in OpenStreetMap und die Darstellung in OSM-basierten Karten und Teil 3 für die Diskussion eines neuen Konzepts der Baumdarstellung. Der deutsche Text hier basiert auf einer automatischen Übersetzung mit deepl.
Die Baumrendering-Implementierung, die ich im vorigen Teil gezeigt und erklärt habe, ist im Wesentlichen nur eine Skizze, die einige der Designkonzepte demonstriert, die man erforschen kann, wenn man die technischen Beschränkungen gängiger automatischer Kartenrendering-Tools wirklich außer Acht lässt. Ist das zu viel für einen allgemeinen Kartenstil? Vielleicht.
Wie ich vor kurzem bereits erwähnt habe, ist die ganze Welt des automatisierten, regelbasierten Kartendesigns, wenn man die vorgefertigten Pfade verlässt, die bereits von den Technologieunternehmen und den für sie arbeitenden Tool-Entwicklern ausgekundschaftet wurden, weitgehend unerforschtes Gebiet. Die Arbeit an der Baumdarstellung hat mir einmal mehr vor Augen geführt, wie sehr das insbesondere für große Kartenmaßstäbe und hohe Zoomstufen gilt. Sobald man anfängt, Karten speziell für z19/z20 zu entwerfen, bewegt man sich in der traditionellen Domäne von Architekturzeichnungen und Lageplänen – was ein ganz neues Feld von Überlegungen und Designideen ist, wie ich im ersten Teil mit einigen Beispielen versucht habe anzudeuten. Die meisten Designer digitaler interaktiver Karten behandeln diesen Maßstabsbereich bisher einfach als eine Extrapolation der kleineren Maßstäbe. Dies gilt umso mehr für alle modernen Vektorkacheln, bei denen alles oberhalb von z16/z17 buchstäblich nur das gleiche Rendering in größeren Maßstäben plus mehr POI-Symbole und Beschriftungen ist.
Und ich denke, diese Serie von Blogposts zeigt auch einmal mehr, dass die Fähigkeiten der derzeit verfügbaren Kartenrendering-Tools sehr begrenzt sind im Vergleich zu dem, was prinzipiell möglich und wünschenswert wäre, um gut lesbare Karten zu erstellen. Die CartoCSS- und Mapnik-Toolchain, die ich hier verwende, hat den Vorteil, dass sie (über PostGIS-Code) die Möglichkeit bietet, dies auf einer niedrigen Ebene von Hand zu implementieren, aber in der Praxis sind solche Low-Level-Techniken für viele Kartendesigner wahrscheinlich unerreichbar. Abgesehen von den offensichtlichen Effizienzproblemen kann man diese Art der manuellen Symbolverarbeitung nicht mit der Erkennung und Vermeidung von Kollisionen zwischen Symbolen und Labels kombinieren.
Daher noch einmal meine dringende Empfehlung an OSM und die FOSS-Community, die ich bereits bei verschiedenen Gelegenheiten geäußert habe: Ihr müsst strategisch in fortschrittliche Kartendesign-Tools für automatisiertes regelbasiertes Kartenrendering investieren. Und wenn Ihr dies tut, dabei aber die Dinge nur aus der Perspektive eines Softwareentwicklers betrachtet oder in die Fußstapfen der großen Technologieunternehmen tretet, werdet Ihr scheitern. Die Hersteller proprietärer Software haben diese Lektion gelernt. Sie beziehen Kartendesigner aktiv in ihre strategische Planung und Forschung ein und hören ihnen zu. Ihre Zielgruppe sind bisher überwiegend noch die traditionellen Kartenersteller, für die Kartendesign die manuelle Verarbeitung konkreter Daten bedeutet und nicht die Entwicklung automatisierter Regeln zur Verarbeitung generischer Daten, wie ich sie hier diskutiere. Aber das wird sich ändern. Verpasst also nicht diese Gelegenheit.
