search

schildbach / public-transport-enabler

Unleash public transport data in your Java project.
https://groups.google.com/forum/#!forum/public-transport-enabler-discuss
GNU General Public License v3.0
390 stars 133 forks source link

[DE] Some (slower) trains not showing up #137

Open bugzillus opened 7 years ago

bugzillus commented 7 years ago

Darf ich hier kurz die Fragestellung aus https://github.com/grote/Transportr/issues/299 wiederholen:

In manchen Fällen werden einige Züge nicht angezeigt. Es scheint daran zu liegen, dass – wie bei der Bahn-Onlineauskunft – standardmäßig der Parameter "Schnelle Verbindungen bevorzugen" gesetzt ist und daher manche langsameren (und meist günstigeren) Züge "unterschlagen" werden.

Beispiel: Berlin Hbf <> Hannover Hbf, hier werden nur die ICE angezeigt, die im Wechsel fahrenden IC überwiegend nicht.

Wichtig wäre, dass "Schnelle Verbindungen bevorzugen" entweder per Schalter ausgewählt werden kann oder hilfsweise immer abgewählt ist, damit tatsächlich alle Züge angezeigt werden, die zum Suchzeitpunkt auf der angefragten Relation verkehren (das ist ja, was man wissen möchte).

schildbach commented 7 years ago

Es gibt an queryTrips() den Parameter Optimize mit den Werten LEAST_DURATION, LEAST_CHANGES und LEAST_WALKING. Hilft das?

bugzillus commented 7 years ago

Nein, leider nicht, siehe verlinktes Ticket oben.

Im Quelltext von https://rabdc.bahn.de/bin/query.exe/dn? finde ich bei den erweiterten Einstellungen dazu: `

` Das versteckte Feld `existOptimizePrice` offenbart m. E. den Zweck der Übung: nicht Fahrzeitverkürzung, sondern Upselling bzw. Maximierung des Preises der verkauften Fahrkarte (indem die langsameren, billigeren Züge erst gar nicht angezeigt werden) ... Vermutlich muss `REQ0HafasOptimize1` mit Wert `0` übergeben werden, damit alle Züge angezeigt werden, ggf. auch zusätzlich `existOptimizePrice` mit dem Wert `1`.
schildbach commented 7 years ago

Ok. Das ist natürlich etwas häßlich. Das "immer abwählen" wäre einfach zu machen, indem im BahnProvider die Method appendCommonQueryTripsBinaryParameters() modifiziert wird. Hätte das in deinen Augen einen Nachteil? Torsten @grote, was denkst du?

Mit dem Schalter tue ich mir etwas schwer, eine Verallgemeinerung zu finden. Wir könnten evtl. einen vierten Optimize-Wert LEAST_PRICE einführen, der dann erstmal nur beim BahnProvider wirkt. Aber dann müssten wir eigentlich eine Liste von Optimierungs-Zielen einführen, so daß man mehrere angeben kann.

bugzillus commented 7 years ago

Ich habe mich mit der API noch nicht befasst. Parameter, bei denen eine "Optimierung" (Selektion) intransparent bei der Bahn abläuft oder Wertungen beinhaltet, sehe ich kritisch, zumal sie beim Ticketkauf relevanter sind als bei der adhoc-Nutzung von Apps wie Öffi oder Transportr, wo die Entscheidungskriterien für/gegen eine Verbindung oft ganz anders aussehen und man manchmal auch nur Details/Updates zu bereits gebuchten Verbindungen braucht – und diese dann auch aufrufen können muss.

Sonst ist das Ergebnis wie vorliegend: Ein Teil der Verbindungen wird von der Bahn unterschlagen und der Anwender merkt es nicht, oder er merkt es und fragt sich, ob der Zug ausfällt. Insofern wäre ich für "immer abgewählt" als Standard und gleichzeitig eine Wahlmöglichkeit, so dass Apps den Wert auch vom Benutzer ändern lassen können, wo es gewünscht und implementiert ist.

LEAST_PRICE würde ich nicht als Kriterium benennen, solange nicht ein tatsächlicher Preisvergleich erfolgt, da langsamere Verbindungen nicht zwangsläufig billiger sind (hängt von Ticketart, verfügbaren Sparpreisen, genutzten Zugarten, und beim Flexpreis von der Streckenlänge der jeweiligen Verbindung ab).

schildbach commented 7 years ago

Nur kurz: Beim BahnProvider muss man sich immer auf die DB verlassen, das ist die zugrundeliegende Idee der Provider. Wenn du das nicht willst, betreibe ein eigenes Auskunftssystem (z.B. mit der Software von Navitia) und dann schreibe einen Adapter dafür. Damit hast du dann die volle Kontrolle, zumindest solange du den Rohdaten traust…

bugzillus commented 7 years ago

Ja, das war aber nicht mein Anliegen. Erkenntnis aus diesem Ticket ist bislang, dass der Bahn-Server in default-Einstellung offensichtlich aus Marketing-Gründen vorhandene und für manche wichtige Verbindungen nicht wiedergibt (und für den Anwender damit als "nicht vorhanden" deklariert). Das ist ein erheblicher Widerspruch zum erwarteten Verhalten einer Fahrplan-Abfrage(-App). Um solche Effekte zu minimieren, würde ich Optimierungen und Priorisierungen lieber (nachvollziehbar) dem Client bzw. Anwender überlassen als dem Bahn-Server, mehr wollte ich nicht zum Ausdruck bringen.

fynngodau commented 5 years ago

Ich halte es für problematisch, wenn gewisse Verbindungen serverseitig verschwiegen werden. Der Nutzen von öffi und transportr ist für mich mitunter dadurch, dass ich nicht alle akzeptablen Verbindungen sehen kann, insofern verringert, dass ich, wenn ich sie doch sehen möchte, meine Reisedaten nochmals auf reiseauskunft.bahn.de eingeben muss.

Es ist mir in der Vergangenheit bereits passiert, dass ich dachte, zu einer gewissen Zeit fahre doch kein Regionalexpress, weil der Server sie aufgrund einer zeitlich einigermaßen nahegelegenen, ICE-haltigen Verbindung unterdrückt hatte. Die Anzeige durch die Deaktivierung der Fernverkehrszüge in der Verkehrsmittelauswahl zu erzwingen empfand ich als nervig.

Deswegen bin ich stark dafür, die "Schnelle Verbindungen bevorzugen"-Funktion (die mittlerweile auf der Webseite "Schnellste Verbindungen anzeigen" heißt, was die wahre Intention wohl noch weiter verschleyern soll) für alle Anfragen zu deaktivieren.

xaverdh commented 1 year ago

Das Problem gibt es immer noch. Wie schwierig wäre es "immer abwählen" zu implementieren, und würde so eine Lösung akzeptiert? Ich bin kein Experte für Java, aber könnte es mal versuchen.

derhuerst commented 1 year ago

Meine 2 Cent hierzu:

Ich halte es für problematisch, wenn gewisse Verbindungen serverseitig verschwiegen werden. Der Nutzen von öffi und transportr ist für mich mitunter dadurch, dass ich nicht alle akzeptablen Verbindungen sehen kann, insofern verringert, dass ich, wenn ich sie doch sehen möchte, meine Reisedaten nochmals auf reiseauskunft.bahn.de eingeben muss.

Es ist mir in der Vergangenheit bereits passiert, dass ich dachte, zu einer gewissen Zeit fahre doch kein Regionalexpress, weil der Server sie aufgrund einer zeitlich einigermaßen nahegelegenen, ICE-haltigen Verbindung unterdrückt hatte.

Das ist übrigens selbst ohne den Modus "schnellste Verbindungen bevorzugen" so. Der Routing-Algorithmus, den die DB einsetzt, sortiert anhand bestimmter Kriterien viele (an sich mögliche) Verbindungen aus, ob er dabei strikt Pareto-optimal arbeitet ist AFAIK unklar.

Die Anzeige durch die Deaktivierung der Fernverkehrszüge in der Verkehrsmittelauswahl zu erzwingen empfand ich als nervig.

Deswegen bin ich stark dafür, die "Schnelle Verbindungen bevorzugen"-Funktion (die mittlerweile auf der Webseite "Schnellste Verbindungen anzeigen" heißt, was die wahre Intention wohl noch weiter verschleyern soll) für alle Anfragen zu deaktivieren.

Ich denke bei der Wahl der Standard-Einstellung sollte die übliche Nutzung des DB-Backends in Öffi & Transportr betrachtet werden. Diese Standard-Einstellung könnte ja auch von der in PTE (als die unvoreingenommene low-levelige Komponente) abweichen.