Das Konzept
Um bei der Erfassung von Wanderwegen vor Ort die Übersicht zu behalten, befolge ich zwei Regeln:
- 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 einerroute
-Relation beschrieben, und dieseroute
-Relationen werden demWanderwege in ...
-network zugeordnet. Wanderwege der ArtRund um Solingen
werden nur der jeweiligen Gemeinde zugeordnet, auch wenn sie - natürlich - das Gemeindegebiet verlassen. - 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:
- Arbeitsersparnis bei der Erfassung;
- Vorarbeit für die Qualitätssicherung;
- 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, insbesondere 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:
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:
- Riesenrelationen sind böse;
- Auch lange Wege werden in kurzen Stücken betreut;
- 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 dieWanderwege in ...
-Relationen. Die Relation enthält zwar Routen, ist also ein Netzwerk, enthält aber Routen mit verschiedenennetwork=
-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 NetworkWanderwege 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 vonsuperroute
undpart
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.