witz des Jahres… alleine die Zuordnung von OSM Relationen zu GTFS Trips ist horror… wenn mal mehr Varianten sind. Dann jede Variante auf Vollständigkeit und richtige Sortierung der Haltestellen und des Verlaufes… ist eine Tagesaufgabe pro Linie.
Aber man behaart auf diese tagging so wie ich raus lese, dann kann ich ja Zukünftig bei Straßeneinbauen z.B. Kreisverkehr bei denen man unweigerlich die PTv2 Relationen fixen muss… die Aufgaben den “PTv2” Befürworten zu überlassen…
Na, na, na 
Ich dachte, man könnte auch in PTv1 mit router_master-Relationen arbeiten, so dass es das Problem nicht gibt. Und da (leider) die tatsächliche Route in Form von Wegesegmenten in PTv2 verpflichtend ist, lässt sich ein automatisches Routen nur anhand von Haltestellen dort (momentan) nicht korrekt abbilden.
PTv1 sieht keinen route master vor… aber an sich ist ein Route Master eine Sammelrelation die man eigentlich nicht benötigt… z.B. Overpass auch so alle Relationen.
Wieder ein Nachteil… weil z.B. im GTFS ist das Shape optional… weil es an sich nicht benötigt wird für die Routenberechnung… nur für eine schöne Kartendarstellung…
Entscheidend ist vielmehr ich Steige an Punkt A ein und komme bei Punkt B um die Uhrzeit an…
Sieht es nicht vor, weil die erst in PTv2 ergänzt wurden. Aber ich wüsste nicht, was dagegen spricht, welche anzulegen. Das Tagging derselben ist ja nicht PTv2-spezifisch.
Overpass benutzen, um Varianten einer Route zu bekommen, mag meistens funktionieren, aber gerade wenn die Variation einer Linie zu Dingen wie Suffixen im Namen führt, wird das nicht mehr so einfach gehen. Ich bin gerade in einer Stadt, wo die Buslinien 1-16 existieren, die Nachtlinien aber 1N bis 16N heißen, weil der Weg leicht anders ist. Leicht, weil sie mehrere Schlenker fahren, die sie sonst nicht fahren. Dann gibt es noch 1E bis 16E, welches die Express-Linien sind, die halten dann an einigen Haltestellen wiederum nicht mehr. Ich finde das Anlegen von route_master-Relationen auch relativ gradlinig, das ist weder Hexenwerk, noch extrem viel Arbeit.
Für mich sind Routen in PTv2, aber ohne Weg-Segmente und ohne stop_position zusammengefasst in route-master-Relationen schnell erstellt und einfach zu pflegen. Vielleicht könnte man auch alle Varianten in eine Route quetschen, aber das würde voraussetzen, dass die grobe Reihenfolge der Stops immer identisch ist, ansonsten bräuchte es massiv Support der Editoren, um die Varianten gut abzubilden. Aber träumen darf man ja wohl 
Laut Taginfo gibt es 41407 Objekte mit public_transport:version=2 und opening_hours=*, also ein bissle Daten gibt es. Router die es auswerten habe ich noch nicht gesehen.
Z.B. habe ich einige Routen in Toronto mit opening_hours bzw. departures versorgt, wertet irgenwelches Tool das aus? OsmAnd scheinbar nicht - gibt gar keine Ab/Ankunftszeiten an, und routet tagsüber mit Nachtrouten.
Beispiele:
opening_hours versehendepartures sowie opening_hours versehenIch hab mich schon ewig nicht mehr damit beschäftigt, aber könnte man, korrektes Tagging der Haltestellen via gtfs:* vorausgesetzt, nicht dort, wo GTFS-Daten vorliegen, diese Daten nutzen statt Relationen? In Hannover gibt es (noch) keinen Feed dazu, deswegen hatte ich bisher auch keinen Grund, mich wieder damit zu beschäftigen.
Schon, aber dafür braucht man keine ÖPNV-Daten in OSM und nutzt einfach OpenTripPlanner mit GTFS-Daten
Das empfinde ich mit PTNA mittlerweile als sehr einfach. PTNA berechnet ja automatisch eine Tabelle für jede Kombination aus OSM-Route und GTFS-Trip mit einer Prozentualen Übereinstimmung im entsprechenden Feld. Wenn man dann einfach die Tabelle nach der entsprechenden Spalte sortieren lässt, hat man den GTFS-Route oben stehen, der am ehesten passt. Dann kann man ggf noch auf einen Blick prüfen ob Start- und Endhaltestelle und Anzahl der Stops passen. Das dauert zusammen keine 3 Sekunden. Problematisch ist es, wenn es gar keine passenden GTFS-Route gibt, oder GTFS-Routen übrig bleiben. Ist dann die OSM Route zu viel oder falsch, oder was auch immer, womit wir dann genau wieder bei meiner ursprünglichen Fragestellung angekommen sind und sich der Kreis wieder schließt, ohne wirklich weiter gekommen zu sein.
An sich geht das nicht… Weil ein gtfs nicht stabil bleiben muss… In der nächsten Release kann alles anders sein… Hängt von der Software des öpnv Unternehmens ab.
Einzig wenn für die Haltestellen ref:IFOPT verwendet wird bleibt diese stabil… diese gibt die genaue Plattform (bzw. Steig oder Haltestelle/Station) angeben. Wird in der EU im zentralen Register gepflegt. Andernorts kann andere stabile ref=? geben.
Ja genau deshalb sollte man die ja auch verwenden. Gibt es für jede Haltestelle in Deutschland als gemeinsamen Datensatz von der DELFI mit OSM-kompatibler Lizenz. Leider gibt es nicht für jede Region nutzbare GTFS-Sätze, die diese enthalten. Hier müsste man vielleicht noch mal die DEFI freundlich “bearbeiten”. Die hat da auch einen (theoretisch) vollständigen Datensatz, der aber keine kompatible Linzenz hat.
Genau das macht z.B. Transitous. Das braucht auch keine gtfs:* sondern nutzt, falls vorhanden, die IFOPT der Haltestelle um GTFS-Stop auf public_transport=platform zu mappen und wenn keine IFOPT da ist nurtzt es eine Heuristik aus Haltestellennamen, Koordinaten und noch ein paar anderen Werten, was meist auch recht gut funktioniert. Zum Routen über GTFS braucht es auch nicht zwingend einen Feed für Hanover, weil auch der deutschlandweite von DELFI geht, der eine freie Lizenz hat. Der hat nur keine OSM-kompatible Lizenz, daher darf man den nicht als Mapping-Vorlage verwenden.
Du solltest hier aber nicht Äpfel mit Birnen vergleichen. Oder anders ausgedrückt: Wie ordnest du die GTFS-Trips im PTv1 zu?
Ist das so? Bei PTv2 reicht ein Blick in PTNA. Wie stellst du das bei PTv1 sicher wo alle Strecken in einer Relation sind? Wie sortierst du eine PTv1 “route”?
Muss man das? Teile deine Kreuzung, so dass jeder Straße ein einzelner Weg ist. Die Aufteilung der Relationen macht jOSM im Hintergrund. Füge in jeden dieser Wege einen neuen Node ein, kurz hinter dem Kreuzungspunkt. Teile die 4 Wege an diesen Nodes. Auch hier macht jOSM im Hintergrund die Relationsarbeit. Mache nun die kurzen Wegsegmente unabhängig, so dass jedes Segment 2 eigene Nodes hat. Forme dann aus diesen Segmenten deinen Kreisverkehr, in dem du die Wege verbindest und dann optional rund machst. Auch hier macht jOSM die Relationsarbeit quasi automatisch. Beim Verbinden musst du ihm nur sagen, dass du alle Relationen behalten willst.
Was für ein Nachteil und was ist in OSM schon verpflichtend? Du kannst deine PTv2 route auch nur mit platform nodes hochladen. Genauso wie bei PTv1.
Wenn man es einfach will, fragt mach Tante G dachte ich
Mit den GTFS-Daten alleine wirst du nur wahrscheinlich nie Dinge machen können, wie z.B. Barrierefreies Routing von einem Bahnsteig zum anderen. Zumindest die Haltestelleninfrastruktur ist da schon sehr hilfreich.
Meines Erachtens ist das eine zweischneidige Sache. Was Google sicherlich hervorhebt ist die angebotene Google Suche und damit wohl auch das beste POI-Routing derzeit. Auch den Vergleich mit dem Auto bieten ansonsten nur wenige. Das ÖPNV-Routing selber ist aber nur sehr mäßig.
Wer hat gesagt das ich PTv1 will… ich will Routing…
Das geht nicht bei einem großen Kreisverkehr mit Ab- und Zufahrten… da muss man zwangläufig an die Relationen…
Dafür ist ja auch GTFS nicht gedacht… das ist ÖPNV Routing gedacht… Der Bahnsteigwechsel o.ä. fällt dann ins Fußgängerrouting… der OpenTripPlanner kann das z.B. diese kombiniert OSM Daten mit GTFS…
Das hab ich auch nicht behauptet, sondern Jarek, wenn ich ihn da richtig verstanden habe. Ich habe auch Beispiele genannt, die beides Kombinieren. Darüber hinaus, benutzen die Verkehrsunternahmen natürlich ihre Fahrplandaten um Umsteigebeziehungen zu berechnen. Die enthalten meist tabellarische Umsteigebeziehungen. Wirklich geroutet wird da bisher nichts, außer ggf dem Vor- und Nachlauf. Sieht dann z.B. so aus.
Kannst Du, aber es wäre dann prinzipiell eine unvollständige Relation, weil die Wege verpflichtend sind. Wenn man das offiziell erlauben wollte, sollte man das Ganze nicht mehr PTv2 nennen, weil es aus Sicht der Datenkonsumenten eine Änderung des vereinbarten Formates ist. Aber grundsätzlich wäre es natürlich schön, wenn diese Wege optional wären.
Ich würde allerdings gtfs:* schon besser finden, gerade wenn es z.B. um SEV geht oder um große Haltestellen. Aber im Grunde scheint es doch so, dass eine solche Automatisierung viel besser funktioniert – mal abgesehen davon, dass das Erstellen von ÖPNV-Karten langsamer wäre.
Im Falle von DELFI könnte man ja mal nachfragen, ob OSM-Mapper die Daten für diese Zwecke unter einer anderen Lizenz nutzen dürfen.
Selbst wenn man dagegen ist, die Daten nicht mehr manuell über PTv1/v2 einzupflegen, könnte man die GTFS-Daten immer noch gut zu Qualitätskontrolle nutzen.
