Was mir fehlt sind die use-cases. Was soll mit den Daten machbar sein, und was nicht? Und dann sollte man noch kurz darüber nachdenken, ob die use-cases auch nützlich sind … zumindest wenn die Bereitstellung der dazu notwendigen Daten kompliziert ist.
Der Vorschlag ist grundsätzlich gar nicht schlecht. Eines der Hauptprobleme bei PTv2 ist damit allerdings nicht gelöst, nämlich die Erfassung jeder einzelnen Linienvariante. Den dazu notwendigen Aufwand sehe ich in keinem Verhältnis zum Nutzen. Gerade Busse im ländlichen Bereich haben schnell mal eine Vielzahl von unterschiedlichen Fahrtwegen. Die alle zu erfassen macht einfach keinen Spaß. Wer erstellt schon freiwillig für einen Fahrplan wie http://www.suedbadenbus.de/suedbadenbus/view/mdb/kursbuch/mdb_237892_7245.pdf jede einzelne Routenvariante? (Abgesehen von ein paar Enthusiasten, die aber nicht reichen, um flächendeckend halbwegs vollständige und aktuelle Daten hinzubekommen)
Ich würde hier fast wieder zu PTv1 tendieren, wo man einfach nur in einer Relation pro Linie die befahrenen Ways gesammelt hat. Damit ist pro Linie nur noch eine Relation nötig, die auch nicht sortiert sein muss. Der Aufwand zur Pflege reduziert sich damit auch extrem, da die Infos weniger schnell veraltet sind und dann auch nur eine Relation anzupassen wäre. Für ein reines Rendering wie bei openptmap.org reicht das völlig. Und wenn jemand den genauen Fahrtverlauf einer bestimmten Fahrt wissen will, kann er das über Routing ermitteln. Dabei wäre die Relationen auch hilfreich, denn damit könnte man das Routing auf die in den Relationen enthaltenen Ways beschränken, sodass man auch ziemlich genau den exakten Fahrtweg ermitteln würde.
Wir sollten uns fragen, ob wir in OSM wirklich die einzelnen Routenvarianten so detailliert erfassen und mit jedem Fahrplanwechsel pflegen sollen (was bisher beides überhaupt nicht funktioniert), oder ob wir uns nicht auf Routen nach PTv1 oder sogar nur die reine Infrastruktur der Haltestellen beschränken sollen, sodass man mit externen Fahrplandaten die genauen Verläufe jeder einzelnen Fahrt per Routing bestimmen kann.
An dieser Stelle schon einmal die Ankündigung, dass ich auf der FOSSGIS einen Vortrag zum ÖPNV-Mapping halten werde. Dort werde ich unter anderem auf die Taggingschemata, den generellen Nutzen von ÖPNV-Daten in OSM und mögliche Vereinfachungen eingehen.
Gruß
Alex
Das ist eine gutes Beispiel 
da muss man ja froh sein wenn der Fahrere des Busses weiss wo er hin muss, wer da noch durchblick… Glückwunsch… 
In #68 habe ich sowas auch schon vorgeschlagen, warum sollte man alles ausschließlich mit OSM-Daten erschlagen?
Solche Leichen ähm Routen dürfte so ziemlich jede ländliche Gegend im Keller auf der Straße haben… unser 476er ist da ähnlich: http://www.rvs-lds.de/tl_files/fahrplaene/476.pdf
Ich hatte mal angefangen, bin dann aber am Erfassungsaufwand und auch mangels Fehlerprüftools gescheitert…
Sven
Wenn ich solche Fahrpläne sehe, würde ich vermutlich auch kapitulieren und es bei einer Masterrelation mit allen Haltestellen (halbwegs geordnet) belassen. Die müsste dann den Betreiber und auch einen Link auf den Fahrplan enthalten. Nur dieser müsste idR beim halb- bis ganzjährigem Fahrplanwechsel, bei dem es sehr wahrscheinlich auch Routenänderungen gibt, aktualisiert werden.
Use-Case-Beispiel: Bei der OSM-basierten Suche nach den nächsten ÖPNV-Haltestellen wird mir neben der Navigation dorthin im ersten Schritt zusätzlich der dortige Fahrplan angeboten.
Hi,
ich hab mir… vor Tagen angefangen mich zu spielen um mir das Erstellen einer Relation für Bus einfacher zu machen.
Also… eine OSM-Datei genommen mit einer Relation wo schon alle Bushaltestellen drin sind… automatisch (XSLT) 
eine HTML-Liste generieren lassen… damit ich dann die Variante bzw. überhaupt den Weg zusammen klicken kann… um dann einen Link der Haltestellen zu erhalten… um einen Vorschlag der Wegwahl zu haben…
Ist noch am Anfang aber es funktioniert schon 
Aber ist mit heißer Nagel gestrickt… also nicht so genau hinsehen 
Du hast doch den Bus502 auch sehr gut erfasst oder mit erfasst. http://www.overpass-api.de/api/sketch-line?ref=502&network=Verkehrsverbund%20Berlin-Brandenburg&style=padua , offensichtlich gibt es da auch etwa 7 Varianten.
Die angedachte Teilstrecken-Zusammenfassung als Unter-Relation wäre hier keine große Hilfe.
Gruß Axel
Ja, ich hab mir auch reichlich Mühe gegeben. Auch der 500er hat mehrere Varianten.
Jetzt ist unsere Bahnhofstraße mindestens bis Herbst gesperrt. Ein Umbau der Relationen ersparte ich mir aber wahrscheinlich. Hier führen viele Routen entlang: http://openptmap.org/?zoom=17&lat=51.938&lon=13.88086&layers=B0000TFFT. Das wäre echt aufwändig, weil diese Straße für den Busverkehr eine zentrale Straße ist.
Sven
Das Auftrennen könnte man zwar so definieren, ist aber nicht zwingend erforderlich. Alternativ kann man nur dort trennen, wo man es auch heute schon machen muss. Dann sind bei der Auswertung Duplikate von Wegen zu entfernen. Alternativ kann die Auswertung auch die über die Stop-Positionen der atomaren Segmente überstehenden Wegabschnitte in den Ergebnisdaten abschneiden.
Technisch würde es mit EInschränkungen auch mit Platform statt Stop funktionieren.
Eine (Bus-)Linien-Relation muss nur die Haltestellen enthalten. Wenn dann an den Haltestellen noch der “Fahrplan” verlinkt ist - perfekt.
Ein (noch jetziges) Problem wird es aber mit Bahn, Straßenbahn, U-Bahn, …
Oder: Die vielen Verkehrsbetriebe (Mentz, VVN, …) stellen einen “öffentlichen” ÖPNV-Router als “Dankeschön” für die Erfassung der Haltestellen in OSM zur Verfügung, deren Daten sie ja nun auch vermehrt nutzen.
Und wenn eine Haltestelle fehlte und jemand sie mappt und dann mit “Zur Relation hinzufügen” hinzufügt, dann hat die berechnete Route nur noch Schrottwert. Das merkt dann aber keiner weil es keine Grundlage für eine Fehlermeldung mehr gibt.
Das ist ganz klar der Preis dafür, dass die Fahrlinien fehlen. Je weniger Informationen in der Relation stecken, desto empfindlicher wird sie gegenüber Fehlern, hier die Reihenfolge der Haltestellen.
Zur Not könnte ein QA-Tool die Abstände benachbarter Haltestellen überprüfen, “perfekt” ist das aber nicht.
Aber andererseits: Wenn jemand den Fahrweg falsch einträgt, merkt das ein QA-Tool auch nicht.
Zumindest auf der Verkehrskarte wäre der Fehler wohl sichtbar. Der derzeitige Zustand ist wohl eher, QA-Tools zeigen Fehler an und niemand korrigiert sie, außer vielleicht in einigen Regionen. Das ist auch nicht besser.
Ganz so einfach ist es leider auch nicht. Ein Vergleich mit der Transport Map zeigt, dass die Busroute hier teilweise falsch ist.
Man könnte dem Router allerdings helfen:
- Alle highways auf denen ein Linienbus verkehrt, werden mit einem speziellen Tag gekennzeichnet. Dann brauchen nur diese zum Routen verwendet zu werden.
- Alternativ könnten wir alle längeren Ways, die von einer Linie inkl aller Varianten verwendet werden, in eine gemeinsame Fahrwegrelation (unterhalb von Route-Master) aufnehmen. Diese Wege sind dann vom Router bevorzugt zu verwenden. Da beim Aufnehmen der Wege weder Richtung noch Reihenfolge zu berücksichtigen sind und auch die Auswahl der Linienvarianten entfällt, wird der Aufwand stark reduziert, zumal auch die vielen kleinen Wege in Kreuzungsbereichen ignoriert werden können. Da Lücken zulässig wären, braucht der Editor die Relationen auch nicht mehr gegen Zerbrechen zu schützen, was die highway Bearbeitung stark vereinfacht.
Im Schienennetz ist das Routing wohl eher einfach, da weniger Wahlmöglichkeiten vorhanden sind, zumal man Nebengleise für Zugfahrten ignorieren kann.
Beim Rendern einer Verkehrskarte haben wir noch ein grundsätzliches Problem mit Routinglösungen: Wie erkennt der Renderer welche Linien für den zu rendernden Bereich zu routen sind? Wir werden eine maximale zulässige Entfernung zwischen Elementen in den Linienrelationen definieren müssen. Dann hat der Renderer alle Linien zu routen, die in einer entsprechenden Entfernung vom zu rendernden Kartenausschnitt direkte oder indirekte Member haben.
Ja des ist dann schon eine Gefahr… dahingehend… ist die jetzige Relation mit allen Teilen robuster… Aber vielleicht zum erstellen einer Relation? Das mir das Routing-Programm… Eine Relation ausgibt…
Bis jetzt kann man mit einem Routing-Programm mir das anzeigen lassen… kann mir ein GPX downloaden… welches im Josm anhängen kann… usw. ist schon hilfreich…
Was ein Routing-Programm besser kann… alle Tags zu beachten… Einbahnstr. irgendwelche Beschränkungen usw. usw. Abbiegebeschränkungen usw… Wer überblickt das schon alles beim erstellen einer Route?
Aber hier würde es schon gut funktionieren… auch wenn noch eine Bushaltestelle auf dem Weg fehlt…
Ich denke, niemand sollte Einbahnstraßen etc. beim Anlegen einer Busroute berücksichtigen! Man sollte einfach nur das mappen, was man festgestellt hat.
OK also lieber gegen Verkehrsregeln verstoßen…
Ja. Der Verstoß gegen die Verkehrsregeln ist ein wertvoller Hinweis. Vermutlich ist bei der Straße was falsch gemappt worden und man kann es korrigieren.
Ich verstehe nicht wie du Buslinien einträgst… bzw. herausfindest wie der Bus wo fährt? Fährst du mit dem z.B. Bus von Anfang bis Ende und dann wieder mit diesen wieder zurück bis zum Anfang? Und dann das ganze mit jeder Variante die diese Buslinie hat dann das gleiche noch einmal? Mir erschliesst sich deine Arbeitweise dabei jetzt nicht ganz? 
Wenn ich mit jeder Buslinie und Variante die ich schon eingetragen habe fahren müsste… dann wüsste ich was ich das nächste halbe Jahr mache… und wäre viel Geld los
Ja, eigentlich schon. Meist fahre ich nicht die ganze Strecke und trage dann eben nur einen Teil ein.
Die meisten Buslinien an denen ich mitgearbeitet habe sind aber nicht von mir erfasst worden … ich hab sie nur repariert.
Man braucht schon eine Monatskarte oder sowas sonst zahlt man sich dumm und dusselig. Da ich kein Auto habe gilt das bei mir aber sogar im Urlaub. 