Der Tourenplaner von singletrails.com zeigt sich seit kurzem im neuen Gewand. Die Funktionen zur Routenplanung wurden neu sortiert und jetzt gut erreichbar in einer Toolbox platziert. Unter anderem findet ihr jetzt:

  • Länge, Auf- und Abstieg der bislang geplanten Tour
  • Undo und Redo für jede Änderung eurer Tourenplanung
  • Speichern und Öffnen von Touren (kostenlose Anmeldung erforderlich)
  • Übersicht über die Straßen- und Wegbeschaffenheit

Eine Einführung in die Tourenplanung findet ihr im verlinkten Youtube-Video

Wer kennt es nicht: unterwegs auf einer langen MTB- oder Rennrad-Tour, die Sonne brennt, die Trinkflasche ist leer und die Suche nach einem Brunnen zieht sich endlos. Nicht zuletzt aus Eigennutz bietet singletrails.com jetzt eine einfache Möglichkeit die nächstgelegene Wasserquelle zu finden. Dazu muss man nur über das Ebenen-Auswahltool, das sich rechts oben in jeder Karte findet, die Ebene „Trinkwasser“ auswählen. Anschließend werden alle bekannten Stellen mit einem blauen Wasserhahn-Symbol markiert.

Da ihr ja in der Regel im Umkreis der Stelle sucht an der ihr euch gerade befindet noch ein kleiner Tipp: über das Positions-Symbol, das ihr auf der linken Seite der Karte unterhalb der Suchlupe findet, positioniert ihr die Karte automatisch auf euren aktuellen Standort. Wie bei allen Kartenanwendungen üblich muss dafür allerdings die Lokalisierungsfunktion eures Handys aktiv sein und ihr müsst ggf. der Webseite gestatten die aktuelle Position zu ermitteln. Falls ihr euch an dieser Stelle Gedanken über die Sicherheit eurer persönlichen Daten macht kann ich euch beruhigen: die Position wird nur verwendet um die Karte an die richtige Stelle zu rücken und wird zu keinem Moment ins Internet übertragen.

Die Daten kommen übrigens wie so viele Informationen auf dieser Seite direkt aus openstreetmap.org, dem großartigen Internetprojekt in dem Tausende von Mitwirkenden ihre  lokalen Kenntnisse in einer Kartendatenbank hinterlegen. Da stellt sich natürlich sofort die Frage wie vollständig und verlässlich die dort hinterlegten Daten sind. Daher habe mir meine heißesten Touren in Erinnerung gerufen und ihren Verlauf geprüft. Das Ergebnis war erstaunlich: ich habe viel mehr Trinkwasserstellen gefunden als ich vermutet hätte. Anfangs war ich etwas skeptisch und habe versucht die Fundstellen über andere Quellen, insbesondere Google Street View, zu verifizieren. Und voilá – in den allermeisten Fällen fand ich die Bestätigung. Die Fälle an denen ich mir beim besten Willen nicht vorstellen kann dass dort Wasser zu finden ist schätze ich auf maximal 5% der untersuchten Stellen. Und auch umgekehrt: an den allermeisten Trinkstopps an die ich mich erinnert habe zeigte auch die Karte kühles Nass.  Insgesamt bleibt für mich das Fazit dass ich tatsächlich oft mit hängender Zunge an einem erfrischenden Brunnen vorbeigefahren bin, wo ich nur den Kopf hätte kurz drehen müssen.

Es ist aber auch festzustellen dass nicht in allen Regionen die Daten gleich gut gepflegt sind. Glücklicherweise scheint es aber so zu sein dass die Wasserstellen in den heißen europäischen Ländern zuverlässiger erfasst sind als in den gemäßigten. Da openstreetmap.org ein Gemeinschaftsprojekt ist kann jeder mithelfen die Daten zu verbessern. Wer also eine Quelle oder einen Brunnen vermisst oder feststellt dass an der Stelle definitiv nichts mehr vorhanden ist würde der Radwelt einen Gefallen tun indem er/sie die Informationen auf den aktuellen Stand bringt. Informationen wie Wasserstellen in openstreetmap hinterlegt sind findet ihr unter dem Tag drinking_water. Innerhalb weniger Tage ist die Information dann auch auf singletrails.com verfügbar.

 

 

 

Verlässliche Höheninformationen sind essentiell um eine MTB-Runde aus konditioneller und technischer Sicht bewerten zu können. Gefahrene Geschwindigkeit, Belastungsintensität, Fahrzeit aber auch Fahrspaß hängen maßgeblich von den Steigungen und Gefällen ab. Bewältigte Höhenmeter und Kalorienverbrauch sind wichtiger Bestandteil jeder Auswertung.

In einer Beitragsreihe möchte ich verschiedene Aspekte beleuchten, die vielleicht hilfreich sind um die Höheninformationen die euch ein GPS Gerät, eine Navigationsapp oder eine Auswertung anzeigen, beurteilen zu können. Beginnen möchte ich mit ein paar Anmerkungen zu digitalen Höhenmodellen.

Quellen für Höheninformationen

Es gibt im wesentlichen 3 praktisch relevante Quellen für die Höheninformationen die euch im MTB Alltag begegnen:

  • Zahlreiche GPS-Geräte (und einige wenige Smartphones) besitzen einen eingebauten barometrischen Höhenmesser, der die aktuelle Höhe anhand des Luftdrucks bestimmt. Diese Methode kann Höhenänderungen sehr gut messen. Um die absolute Höhe richtig wiederzugeben muss der Höhenmesser allerdings an Punkten mit  bekannter Höhe kalibriert werden. Weiterhin sind bei der Interpretation der gemessenen Höhen externe Einflüsse zu berücksichtigen, insbesondere Luftdruck- und Temperaturschwankungen aufgrund von Wetteränderungen oder eine  eventuelle Beeinträchtigung des Sensors durch Nässe und Schmutz.
  • Aus den Signalen der GPS-Satelliten kann neben der Position im Prinzip auch die Höhe ermittelt werden. Allerdings ist die Genauigkeit dieser dritten Dimension systembedingt um etwa eine Größenordnung schlechter als die der Ortskoordinaten. Zudem ist die Höhenmessung auf schlechte Empfangsbedingungen (zu wenige sichtbare GPS-Satelliten, ungünstige Satellitenkonstellation, …) deutlich anfälliger, was zu sprunghaften Änderungen in den gemessenen Höhen führen kann. Die Höhenbestimmung über GPS ist daher lediglich für eine grobe Bestimmung der absoluten Höhe unter guten Bedingungen geeignet, nicht aber zum Aufzeichnen von detaillierten Höhenprofilen. Mangels Alternativen wird diese Methode in der Regel die von Geräten ohne barometrische Höhenmessung und Navigations-Apps verwendete Quelle sein.  In einem späteren Blogbeitrag werde ich vielleicht diese Art der Höhenbestimmung noch näher betrachten.
  • Zu guter Letzt gibt es noch die digitalen Höhenmodelle, um die es in diesem Beitrag gehen soll. Bei ihnen sind die Höhendaten in einer großen Datenbank hinterlegt. Aus dieser werden die Höhen zu den aufgezeichneten Track-Koordinaten ermittelt und dem Track hinzugefügt. Dies geschieht meist erst im Nachhinein wenn man einen gefahrenen Track in ein Portal hochlädt. Bezüglich dieser Höhenmodelle gibt es einiges zu beachten, was ich im folgenden kurz erläutern möchte.

Die digitalen Höhenmodelle SRTM und ASTER

Es gibt zahlreiche digitale Höhenmodelle, etwa von Vermessungsämtern, die allerdings meist nur eine begrenzte Region abdecken und in unterschiedlichen Referenzsystemen vorliegen. Von besonderer Bedeutung sind daher zwei Höhenmodelle die (mit Ausnahme der Polregionen) eine globale Abdeckung besitzen:

  • Dei Daten zum SRTM (Shuttle Radar Topography Mission) Modell wurden 2000 während einer Space Shuttle Mission mittels Radarmessung aus dem Weltall ermittelt. Sie liegen in einem Raster von 90x90m oder 30x30m vor. Aufgrund der verwendeten Messmethode geben die Höhendaten die Oberflächenstruktur inklusive Bewuchs und Bebauung wieder. 
  • Für das Höhenmodell ASTER wurden stereoskopische Aufnahmen vom Erdbeobachtungssatelliten Terra ausgewertet. In dem man die gleiche Stelle aus unterschiedlichen Blickwinkel aufnimmt kann aus diesen Aufnahme die Höhe zurück berechnet werden.  Die Auflösung beträgt ca. 30m. Auch 

Es gibt wissenschaftliche Untersuchungen und Vergleiche der Genauigkeit (z. B. Loudi Yap et al). Aus diesen lässt sich jedoch nur schwer ablesen welche praktischen Folgen sich aus der Verwendung eines digitalen Höhenmodelles ergeben. Ich möchte daher die Betrachtung pragmatisch anhand eines repräsentativen Areals bei mir in der Nähe führen.

Als Referenz nutze ich dazu das offizielle Modell DGM 1 des Bayerischen Vermessungsamtes. Es wurde von Flugzeugen aus mittels LIDAR Methode gemessen, welche die tatsächliche Bodenstruktur wiedergebt. Die hohe Genauigkeit ist bereits in der Relief-Darstellung deutlich erkennbar, da man z. B. die Verläufe einzelner Wege klar erkennt. Die Höhengenauigkeit wird mit ± 0,2 m angegeben. Die Höhendaten liegen in einem Raster von 1x1m vor.

Das Testgebiet

Bei dem Testgebiet handelt es sich um einen ca. 400m x 400 m grosses Arreal (blauer Kasten) rund um einen Hochbehälter im Fürther Stadtwald, welcher in Form zweier rechteckiger Plateaus in der Reliefdarstellung erkennbar ist.

Referenz-Region

Westlich davon fällt das Gelände relativ steil ab und führt in zwei Geländeeinschnitten Richtung Norden, wo sich auch Reste mittelalterlicher Steinbrüche finden. Diese sind als Abbruchkanten gut sichtbar. In diesem Bereich finden sich einige schöne MTB Abfahrten. Richtung Osten und Norden fällt das Gelände ebenfalls deutlich aber weniger steil ab.

Vergleich SRTM-Höhenmodell zu Referenzmodell

Im folgenden Bild sind die Höhendaten aus dem SRTM-Modell (links) und aus dem LIDAR-Referenzmodell (Mitte) nebeneinandergestellt. Die Höhendaten sind im 90×90 m Raster der SRTM-Daten ermittelt, so dass keine Interpolation notwendig ist. Im rechten Bild ist die Differenz der Daten angezeigt und in Abhängigkeit der Differenz farblich eingefärbt.

Vergleich SRTM - Referenzmodell

Die geringste Abweichung von 1,7 m findet man im Bereich des Hochbehälters (weiss). Dass entspricht der Erwartung dass dies die einzige Fläche ohne Bewuchs ist und die Oberflächenmessung aus SRTM das beste Ergebnis liefern sollte. Interessanterweise ist dieser Punkt im Referenzmodell auch der höchste, was auch der Realität entspricht. Im SRTM-Modell gibt es jedoch im umgebenden Wald zahlreiche mit grösseren Höhen. Dies spiegelt sich auch im rechten Bild wieder, wo die Unterschiede typischerweise 10m und mehr betragen sobald Bewaldung vorhanden ist. Auch wenn es schwierig ist die reale Höhe der Bäume abzuschätzen und vorherzusagen wie die SRTM-Messmethode über die Baumkronen mitteln wird ist dies ein typischer Wert, den man oft findet wenn man Höhen aus dem SRTM-Modell über Baumgrenzen hinweg ermittelt.

Auffällig ist ebenfalls dass die Höhendaten im SRTM-Modell weniger stark variieren als im LIDAR-Referenzmodell. Im erweiterten Ausschnitt sieht man dass so schnell Differenzen von 25m und mehr (rot markiert) entstehen.

Vergleich SRTM - Referenzmodell (grosser Ausschnitt)

Es ist also so dass die SRTM-Höhen nicht einfach der Bodenstruktur plus einem konstanten Offset für die Bewaldung folgen. Vielmehr ist das Relief deutlich verwaschener und gibt das tatsächliche Relief nur sehr grob wieder. Man kann sich das so erklären dass mittels der SRTM-Methode  nicht die Höhe an genau einem Punkt, sondern ein Mittelwert über einen Bereich um diesen Punkt herum gemessen wird. Das erkennt man an den beiden Stellen mit rot markierten Höhenpunkten besonders gut.

Im rechten Bereich fällt das Gelände auf etwa 300 m um ca. 30 m in eine breite Senke ab. In den SRTM-Daten findet man nur etwa die Hälfte dieser Höhendifferenz.  Die Auflösung ist also scheinbar so grob dass in die SRTM-Höhe die höheren Bereiche der Umgebung mit einfließen. Oben links findet man eine Abweichung ähnlicher Größenordnung. Hier befindet sich in der Realität gar keine Senke. Vielmehr scheint sich die leichte Anhöhe, die nordwestlich liegt, auf die gemessenen Werte auszumessen. Insgesamt lässt sich aus den Beobachtungen abschätzen dass die gemessene Reliefauflösung noch gröber ist als die reine Rasterweite der Daten (im Beispiel 90 m).

In der Praxis kommt eine weitere Unsicherheitsquelle hinzu. Da die Höhendaten in einem Raster vorliegen muss man zur Bestimmung der Höhe an einer bestimmten Stelle immer eine Interpolation vornehmen, also aus den Werten der in der Nähe liegenden Rasterpunkte einen Zwischenwert errechnen. Das Problem ist nun dass eine reale Bodenstruktur sich nicht einfach über lineare oder quadratische Formeln abbilden lässt. Verwendet man für die Interpolation jedoch Formeln höherer Ordnung so muss man zwangsweise weiter entfernter liegende Messpunkte mit einbeziehen, von denen man weiß dass sie immer weniger Aussage über den eigentlich interessierenden Punkt erlauben. In Summe kann man also festhalten dass man selbst wenn man ein Raster verlässlicher Höhenmessungen hätte die Bestimmung der Höhen an beliebigen Punkten nicht mit der gleichen Genauigkeit möglich ist.

Als Zwischenfazit kann man also drei Schwachstellen des digitalen Höhenmodells SRTM festhalten:

  • der Einfluss von Bewuchs und Bebauung
  • sehr grobe Reliefauflösung
  • Fehler durch Interpolation

Praxistest Nr. 1: Höhenverlauf am Main-Donau-Kanal

Für den ersten Praxistest nutze ich den nahezu perfekt ebenen Weg am Main-Donau-Kanal bei Fürth, den ich auf einer Länge von ca. 3,5 km in beide Richtungen abgefahren bin. Die interessanten Stellen sind in der Übersichtskarte gut erkennbar:

Beispiel 1: Trackverlauf
  • die Aufzeichnung beginnt und endet mit einer Treppe (links oben im Bild), deren Höhenunterschied etwa 10 m beträgt. Dies ist der einzige relevante Höhenunterschied während der Testfahrt. Diese Stelle sollte im Höhenprofil als kurzer, steiler Ab- und Anstieg erkennbar sein.
  • nach etwa 2,5 km nähert man sich der etwa 300 m langen Kanalbrücke, die den darunterliegenden Rednitzgrund in einer geschätzten Höhe von 15m überquert. Diese Stelle ist der Prüfstein, an dem man zuverlässig erkennen kann ob eine Messung auf digitalen Höhenmodellen basiert. Ist dies der Fall wird die Höhe über einen Bereich gemittelt, der Teile der Brücke aber auch der darunterliegenden Wiese umfasst, und somit zwangsläufig zu tief ermittelt. Im Ergebnis wird das Höhenprofil eine künstliche Senke aufweisen.
  • im Verlauf der Testfahrt unterquert man eine Reihe von Strassenbrücken. Hier ist der umgekehrte Effekt zu erwarten: in über digitale Höhenmodelle ermittelte Werte sollte diese zum Teil mit eingerechnet sein und somit zu hoch ausgewiesen. Solche Stellen würden als virtuelle Anstiege erkennbar sein.
  • Ansonsten ist das Terrain uneinheitlich. Auf der einen Seite liegt der etwa 40 m breite Kanal konstant geschätzte 3-4 m unterhalb des Radweges. Auf der anderen Seite befindet sich im oberen Drittel ein Abhang von zu Beginn ca. 15 m Höhe. Die Höhendifferenz wird kontinuierlich kleiner bis auf Höhe von Eschenau der Radweg etwa auf Höhe der Umgebung und sogar leicht darüber ist. Etwa auf Höhe der unterquerten Bahnbrücke rückt die Bewaldung wieder näher heran. Auf der anderen Seite der Kanalbrücke ist der Radweg wiederum leicht erhöht gegenüber der Umgebung.

Diese Teststrecke habe ich parallel mit einer Reihe von Smartphone-Apps aufgezeichnet, bei denen ich die Verwendung digitaler Höhenmodelle vermutete. Dies sind:

  • Komoot (orange)
  • AllTrails (Gpsies-Nachfolger) (hellgrau)
  • Strava (blau)
  • RideWithGPS (gelb)
  • als Referenz dient ein Garmin Edge 1030 mit barometrischer Höhenmessung (dunkelgrau).
Beispiel 1: Höhenverlauf

In der Darstellung sind die gemessenen Höhen über der Zeit gezeigt. Die horizontalen Linien haben einen Abstand von 5 Höhenmetern. Da Aufzeichnungen mit bikemap und outdooractive nicht mit Zeitstempel exportierbar sind konnte ich sie nicht in die Auswertung einbeziehen.

  • Entsprechend der Erwartung ergibt sich für den Edge 1030 ein fast ebener Verlauf entlang des Kanalwegs. Die langsame Schwankung von ± 2 m zeigt dass auch die barometrische Messung eine gewisse Ungenauigkeit mit sich bringt. Ebenfalls gut zu erkennen sind die An- und Aufsteige an der Treppe zu Beginn und am Ende des Tests.
  • Die Messungen mit AllTrails, RideWithGPS und Strava zeigen eine deutlich geringere Höhe im Bereich der Kanalbrücke mit einem Minimum im Bereich der Rednitzquerung. Dies lässt den Schluss zu dass diese Apps mit digitalen Höhenmodellen arbeiten. Auch der fast perfekt symmetrische Verlauf bei Hin- und Rückfahrt ist ein starkes Indiz hierfür. Es gibt zahlreiche ausgeprägte Strukturen, die sich bis in Details wiederholen.
  • In der Nähe von Brücken und Anhöhen hingegen weisen diese Apps tendenziell höhere Werte aus, da wo die Umgebung niedriger als der Radweg liegt dagegen dagegen niedrigere (Nähe Eschenau bei 2 km und nach der Kanalbrücke in der Mitte der Darstellung). All das lässt sich mit den Eigenheiten der digitalen Höhenmodelle in Einklang bringen.
  • Im Gegensatz dazu lässt sich das mit der Komoot App aufgezeignete Profil nicht mit digitalen Höhenmodellen im Einklang bringen. Es fehlt die charakteristischen Senken und Anstiege an den zu erwartenden Stellen und die Aufzeichnung ist nicht symmetrisch. Mein Verdacht ist dass diese App die GPS-Höhe verwendet, was ich allerdings nicht belegen kann.

Die drei per Höhenmodell erzeugten Profile schauen im Detail doch sehr unterschiedlich aus. Das zeigt deutlich dass in der Auswertung der digitalen Höhenmodelle noch viel zusätzlicher Spielraum liegt. Vielleicht nutzen die einzelnen Apps verschiedene Modelle, mit Sicherheit werden sich aber die verwendeten Algorithmen zur Auswertung (z. B. unterschiedliche Abstände der Stützstellen), Interpolation und Glättung von Daten unterscheiden. Wichtig ist dass diese Nachbearbeitung keines der systembedingten Defizite der digitalen Höhenmodelle kompensieren, sondern im besten Fall lediglich keine weiteren Ungenauigkeiten erzeugen kann.

Bei der Betrachtung der Profile stellt sich zwangsläufig die Frage wie viele Höhenmeter daraus ermittelt würden. Würde jede Schwankung und jeder Zacken aufsummiert ist offensichtlich dass ein erheblicher Wert zustande käme (zur Erinnerung: der reale Wert ist nahe 0 Höhenmeter). Aber auch bei starker Glättung würde jede Messung ein anderes Ergebnis liefern. Dieses Thema zu beleuchten würde diesen (bereits sehr langen) Blog sprengen, daher werde ich diese Aspekt in einem späteren Beitrag betrachten.

Praxistest Nr. 2: offenes Gelände

Nachdem der ersten Test gezielt eine Strecke gewählt wurde bei der die Probleme der digitalen Höhenmodelle zu Tage treten möchte ich im zweiten Tests das Umgekehrte versuchen. Nach dem Gesagten sollten digitale Höhenmodelle das beste Ergebnis liefern

  • in offenem Gelände, insbesondere ohne Bewuchs, Bewaldung oder Bebauung
  • in annähernd flachem Gelände (d. h. die Geländestrukturen sollten deutlich weitläufiger sein als die Rasterabstände der Höhenmodelle)

Ich habe im Rahmen meiner örtlichen Möglichkeiten daher eine Runde zusammengestellt, die so weit wie möglich über offene, abgeerntete Felder führt. Ganz vermeiden konnte ich Anstiege, kurze Waldstücke und Ortschaften nicht, aber sie bieten natürlich wiederum die Gelegenheit diese Stellen genauer anzuschauen. Sie sind daher mit 1 bis 5 markiert.

Test 2 - Streckenverlauf

Gemessen wurde wieder mit den oben genannten Apps. Die Messungen wurden auf den gleichen Werte am Startpunkt kalibriert und diesmal die Abweichung von der Edge1030-Messung dargestellt. In der Darstellung fehlt die Alltrails-Messung, da sie aufgrund des großen Signalrauschens die Lesbarkeit stark beeinträchtigt hätte. Im Einzelnen sind dargestellt:

  • Komoot (blau)
  • RideWithGPS (orange)
  • Strava (hellgrau)
  • Garmin Edge 1030 (Nullinie)
Test2: Höhenabweichung

Es fällt auf dass über den größten Teil der Teststrecke die Höhen sehr nahe beieinander liegen (die horizontalen Linien entsprechen 10 Höhenmeter), egal ob sie aus barometrischer Messung (Edge 1030), digitalem Modell (Strava, RideWithGPS) oder unbekannter Quelle (Komoot) stammen. Die wenigen Stellen an denen die digitalen Höhenmodellen Abweichungen von 10 m erreichen lassen sich ausnahmslos auf örtliche Eigenheiten wie Bewaldung (1, 3, teilweise 4 und 5) oder starker Bodenkontur (1, 2, 4).  Also genau dort wo man Ungenauigkeiten erwartet kann.

Das Ergebnis der Komoot-Messung lässt sich aufgrund der Unklarheit über die Datenquelle nicht wirklich interpretieren. Dass der große Höhenunterschied zu Beginn (Punkt 1) entgegengesetzt des Ausschlags der auf digitalen Höhenmodell basierenden Messungen ist lässt aber schon vermuten dass tatsächlich eine grundsätzlich Methode verwendet wird.

Fazit

Höheninformationen die aus digitalen Höhenmodellen stammen sind mit Vorsicht zu genießen. Es gibt Situationen in denen sie für die absolute Höhe gute Ergebnisse liefern:

  • in freiem Gelände, also ohne Bewuchs, Bebauung und Wald
  • wenn die Geländestrukturen weiträumig (100 m und größer) und gleichförmig sind

Diese Voraussetzungen werden allerdings für die wenigsten MTB relevanten Strecken gegeben sein. Tatsächlich zeigt die Untersuchung dass schnell Fehler in der absoluten Höhe von 10 m und mehr auftreten, einerseits kleinteiligere Bodenstrukturen nicht wiedergegeben werden, aber andererseits bei flachen Strecken signifikante Höhenänderungen angezeigt werden die es in der Realität nicht gibt.

Es ist zu bezweifeln dass auf dieser Basis Kennzahlen wie Höhenmeter, Steigungen oder Kalorienverbrauch verlässlich ermittelt werden können. Ich möchte hier aber nicht vorgreifen, sondern dieses Thema in einem separaten Beitrag genauer betrachten.

 

Radwege auf Bahntrassen sind für viele der Inbegriff des entspannten Radfahrens. Abgesehen von kleinen Unannehmlichkeiten, wie Hindernisse und Poller an Straßenquerungen, bieten sie meist eine fantastische Kombination von Verkehrsarmut, Landschaftserlebnis, mässigen Steigungen und sanft geschwungener Streckenführung. Umso erfreulicher ist es, dass in letzter Zeit immer mehr Strecken für Radfahrer ausgebaut und zum Teil mit hervorragendem Belag versehen werden.

Um diese Strecken gezielt in Routenplanungen aufnehmen zu können werden sie auf den Kartenansichten von singletrails.com besonders hervorgehoben. Auch wenn die Seite derzeit noch im Aufbau ist kannst du das Ergebnis bereits am Karten-Prototyp anschauen. In der Ebenenauswahl (oben rechts) musst du dazu die Ebene „abandoned railways“ aktivieren.

Darstellung von Radwegen auf Bahntrassen

Für den Zustand der Wege auf Radtrassen habe ich folgende vier Linientypen verwendet.

Asphaltiert und harter Untergrund (rennradtauglich)

Der Weg ist als asphaltiert oder mit sonstigem harten Untergrund erfasst. Zu letzterem zählen im Prinzip auch Pflastersteine oder Zementplatten. Die Erfahrung zeigt aber dass solche sehr selten auf alten Bahntrassen anzutreffen sind, so dass ich darauf verzichtet habe dafür eine gesonderte Darstellung einzuführen. Der Weg sollte also problemlos mit dem Rennrad befahrbar sein.

Schotter und verdichteter     Untergrund    (gravel bike)

Hier solltest du mit einem Crosser oder Gravelbike keine Probleme haben. Für Rennrad ist er weniger geeignet.

Weicher und sonstiger Untergrund

Hier kann dir alles begegnen: loser Untergrund, Gras oder Sand. Es sind aber auch diejenigen Wege so dargestellt  bei denen schlichtweg keine Angabe vorhanden ist. Die sichere Wahl ist auf jeden Fall das MTB.

Ehemaliger Trassenverlauf   (ohne Weg)

An dieser Stelle verläuft kein Weg und kein Pfad. Da ich bei Lücken in angezeigten Routen automatisch nachschaue ob es vielleicht doch noch ein Stück Radweg existiert, bei dem nur die Kennzeichnung vergessen wurde, stelle ich auch hier den ehemaligen Trassenverlauf dar. Interessanterweise wird so auch deutlich wie viele unerschlossene Wege noch im Verborgenen schlummern.

 

Auf der Karte sieht das am Beispiel der Umgebung von Mansfield wie folgt aus:

Abandoned railroad

 

Kennzeichnung in OpenStreetMap

Die Darstellung basiert auf den in OpenStreetMap hinterlegten Informationen. In einem früheren Post habe ich kurz erläutert wie man diese Informationen anzeigen und aktualisieren kann.

Generell sind Bahntrassen sind über das Attribut railway gekennzeichnet. Aufgelassene Bahnstrecken sind dabei entweder über die Werte „abandoned“ oder „disused“ gekennzeichnet. Der Unterschied ist dass bei „abandoned“ die Gleisanlagen bereits entfernt wurden, während diese bei „disused“ noch vorhanden sind.

Damit eine solche Trasse als radfahrtauglicher Weg gelten kann muss das Attribut highway  einen passenden Wert enthalten (z. B. „cycleway“, „path“ oder „service“). Bei solchen Wegtypen, bei denen man nicht davon ausgehen kann dass das Radfahren erlaubt ist (z. B. „footway“, „bridleway“), muss weiterhin die Erlaubnis über das Attribut bicycle explizit gesetzt sein, typischerweise über einen der Werte „yes“ oder „designated“.

Ob ein Weg rennradtauglich ist oder er sich für einen anderen Radtyp eignet liefert das Attribut surface. Mit smoothness bietet OpenStreetMap grundsätzlich eine weitere Möglichkeit die Oberflächenbeschaffenheit weiter in „excellent“, „good“, „bad“ etc. zu unterscheiden. Allerdings sind die Angaben hier derart spärlich, dass ich darauf verzichtet habe eine weitere Unterscheidung einzuführen.

Jeder Radfahrer nutzt heutzutage OpenStreetMap – aber vielleicht ist dies nicht allen bewusst. Dieses großartige Projekt, in dem abertausende Menschen ihr Wissen über geographische Gegebenheiten in eine freie Datenbank zusammen tragen, liefert die Grundlage für viele der nützlichen Apps, die das Radfahrerleben leichter machen. Seien es die Karten und Navigationshinweise in Navigations-Apps oder auf GPS Computern, Software zur Planung von Touren oder all die Seiten, in denen man seine aufgezeichneten Aktivitäten sammeln und veröffentlichen kann: sie alle nutzen oft Daten von Openstreetmap. Das gilt natürlich auch für singletrails.com.

Wie bei allen Datensammlungen gilt: shit in – shit out. Oder ganz konkret: wenn euch euer Navi mal wieder auf eine Schnellstraße, einen Rattenweg oder eine Fußgängertreppe hinab führt liegt das sehr oft an falschen oder unvollständigen Daten in Openstreetmap. Grund genug sich einen Blick darauf zu werfen wie diese Daten eigentlich entstehen. Und die gute Nachricht vorneweg: jeder kann (und sollte) sein Wissen beisteuern um die Daten zu verbessern. Der Einstieg ist dank leistungsfähiger Werkzeuge recht intuitiv und bei etwas Vorsicht ohne großes Risiko.

Ein praktisches Beispiel: Oberfläche eines Weges ergänzen

Statt vieler Theorie zeige ich euch ein Beispiel aus der Praxis: gerade für Rennradfahrer ist der Straßenbelag eines der Hauptkriterien für die Streckenwahl. Bei „normalen“ Straßen, die auch für den Autoverkehr freigegeben sind gehen die meisten Apps davon aus dass sie asphaltiert sind, wenn in den Daten keine andere Oberfläche hinterlegt ist. Bei kleineren Wegen, die man bei der Routenplanung gerne als reizvolle, verkehrsarme Varianten einbauen möchte, ist die Situation nicht so klar und man erlebt oft böse Überraschungen.

Das konkrete Beispiel findet sich nahe Saint-Symphorien südlich von Bordeaux. Dort verläuft ein wunderschöner Radweg mit perfekter Oberfläche über viele Kilometer auf einer stillgelegten Bahntrasse. Auf openstreetmap.org finden wir ihn als gestrichelte blaue Linie.

openstreetmap standard view

Um die Eigenschaften des Weges genau anschauen zu können muss ich in den Bearbeitungsmodus wechseln. Das geht einfach über den Befehl „Bearbeiten“ links oben, der den Standard-Editor iD startet. Nachdem ich mich angemeldet (ein Login erhaltet ihr schnell und unkompliziert über „Registrieren“) und den Zoom vergrößert habe sehe ich die Objekte, aus denen die openstreetmap Datenbank aufgebaut ist, in Form von Linien, Flächen und Symbolen. Diese kann ich anklicken und erhalte im linken Bereich die Objekteigenschaften angezeigt.

openstreetmap.org im Bearbeitungsmodus

Ganz oben steht um welchen Objekttyp es sich handelt, in diesem Fall einen Radweg.

In manchen Fällen werden darunter wie hier Probleme angezeigt, die entweder von anderen Autoren erkannt und markiert oder von im Hintergrund laufenden Qualitätskontrollen entdeckt wurden. Im konkreten Fall kreuzt der Radweg (rot) oben links einen Fluss (hellblau), ohne dass eine Brücke oder ein Durchfluss eingetragen ist. Wenn Probleme vorliegen sollte man prüfen ob sie für das eigene Änderungsvorhaben relevant sind, meist ist das aber nicht der Fall.

Unter „Alle Felder“ finden wir schließlich die Informationen die uns beim Radfahren eigentlich interessieren: Oberfläche, Einbahnstraße, Straßenname usw. Der Editor iD gibt beim Bearbeiten sehr gute Hilfestellung, indem er eine Liste möglicher Werte vorschlägt. Beim genauen Hinschauen erkennt man dass viele der angezeigten Daten ausgegraut sind, beispielsweise bei „Erlaubnis für Motorfahrzeuge: nein“. Diese Eigenschaften sind tatsächlich nicht in der Datenbank hinterlegt sondern werden als Standardwerte angenommen. Für sie gibt es allerdings keine offizielle Festlegung, sondern nur mehr oder weniger verbindliche Empfehlungen. Wenn ihr genauer verstehen wollt wie die einzelnen Eigenschaften zu verwenden sind hilft euch der Klick auf das Info-Icon rechts neben jeder Eigenschaft. Über einen Link werdet ihr in die openstreetmap-Wikiseiten geleitet, wo es zu jeder Eigenschaft und jedem Wert umfangreiche Hilfestellung gibt wie zum Beispiel für das „access“ Feld, das Zugangsbeschränkungen beschreibt.

Man muss also ab und zu genau hinschauen um zu verstehen was zu einem Objekt genau hinterlegt ist und was der Editor nur „vermutet“. Letztendliche Klarheit erhält man im Abschnitt „Alle Eigenschaften“ , in welchem die Objekteigenschaften genau so aufgelistet sind wie sie in der openstreetmap-Datenbank stehen.

Jetzt wird’s ernst – die Änderung

Für die Oberfläche wähle ich aus der Vorschlagsliste „asphalt“. Sofort erscheint auch unter „Alle Eingenschaften“ der Datenbankeintrag surface=asphalt.

War es das schon? Natürlich noch nicht ganz. Die Änderung ist zunächst nur beim Bearbeiter lokal erfasst. Sie sofort in die globale openstreetmap-Datenbank zu übertragen, aus der sich alle nutzenden Apps bedienen, wäre viel zu risikoreich. Bevor man das tut sollte man die Änderungen noch einmal sorgfältig kontrollieren. Der Editor unterstützt auch hierbei, indem er die Anzahl der Änderungen und, wenn man auf „Änderungen speichern“ klickt, die Liste der Änderungen angezeigt. Findet man Ungereimtheiten kann man versuchen mittels der Undo-Funktion auf einen verlässlichen Stand zu kommen. Ist man sich auch danach noch unsicher ist der beste Weg die Bearbeitung abzubrechen und neu zu beginnen. Denn über eines muss man sich immer im Klaren sein: hat man die Änderungen abgeschickt gehen sie direkt „live“. Bei openstreetmap als kollaborativem Projekt gibt es keine zentrale Instanz die die Eingaben noch einmal prüft (wie könnte sie das auch weltweit leisten). Der aktuell sehr gute Qualitätsstand der Daten auf openstreetmap.org zeigt aber dass es auch ohne geht, wenn alle beitragenden Autoren gewissenhaft, verantwortungsbewusst und vorsichtig handeln.

Nachdem ich die Änderung noch einmal überprüft habe will ich sie nun speichern.  Es gehört zum guten Ton über einen aussagekräftigen Kommentar zu beschreiben was geändert wurde, damit sich andere Autoren dies nicht mühsam aus den einzelnen Eigenschaften heraussuchen müssen. In diesem Fall schreibe ich „added surface information for cycleway“ und klicke anschließend auf „Hochladen“.

An dieser Stelle kann man noch ankreuzen, dass man seine Änderungen von jemand anderem überprüfen lassen will. Das ist für den Anfänger sicherlich eine gute Idee, allerdings gibt es für die Überprüfung keinen geregelten Prozess und es ist somit Glückssache ob man hilfreiches Feedback erhält. Insbesondere muss man sich bewusst sein dass die Änderung auch dann sofort „live“ geht, wenn man diese Option gewählt hat, und somit die gleiche Sorgfalt erfordert.

Jetzt sind wir allerdings wirklich fertig. Die Änderung wird sehr schnell in die globale Datenbank übernommen. Ein anderer Autor der sich wenig später einloggt sieht also bereits den geänderten Stand. Bis die Änderung dann tatsächlich in einer Kartendarstellung oder App wirksam wird vergehen in der Regel einige Tage bis Wochen. Das ist sehr individuell und abhängig davon wie oft aktualisierte Daten von openstreetmap.org abgerufen werden und wie sie dann weiter verarbeitet werden.

Fazit: es ist gar nicht schwer

Das gezeigte Beispiels war ein sehr einfaches, aber tatsächlich sind allermeisten Verbesserungen nicht viel komplexer. Man erkennt z. B. an der Darstellung Karte oder dem Verhalten bei der Navigation dass etwas nicht stimmt, prüft auf openstreetmap.org die Objekteigenschaften im Bearbeitungsmodus und ergänzt oder korrigiert einzelne Eigenschaften.

Ich kann euch nur ermuntern selbst einmal eine Bearbeitung zu versuchen, wenn ihr entdeckt dass Informationen unvollständig oder nicht korrekt sind. Im Web findet ihr auch viele weitere Anleitungen, Videos und Forumsbeiträge die euch bei den ersten Schritten helfen, etwa

openstreetmap.org welcome page

learnosm.org

OpenStreetMap-Tutorial für Anfänger