Dies ist ein weiterer Beitrag in meiner Reihe zum Thema Gestaltung von OpenStreetMap-Karten – anknüpfend an was ich vor einiger Zeit zu Gewässern und Furten geschrieben habe.

Wasser-Barrieren

Im ersten Teil geht es um die Darstellung von Wasser-Hindernissen oder Wasser-Barrieren, damit sind Dämme, Schleusen-Tore und Wehre sowie Wasserfälle gemeint. Wie bei Furten können diese Hindernisse in OpenStreetMap alle als Punkte auf der Gewässer-Linie erfasst werden. Für Wasserfälle ist dies die einzige anerkannte Methode – die Reliefkante, über die der Wasserfall fließt, wird als Kliff erfasst. Der Standardstil stellt Schleusen-Tore und Wehre durch einfach Kreise dar, welche in der Zeichenbreite von Flüssen sehr spät ab z17 dargestellt werden. Dies sieht recht wenig ansprechend aus.

Wasserfälle stellt OSM-Carto seit kurzem als einfache Punktsymbole dar – ebenfalls unabhängig von der Gewässerlinie.

Wie bei Furten gibt es natürlich auch hier die Möglichkeit, eine Liniengeometrie auf Grundlage der den Punkt schneidenden Gewässerlinie zu konstruieren. Für Dämme, Wehre und Schleusen-Tore erlaubt es dies, durch Punkte erfasste Objekte im selben Stil darzustellen wie als Linien erfasste Objekte. Und für Wasserfälle ermöglicht es eine kompakte und intuitiv verständliche Darstellung.

Ich habe auch die Darstellung von Wehren so angepasst, dass man die Fließrichtung des Wassers erkennen kann. Auch bei durch Punkte erfassten Schleusen-Toren und Wasserfällen ist dies möglich. Für Wehre und Wasserfälle dient hierzu eine das Wildwasser symbolisierende helle Linie unterhalb. Bei durch Punkte erfassten Schleusen-Toren wird die Linie mit einem leichten Knick gezeichnet, welcher die Öffnungsrichtung der Tore symbolisiert.

Das Problem hierbei ist, dass mit den in diesem Kartenstil für die Darstellung verwendeten Werkzeugen (und im Grunde gilt das für alle verbreitet für solche Zwecke verwendeten Werkzeuge) diese Art von Darstellung recht schwierig zu implementieren ist. Die kreuzende Gewässer-Linie zu ermitteln ist offensichtlich etwas, das man auf der Datenbank-Ebene in SQL tun muss. Aber die dabei zu erzeugende Geometrie muss an die Darstellungs-Breite der Gewässer-Linie angepasst werden, man muss also die Geometrie-Erzeugung Zoomstufen-abhängig parametrisieren.

Hier ein paar praktische Beispiele, wie das Ganze im Ergebnis aussieht.

Mit dieser Darstellung, welche als Punkte und Linien erfasste Objekte im selben Stil anzeigt, stellt sich die Frage, welche Form der Erfassung die bessere ist. Das Problem dabei ist, dass Gewässer-Linien üblicherweise bei kleinen Maßstäben dicker gezeichnet werden als sie wirklich sind, damit sie gut sichtbar bleiben. Bei großen Maßstäben werden sie hingegen entweder dünner als in Wirklichkeit gezeichnet oder – falls ein Wasserflächen-Polygon existiert – in der realen Breite. Im einfachsten Fall ist die von mir konstruierte Linien-Geometrie so lang wie die Gewässerlinie in der Breite ist. Die Darstellung sieht folglich bei kleinen Maßstäben recht gut aus, bei größeren Maßstäben jedoch nicht mehr, falls es ein Wasserflächen-Polygon gibt und die Zeichenbreite der Barriere nicht an die Breite des Polygons angepasst wird.

Wenn hingegen eine Wehr mit einer Linie über die gesamte Wasserfläche hinweg erfasst ist, sieht dies bei hohen Zoomstufen gut aus, nicht jedoch bei kleinen Maßstäben, denn die Linien-Geometrie ist dann zu kurz für die in diesem Fall breiter als in der Realität gezeichnete Fluss-Linie. Ich habe für diese zwei Fälle auch Lösungen implementiert, diese sind jedoch deutlich komplexer und aufwändiger als der erste einfache Fall.

Um die verschiedenen Fälle besser zu verstehen hier das Ganze in Tabellen-Form, erst wie bei OSM-Carto dargestellt, dann mit den hier vorgestellten Techniken.

	Punkt	Linie
niedrige Zoomstufe
hohe Zoomstufe

	Punkt	Linie
niedrige Zoomstufe
hohe Zoomstufe

Insgesamt betrachtet ist also sowohl die Erfassung als Punkt als auch als Linie für den Zweck der Karten-Darstellung wie hier demonstriert eine brauchbare Basis. Die Erfassung mittels Polygonen hingegen ist – egal wie man Konkret die Umrisse eines solchen Polygons definiert – deutlich schwieriger zu interpretieren um eine hochwertige Darstellung in Karten zu produzieren. Für Dämme sind Polygone zur Erfassung weit verbreitet und akzeptiert. Für die übrigen Barriere-Formen hingegen ist dies – wenngleich in der Dokumentation klar nicht vorgesehen – auch erstaunlich verbreitet durch die weit verbreitete Fehlannahme, dass die Erfassung von Objekten als Polygone immer besser ist als jede andere Erfassungsform.

Für die Effiziente Darstellung wichtig ist aber vor allem Auch, die Wasserflächen-Erfassung der Flüsse in relativ kleinen Polygonen durchzuführen und nicht welche zu bauen, die sich über hunderte Kilometer erstrecken.

Ein weiteres Problem, welches aus den für die Darstellung verwendeten Werkzeugen resultiert ist, dass man für die Beschriftung alle diese recht komplexen Abfragen noch einmal durchführen müsste, denn die Beschriftung erfolgt in einer getrennten Darstellungsebene und man kann die Abfrage-Ergebnisse nicht zwischen verschiedenen Ebenen wiederverwenden. Für den Moment habe ich hierauf verzichtet so dass die Beschriftungen von Wasser-Barrieren einfach Punkt-Beschriftungen sind und nicht in die Zeichen-Richtung der Barriere ausgerichtet sind.

Ich bin mir nicht ganz sicher, wie diese Darstellungsform als Rückmeldung an Mapper wirkt. In den meisten relativ einfachen Fällen denke ich, dass eine Darstellung auf Grundlage einer Vernünftigen und konsistenten Interpretation der Daten wie ich sie hier durchführe in Ordnung ist, selbst wenn sie recht weit über eine einfache und direkte Visualisierung der Daten hinaus geht. Und meiner Meinung wird dadurch auch die positive Nachricht kommuniziert, dass eine recht einfache Erfassungs-Form (wie ein Punkt, welche eine Barriere auf einer Gewässer-Linie repräsentiert) ausreichend Informationen für eine präzise Darstellung beinhaltet und es nicht erforderlich ist, dass der Mapper quasi per Hand die Karte zeichnet. Aber insbesondere in den zwei komplizierteren Fällen (die Erfassung als Punkt bei hohen Zoomstufen und mit einem Wasserflächen-Polygon und die Erfassung als Linie bei niedrigen Zoomstufen) ist es recht wahrscheinlich, dass es Fälle gibt, wo die vorgestellten Methoden nicht gut funktionieren und dies zu einem nicht intuitiven Ergebnis führt. Wie problematisch dies wäre ist aber eine offene Frage. Dies ist auf jeden Fall ein Thema für das es deutlich zu wenig praktische Erfahrungen gibt um verlässliche Schlussfolgerungen zu ziehen.

Wasser-Quellen

Die zweite Änderung, die ich hier vorstellen möchte, betrifft das Aufräumen bei den inzwischen recht chaotischen Darstellungen von Punkt-Symbolen mit Wasser-Bezug in OSM-Carto. Eines davon – den Wasserfall – habe ich schon oben diskutiert. Die anderen zwei Symbole mit Wasser-Bezug in OSM-Carto sind im Moment Springbrunnen und Quellen. Zusammen mit den Wasserfällen werden für diese drei Objekt-Klassen drei verschiedene Farben verwendet was gestalterisch ziemlicher Unsinn ist.

Aber bevor ich das verbessern konnte, musste ich mich um ein anderes Problem kümmern. Der Standardstil verwendet seit langer Zeit einen Kräftigen Blau-Ton für die Darstellung von Symbolen mit Bezug zu Fortbewegung und Unterkunft – zum Beispiel Bushaltestellen, Parkplätze, Hotels, Campingplätze usw. Diese Verwendung von Blau hat zwar eine lange Tradition in OpenStreetMap – ist aber für ein intuitives Verständnis der Karte nicht ideal und steht im Konflikt mit der Verwendung von Blau für die Darstellung von Dingen mit Wasser-Bezug, wofür ein kräftiges Blau auch nützlich sein kann. Ich hab folglich die Symbol-Farben ein wenig um-organisiert – indem ich die Verwendung von Violett, zuvor nur für Lufttransport-Objekte eingesetzt, auf die Symbol-Klassen ausgedehnt habe, für die zuvor das kräftige Blau Verwendung fand. Daran muss man sich natürlich erst ein bisschen gewöhnen. Gleichzeitig habe ich auch die Verwendung von Grün für Freizeit-Symbole abgeschafft, welche vor einiger Zeit eingeführt wurde und welche – ähnlich wie bei Blau – eigentlich auf Objekte mit Vegetations-Bezug beschränkt bleiben sollte.

Hierdurch wird das kräftige Blau frei für die Verwendung für Punkt-Symbole mit Wasser-Bezug.

Die Darstellung von Quellen ist in OSM-Carto vor kurzem geändert worden aber nicht wirklich in einer sehr vorteilhaften Form. Die Haupt-Motivation für diese Änderung war es, das alte Symbol mit einer ‘s’-Form abzuschaffen, was für ‘spring’ steht und für eine internationale Karte offensichtlich nicht optimal ist. Aber man sollte sich dabei klar machen, dass das alte Symbol als geometrisch einfaches Punkt-Symbol für die Verwendung bereits bei recht niedrigen Zoomstufen recht gut funktioniert hat, denn es ist sehr kompakt und wenig aufdringlich und gleichzeitig recht klar und wiedererkennbar.

Die neue Symbol-Gestaltung ist – wenngleich mit guten Absichten entwickelt – aus verschiedenen Gründen nicht optimal:

• Das generische Kreis-Symbol ist sehr wenig spezifisch und kann auf eine Vielzahl von Objekt-Typen mit Wasser-Bezug hindeuten (oder ohne Wasser-Bezug, denn das kräftige Blau kommt ja auch anderweitig zum Einsatz).
• Das Symbol ist größer und auffälliger ohne dass es gleichzeitig klarer und besser lesbar ist als das alte. Es erzeugt erhebliche Unruhe in der Karte, insbesondere bei niedrigen Zoomstufen.
• Die Zeichen-Reihenfolge platziert das Symbol unterhalb der Gewässer-Linien, was eine ganze Reihe von Problemen bewirkt, insbesondere indem es eine Abhängigkeit von der Reihenfolge der Wasser-Ebenen erzeugt (wo die Gewässer-Linien über den Flächen gezeichnet werden), was eine recht starke Einschränkung darstellt.

Mein Ansatz ist hier, die selbe Grundform für verschiedene Wasser-Quellen-Objekte zu verwenden und durch Variation des Symbols verschiedene Objekt-Klassen zu differenzieren. Das Symbol ist dabei sehr kompakt gestaltet so dass es bei den niedrigen Zoomstufen nicht nennenswert mehr Platz einnimmt als das ursprüngliche ‘s’-Symbol. Die Symbol-Größe wird dann zwei Zoomstufen oberhalb etwas vergrößert um die Lesbarkeit zu verbessern. Hier ist gezeigt, wie das Ganze aussieht. Brunnen werden eine Zoomstufe später angezeigt als Quellen (z15 und z14) und Springbrunnen ab z17.

Wie man sieht ist die Grundform des Symbols die selbe für mit Gewässer-Linien verbundene und isolierte Quellen so dass man erkennen kann, dass es sich um den selben Objekttyp handelt. Aber die Darstellung in Verbindung mit einer Gewässer-Linie muss natürlich an deren Gestaltung angepasst werden, so dass beide Formen nicht exakt indentisch aussehen. Und ich habe die Darstellung von heißen Quellen und Geysiren ergänzt. Diese werden mit einem roten Punkt in der Mitte dargestellt. Nur zeitweilig wasserführende Quellen sind auch durch eine Symbol-Variation unterschieden. Bei den höheren Zoomstufen sieht man außerdem neue Symbole für amenity=water_point und man_made=water_tap.

Die Darstellung von mit Gewässer-Linien verbundenen Quellen ist implementiert, indem ich die Geometrie aus SQL heraus erzeuge. Wie bei den Wasser-Barrieren erfordert dies die Parametrisierung mit der Darstellungs-Breite der Gewässer-Linie in Abhängigkeit von der Zoomstufe auf SQL-Ebene. Ein alternativer Ansatz wäre es, SVG-Symbole zu verwenden und diese passend zu rotieren. Aber man bräuchte hierfür eine recht große Anzahl unterschiedlicher SVGs für die verschiedenen Linienbreiten so dass das Ganze am Ende kaum weniger aufwändig wäre.

Eine weitere Neuerung ist die Darstellung eines zusätzlichen Becher-Symbols neben dem Haupt-Symbol bei höheren Zoomstufen für Objekte mit einem zusätzlichen Attribut amenity=drinking_water oder drinking_water=yes. Dies ist eine weitere Anwendung, bei der die Einschränkungen der verwendeten Werkzeuge sichtbar werden. Idealerweise würde man das Zusatz-Symbol dort platzieren, wo Platz vorhanden ist. Ich glaub jedoch nicht, dass dies mit den für diesen Stil verwendeten Werkzeugen möglich ist. Folglich habe ich einfach eine konstante Nordwest-Position gewählt. Was im Grunde möglich wäre ist die Positionierung bei mit Gewässer-Linien verbundenen Quellen so, dass das Symbol nicht über die Linie gezeichnet wird.

Die kleinen Symbole für Wasser-Quellen werden mit einem dünnen Weißen Rahmen gezeichnet, so dass sie vor einem dunklen oder strukturierten Hintergrund besser sichtbar sind. Hier ein paar praktische Beispiele dafür, wie das Ganze in der Karte aussieht.

Zusammenfassung

Was ich hier vorgestellt habe sind eine Reihe von kartographischen Gestaltungs-Techniken, welche dabei helfen können, bessere Karten zu produzieren:

• Die Verwendung von räumlichen Beziehungen zwischen verschiedenen Karten-Elementen (konkret: Punkt-Objekte mit Wasser-Bezug und die Gewässer-Linie auf der sie sich befinden) für ein harmonischeres und weniger unruhiges Kartenbild und für zusätzliche Informationen (wie die Wasserfluss-Richtung) für den Karten-Nutzer.
• Die Verwendung subtiler Symbol-Variationen um leicht unterschiedliche Objekt-Typen darzustellen und um zusätzliche Informationen zu transportieren ohne dass die Interpretation der Karte deutlich komplizierter wird. Verwendung von kombinierten Symbolen aus mehreren Komponenten für zusätzliche Informationen (hier: Die Verwendbarkeit von Wasserquellen als Trinkwasser).
• Die Verwendung einer vereinfachten Symbol-Variante bei kleineren Maßstäben für eine kompaktere Darstellung.
• Die Vereinheitlichung verschiedener Erfassungsformen (hier: Erfassung von Wasser-Barrieren als Punkte und Linien) in einem einheitlichen Design für verschiedene Maßstäbe.

Wie immer findet man die vorgestellten Änderungen zum Studieren und Testen im alternative-colors-Stil.