Het gebeurt zo af en toe dat bij een reis (in mijn geval vaak met de 5600) de vertraging op bepaalde stations niet getoond wordt. Dit komt bijvoorbeeld voor bij de stations: Wezep, Ermelo en Etten-Leur. Op Treinposities is dit ook het geval: https://treinposities.nl/ritinfo/20221215/5638
Het lijkt me onmogelijk dat een trein op een traject van enkele minuten een vertraging van 7 minuten in kan lopen, dus ik vermoed dat er hier iets mis gaat met de NS-App zelf. Een voorbeeld uit de NS-App:
Het toeval wil dat mij dit gisteravond ook al was opgevallen. Fijn dat je ook hebt gevonden dat dit ook op stations Wezep en Etten-Leur gebeurt. Ik durf m'n vingers niet te branden aan de oorzaak, maar ik zet het voor je door.
Bij bijvoorbeeld die 5639 loopt het ook in de aanleverende dataset fout, sterker nog, er wordt een actuele aankomsttijd van 12:18 en een actuele vertrektijd van 12:01 gegeven op Harderwijk. Dat is onmogelijk natuurlijk, vertrekken voordat je aangekomen bent. Zal eens een ticket inschieten.
Gebeuren weer meer vreemde dingen. Gisterochtend had de trein van Helmond naar Eindhoven van 7.32 uur een kwartiertje vertraging. In de app was deze trein op dat moment geheel verdwenen.
Mocht je echt opvallend voorbeelden hebben, drop ze gerust, kan altijd wat nazoeken en insturen.
Zit ff op treinposities te kijken. Zo te zien is deze onder een ander nummer gaan rijden na een storing. Heeft hier wellicht helemaal niks mee te maken
Goedemorgen Ruben,
Het toeval wil dat mij dit gisteravond ook al was opgevallen. Fijn dat je ook hebt gevonden dat dit ook op stations Wezep en Etten-Leur gebeurt. Ik durf m'n vingers niet te branden aan de oorzaak, maar ik zet het voor je door.
Nog een twee stations waarbij dit ook het geval is: Brummen & Sassenheim
Dit gebeurt ook wel eens bij Veenendaal-De Klomp
En weer één: Rosmalen
Conclusie: veel meer dan de paar stations die al langer bekend zijn vanwege de locatie van de meetpunten.
Het verantwoordelijke team heeft de bug inderdaad terug kunnen vinden, een fix zou op korte termijn doorgevoerd moeten zijn. Zou alle genoemde stations moeten omvatten, in geval van de 5600:
>...] waarbij we de vertraging op een stop waar we doorgaans geen metingen voor krijgen (EML en WZ in dit geval) verkeerd afhandelen.
En laten we eerlijk zijn, DCRI was er rap bij. Vrijdag 17:30h was de boel bij de juiste mensen om na te zoeken, vrijdag 22:40h ging het een stapje verder, en vanmorgen net voor de lunch terugkoppeling over een spoedige fix. Zo kan het ook
En laten we eerlijk zijn, DCRI was er rap bij. Vrijdag 17:30h was de boel bij de juiste mensen om na te zoeken, vrijdag 22:40h ging het een stapje verder, en vanmorgen net voor de lunch terugkoppeling over een spoedige fix. Zo kan het ook
Complimenten voor jou & het betreffende team!
Ik zal het de komende dagen eens in de gaten houden!
Mocht je nog altijd bijzonderheden zien, laat het vooral weten. Er kunnen natuurlijk meerdere dingen naast elkaar spelen, deze bug is ook ontstaan door een andere wijziging aan de vertragingsberekening.
Mocht je nog altijd bijzonderheden zien, laat het vooral weten. Er kunnen natuurlijk meerdere dingen naast elkaar spelen, deze bug is ook ontstaan door een andere wijziging aan de vertragingsberekening.
Komt goed!
Nu maak je me wel nieuwsgierig, wat houdt die wijziging in dan…?
Die details heb ik niet zo direct, sorry.
We kunnen weer verder, want ik heb een nieuw probleem gesignaleerd. De NS-App geeft nu als er sprake is van vertraging steeds aan dat er zowel bij aankomst- als vertrektijd vertraging is, terwijl daar niet altijd sprake van is. Een voorbeeld is een trein van de 5600-serie die om 18.34 op station Nijkerk aankomt en daar om 18.35 (18.34 +1) vertrekt, in de app staat alsof deze trein ook met +1 aankomt. (Dus: a: 18.34 +1 v: 18.34 +1). Ik heb meerdere reizen opgezocht op meerdere trajecten (en vergeleken met de gegevens van Treinposities) en ik ben tot deze conclusie gekomen.
Dit probleem komt overigens alleen voor als de aankomst- en vertrektijd hetzelfde is (dus bijvoorbeeld: a: 17.12 en v: 17.12). Als er een verschil is, wordt er wel onderscheid gemaakt (bijvoorbeeld: a: 22.08 en v: 22.09 +3) (of a: 08.06 +5 en v: 08.08 +4). Kan iemand hiernaar kijken en dit probleem oplossen?
Dat is wel een lastige, want hoe weet men van tevoren dat een trein die op tijd rijdt/aankomt met vertraging zal vertrekken?
Als het om 1 minuut gaat (aankomst Nijkerk) maakt het natuurlijk weinig uit, alhoewel dat natuurlijk wel het wegvallen van een overstap kan betekenen.
Aan de andere kant zit er bij een overstapstation volgens mij altijd al (meer dan) een minuut tussen aankomst- en vertrektijd, en dan speelt het probleem niet.
Ha, daar hebben we begin van de week over gesproken idd. Er was nog altijd een situatie waar, met veel kleinere verschillen, de vertrektijd voor de aankomsttijd lag. Dat komt doordat men op veel kleinere stations geen aankomstvertraging vanuit procesleiding krijgt. Die wordt dus geschat. Er komt daarna wel een actuele vertrektijd, waardoor verschil ontstaat. Men heeft dat gefixt na melding, maar waarschijnlijk introduceert dat nu dit probleem
Dat is wel een lastige, want hoe weet men van tevoren dat een trein die op tijd rijdt/aankomt met vertraging zal vertrekken?
Als het om 1 minuut gaat (aankomst Nijkerk) maakt het natuurlijk weinig uit, alhoewel dat natuurlijk wel het wegvallen van een overstap kan betekenen.
Aan de andere kant zit er bij een overstapstation volgens mij altijd al (meer dan) een minuut tussen aankomst- en vertrektijd, en dan speelt het probleem niet.
Het gaat hier vooral om het feit dat een trein op tijd aankomt, maar met +1 vertrekt (of meer) en dat dit in de app wordt getoond als aankomt met +1 én vertrek met +1. Ditzelfde natuurlijk ook met +2 en hoger. Zelfs als een trein op tijd ergens aankomt en 5 minuten te laat daar weer vertrekt, staat het a: ..:.. +5 en v: ..:.. +5
Ha, daar hebben we begin van de week over gesproken idd. Er was nog altijd een situatie waar, met veel kleinere verschillen, de vertrektijd voor de aankomsttijd lag. Dat komt doordat men op veel kleinere stations geen aankomstvertraging vanuit procesleiding krijgt. Die wordt dus geschat. Er komt daarna wel een actuele vertrektijd, waardoor verschil ontstaat. Men heeft dat gefixt na melding, maar waarschijnlijk introduceert dat nu dit probleem
Ja, klopt, dat zag je op bepaalde stations (o.a. Bilthoven en Nijkerk) best wel vaak. Ik heb zelfs een keer meegemaakt (op Deurne) dat een trein met dezelfde aankomst- en vertrektijd volgens de app met +3 aankwam en met +1 vertrok. Maar fijn dat dat er in ieder geval uit is!
Ik denk dan, dat nu de aankomsttijd gelijk wordt getrokken met de vertrektijd qua vertraging indien deze volgens dienstregeling gelijk zijn en dat daardoor dit probleem ontstaat.
Ha, daar hebben we begin van de week over gesproken idd. Er was nog altijd een situatie waar, met veel kleinere verschillen, de vertrektijd voor de aankomsttijd lag. Dat komt doordat men op veel kleinere stations geen aankomstvertraging vanuit procesleiding krijgt. Die wordt dus geschat. Er komt daarna wel een actuele vertrektijd, waardoor verschil ontstaat. Men heeft dat gefixt na melding, maar waarschijnlijk introduceert dat nu dit probleem
Twee weken later is er helaas nog niets veranderd, of dat moet toevallig de afgelopen paar uur zijn gebeurd. Nu is dit geen mega-probleem, maar ik zou het toch fijn vinden als dit probleem snel wordt verholpen. Hoe staat het ervoor?
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
Bestand scannen voor virussen
Sorry, we zijn de inhoud van dit bestand nog aan het controleren om er zeker van te zijn dat het veilig is om te downloaden. Probeer het nog een keer over een paar minuten.
