DepArrTime on Destination: doesn't deliver any results before arrival time

[Flurin-BLS]

Wenn wir eine Abfrage mit Bern-Thun 'Ankunft 13:00' senden, erhalten wir keine Verbindung die vor 13 Uhr in Thun ist, nur Verbindungen die nach 13 Uhr in Thun ankommen.

Bei OJP 1.0 ist das wie erwartet - es werden 5 Verbindungen geliefert die vor 13:00 Uhr ankommen.

• Bsp OJP 1.0 Thun-Bern Arrival 13:00
• Bsp OJP 2.0 Thun Bern Arrival 13:00

Doku zu NumberOfResults

Was ist das gewünschte verhalten von OJP 2.0? Wir brauchen bald möglichst eine Antwort was "korrekt" ist - denn so wie es heute implementiert ist liefert es keine "brauchbaren" Resultate.

[u233336]

@TO-mdv Ich hätte hier auch die Erwartung, dass mit dem Tag in der Destination die Verbindungen ausgegeben werden, die vor der angegeben Zeit an der Zieldestination ankommen:

8507000 Bern 2024-11-02T11:00:00.475Z

Hier sollten also "nur" Verbindungen ausgegeben werden, die vor 11:00:00 Uhr in Bern ankommen. OK, vielleicht kommt noch eine Verbindung nach 11:00 Uhr an.

Weshalb ist das nicht der Fall?

[TO-mdv]

Können wir gerne im nächsten Sprint so einplanen, so haben wir das gleiche Verhalten wie sbb.ch:

[TO-mdv]

SH-3926 OJP2.0 Anpassung Verhalten Ankunft um

[TO-mdv]

@r3to wir haben das Verhalten angepasst. Du kannst auf INT testen, ich würde das in einer Woche auf PROD releasen

[r3to]

@TO-mdv Danke, jetzt sind alle tripResults vor der angegeben Ankunftszeit. Also analog NumberOfResultsBefore. Wir möchten allerdings den passendsten Trip (also der, der kurz vor der angegeben Zeit ankommt) weiter oben in der Liste haben. Idealerweise an Stelle zweiter oder dritter Stelle. Andernfalls wäre das passende Resultat nicht in der Liste sichtbar sein

[TO-mdv]

@r3to Ich dachte, wir hätten uns geeinigt dass "Ankunft um X" mit NumberOfResults = 5 bedeutet, liefere mir 5 Trips die alle vor X ankommen. Das haben wir so umgesetzt, so wie es auch sbb.ch macht (siehe Screenshot oben).

Wenn ich dich richtig verstehe, möchtest du noch 1-2 Verbindungen die nach X ankommen. Aber dieses Verhalten finde ich dann nicht konsequent. Was sollen wir denn machen, wenn jemand mit NumberOfResults=1 anfrägt? Oder 3 ? Dann geben wir unter Umständen wieder Trips aus, die erst nach X ankommen und genau das wollen wir ja nicht.

[r3to]

Sälü @TO-mdv

Wir haben uns gestern am Weekly missverstanden, war auch etwas chaotischer als üblich, sorry.

Habe das Verhalten bei der Ankunftszeit beim TR auch noch gerade mit @ue71603 und @Flurin-BLS besprochen. Unser Wunsch ist schon, dass in den TripResults sowohl Resultate vor, wie auch nach der angebenden Ankunftszeit drin sind.

Die idealste Lösung fände ich:

Request mit Ankunftszeit 09:41

TripResults:
  [0] Trip mit Ankunft 09:20
  [1] Trip mit Ankunft 09:30
  [2] Trip mit Ankunft 09:40
  [3] Trip mit Ankunft 09:50
  [3] Trip mit Ankunft 09:50
  [3] Trip mit Ankunft 10:00
  [n] ...

Aktuell wird ja NumberOfResults nicht in konsequent Fall berücksichtigt und wir erhalten manchmal auch mehr Resultate, als die angegebene Zahl, deshalb wäre der beschriebene Case von NumberOfResults < 3 ja auch nicht problematisch.

[TO-mdv]

@u233336 @ue71603 Aus meiner Sicht ist diese Anforderung sehr kundenspezifisch und entspricht nicht dem OJP Standard. Dieser UseCase müsste aus meiner Sicht mit den Parametern NumberOfResultsBefore und After Clientseitig umgesetzt werden. Oder wie seht ihr das?

[ue71603]

Hallo zusammen. Wie sieht der MENTZ-Standard aus? Wir können das auch in der Routinggruppe kurz diskutieren. Es kommt zwar von BLS, aber allenfalls empfinden mehr Kunden so. Mir ist auch wichtig, dass Malte nicht einen völligen Murks bauen muss @u233336 : Wie vorgehen?

[r3to]

@TO-mdv ja, wir können das Verhalten auch mit NumberOfResultsBefore und NumberOfResultsAfter in unserem Client (resp. vermutlich besser im SDK) umsetzen, falls sich unser Wunsch zu stark vom Standard unterscheidet.

[u233336]

Hallo zusammen Ich will eine mehrheitsfähige und nachhaltige Lösung. Besprechen in der Routinggruppe finde ich sinnvoll.

[Flurin-BLS]

@TO-mdv - ich finde die Frage von @ue71603 sehr spannend, ist die die selbe die ich schon via Slack gestellt habe. Was macht ihr "standardmässig"? Ich kann mir nicht vorstellen das das was heute angeboten wird irgend einem Kundenwunsch entspricht. Resp. ist mir rätselhaft wie das jemand "sinnvoll" nutzen soll.

[TO-mdv]

Bei EFA mit unserem eigenem Weblayout geben wir standardmässig eine zusätzliche Fahrt aus (bei Abfahrt um: eine vorher, bein Ankunft um: eine nachher). Aber hier geht es ja um einen Standard (OJP), welche das Verhalten genau definiert. Will man davon abweichen, hat man Parameter wie After/Before zur Wahl. Falls wir dieses Verhalten so kundenspezifisch anpassen sollen, müssen wir das konsequenterweise auch bei der Abfahrt machen (immer noch einen Trip vor der gewünschten Abfahrt).

[r3to]

Ich bin davon ausgegangen, dass der OJP Standard bei NumberOfResults auf Departure auch eine Abfahrt vorher zulässt, also analog zu EFA. zur Ankunftszeit sehe ich da keine Aussage, aber das EFA-Verhalten finde ich auch in diesem Fall sinnvoll.

Aber grundsätzliche ist unsere Anforderung für die Ankunftszeit mit 3 vorher, n nachher schon recht spezifisch und macht wohl keinen Sinn über NumberOfResults zu lösen. → Ich klinke mich hier aus der Diskussion aus und werde falls nötig ein SDK Issue erstellen um diese Funktion zu implementieren.

[Flurin-BLS]

Habe die Situation gerade noch mit @r3to diskutiert. Uns spielt es Grunsätzlich keine Rolle welcher Weg gewählt wird, es gibt aber klare Vorteile für die Variante 2 - zumindest für unsere Umsetzung.

Hier unsere Analyse: --> Unser Ziel der 3. Treffer ist die letzte Fahrt mit Arrival Time before hh:mm:sss --> Es braucht einen Request und wir haben alle Daten für die Fahrtübersicht (mind. 5 Fahrten)

Variante 1 - wie EFA (1 vor und nachher bei Dep/Arr) - wir fragen einfach mit Arrival und Number of Result an:

<NumberOfResults>4</NumberOfResults>

--> es kommen 4 Treffer zurück - gemäss Doku können es aber auch 5 sein? @AndreasAtSBB oder greift das "beware" mit -1 Minute nur bei Abfrage nach "departure*? --> in der Liste muss an die richtige Stelle gescrolled werden für die "korrekte" Anzeige Problem: bei grossem Device ist die Liste nicht voll --> es muss geprüft werden ob es noch Platz hat für Verbindungen --> nachladen

Variante 2 - Arrival liefert nur Verbindungen vorher - wir nutzen die Parameter um zum Ziel zu kommen:

<NumberOfResultsBefore>3</NumberOfResultsBefore>
<NumberOfResultsAfter>2</NumberOfResultsAfter>

--> es kommen immer 5 Treffer zurück --> Hier ist sichergestellt wie viele Treffer vor resp. nachher angezeigt werden - daher kein scrollen und kein nachladen in der App nötig

[TO-mdv]

Wir halten uns also mit der OJP Implementierung an den Standard und lassen das Verhalten so, wie es akutell ist (keine X Fahrten Davor/Danach abweichend von der Anfrage).

BLS löst das Problem mit NoR Before/After, da es hier auch kein Nachladen benötigt.

[AndreasAtSBB]

Bei OPJ 2.0 ist immer nach der Zeit oder eben vorher bei NoR Before. Es können aber allenfalls mehr als die angeforderten Antworten geliefert werden, dies hat mit der Bewertung der Antworten des Routers zu tun, dass es dann allenfalls noch eine Fahrt mehr zurück gibt. Damit solltet ihr dann umgehen können.

[r3to]

@AndreasAtSBB [BaseTripPolicyGroup](https://vdvde.github.io/OJP/develop/documentation-tables/ojp.html#group_ojp__BaseTripPolicyGroup) definiert NumberOfResults und NumberOfResultsBefore|NumberOfResultsAfter als choice.

NumberOfResults ist im Gensatz zu NumberOfResultsBefore|NumberOfResultsAfter etwas ambivalenter beschrieben im Standard:

NumberOfResults: The number of trip results that the user wants to see at least. Be aware that some implementations will deliver one of the TripResults before the indicated departure time. This means that you can't assume that you get the exact number of results that you asked for in the request from the server.

[AndreasAtSBB]

Richtig, wenn du bestimmen möchtest, dann NoR Before/After, ansonsten hat der Router etwas mehr Freiheit. Wir lasse dann aber trotzdem noch den NoR umbauen, dass bei Ankunft die Reisen "Before" gesucht werden.

@TO-mdv benötigst du dazu noch ein Ticket? NoR soll gleich wie bei OJP 1.0 funktionieren, wenn in Destination, dann "Before" DepArrTime.

[r3to]

@TO-mdv Beim testen haben wir gerade gesehen, dass in den PTSituations nun SummaryContent fehlt. Das wäre ein Breaking Change, bitte nicht mit dem Stand auf PROD gehen https://gist.github.com/r3to/323ee2320c2c73a5e4149ac6cf5d3069