Konzept zur Erfassung von Wanderwegen

Das Konzept

Um bei der Erfassung von Wanderwegen vor Ort die Übersicht zu behalten, befolge ich zwei Regeln:

  1. Ich erzeuge für jede Gemeinde, in der ich Wanderwege erfasse, eine Relation mit dem Namen Wanderwege in Woauchimmer. Jeder lokale Wanderweg in dieser Gemeinde wird in einer route-Relation beschrieben, und diese route-Relationen werden dem Wanderwege in ...-network zugeordnet. Wanderwege der Art Rund um Solingen werden nur der jeweiligen Gemeinde zugeordnet, auch wenn sie - natürlich - das Gemeindegebiet verlassen.
  2. Ich zerschneide gemeindeübergreifende Wanderwege in der Nähe der Gemeindegrenzen in Teilstücke. Die Teilstücke fasse ich zu einer Superrelation zusammen, die den Gesamtwanderweg beschreibt, und ordne sie zusätzlich der Wanderwege in ... Relation zu.

Diese Vorgehensweise wurde kritisiert. Deshalb erläutere ich hier, warum ich so vorgehe.

Die Einwände

In einer Mail hat ein OSM-Mitstreiter meine Vorgehensweise kritisiert:

ich habe gesehen, dass Du viele Sammelrelationen der Art "Wanderwege in Duesseldorf" o.ae. anlegst.

Diese Arten von Relation sind relativ umstritten, da sie den Grundzuegen einer geographischen Datenbank widersprechen. In einer Datenbank ohne Geographie wuerde man so etwas machen - ein gutes Beispiel sind die Kategorien in der Wikipedia, da wird man ja gleich schief angeguckt, wenn ein Artikel mal zu *keiner* Kategorie gehoert. In einer Datenbank mit Geographie braucht man so etwas nicht, weil man einfach sagen kann: Dies sind die Grenzen von Duesseldorf, bitte gib mir alles, was hier drin liegt und ein Wanderweg ist.

Der Ersteller der OSMC Reit- und Wanderkarte schreibt:

Ich würde Euch empfehlen, unnötig zerhackte Relationen zu einer einzigen zu konsolideren, das hält die Welt einfacher und übersichtlicher.

Überlegungen zur regionalen Zuordnung der Wanderwege

Für die Zuordnung zu Gemeinden habe ich drei Gründe:

  1. Arbeitsersparnis bei der Erfassung;
  2. Vorarbeit für die Qualitätssicherung;
  3. Nutzung einer existierenden Ontologie.

Arbeitsersparnis bei der Erfassung

Die Routenführung von Wanderwegen ist willkürlich: sie folgt zwar (meistens) vorhandenen Wegen, die Wegeauswahl ist aber subjektiv und weder zu erschließen noch aus einer Luftaufnahme zu ersehen.

Damit sind Wanderwege nur durch eine Begehung oder Beradelung zu erfassen. Dieses Schicksal teilen sie mit Einbahnstraßen und Geschwindigkeitsbeschränkungen und sonstigen Verboten.

Eine Erfassung zu Fuß oder per Radl ist zeitaufwendig - deshalb versuche ich auf jeder einzelnen Tour so viele Informationen wie nur möglich zu sammeln. Auch wenn ich gerade einem Wanderweg X folge, erfasse ich an Abzweigungen auch kreuzende und einmündende andere Wanderwege Y und Z.

Dabei ist möglich, dass ich oder jemand anders den gleichen Wanderweg einmal kreuzt, und da wäre es schön, wenn die Schnipsel in einer Relation zusammenfinden. Dabei hilt die Zuordnung zur jeweiligen Gemeinde: in dieser Relation kann jeder Bearbeiter nachschauen, ob der gerade zu erfassende kreuzende Weg bereits als Relation existiert.

Vorarbeit für die Qualitätssicherung

Höhere Dienste wie Routenplaner können auf OSM-Daten erst dann sinnvoll aufsetzen, wenn ein bestimmtes Qualitätsniveau erreicht ist, insbesonders eine Vollständigkeit. Diese Vollständigkeit kann aber nur vor Ort überprüft werden.

Ob alle Wanderwege deutschlandweit oder auch nur regierungsbezirksweit erfaßt sind, ist kaum zu entscheiden. Eine Vollständigkeit für eine Gemeinde ist dagegen sowohl zu entscheiden als auch zu erreichen.

So arbeite ich gerade an der Vervollständigung der Wanderwege in Hilden (XML).

Nutzung einer existierenden Ontologie

Wenn immer möglich, nutze ich bestehende Klassifikationssysteme. Bei der geographischen Untergliederung bietet sich für Deutschland die politische Gliederung an, repräsentiert durch den amtlichen Gemeindeschlüssel. Insbesondere benutze ich die jeweilige Gemeindekennzahl ergänzt um ein Prefix de. als ref-Attribut in den Wanderwege in ...-Relationen.

Vorgeschichte zur Aufteilung nichtlokaler Wanderwege

Ich habe schon Tracks gesammelt, als ich noch nichts von OSM wußte. Unter diesen alten Tracks sind auch drei Fernwanderwege:

  1. A Coast To Coast Walk (England)
  2. Schwarzwald-Querweg
  3. Rheinsteig

Die Erfassung des Coast2Coast war problemlos: der Weg führt duch dünnbesiedeltes Gebiet mit entsprechend wenig OSM-Bearbeitern.

Der Querweg führt über 180km durch teils dichtbesiedeltes Gebiet mit entsprechend viel OSM-Aktivität. Die Relation hat zur Zeit knapp 500 Members - dennoch hatte ich während der Erfassung mehrfach Konflikte beim Speichern von Zwischenergebnissen. Die Wahrscheinlichkeit, dass bei dieser Streckenlänge jemand anderes gleichzeitig an einem Teil der Strecke arbeitet, ist zu groß.

Den Rheinsteig habe ich auch als große Relation begonnen, bis zu den ersten Konflikten. Darauf hab ich ihn an Gemeindegrenzen in Teilstücke zerschnitten.

Überlegungen zur Aufteilung nichtlokaler Wanderwege

Für die Zuordnung zu Gemeinden habe ich mehrere Gründe:

  1. Riesenrelationen sind böse;
  2. Auch lange Wege werden in kurzen Stücken betreut;
  3. Praktische Hilfe bei der Qualitätssicherung.

Riesenrelationen sind böse

Das Speichern von Riesenrelationen ist langsam, weil (zur Zeit) alle Member übertragen werden, auch wenn nur einer betroffen ist. Das läßt sich nur durch eine Erweiterung der API um inkrementelle Operationen auf Relationen ändern. Die Entwicklung (Fixierung der Reihenfolge von Member in der nächsten Version der API) geht aber in eine andere Richtung.

Das Problem der Riesenrelationen betrifft nicht nur die Wanderwege, sondern auch die Straßen: wenn ein Wanderweg hundert Meter an einer Bundesstraße entlangläuft, muß ich die Straße an den beiden Einmündungen zerschneiden, um das Stück dazwischen dem Wanderweg zuordnen zu können. Dadurch ändert sich die oft vorhandene Bundesstraßen-Relation, und beim nächsten Upload werden dann möglicherweise tausende von Membern übertragen.

Je größer die Relation, umso wahrscheinlicher werden Konflikte durch gleichzeitiges Arbeiten an der Relation. Die Konflikte werden vom Editor überraschend gut gehandhabt (ein dickes Lob an die Entwickler), dennoch ist jede Unterbrechung des Arbeitsflusses äußerst lästig.

Offensichtlich sind auch die API-Entwickler unglücklich mit Riesenrelationen: im nächsten API wird die Anzahl der Member einer Relation begrenzt werden.

Auch lange Wege werden in kurzen Stücken betreut

Wanderwege fordern lokale Begehung, virtuell zur Erfassung, aber auch in der Realität zur Überprüfung und Markierung. Real teilen sich mehrere Menschen oder mehrere Ortsgruppen die Arbeit.

Kein Einzelner kann die Vollständigkeit und die Qualität sicherstellen, weder der Markierung des realen Weges, noch der Erfassung in einem Datenbestand. Eine Aufteilung in Abschnitte menschlicher Größe ist die Lösung.

Und hier bieten sich wieder die Gemeindegrenzen an und eine Einordnung der Teilstücke in die jeweilige Wanderwege in ...-Relation.

Praktische Hilfe bei der Qualitätssicherung

Wenn ich für einen begrenzten Bereich die Verantwortung für die Qualität der Daten übernehmen will, braucht es eine Benachrichtigung bei Änderungen des Datenbestandes.

Nun beginnt als Beispiel der Wanderweg X19 sozusagen vor meiner Haustüre. Wenn sich da im Bereich Düsseldorf und vielleicht noch Hilden und Langenfeld sich etwas tut, so kann ich hinfahren und nachschauen. Ich werde aber nicht ans andere Ende der Strecke fahren.

Ich möchte also nur auf einem Teilabschnitt benachrichtigt werden - und das ist möglich, wenn ich die (bereits existierende) Benachrichtigungsfunktion auf einem oder mehreren Abschnitten des Wanderweges aktiviere.

Unklarheiten

  • Ich verwende type=network für die Wanderwege in ...-Relationen. Die Relation enthält zwar Routen, ist also ein Netzwerk, enthält aber Routen mit verschiedenen network=-Tags - network paßt also nicht ganz.
  • Ich verwende type=superroute für die Superrelationen der überörtlichen Wanderwege. Der Name gefällt mir nicht gut, aber ich finde auch keinen besseren.
  • Ich habe die Wanderwege in... in einem Network Wanderwege in NRW zusammengefaßt. Das funktioniert zur Zeit; die Relation wird aber zu groß werden, wenn Wanderwege in weiteren Gemeinden auf diese Weise erfaßt werden.
  • Als Role für die Zuordnung zur Superrelation verwende ich part. Es wäre schön, wenn die Kartenrenderer eine Superrelation beachten würden - dann könnte man die Metadaten nur einmal an der Superrelation speichern und nicht in jeder einzelnen Teilrelation.
    Die Auswertung von superroute und part in den Kartenrenderern würde auch viele Einwände gegen das Aufteilen gegenstandslos machen.
  • Bei Großstädten ist der Bereich Gemeinde eigentlich zu groß. Die Vielzahl von Bearbeitern in einer Großstadt erlaubt aber die Einrichtung von Verwaltungsseiten im Wiki, Stammtischen usw., also einer expliziten Selbstorganisation. Andererseits ist in dünnbesiedelten / wenig besiedelten Gebieten die Gemeinde zu klein, da wäre eher ein Kreis angemessen.

Dieser Beitrag ist auf Openstreetmap.org verknüpft.