ÖPNV Bus stop_position

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…

https://openstreetmap.org/relation/122830

https://graphhopper.com/maps/?point=48.3957876%2C11.7461972&point=48.3978374%2C11.7509125&point=48.3960282%2C11.7543417&point=48.3948201%2C11.7582813&point=48.3910979%2C11.7626478&point=48.3888654%2C11.7576894&point=48.3848102%2C11.7651958&point=48.3890347%2C11.7647564&point=48.3907990%2C11.7683808&point=48.3953720%2C11.7699785&point=48.3952014%2C11.7652414&point=48.3927988%2C11.7646719&point=48.3944039%2C11.7592062&point=48.3958966%2C11.7551200&point=48.3978374%2C11.7509125&point=48.3957876%2C11.7461972&locale=de&vehicle=bus&weighting=fastest&elevation=true&use_miles=false&layer=Omniscale

Ich denke, niemand sollte Einbahnstraßen etc. beim Anlegen einer Busroute berücksichtigen! Man sollte einfach nur das mappen, was man festgestellt hat.

OK :laughing: 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? :confused: 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 :laughing:

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. :slight_smile:

Ich mach es so gut es geht, ohne mit den ganzen Bussen zu fahren… und auch vervollständigen… reparieren usw. fehlende ergänzen. Mach etliche Fehler/Hinweise… sollte was nicht stimmen kann man es ja korrigieren… aber der Anfang ist schon gemacht und der macht am meisten Arbeit :slight_smile: Ob jetzt der Bus die eine oder eventuell andere Straße nimmt ist eigentlich fast egal… Hauptsache er hällt an der nächsten Haltestelle :slight_smile:

Wenn ich den Fahrweg der Buslinie nicht kenne, würde ich ihn auch nicht taggen.

Außerdem müßte man sich Gedanken über die Datenquelle machen, ist Abschreiben von Fahrplänen im Sinne von OSM?

Ist im Sinne von OSM ;). Hab da mal gehört… alles was sich vor Ort überprüfen lässt kann man OSM hinzufügen. Da der Fahrplan vor Ort öffentlich aushängt und von jedermann überprüft werden kann… passt also… :sunglasses:

Da hier im Thread auch mein damaliger PTv3-Entwurf diskutiert wurde:
Es gibt einen neuen … die Segmente sind komplett wieder rausgeflogen und vieles wurde umbenannt. Siehe http://gafte.de

Also ich hätte folgende Use-Cases:

-Erstellung von Netzplänen: Gibt es etwa bei der Rheinbahn

-Generieren von Services wie dem DB-Zugradar, bei denen die exakte Route bekannt sein muss.

-ÖPNV-Router, die den Weg zur platform (bei einem platform-way bis auf Höhe der entsprechenden stop-position) genau anzeigen und damit auch etwa Umsteigezeiten berechnen können.

-Abfahrtsmonitore wie Öffi könnten bei korrekten Daten die stop_areas auf einer Interaktiven Karte zeigen, ein Klick auf eine stop_area führt zu einem Abfahrtsmonitor, und wenn man dann auf eine Abfahrt klickt wird mittels der online hinterlegten Echtzeit-Halteposition die position der entsprechenden stop_position auf einer Karte angezeit.

Wie du siehst ist vieles denkbar und dank PTv2 auch machbar, man muss nur die Daten korrekt erfassen. Dass der entsprechende Aufwand sogar wirtschaftlich sein kann zeigen Unternehmen wie Menz, die immer mehr Kunden betreuen.

Dass es OSM-Daten allerdings auch in die internen Abläufe bei Verkehrsunternehmen schaffen wage ich jedoch sehr zu bezweifeln, dafür sind unsere Daten leider viel zu vandalismusanfällig und damit unzuverlässig. Für die Kundeninformation sind sie jedoch sehr gut geeignet.

Grüße

Ich glaube noch nicht mal das Vandalismus das entscheidende Problem wäre. Dem kann man begegnen, in dem man beim Fahrplanwechsel eine Review der Daten macht und diese dann für den eigenen Gebrauch einfriert, bzw Änderungen nur übernimmt wenn diese überprüft wurden.

Ich glaube aber für solche Zwecke ist unser Datenformat nicht geeignet. Verkehrsunternehmen brauchen auch Angaben wie Fahrzeugumläuf, Ruhezeiten usw. Wir sollten uns auf die Fahrgastaspekte konzentrieren.

Da liegt die Zukunft. Bisher arbeiten die Verkehrsunternehmen in der Regel mit statischen Umsteigematritzen. Das macht das Routing sehr unfexibel und erlaubt auch nicht, dem Kunden exakte Umsteigewege anzuzeigen. Das Interesse ist groß.

Das ist mancherorts schon Gegenwart. Dabei werden hier im VRR die Haltestellen als Nodes in einer Datenbank des Verkehrsunternehmens gespeichert und zwischen den Nodes wird Fußwegrouting auf OSM-Daten gemacht. D.H. also lustigerweise, dass für den ÖPNV OSM-Daten genutzt werden, soweit es keine ÖPNV-Daten sind.

Je nach Qualität der einzelnen Nodes in der Nodedatenbank des Verkehrsunternehmens ist die Qualität unterschiedlich. Wir könnten evtl. durch unsere linienförmigen und flächenförmigen Steige bei Bahnen bessere Ergebnisse erzielen, da ein einzelner Node bei einem Bahnsteig mit mehreren Abgängen schlechte Abstände liefert…

Das ist mir schon klar. Ich meine, dass bisher z.B. kein Bahnsteig zu Bahnsteig Routing gemacht wird, das geht momentan nur mit statischen Matritzen mit statischen Umsteigezeiten. Würde man auch hier die OSM daten nutzen um zu ermitteln welche Umsteigebeziegungen möglich sind, wäre das sehr viel flexibler.

Ich haben ihn mir durchgelesen und finde ihn recht interessant, verstehe aber glaube ich nicht alles. Ich werde aber mal Feedback geben aber da immer nur einzelne Aspekte herausgreifen, da mir das sonst zu viel auf einmal wird. In diesem Fall PIOs:

Wenn ich das richtig verstanden habe, lösen PIOs u.a. das Problem, das Wartebereich und Platform nicht identisch sein müssen. PIOs markieren quasi die Grenze zwischen Fussgänger (Rollstuhl oder was auch immer) und ÖPNV-Routing richtig? Das halte ich für einen recht pragmatischen, nützlichen und intelligenten Ansatz. Hab da noch Fragen:

Lösen PIOs das Problem, dass es ggf unterschiedliche Bahnsteige zum Ein- und Ausstieg gibt und daher der PIO in beide Richtungen unterschiedlich sein müsste?

Wurde die wachsende Rolle des Bedarfsverkehrs berücksichtigt? Kann man so etwas wie “Einstieg nur nach Anmeldung 30min im Voraus” abbilden?

Was für real existierende Probleme lösen die PIOs noch?

Ja. Wobei auch mal noch ein ganzes Stück zwischen PIO und Verkehrsmittel liegen kann. Z.B. wäre bei der Fähre Kiel-Göteborg der PIO im Gebäude von Stena Line, denn da muss man als Fußgänger hin – da ist die Kontrollschleuse. Das Schiff fährt aber ein ganzes Stück entfernt ab. Dazwischen liegt ein langer Gang, der dann nicht erfasst ist. Aber in dem Gang gibt es auch keine Möglichkeit, sich zu verlaufen.

Nein. Aber man könnte die Rollen “pio-in” und “pio-out” dazunehmen. Über das “+” kann man ja beliebig viele Einzelangaben zu einem Halt machen. Man kann das Problem bei Autos (als Fährpassagiere) auch über oneway lösen … aber das geht bei Fußgängern vermutlich nicht.

Nein. Jedenfalls habe ich keine Idee, wie man das mit vertretbarem Aufwand da reinbekommen kann. Das muss wohl über Fahrplanangaben gemacht werden.

Konflikte mit dem Mapping physischer Objekte. Ich kenne einige gute Mapper, die keinen Nerv mehr haben auch nur eine Bushaltestelle anzulegen.

PIOs sind nie physisch. Es ist immer klar, dass man für einen Bahnsteig railway=platform und für einen physisch vorhandenen Bussteig highway=platform oder highway=pedestrian oder was-weiss-ich nehmen muss. Man kann das nie durch ptv3_object=pio ersetzen. Dadurch kann man auch mehrere PIOs auf einem Bahnsteig haben. In Mainz Hbf gäbe es z.B. auf dem physischen Bahnsteig an den Gleisen 4 und 5 die PIOs 4a, 4b, 4, 5a, 5b und 5. In Duisburg Hbf gäbe es z.B. einen PIO für die relativ zum Bahnsteig sehr kurzen Doppelstockzüge. Damit käme man für das Umsteigen vom Zug in die U-Bahn auf realistische 300m … vom Bahnsteig zur U-Bahn sind es dagegen nur 30m. (Die Zahlen sind grobe Schätzungen. Die genauen Zuglängen und Haltepositionen hab ich nicht.)