Gerade die Einfachheit des Vorschlags von Weide gefällt mir so außerordentlich. Das Relationengetümmel im alten Proposal ist genau das, was es dem nicht so erfahrenen Mapper schwer macht, die Übersicht zu halten. Nach dem neuen Proposal sehen die Relationsbezüge für ein funktionierendes Mapping einer Standard-Buslinie ohne Varianten so aus:
Wir packen die Haltestellen und die Route pro Fahrtrichtung in dieser Reihenfolge und in Fahrtrichtung sortiert in jeweils eine Relation: type=pt2, pt2=variant.
Die beiden sich ergebenden Relationen kommen wieder in eine Elternrelation: type=pt2, pt2=master.
Das war es auch schon, was für ein erstes Funktionieren einer Buslinie zwingend notwendig ist. Es ist so einfach, dass dies nahezu jeder leisten kann, der eine Grundverständnis einer Relation hat. Selbst wenn es Varianten gibt, wird hier der Mapper ohne Informatikhintergrund in die Lage versetzt, zumindest eine Hauptvariante einer Buslinie anzugeben. Hat er dies erst einmal gemacht, ist dann auch ein abweichender Fahrweg als weitere Variante nicht mehr so schwer. Bei dem Modell ist es zudem nicht mehr notwendig, pro Halt eine Plattform und eine Stoppstelle zu definieren - die Plattform reicht. So kann diese von jedem Mapper verschoben werden, ohne dass dabei vergessen wird, die Stoppstelle auch zu verschieben oder umgekehrt.
Das Weide-Schema entspricht dann auch dem, was der einfache Bürger intuitiv auch als Haltestelle wahrnimmt. Im Allgemeinen wird eine Haltestelle in der Wirklichkeit durch das Schild am Mast symbolisiert. Auch wenn ein ÖPNV Unternehmen eine Haltestelle versetzt, wird das Haltestellenschild abgenommen und an anderer Stelle aufgestellt. Der Bus hält dann einigermaßen lotrecht dazu auf der Straße. Genau das bildet das neue Modell 1:1 ab.
Sofern eine Anwendung eine Stoppstelle benötigt, läßt sich diese leicht durch Lötfällen auf die Route automatisch ermitteln, wie der OSM Inspector zeigt:
http://tools.geofabrik.de/osmi/?view=addresses&lon=6.94298&lat=51.16239&zoom=18&opacity=1.00&overlays=buildings,buildings_with_addresses,postal_code,nodes_with_addresses_defined,nodes_with_addresses_interpolated,no_addr_street,street_not_found,interpolation,interpolation_errors,connection_lines,nearest_points,nearest_roads
Zudem ist die stop_area, die bisher zum Ermitteln des Haltestellennamens notwendig war, nicht mehr zwingend erforderlich. Sie kann optional beim Zusammenfassen bei Umsteigepunkten noch angewendet werden. Die Buslinie funktioniert aber jetzt auch ohne diese - eine weitere deutliche Entblähung.
Dass das Modell etwas komplizierter werden muss, wenn Varianten gemappt werden, liegt in der Natur der Sache. Aber auch hier schafft das Weide-Schema verglichen mit dem alten, mehr Möglichkeiten bei weniger Komplexität. Obendrein beseitigt es immense Redundanzen (mit entsprechenden Fehlermöglichkeiten durch Abweichen eigentlich gleichzulautender Einträge) und ist konsistenter sowie eindeutiger.
Dass ich mich bei dieser Beurteilung zunächst auf Buslinien beschränke, hat seinen Grund. Denn sie sind es, die bis in den letzten Winkel der Republik fahren und daher von möglichst jedem Mapper mit Relationskenntnissen verstanden werden sollten. Für die Bahnen, die meist nur in größeren Städten oder überregional verkehren, sollten zumindest in den deutschsprachigen Ländern genug Mapper mit fortgeschrittenen Mappingkenntnissen existieren. Aber auch diese werden nach dem Modell von Weide einfacher. Zudem ändern sich Gleisverläufe nicht so einfach wie Busrouten.
Dennoch ein Wort zu den Straßenbahnen. Dort gibt es zumeist etablierte Bedarfsumleitungen. Diese lassen sich - einmal anläßlich einer solchen Nutzung gemappt - aus, ein- und umgliedern.
Je weiter ich mich in das Weide-Schema vertiefe, um so mehr tritt die Genialität zu Tage - verglichen mit allem Anderen, was wir bisher auf OSM im ÖPNV Bereich hatten.