Support
Till senaste kommentaren

Tidslucka på 40–50 sekunder mellan realtidsdata och perrongtavlor

Hej,
Jag utvecklar Tunnebana app, en app som visar tunnelbanans avgångar och tåglägen med data från SL Transport och GTFS Regional Realtime.
Vid egna observationer på stationen har jag märkt följande:
  • Stationsskylten slutar visa minutantal när tåget närmar sig, ungefär 20–30 sekunder före ankomst.
  • Under stationsuppehållet, cirka 20-25 sekunder, visas fortfarande inget minutantal för tåget.
  • När tåget lämnar stationen börjar skylten visa nästa avgång.
I min app visas ibland fortfarande ”1 min” när tåget kör in. Därefter visas ”Nu”, som kan ligga kvar cirka 20-35 sekunder efter att tåget har lämnat stationen.
Jag undersöker även appens nedräkning, cache och uppdateringsintervall. Jag har ännu inte fastställt om fördröjningen uppstår i min implementation eller i underlaget från API:erna.
Jag skulle uppskatta hjälp med följande:
  1. Använder stationsskyltarna samma prognoser och statusinformation som publiceras genom SL Transport?
  2. Vilket fält eller vilken kombination av uppgifter rekommenderar ni för att avgöra att en tunnelbanetur har lämnat en specifik station?
  3. Hur ska display, expected och state tolkas när tåget närmar sig, står vid stationen och avgår?
  4. Finns det någon känd fördröjning eller cachetid som kan förklara att avgången ligger kvar efter att tåget lämnat stationen?
  5. Kan GTFS Regional Realtime ge ett tillförlitligt besked om att stationsbesöket är avslutat, eller finns begränsningar för tunnelbanan?
Målet är att undvika att appen visar ”Nu” för ett tåg som användaren inte längre kan kliva på, utan att samtidigt ta bort ett försenat tåg som fortfarande står kvar.


Tack för hjälpen!

Vänliga hälsningar,
Adam Karim
2026-09-16

Adam Karim

Kommentarer

  • Komplettering om avgångstider för tunnelbanan

    Hej igen,

    Vid fortsatt felsökning har vi hittat att min app kunde behålla ”Nu” i 30 sekunder efter prognostiden. Kompletteringen från tidtabellen kunde också återinföra en avgång som försvunnit från SL:s svar. Detta kan förklara en del av det observerade beteendet.

    Jag vill därför förtydliga att jag ännu inte har fastställt något fel i era API:er.

    Det jag framför allt behöver förstå är:

    • Vilken uppgift visar tillförlitligt att en tunnelbanetur har lämnat en viss station?
    • Kan en TripUpdate med timestamp senare än departure.time fortfarande innehålla en prognos, eller innebär det att avgången har registrerats?
    • Hur ska SL Transports state, exempelvis ATSTOP, och display användas tillsammans med expected vid ankomst och avgång?
    • Använder perrongtavlorna information som inte finns tillgänglig genom dessa API:er?
    Målet är att undvika både kvarvarande ”Nu” efter avgång och att felaktigt ta bort ett tåg som fortfarande står vid stationen.

    Tack för hjälpen!

    Vänliga hälsningar,
    Adam Karim
    Adam Karim
  • Hej Adam,

    GTFS Regional Realtime kommer indikera när en arrival eller departure har bekräftats, genom att sätta uncertainty till 0. Filerna uppdateras dock var 15e sekund, och det kan ta några sekunder innan uppdateringen kommer in, så det kan bli mer än 15s fördröjning mellan att ett tunnelbanetåg kommer fram och att TripUpdates visar den bekräftade tiden. En ankomst/avgång är endast bekräftat om uncertainty är 0, är prognosen för filens tidstämpel så är det en prognos som inte stämde, på samma sätt som att den kan stå "nu" vid bussen när den fortfarande är mer än eminut borta pga kö.

    Jag skickar frågorna angående SLs API vidare till dem.

    Hälsningar,
    Bert 
    Bert på Trafiklab
  • Hej Adam,

    Vi fick följande information från SL.

    För att avgöra om en tunnelbanetur har lämnat en viss station är DepartureState den relevanta uppgiften. DEPARTED, PASSED och MISSED innebär att avgången inte längre är aktuell för resenären. Avgångar med EXPECTED, ATSTOP, BOARDING och BOARDINGCLOSED är däremot relevanta att visa. Avgångar med status NOTEXPECTED, NOTCALLED, INHIBITED, DEPARTED, PASSED, MISSED, REPLACED, ASSUMEDDEPARTED bör inte visas.

    Display anger hur tiden ska presenteras och ska användas tillsammans med expected. ATSTOP innebär att tåget står vid stationen, medan DEPARTED visar att avgången har registrerats. JourneyState gäller hela trafikturen och har företräde framför DepartureState. SL tar bort en avgång ur systemen när expected har passerats med 60 sekunder, bland annat för att hantera uteblivna uppdateringar.

    Det finns vissa funktioner i äldre skyltsystem som har egen logik, vilket kan göra att perrongskyltarnas presentation skiljer sig från det som går att utläsa direkt ur API:erna. SL arbetar successivt med att bygga bort dessa skillnader.

    Hälsningar,
    Bert
    Bert på Trafiklab
  • Hej Bert!

    Stort tack för ditt och SL:s tydliga svar. Det hjälper mycket i felsökningen.

    Jag har två följdfrågor:

    1.Hinner statusarna DEPARTED, PASSED och MISSED normalt visas i SL Transport API innan avgången tas bort ur svaret, eller kan avgången försvinna utan att vi någonsin får dessa statusar?

    2.Vilka värden i JourneyState ska göra att avgången döljs trots att DepartureState exempelvis är EXPECTED eller ATSTOP? Finns en dokumenterad prioritetsordning eller exempel?

    Jag vill säkerställa att appen varken visar en redan avgången tur eller döljer ett tåg som fortfarande står kvar vid ett längre uppehåll.

    Tack för hjälpen!

    Vänliga hälsningar,
    Adam Karim
    Adam Karim

Kommentera eller skriv ett nytt inlägg

Ditt namn och inlägg kan ses av alla. Din e-post visas aldrig publikt.