Hier ein weiterer Beitrag aus meiner Serie zum Thema Gestaltung von OpenStreetMap-Karten – diesmal zur Darstellung von implizit erfassten Böschungen.
„embankments“ in OpenStreetMap sind künstliche Böschungen, welche vor allem gebaut werden um für den Bau von Straßen oder Schienen eine ebene Plattform zu schaffen – oder um anderweitig die Topographie künstlich zu gestalten. „cutting“ hingegen beschreibt das Gegenteil, künstliche Einschnitte in die natürliche Topographie, welche ähnlichen Zwecken dienen.
Was bedeutet in diesem Zusammenhang implizit? In OpenStreetMap können Böschungen explizit durch eine Linie mit dem Tag man_made=embankment erfasst werden, welche am oberen Rand der Böschung gezeichnet wird. Dies wird seit langem im OSM-Standardstil ähnlich wie natürliche Kliffe dargestellt mit einer grauen Linie und Markierungen auf der einen Seite, um die Richtung der Böschung zu zeigen. Die implizite Erfassung von Böschungen hingegen bedeutet, dass man die Böschungen entlang einer Straße oder Bahnlinie über ein Zusatz-Attribut erfasst. Dies geschieht mittels embankment=yes und cutting=yes. Die implizite Erfassung mittels embankment=yes ist mehr als doppelt so weit verbreitet wie man_made=embankment – zusammen sind embankment=yes und cutting=yes dreimal so verbreitet.
Dennoch werden embankment=yes und cutting=yes in OSM-Carto nicht dargestellt – da es nicht ganz einfach ist, dies in einer ansprechenden Form zu tun.
Was recht problemlos möglich wäre ist die Darstellung von embankment=yes mit einer besonderen Farbe der Umrahmung ähnlich der Darstellung von Brücken (oder wie meine Darstellung von Furten im alternative-colors-Stil). Dies wäre jedoch schwer intuitiv verständlich. Ein besserer Weg der Darstellung wäre in Form einer Linie mit seitlichen Marken wie sie bei man_made=embankment verwendet werden um die Straßen-Linie herum. Hier ist gezeigt, wie das aussehen würde:
Sehr einfache Form der Darstellung von Böschungen und die Fehler, zu denen dies führt
Wie man sieht ist das Ergebnis in ganz einfachen Fällen ganz akzeptabel, das Ganze geht jedoch in komplizierter gelagerten Fällen teils komplett daneben. Insbesondere bei Straßen, wo beide Fahrbahnen separat erfasst werden wie Autobahnen ist dies ein großes Problem.
Um diese Probleme zu vermeiden muss man für jede Straße mit Böschungen deren Umfeld, also andere Straßen mit und ohne Böschungen, mit berücksichtigen. Dies wird sehr schnell sehr kompliziert und in Bezug auf den Rechenaufwand teuer. Hier ist das Ergebnis eines Kompromisses, den ich zwischen Qualität und Geschwindigkeit ausgewählt habe.
Aufwändigere Darstellung von Böschungen
Die Abfrage dafür ist etwa 4-5 mal langsamer als die zuvor gezeigte trivial-Version – das klingt nach viel, ist aber eigentlich gar nicht so schlecht. Aufgrund der Art und Weise, wie die Abfragen durchgeführt werden, ist dies jedoch deutlich weniger effizient, als dies eigentlich theoretisch möglich wäre. Für die Darstellung der Straßen selbst muss man ja sowieso alle Straßen in der jeweiligen Kachel abfragen und man könnte das Ergebnis davon auch verwenden, um die notwendigen Berechnungen bei den Böschungen durchzuführen. Unglücklicherweise lassen sich mit Mapnik jedoch die Ergebnisse von Abfragen nicht in anderen Ebenen wiederverwenden.
Ein weiteres technisches Problem, mit welchem ich schon bei der Darstellung von Quellen und Wasser-Barrieren zu tun hatte ist, dass es für komplexere Geometrie-Berechnungen notwendig ist, die verwendeten Linienbreiten in Abhängigkeit von der Zoomstufe innerhalb des SQL-Codes zu kennen. Um dies zu ermöglichen ohne jedesmal ein längeres CASE-Statement mit den verschiedenen Linienbreiten dort in den SQL-Code einzufügen, wo die Linienbreite eingeht und welche dann alle geändert werden müssen, wenn irgendwo mal eine Linienbreite geändert wird, habe ich ein Skript geschrieben (abgeleitet vom bestehenden Skript für die Straßen-Farben), welches sowohl SQL-Funktionen als auch MSS-Code für die Definition und Auswahl der Linienbreiten auf Grundlage einer yaml-Datei erzeugt.
Die impliziten Böschungen werden werden für alle üblichen Straßen und Wege sowie für Eisenbahn-Schienen und Wasserwege dargestellt.
Böschungen für alle Arten von Linien-Objekten
Wie man sieht habe ich den Abstand der Marker auf den Linien im Vergleich zu OSM-Carto reduziert, da dies mit kleinen Krümmungs-Radien der Böschungen im Zusammenhang mit Straßen besser funktioniert.
Ich beginne mit der Darstellung von impliziten Böschungen ab z16. Früher anzufangen würde bedeuten, dass das Gesamtobjekt Straße plus Böschung sehr viel Platz einnimmt, denn normalerweise werden Straßen bei z15 und unterhalb in einer Linien-Breite gezeichnet, welche über ihrer tatsächlichen Breite liegt und die Böschung macht dies noch breiter. Das führt in vielen Fällen zu Überlappungen mit anderen Objekten und damit zu merkwürdigen Ergebnissen, insbesondere in detailliert erfassten Gebieten, was als Anreiz zum Mappen kontraproduktiv wäre.
Hier ein paar Beispiele bei z16:
Und hier bei z17:
Das letzte Beispiel zeigt sowohl implizit und explizit erfasste Böschungen. Die impliziten Varianten werden bei diesem Maßstab in etwa in ihren tatsächlichen Dimensionen dargestellt. Die implizite Erfassung hat ganz allgemein den Vorteil, dass sie sowohl in diesem Fall, als auch bei anderen Maßstäben gut aussieht während die explizite Erfassung nur dann ordentlich aussieht, wenn die Straße oder der Weg in ihrer tatsächlichen Breite gezeichnet wird. Bei einer geringeren Linienbreite bei den höheren Zoomstufen entsteht eine Lücke zwischen der Straße und der Böschung und bei einer größeren Linienbreite überlappen sich die Linien-Signatur der Straße und die Böschung, so dass letztere entweder nicht oder nur teilweise sichtbar ist. Dies zu vermeiden und die explizit erfasste Böschung bei den niedrigen Zoomstufen passend zu verdrängen wäre recht schwierig. Um hochwertige Karten mit relativ geringem Aufwand zu produzieren ist die implizite Erfassung von Böschungen also deutlich günstiger.
Wer das Ganze selbst ausprobierene möchte findet die Änderungen wie üblich im alternative-colors-Stil.