Resrobot Stolptidtabeller 2 och SL realtimedepartures
Hej,
Vid en jämförelse mellan Resrobot Stolptidtabeller (Beta) 2 och SL Realtidsinformation 3 finns det vissa skillnader som jag noterat.
- SL visar tid i sekunder, detta gäller både tid enligt tidtabell och förväntad avgång. Resrobot visar ej sekunder för varken tidtabell eller realtid.
- Tiden under realtid från SL och Resrobot är olika, eller SLs API tar kanske med realtid längre fram än vad Resrobot gör?
Ett exempel för samma avgång.
SL
TimeTabledDateTime: "2015-09-10T19:50:06",
ExpectedDateTime: "2015-09-10T19:52:22",
Resrobot
time: "19:50:00",
date: "2015-09-10",
rtTime: "19:50:00",
rtDate: "2015-09-10",```
Tyder detta på bugg/buggar i beta versionen av Resrobots nya API eller kommer informationen från olika håll?
Följ inlägget
0
följare
Hej Johan,
Resrobots Stolptids API kommer att uppgraderas till nyare version av SL' s realtidsAPI inom en snar framtid (max två månader).
Skillnaden borde då försvinna (om den finns i nuläget). Du kan ha rätt i att det kan vara olika system som genererar realtidsvaret och är orsaken till skillnaden.För vilket trafikslag var ditt exempel?
Har du möjlighet att själv välja realtids API så är det nog bäst att direkt anropa SL's realtidsAPI för tillfället. Det rekommenderas om din lösning är för SL's trafik.
rtTime/rtDate i APIsvaret är endast ifyllda om realtidsinformation finns för avgången. Fälten saknas i svaret, om svaret är helt tidstabellsbaserat.
Med vänlig hälsning, Åke
Tack för svar. Exemplet var hämtat från en buss.
Handlar det om brist på data att det inte finns med sekunder eller är det per design i Resrobot? Förstår att tider som presenteras inte är exakta/precisa men 30s hit eller dit kan göra en del om ett resultat kommer med vid en fråga. Så vill framföra ett önskemål om tillägg av sekunder om det finns möjlighet.
Nedan exempel visar på upp till 45 sekunders diff.
Resrobot
time: "10:40:00",
date: "2015-09-11",
SL
TimeTabledDateTime: "2015-09-11T10:40:45"
Frågorna mot SL och Resrobot ställdes parallellt och det är tydligt att svaren skiljer sig. Har idag även gjort live tester (på stan) med data som går mot Resrobot, där SLs realtidsapi ligger i synk med SLs skyltsystem för bussar medan det för Resrobots API kan skilja sig på ett par minuter.
Hej Johan,
Avgångstider (och alla andra tider i Resrobots APIer) utan sekunder följer Samtrafiken egna önskemål som gäller i vårt egna gränssnitt Resrobot. I Resrobot visas inte sekunder, då Samtrafiken bara skulle kunna få tillgång till det från någon enstaka operatör (SL).
Vi planerar inte att ändra på detta i nuläget.
Orsaken till att realtidsinformationstiderna skiljer sig åt får vi undersöka vidare. Troligen, kommer du se att Resrobot också visar fel (i de fall som du upptäcker).
Med vänlig hälsning, Åke
Förstår ert resonemang om sekunder, sista inlägg om det från mig i ämnet, i fallet med 45 sekunders diff, kommer den avgången listas om frågan ställs vid "10:40:10"?
Hur är det med de andra källorna för realtid utöver SL, föreslår ni att gå direkt mot deras system för avgångar med eller är detta bara ett problem för SL?
Tack!
Hej Johan,
Då färdmedlet inte avgått 10:40:10 (10:40:00 i tidtabellsdata) så borde det finnas med i realtidsinformation satt till avgångstid 10:40:00 (samma som tidtabellstiden).
Först 10:40:46, om det anländer med 45 sekunders diff enligt ditt scenario, borde avgången försvinna från realtidsinformationen, om nu SL's realtidssystem filtrerar bort informationen som man kan önska sig.
10:41:00 försvinner sedan tidstabellsavgången från svaret.
Det är svårt att beskriva de olika realtidsdatakällornas logik - då vi saknar insyn hur dessa fungerar internt. Har du möjlighet att gå direkt mot källorna är det nog den bästa lösningen för dig. Då får du även med sekunder (om det finns med) i ditt svar.
Med vänlig hälsning, Åke