SL Platsuppslag
Hej,
SL:s platsuppslags svar innehåller numera siteid:s som inte längre matchar de siteid:som används iövriga API:et (t.ex. realtidsinformation).
Exempel: Medborgarplatsens siteid är "9191", men söker man på "Medborgarplatsen" får man numera "300109191" som svar. "9191" syns som de sista 4 siffrorna, men vad är de övriga siffrorna?
Detsamma gäller alla andra stationer och hållplatser; de föregås av nya siffror.
Är detta en s.k. bugg eller har SL bytt siteid:s i platssupslag-API:et?
SL:s platsuppslags svar innehåller numera siteid:s som inte längre matchar de siteid:som används iövriga API:et (t.ex. realtidsinformation).
Exempel: Medborgarplatsens siteid är "9191", men söker man på "Medborgarplatsen" får man numera "300109191" som svar. "9191" syns som de sista 4 siffrorna, men vad är de övriga siffrorna?
Detsamma gäller alla andra stationer och hållplatser; de föregås av nya siffror.
Är detta en s.k. bugg eller har SL bytt siteid:s i platssupslag-API:et?
Följ inlägget
2
följare
SL har bytt vilka id:er som returneras idag för att få det att matcha mellan system igen. Det har kommit till 30010 framför varje siteId. Dessa id:er, som börjar på 30010, används till den uppdaterade versionen av reseplanerare-api:et, och ska matcha mellan alla api:er. För närliggande hållplatser är det mainMastExtId som innehåller detta id.
SL Realtid 4 har inte fått en uppdatering än men kommer få den så snart som möjligt, jag antar att den också kommer gå på dessa nya 30010 id:er.
Hälsningar,
Bert
Jag har en till fråga:
De senaste veckorna får SL:s Realdtidsinformation API ibland spel och börjar returnera "ExpectedDateTime" som ligger flera timmar bakåt i tiden ("DisplayTime" stämmer fortfarande och visar t.ex "6 min").
Detta fel varar i cirka 5 minuter, sedan fungerar det igen. För att sedan återgå till "negativa" tider, och tillbaka, och om och om igen, ibland i flera timmar.
Eftersom SL själva mest verkar använda sig av "DisplayTime", och troligtvis även de flesta API-användarna, undrar jag om detta fel överhuvudtaget har uppmärksammats?
Vår mjukvara har fått implementera en säkerhetsfunktion som övergår till att använda "DisplayTime" ifall "ExpectedDateTime" är negativ. Men det hade varit bättre om "ExpectedDateTime" var pålitligt.
//Nisse
// Bert
Jag skulle inte känna mig helt bekväm med att blint gå på detta spåret, med tanke på hur mycket dessa nya id påminner om det "HafasId" som enligt Närliggande2-dokumentationen finns i "extId".
Här är beskrivningen av Närliggandes SiteId:
"3FG1EDCBA där där FGEDCBA är de 7 sista sifforna i site.number utfyllt med nollor.
SiteId: 9600
HafasId: 300109600"
Visserligen är det väldigt tvetydigt varför beskrivningen för SiteId beskriver värdena för ett helt annat fält än SiteId ("3FG1EDCBA"), och det är oklart vad "site.number" är för något, men jag skulle ändå ha dragit slutsatsen att de nya siteId för Platsuppslag följer denna mall, och inte regeln att de "börjar med 30010". Men vad vet jag.
Konstigt var det i alla fall att få ett mejl om att "uppdatera URL:en" och sedan få inkompatibel data som en bonusöverraskning, som man bara märker om man har turen att testa den data som till ytan ser likadan ut som förut 🤷♂️
Jag fick i alla fall inte de nya långa ID att funka i SL Transport – får bara helt tomma (men korrekta) svarsdata.
Hur vet jag vad jag ska göra med dessa nya långa id? Och när jag ska göra det?
När SL ändrade värden som returneras av platsuppslag verkar man inte ha tagit hänsyn till detta i nya Transport-API:et. Detta är ett fel i API:et och har felanmälts.
Hälsningar,
Bert
Det verkar dessvärre som att buggen med "ExpectedDateTime" (numera "expected") från gamla API:t har följt med till det nya.
Som jag nämnde tidigare får man ibland ett svar med negativa avgångstider. Vad jag kan se är "expected" en timme bakåt i tiden. När jag jämför med avgångarna på SL.se så ser jag att själva avgångarna stämmer och är i rätt ordning, men deras avgångstider ("expected") är alltså en timme bakåt i tiden.
Jag tar mig friheten att spekulera i att API:t sköts av flera olika servrar, varav en eller flera av dem kanske har en felaktigt inställd lokal tid, t.ex. GMT istället för UTC+02.00. Kan det vara något sånt?
MVH
Nisse
Ibland är tiderna fel i svarsdata, detta beror på fel i bakomliggande dataflödet. Mer om detta finns i denna tråd: https://kundo.app/org/trafiklabse/d/sl-transport-api-visar-historiska-avgangar/#c4584335
Hälsningar,
Bert