Mit Fahrplandaten:
Wenn Fahrplandaten vorhanden sind, reichen die Haltestellen aus, sofern an ihnen eine Id getaggt ist, die auch in den Fahrplandaten zu finden ist.
Relationen sind dann nur notwendig, wenn man in OSM die Route erfassen möchte oder die Fahrplandaten keine Geometrien enthalten.
Ohne Fahrplandaten:
Um zu Interpolieren reicht eine Relation pro Variante/Fahrstrecke mit den Haltestellen als enthaltenen Nodes. Die Reihenfolge der Nodes ist dabei wichtig. (Mit optionalen Via-Punkten könnten fehlerhafte Berechnungen auf die korrekte Route gezwungen werden)
Eine kleine Demo dafür: https://jsfiddle.net/9j1j56bp/ (Haltestellen rote Kreise, erfasste Fahrtwege rot, aus Haltestellen berechnete Fahrwege grün gestrichelt)
Im Südosten der Route weicht die errechnete Route von der realen Route ab. Das ist dem geschuldet, dass OSRM den kleinen Weg in Ost-West-Richtung nicht befährt, denn er ist für den normalen Verkehr gesperrt. Ein angepasstes Routingprofil würde Abhilfe schaffen.
Wenn man also toleriert, das der Auswertende einfaches Routing betreibt, so kann man auf die Wege in den Relationen verzichten.
Die Frage ist was ist einfaches routing? Die zweite Frage ist, was passiert wenn jemand die Atrribute der Strecken ändert? Nach welchen Kriterien wird geroutet?
Es macht einen großen Unterschied ob man Strecken nach der kürzesten Fahrzeit oder nach der kürzesten Entfernung auswählt. In einem Fall ist das der Unterschied zwischen 32 oder 42 km. Das macht dann also eine Abweichung von 1/3 der Gesamtstrecke aus.
Eine weitere Frage ist ob man von einer Haltestelle zur nächsten oder die Gesamtstrecke betrachtet. Wenn der Weg von Haltestelle 1 zu Haltestelle 2 sehr kurz ist, dafür aber zu Haltestelle 3 wegen der falschen Richtung (stop_positionen haben keine Richtung) dann ein deutlich längerer Weg entsteht kann das nur durch manuelle Eingriffe behoben werden.
Wie anfällig sind die berechneten Routen? Wenn eine Routenrelation unterbrochen wird, sieht man das in Josm recht schön und es läßt sich meist ohne Ortskenntnis schnell reparieren. Wenn Viapunkte oder Haltestellen gelöscht werden, ändert sich der berechnete Verlauf und man muss wissen das dieser Falsch ist um ihn zu korrigieren.
Aber recht herzlichen Dank für diese tolle Anwendung!
Wie rechenintesiv ist die Anwendung eigentlich? Die ÖPNVKarte hat ja große Probleme mit der Aktualität weil es aufwendige Vorarbeiten gibt.
Ich halte nichts von der automatischen Berechnung von Busrouten. Sie funktionieren nur, wenn die Haltestellenlisten komplett und Haltestellenlisten und Wege fehlerfrei sind. Es tragen schonmal Leute hightway=secondary irgendwo ein. Der schrittweise Aufbau einer Busroute durch Beiträge mehrerer Mapper, die verschiedene Teilstücke befahren haben, kommt in dieser Vorstellungswelt nicht mehr vor.
Auch ich laufe an ÖPNV Daten konsequent vorbei. Meiner Meinung nach ist es die Aufgabe von Verkehrsunternehmen und Verkehrsbestellern die Daten zu pflegen. Und gerade bei ÖPNV Daten gilt: Eine Erfassung im Wiki Prinzip (lieber etwas als garnichts, kann ja verbessert werden) fuert unweigerlich zu toten Situtationen. Hat man Pech bleibt man irgendwo stecken.
Wieso also sollte ich mich drumm kuemmern? Die Verkehrbetreiber können gerne OSM Daten nutzen. Aber fuer mich als Nutzer ist es total unverständlich, wieso ich OSM jemals zur Fahrtenplanung nutzen können sollte. Es ist ja schon rein praktisch so: Die Verkehrsbetreiber zeigen Verbindungen an, die sie auch garantieren muessen. Und es ist schwer vorstellbar, dass man ohne diese “Hinkommen” Garantie losfahren will.
Ausserdem wird es ja zunehmend komplex - mit anrufgesteuertem Verkehr, mit Bedarfshaltestellen etc. Die Informationen braucht man viel zu zeitnah als dass man dafuer auf eine OSM karte gucken wollte.
Ich finde aber die Haltestellen sollten in OSM vorhanden sein. Es geht ja auch um andere Planung (Wanderungen, Routing, …), wo ich schon gern wüsste, wo die nächste Haltestelle ist. Und wenn in OSM dann noch der Link zum Fahrplan oder Unternehmen steht - ist allen geholfen.
Das Beispiel von Augustus Kling zeigt, dass es doch relativ einfach ist eine Route zu berechnen.
Wie er schon schreibt müsste in solchen Fällen ein entsprechndes Tagging greifen. Bus frei oder so ähnlich.
Das will ich aber jetzt hier nicht weiter diskutieren.
Wie schon mehrere user geschrieben haben, machen sie einen großen Bogen um das ÖPNV Tagging.
M.E. liegt es daran - und so ging es mir am Anfang auch - dass es keine klare Aussage gibt, wie eine Bushaltestelle oder eine Relation getaggt werden soll.
Es fängt schon mit dem Name der Haltestelle an. Oft ist kein ref_name angegeben und eine ID schon gar nicht.
Und wenn, dann in unterschiedlichen Schreibweisen. Ich selber weiss auch gar nicht wo ich die ID herkriege.
Hier muss mal eine Abstimmung des Taggings gemacht werden und dann im Wiki eine konkrete Anweisung hinterlegt werden.
Um eine Relation für eine Buslinie kommen wir, denke ich, nicht drum herum.
Da müssen mindestens die Haltestellen drin sein.
Gem. PTv2 soll es für jede Variante eine Relation geben. Damit ist schon mal klar, in welche Richtung der Bus fährt. Jetzt gem. Fahrplan die Reihenfolge der Haltestellen, also stop_position und platform aufzunehmen ist kein Hexenwerk.
Allerdings gibt es auch für die Relation keine eindeutige Beschreibung - zumindest habe ich nichts gefunden.
Also z.B. from to und via als Freitext oder dort die Haltestellen mit ihrem ref_name.
Mit dieser Relation kann man, wie oben gezeigt, den Weg berechnen.
Wie auch schon geschrieben, muss das dann aber immer wieder und von jeder Anwendung gemacht werden.
Deshalb ist es doch pragmatischer den Fahrweg in der Relation zu hinterlegen.
Da dies jedoch die größte Arbeit ist, wäre es doch sinnvoll über ein Plugin oder eine JOSM Funktion nach zu denken, die den Weg berechnet und die ways in die Relation aufnimmt.
Diese Funktion ist ja für alle Routenrelationen zu gebrauchen.
Für Busrouten gem. PTv2 gibt es in JOSM ja schon eine Unterstützung, in dem rechts angezeigt wird, ob der Fahrweg durchgängig ist.
Damit die ganze Taggerei auch Sinn macht müssen die Daten auch auf einfache Weise angezeigt werden.
Dazu müsste in der Verkehrskarte auch eine Funktion eingebaut werden, die bei Klick auf eine Haltestelle die Daten anzeigt.
Ob da dann nur OSM-Daten angezeigt werden oder auch Fahrplandaten wie in der bereits erwähnte Anwendung http://openptmap.org/?zoom=17&lat=53.2303&lon=10.39893&layers=B0000TFFT
muss man noch Diskutieren und abwägen.
Ich würde aus diesem Argument den umgekehrten Schluss ziehen:
entweder einige wenige ÖPNV-Anwendung müssen sich die Routenberechnung durchführen
oder alle Mapper, die Straßen editieren, müssen die verschiedenen ÖPNV-Schemata erlernen und anwenden.
Deshalb wäre es sinnvoller den Fahrweg nur bei Bedarf zu berechnen.
Wenn man am bisherigen Schema nur kosmetische Änderungen vornimmt, bleiben die schon beschriebenen Probleme.
Insbesondere für Linien mit vielen Streckenvarianten gibt es keine praktikable Lösung, wenn Varianten als Relationen mit allen Wegelementen definiert sind.
Für mich den billigsten Weg in einen Graphen zwischen 2 Punkten zu finden. Als komplexer würde ich Routing beispielsweise abhängig von Livedaten (Staus, Wetter, erwartetes Frachtgewicht, …), über mehrere unsortierte/teilsortierte Wegpunkte oder Optimierung mehrerer Fahrzeuge sehen. Für die Busrouten genügt aber wiederholt den Weg zwischen 2 Haltestellen zu finden.
Wenn jemand die Attribute der Strecke ändert, dann ergibt sich potentiell ein neuer/anderer Weg. Im innerstädtischen dürften die Haltestellen jedoch oft zu dicht beieinander liegen um einer anderen Stecke die günstigste Beurteilung durch den Router zu geben. Im ländlichen Bereich findet man wenige gut ausgebaute Straßen über die der ÖPNV läuft. Das sind erstmal meine Vermutungen ohne die Effekte wirklich analysiert zu haben. Falls sich diese Effekte als problematisch herausstellen sollten, kann man ja immer noch optionale Via-Punkte zwischen den Haltestellen zulassen.
Die Kriterien für das Routing sind im verwendeten Profil zu definieren und variieren damit je nach Implementierung. Um beim Beispiel OSRM zu bleiben: die Profile dafür sind Skripten unter https://github.com/Project-OSRM/osrm-backend/tree/develop/profiles wobei eins für Busse ergänzt werden müsste.
Ich halte Routen basierend auf Punkten deutlich weniger anfällig als jene mit Wegen weil die Fehler wegen Splitten oder Vergessen von kurzen Teilstücken ausgeschlossen sind. Diese Fehlerarten waren die, die ich bei meinen Betrachtungen meistens gefunden habe.
Schwer zu sagen, ich rufe einfach die Overpass API und die API von OSRM auf und überlasse damit alle Schwierigkeiten diesen APIs. Vor langer Zeit hatte ich für einen Test einmal OSRM installiert und abgesehen von der Zeit zum initialen Import der OSM-Daten war keine nennenswerte Systemlast erkennbar (normaler Desktop, kein üppig ausgestatteter Server). Wie viel Rechenzeit für die Overpass API benötigt wird, kann ich nicht abschätzen.
Die Anwendung selbst ist ein schneller Hack von gestern Abend in JavaScript, der nur im Browser läuft. Erst holt der von der Overpass API 1 Route und ruft dann OSRM mit vielen Via-Punkten auf. Alle Berechnungen sind quasi Echtzeit.
Die Berechnung der Routen durch die Auswertenden halte ich für durchaus tolerabel. Man muss den Mappern die Erfassung möglichst einfach machen, denn sonst gibt es sowieso nichts auszuwerten.
Mir schweben derzeit mehrere Stufen der Erfassung vor:
Nur Nodes für Haltestellen, möglichst mit Ids aus dem Fahrplan.
Relationen nur mit geordneten Haltestellen-Nodes.
Relationen nur mit geordneten Haltestellen-Nodes und Via-Punkten um das automatische Routing auf den realen Fahrweg zu zwingen.
Relationen mit Wegen zwischen den Haltestellen-Nodes in der geordneten Mitgliederliste. Damit kann man auf das automatische Routing verzichten, wenn ein Weg zwischen 2 Haltestellen vorhanden ist. Es könnte auch die Route nur teilweise mit Wegen erfasst sein.
Damit könnte sich dann jeder aussuchen bis zu welcher Stufe er erfassen will. Ausgewertet werden könnten dann alle diese Relationen auch wenn eine Anwendung nur bis zur Stufe der ersten Relationen in der Liste implementiert ist.
So was habe ich ja weiter oben schon vorgeschlagen.
Aber realistisch betrachtet haben wir wenig Chancen auf eine derartige Änderung.
Wenn wir jetzt nur Relationen mit Haltestellen aufnehmen, erscheinen die in der Verkehrskarte und bei allen Anwendungen, die heute auf Ways setzen, nicht.
Bisher haben wir in diesem Thread 3 Nutzer der Relationen ausgemacht. Aber keiner weiss wie viele es noch gibt.
Als erstes müsste man mal die Leute ansprechen, die die Verkehrskarte erstellen. Wer ist da eigentlich der Taktschläger?
Wie wird den eine solche Änderung realisiert? Wenn man das jetzt mit der ganzen Welt abstimmen muss, dann gibt es, so wie in diesem Thread, erst mal tausende Bedenkenträger.
Deshalb schlage ich vor erst mal den ersten Schritt zu tun und das Haltestellenmapping abzustimmen.
Ich werde dazu Anfang nächster Woche einen eigenen Thread aufmachen.
Danach kommt die Abstimmung der PTv2 Relation.
Danach haben wir hoffentlich ein paar ÖPNV Mapper mehr.
Letztendlich ändert sich ja an den Fahrwegen, wenn sie denn mal erfasst sind, nicht so viel.
Hier liegt ein großes Problem einer Routinglösung. Wenn sich verschiedene Router unterschiedlich verhalten, muss man für die Gesamtheit aller dümmsten anzunehmenden Router mappen. Der Mapper kann dann auch nicht mehr überprüfen, ob er hinreichend gemappt hat.
Wenn schon eine reine Routinglösung, dann sollte es ein zentraler Router oder zumindest ein einheitlich festgelegter Routingalgorithmus sein, wobei der Routingalgorithmus in jedem Fall langzeitstabil sein muss, da bei Algorithmusänderungen alle Routen zu kontrollieren wären, ob die gesetzten via-Punkte noch hinreichend sind.
Vielleicht könnte es eine Lösung sein, wenn zum Beispiel der Overpass-Server bereits fertig geroutete Roten in seiner Datenbank vorhält.
Dies wäre für Anwendungen eine erhebliche Vereinfachung.
Man muss dann die via-Einträge auch bei Veränderungen der Straßen und sogar der Nachbarstraßen kontrollieren! Sogar wenn sich nur Tags in den Nachbarstraßen ändern.
Bisher belästigen wir die Nicht-ÖPNV-Mapper nur mit Zusatzforderungen, wenn sie die Geometrie der Fahrwege ändern … dann würden wir das tun tun, sobald sie irgendwas in der Umgebung der Fahrwege ändern.
Das Problem der aktuellen Relationen ist real: wenn ein Mapper eine Kreuzung zum Kreisverkehr ändert, muss er sich um alle betroffenen ÖPNV-Relationen kümmern; sonst zerstört er sie.
Bei Busrelationen ohne Fahrweg wird der Mapper vermutlich nicht an die Buslinien denken und den Kreisverkehr unbelastet davon eintragen. In nahezu allen Fällen wird der Routingalgorithmus die Busstrecke automatisch korrekt anpassen, ohne dass jemand damit Arbeit hat. Theoretisch könnte durch die Streckenverlängerung des Kreisverkehrs jetzt ein anderer Weg minimal kürzer sein. Nur in diesem müssen die Relationen durch einen Zusatzpunkt bearbeitet werden. Der maximale Schaden besteht darin, dass die Strecke zwischen zwei Haltestellen falsch dargestellt wird und minimal zu kurz berechnet wird.
Die Komplexität des aktuellen Schemas führt dazu, dass sich nur sehr wenige Mapper um die ÖPNV-Daten kümmern.
Ein Beispiel: früher führten mehrere Buslinien durch die Kieler Altstadt. Vor etwa 5 Jahren wurden die Buslinien verlegt, die Straßen verengt, teilweise zu Einbahnstraßen umgebaut. In OSM wurden die alten Haltestellen entfernt und die neuen eingetragen. Den Verlauf der 9 Busrelationen hat bislang niemand angepasst. Mit automatischem Routing hätte die Verschiebung der Haltestellen vermutlich ausgereicht.
Variierende Routen durch verschiedene Routingprofile sehe ich derzeit als ein eher theoretisches Problem. Zu unterschiedlichen Routen kommt es ja nur dann, wenn verschiedene ähnlich gute Routen zwischen 2 Haltestellen (oder Via-Punkten) bestehen. Solange die möglichen Routen nicht ähnlich gut sind, werden unterschiedliche Profile oder Router die selbe Route auswählen und damit das selbe Ergebnis errechnen.
Nun kann man sich fragen wie wahrscheinlich ähnlich gute Routen sind. Oft liegen die Haltestellen so dicht beieinander, dass ein alternativer Fahrtweg keinen Sinn ergibt oder aber die Haltestellen sind weiter voneinander entfernt und so gelegen, dass sie mittels einer größeren Straße erreicht werden können. Beide Fälle dürften recht eindeutig von den Routern beurteilt werden.
Problemfälle sind natürlich durchaus auch vorstellbar, weshalb die Via-Punkte zwischen den Haltestellen genannt wurden um eine konsistente Routenberechnung zu erzwingen. Ich glaube, dass das ausreicht damit das theoretische Problem in der Praxis keins ist. Zudem glaube ich, dass die reduzierte Komplexität des Vorschlags gegenüber der heutigen Schemen zu deutlich weniger Fehlern führt als die Unterschiede zwischen den Routing-Implementierungen verursachen.
Falls euch Gegenbeispiele zu den oben genannten Vermutungen bekannt sind, bitte ich darum beispielhafte OSM-Relationen zu benennen.
Ja, das hat OSM so an sich, aber das hat mit ÖPNV nichts zu tun. Besser gesagt, das ist nichts was im Bezug auf ÖPNV anders wäre wie für sonstige in OSM erfasste Daten.
Man entscheidet anhand der Tags der Relation welches Verkehrsmittel die Route bedient und verwendet dann das zugehörige Routingprofil.
Ich bin mir nicht sicher wie diese Frage zu verstehen ist. Wenn wir vom Routing ausschließlich zwischen den Fährterminals ausgehen, dann würde man auf den kürzesten Fahrtweg kommen (Normalroute mit 80min Fahrzeit, Relation 288513). Die anderen Routen würde man erst mit zusätzlichen Via-Punkten auf den Schleifen/Umwegen erhalten.
Dasselbe Prinzip wie für die anderen Verkehrsmittel. Ausgehend von den Tags der Relation (route=train) würde man das Routingprofil für Züge wählen und daher den Gleisen entlang den Fahrtweg errechnen.
Es gibt dann noch Fälle wie die Fernbusse über den Bodensee, die zwischen Meersburg und Staad die Fähre nehmen. Den Wechsel des Verkehrsmittels kann das Routingprofil für Busse aber erlauben weil die Fähre hierfür freigegeben ist. Der Router nimmt dann an, dass der Bus dem Fährweg entlang fährt und kommt auf die korrekte Route.
Ein Beispiel für so eine Route ist Relation 3045256: https://jsfiddle.net/9j1j56bp/1/ (errechnete und erfasste Route) und Fahrplan: https://meinfernbus.de/unser-angebot/linien/bus-zuerich-muenchen-berlin.html (Fahrplan)
Auffälligkeiten:
Haltestelle in Zürich fehlt in der Relation.
Haltestelle in Allmannsdorf fehlt in der Relation.
Haltestelle in Meersburg fehlt in der Relation.
Automatisches Routing fährt über Markdorf, korrekt wäre über Friedrichshafen. Das liegt an der fehlenden Haltestelle in Friedrichshafen in der Relation.
An der Haltestelle in München weicht die errechnete Route von der in OSM erfassten Route ab.
Die Haltestelle Nürnberg wird nicht von der erfassten Route erreicht.
Die Haltestelle in Lauf in OSM gibt es im Fahrplan nicht.
In Bayreuth weicht die errechnete Route von der in OSM erfassten Route ab. Die erfasste Route führt knapp an der Haltestelle vorbei.
Haltestelle in Himmelkron fehlt in der Relation.
Haltestelle in Leipzig fehlt in der Relation.
In Münchberg weicht die errechnete Route von der in OSM erfassten Route ab. Das liegt an der fehlenden Haltestelle in der Relation.
Kurz vor der Haltestelle in Berlin weicht die errechnete Route von der in OSM erfassten Route ab.
Der Großteil des Fahrtwegs ist bei der errechneten Route und der erfassten Route gleich. Bei den Abweichungen kann ich nicht beurteilen ob die errechnete oder erfasste Route der Realität näher kommt. Keine Variante, die ich im Fahrplan finden kann, entspricht der OSM-Relation. Die Relation besteht aus 2244 Wegen und 3 Nodes – diese Menge ist für eine Fernbusroute nicht überraschend, aber bei 12 Haltestellen in der komplexesten Variante laut Fahrplan meiner Meinung nach nicht tolerabel.
Bei verschiedenen Routern bevorzugt der eine vielleicht eine höhere Straßenkategorie und der nächste die Abkürzung durchs Wohngebiet oder über die Tankstelle. Ein Router könnte auch Straßen aufgrund von surface oder smoothness verwerfen. Access-Tags, Gewichts- oder Höhenbeschränkungen, Hochstgewindigkeiten, Abbiegebeschränkungen etc. würden wohl auch nur von manchen Routern beachtet. Wenn man das alles den Anwendern überlässt, hat man beliebigen Wildwuchs.
Eigentlich würde man sich einen recht einfachen Router wünschen, der z.B. nur auf Straßenkategorie und Länge achtet, da dieser weniger sensitiv auf irgendwelche Änderungen reagiert. Bei baulich getrennten Straßen und insbesondere deren komplexer Kreuzungen braucht man aber einen Router, der eine Vielzahl von Regeln korrekt berücksichtigt, da ansonsten die falsche Fahrbahn gewählt würde.
Bei erfassten Daten haben wir nur einen begrenzten Fehler. Aber die Erfassung soll ja raus. Die in Wesel über den Rhein führende Buslinie bekommt dann durch einen kleinen Tippfehler einen Umweg über Duisburg, der zu allem Übel auch noch plausibel aussieht.
Wenn an einem highway=residential keine Häuser gemappt sind, dann erfinden wir doch auch keine für die Kartendarstellung, obwohl das vermutlich der Realität näher kommt als garkeine.