Dataflöden med trafikinformation från SL
Moderatorer: Jourmaster, Infomaster
Kategoriregler
Övriga diskussioner om lokaltrafik som ej platsar i andra forum. (exempelvis lokaltrafik med båtar)
Allmänna forumregler
Övriga diskussioner om lokaltrafik som ej platsar i andra forum. (exempelvis lokaltrafik med båtar)
Allmänna forumregler
Dataflöden med trafikinformation från SL
Som jag konstaterade i ett annat inlägg visar realtidsskylten vid hpl Årstaskolan just nu korrekt information, inga avgångar och en förklarande text att trafiken är inställd. Men om jag använder appen "SL realtid" (från en extern leverantör) radas avgångarna upp.
Jag trodde att det var samma dataflöde som styrde såväl intern som extern realtidspresentation, men så är uppenbarligen inte fallet.
VARFÖR?
/TKO
Jag trodde att det var samma dataflöde som styrde såväl intern som extern realtidspresentation, men så är uppenbarligen inte fallet.
VARFÖR?
/TKO
Völker, hört die Signale! Auf zum letzten Gefecht!
Re: Dataflöden med trafikinformation från SL
Inget är så enkelt. Men som M_M visat i ett annat inlägg finns det ju olika api:er - använder din app det api som är kopplat till Realtidsinformation 3, så ska i alla fall ändringarna synas, alltså i svaret i strängen på anropet under "Deviations". En avgång försvinner ju aldrig av sig självt, utan kräver ju att någon tar bort avgången. Troligtvis bygger dock den app som du använder på resrobots stolptidsapp - och den visar inte deviations. Borde dock uppdateras om avgången tas bort. Men här kan det nog ändå fungera olika beroende på hur systemet hanterar detta, möjlighet att det finns en skillnad här beroende på vilket bakomliggande system som informationen hämtas ifrån. Kan tänka mig att resrobot hämtar direkt från RUST, medan realtidsinformation 3 hämtar från det system som operatören använder för att kunna lägga till trafikinformation etc till realtidsskyltarna.TKO skrev:Som jag konstaterade i ett annat inlägg visar realtidsskylten vid hpl Årstaskolan just nu korrekt information, inga avgångar och en förklarande text att trafiken är inställd. Men om jag använder appen "SL realtid" (från en extern leverantör) radas avgångarna upp.
Jag trodde att det var samma dataflöde som styrde såväl intern som extern realtidspresentation, men så är uppenbarligen inte fallet.
VARFÖR?
/TKO
--- Inlägget är signerat Lars Lundqvist,
Re: Dataflöden med trafikinformation från SL
Jag hävdar fortfarande - till motsatsen bevisats - att inget av SLs dataflöden gällande busstrafiken visar det faktiska (sanna) läget för varje buss. Därför är det omöjligt att visa en sådan karta som jag hänvisade till i mitt inledningsinlägg.
Ingen vore gladare än jag om jag har fel i denna fråga - men visa det i så fall...
(Ja jag vet att jag närmar mej 'rättshaveriststatus' när det gäller SLs reseplaneringsdata, men jag tror ärligt talat inte på dessa)
I morgon när jag är mindre trött (och inte lika påverkad av verdiccion jag drack till middag för att glömma novembervädret) ska jag ta en ny funderare på detta.
God natt mina vänner
/TKO
Ingen vore gladare än jag om jag har fel i denna fråga - men visa det i så fall...
(Ja jag vet att jag närmar mej 'rättshaveriststatus' när det gäller SLs reseplaneringsdata, men jag tror ärligt talat inte på dessa)
I morgon när jag är mindre trött (och inte lika påverkad av verdiccion jag drack till middag för att glömma novembervädret) ska jag ta en ny funderare på detta.
God natt mina vänner
/TKO
Völker, hört die Signale! Auf zum letzten Gefecht!
-
- Inlägg: 68
- Blev medlem: lördag 17 december 2011 20:10
Re: Dataflöden med trafikinformation från SL
På bilden du la upp förut på realtisskylten visades ju fortfarande alla avgångar som skulle ha gått då, men de la in ett meddelande till varje avgång om att den aldrig kommer att komma. När din app sen hämtar info följer inte det meddelandet med, och det ser därför ut som att trafiken går som vanligt. Dumt utformat.
känslan när man missar tuben med 1 sekunds marginal....
Re: Dataflöden med trafikinformation från SL
Om det var så på bilden att avgångstiderna var kvar, är det ju uppenbart att appen inte valt att ta med det fältet, så det får du nog tala med app-tillverkaren om. Deviation finns ju med i svaret som api:en ger, ifall man använder realtidsinformation 3. Den informationen finns ju också med om man använder SL:s realtidsinformation på hemsidan.
Sedan det här med realtidsinformation. Vi har ju varit inne på detta i andra trådar. Men det finns ju alltså två tider som API:en genererar, men sedan är även systemet som tar emot informationen programmerat för vilken som ska visas och när. Här finns en del ganska stora brister i hur man valt att använda den informationen - men också fördelar. Dock gör det att man förstås inte kan använda api-informationen på samma sätt ifall man nu skulle vilja ha en rättvis bild över bussarnas position.
Det hela beror på att den tid man väljer att visa är tidtabellstid, fram till en viss tid före bussens avgång. Orsaken till detta är nog flera, men en orsak skulle jag tro är att begränsa antalet anrop, en annan förstås att prognosen blir rätt dålig när det är för lång tid innan som realtiden visas. Sedan kan ju inte tiden, heller prognos göras om bussen inte avgått från ändstationen ännu - i de fall föraren inte är inloggad på omloppet (eller om avgången föregås av tomkörning (utan inlagt linjenummer), eller paus/rast.
Därtill blir det förstås ofta kortare fel, så att svarstiderna på anropen blir försenade, varvid ingen uppdatering av tiderna sker etc.
Dock finns ju i RUST på sekunden och gps-information om var bussarna befinner sig (när de går i trafik), så det är ju inget svårt att bygga upp en sådan app om man vill. En sådan app bör ju antagligen inte använda tidtabellstiden - behövs ju inte om inga avgångar visas. Eller då alternativt att man inte använder tidtabellstid för att visa bussarnas position, utan endast för att visa stolptider.
Sedan det här med realtidsinformation. Vi har ju varit inne på detta i andra trådar. Men det finns ju alltså två tider som API:en genererar, men sedan är även systemet som tar emot informationen programmerat för vilken som ska visas och när. Här finns en del ganska stora brister i hur man valt att använda den informationen - men också fördelar. Dock gör det att man förstås inte kan använda api-informationen på samma sätt ifall man nu skulle vilja ha en rättvis bild över bussarnas position.
Det hela beror på att den tid man väljer att visa är tidtabellstid, fram till en viss tid före bussens avgång. Orsaken till detta är nog flera, men en orsak skulle jag tro är att begränsa antalet anrop, en annan förstås att prognosen blir rätt dålig när det är för lång tid innan som realtiden visas. Sedan kan ju inte tiden, heller prognos göras om bussen inte avgått från ändstationen ännu - i de fall föraren inte är inloggad på omloppet (eller om avgången föregås av tomkörning (utan inlagt linjenummer), eller paus/rast.
Därtill blir det förstås ofta kortare fel, så att svarstiderna på anropen blir försenade, varvid ingen uppdatering av tiderna sker etc.
Dock finns ju i RUST på sekunden och gps-information om var bussarna befinner sig (när de går i trafik), så det är ju inget svårt att bygga upp en sådan app om man vill. En sådan app bör ju antagligen inte använda tidtabellstiden - behövs ju inte om inga avgångar visas. Eller då alternativt att man inte använder tidtabellstid för att visa bussarnas position, utan endast för att visa stolptider.
--- Inlägget är signerat Lars Lundqvist,
Re: Dataflöden med trafikinformation från SL
God morgon kamrater!
Tack för all information, jag skall försöka smälta detta.
Några frågor:
Jag antar att RUST är ett av SL:s alla informationssystem, som bland annat innehåller positionsdata för varje busstur. Finns det ett API som innehåller just dessa data?
Om SL redan har alla grunddata som behövs för att ta fram en "positionskarta" tycker jag det är märkligt om man inte redan har en sådan. Den borde kunna vara till stor nytta, t ex för trafikledare. Och även för de som jobbar med trafikupplysning, eftersom man med en snabb koll kan se om den information som presenteras i andra system är rimlig. ("Oj, det är inte en enda buss ute på 160 - då är det knappast troligt att det kommer någon buss till Årstaskolan om 3 minuter trots att det står så")
Jag inser (tror jag!) att den felaktiga information som emellanåt presenteras i tredjepartsapplikationer oftast (?) beror på applikationen, inte på fel i SL:s dataflöde.
Jag har tittat på api-dokumentationen för SL Realtid 3. Där finns tre fält för "avgångstid":
TimeTabledDateTime
ExpectedDateTime
DisplayTime
Jag antar att TimeTabledDateTime innehåller data även för en inställd tur, det är ju tidtabellstiden som avses.
Däremot borde ExpectedDateTime vara tomt om turen är inställd.
Men hur är det med fältet DisplayTime? Har det samma värde som visas på realtidsskylten vid hållplatsen? Och hur förhåller sej detta tidsvärde till de två ovan?
(Det kanske är väl långt att börja diskutera ett api så i detalj här, men kan man diskutera radier på hjulflänsar så...!)
Hade detta varit för 30 år sedan hade jag nog satt mej ner och försökt knåpa ihop en egen app (eller program som det hette då) men nu inser jag att jag dels glömt det mesta, dels att det jag kommer ihåg inte längre är gångbart! Så jag får ställa mitt hopp till yngre generationer.
Idag verkar dock bussarna rulla på här utanför mitt fönster.
Thomas K Ohlsson
Tack för all information, jag skall försöka smälta detta.
Några frågor:
Jag antar att RUST är ett av SL:s alla informationssystem, som bland annat innehåller positionsdata för varje busstur. Finns det ett API som innehåller just dessa data?
Om SL redan har alla grunddata som behövs för att ta fram en "positionskarta" tycker jag det är märkligt om man inte redan har en sådan. Den borde kunna vara till stor nytta, t ex för trafikledare. Och även för de som jobbar med trafikupplysning, eftersom man med en snabb koll kan se om den information som presenteras i andra system är rimlig. ("Oj, det är inte en enda buss ute på 160 - då är det knappast troligt att det kommer någon buss till Årstaskolan om 3 minuter trots att det står så")
Jag inser (tror jag!) att den felaktiga information som emellanåt presenteras i tredjepartsapplikationer oftast (?) beror på applikationen, inte på fel i SL:s dataflöde.
Jag har tittat på api-dokumentationen för SL Realtid 3. Där finns tre fält för "avgångstid":
TimeTabledDateTime
ExpectedDateTime
DisplayTime
Jag antar att TimeTabledDateTime innehåller data även för en inställd tur, det är ju tidtabellstiden som avses.
Däremot borde ExpectedDateTime vara tomt om turen är inställd.
Men hur är det med fältet DisplayTime? Har det samma värde som visas på realtidsskylten vid hållplatsen? Och hur förhåller sej detta tidsvärde till de två ovan?
(Det kanske är väl långt att börja diskutera ett api så i detalj här, men kan man diskutera radier på hjulflänsar så...!)
Hade detta varit för 30 år sedan hade jag nog satt mej ner och försökt knåpa ihop en egen app (eller program som det hette då) men nu inser jag att jag dels glömt det mesta, dels att det jag kommer ihåg inte längre är gångbart! Så jag får ställa mitt hopp till yngre generationer.
Idag verkar dock bussarna rulla på här utanför mitt fönster.
Thomas K Ohlsson
Völker, hört die Signale! Auf zum letzten Gefecht!
Re: Dataflöden med trafikinformation från SL
Blev tvungen att läsa på. Lätt att man spårar ur när man diskuterar alla SL:s system. RUST är tydligen bara namnet på själva statistiksystemet. Så rätt benämning är egentligen SLBIW (Beställarens datawarehouse), Ifrån den hämtas all grunddata. För själva realtidsinformationen använder man en plattform som kallas för Realtidsplattformen. Därifrån hämtas information direkt från bla. trafikledarsystem och SH (störningshanteraren), men därifrån hämtas då också informationen till skyltsystemen. Konsekvensen av detta blir att vill du ta bort en avgång, så gör man inte det i realtidsplattformen utan då troligen i direkt i de system som sköter skyltarna.
Man kan få fram exempel på hur API genereras (här från Slussen kl.12.00). DisplayTime är alltså naturligen bara formatet som visas på skylten (det vill säga X- minuter kvar till avgång). Saknas realtidsinformation visas då tidtabellstiden. Skulle istället realtidstiden visas när det inte finns någon, så skulle det ju bli tomt och skulle ge lika dålig information. Observera dock att "ExpectedDateTime" bara tycks räkna fram tiden trots att bussen inte (troligtvis) avgått från Sofia. Den ger alltså en prognos utifrån att bussen ännu inte avgått och körtiden till Slussen - som då verkar vara "standardinlagd" och inte enligt faktisk körtid för aktuell tur i prognosverktyget. För att det ska fungera med att visa positionerna för bussarna, måste man alltså programmera som så att ifall ingen realtid kan visas - så syns inte heller bussen:
"JourneyDirection": 2,
"GroupOfLine": null,
"StopAreaName": "Slussen",
"StopAreaNumber": 11002,
"StopPointNumber": 11006,
"StopPointDesignation": null,
"TimeTabledDateTime": "2016-11-11T11:44:00",
"ExpectedDateTime": "2016-11-11T12:04:59",
"DisplayTime": "11:44",
"Deviations": [
{
"Text": "Inställd",
"Consequence": "CANCELLED",
"ImportanceLevel": 0
}
],
"TransportMode": "BUS",
"LineNumber": "57",
"Destination": "Karolinska sjukhuset",
"SiteId": 9192
Man kan få fram exempel på hur API genereras (här från Slussen kl.12.00). DisplayTime är alltså naturligen bara formatet som visas på skylten (det vill säga X- minuter kvar till avgång). Saknas realtidsinformation visas då tidtabellstiden. Skulle istället realtidstiden visas när det inte finns någon, så skulle det ju bli tomt och skulle ge lika dålig information. Observera dock att "ExpectedDateTime" bara tycks räkna fram tiden trots att bussen inte (troligtvis) avgått från Sofia. Den ger alltså en prognos utifrån att bussen ännu inte avgått och körtiden till Slussen - som då verkar vara "standardinlagd" och inte enligt faktisk körtid för aktuell tur i prognosverktyget. För att det ska fungera med att visa positionerna för bussarna, måste man alltså programmera som så att ifall ingen realtid kan visas - så syns inte heller bussen:
"JourneyDirection": 2,
"GroupOfLine": null,
"StopAreaName": "Slussen",
"StopAreaNumber": 11002,
"StopPointNumber": 11006,
"StopPointDesignation": null,
"TimeTabledDateTime": "2016-11-11T11:44:00",
"ExpectedDateTime": "2016-11-11T12:04:59",
"DisplayTime": "11:44",
"Deviations": [
{
"Text": "Inställd",
"Consequence": "CANCELLED",
"ImportanceLevel": 0
}
],
"TransportMode": "BUS",
"LineNumber": "57",
"Destination": "Karolinska sjukhuset",
"SiteId": 9192
--- Inlägget är signerat Lars Lundqvist,
-
- Inlägg: 763
- Blev medlem: söndag 21 augusti 2016 8:02
Re: Dataflöden med trafikinformation från SL
Ingen tvekan om att det är en "tung" debatt (i betydelsen viktig, frekvent eller vad man nu vill väga in i ordet), det här med restidsplanerare och realtidsinformation. Bara de senaste dagarna hittar jag inlägg om sånt i minst 8 olika tråddiskussioner:Lars_L skrev:Blev tvungen att läsa på. Lätt att man spårar ur när man diskuterar alla SL:s system. RUST är tydligen bara namnet på själva statistiksystemet. Så rätt benämning är egentligen SLBIW (Beställarens datawarehouse), Ifrån den hämtas all grunddata. För själva realtidsinformationen använder man en plattform som kallas för Realtidsplattformen. Därifrån hämtas information direkt från bla. trafikledarsystem och SH (störningshanteraren), men därifrån hämtas då också informationen till skyltsystemen. Konsekvensen av detta blir att vill du ta bort en avgång, så gör man inte det i realtidsplattformen utan då troligen i direkt i de system som sköter skyltarna.
Man kan få fram exempel på hur API genereras (här från Slussen kl.12.00). DisplayTime är alltså naturligen bara formatet som visas på skylten (det vill säga X- minuter kvar till avgång). Saknas realtidsinformation visas då tidtabellstiden. Skulle istället realtidstiden visas när det inte finns någon, så skulle det ju bli tomt och skulle ge lika dålig information. Observera dock att "ExpectedDateTime" bara tycks räkna fram tiden trots att bussen inte (troligtvis) avgått från Sofia. Den ger alltså en prognos utifrån att bussen ännu inte avgått och körtiden till Slussen - som då verkar vara "standardinlagd" och inte enligt faktisk körtid för aktuell tur i prognosverktyget. För att det ska fungera med att visa positionerna för bussarna, måste man alltså programmera som så att ifall ingen realtid kan visas - så syns inte heller bussen:
"JourneyDirection": 2,
"GroupOfLine": null,
"StopAreaName": "Slussen",
"StopAreaNumber": 11002,
"StopPointNumber": 11006,
"StopPointDesignation": null,
"TimeTabledDateTime": "2016-11-11T11:44:00",
"ExpectedDateTime": "2016-11-11T12:04:59",
"DisplayTime": "11:44",
"Deviations": [
{
"Text": "Inställd",
"Consequence": "CANCELLED",
"ImportanceLevel": 0
}
],
"TransportMode": "BUS",
"LineNumber": "57",
"Destination": "Karolinska sjukhuset",
"SiteId": 9192

Märkligt fel i Västtrafiks reseplanerare
Appar med SL-information
MTR tar över SL pendeltåg
SL och konsten att informera
"Busskarta" i realtid för Stockholm?!
Måste man vara högutbildad för att resa med SL?
Vilka garage kör vilka bussar i Stockholm?
Förvirrat i Farsta. (Islandstorget? Vällingby? Åkeshov?)
Först bara en liten praktisk minimal synpunkt om att i SL-appen, som jag lobbat för tidigare, så har jag sett ett litet rött utropstecken på vissa avgångar, som när man klickar vidare på, har visat samma störningsinformation som på skyltarna vid hållplatserna/stationerna. Därmed förstås inte sagt att det alltid är så, bara att möjligheten existerar.
Men jag ser nog en möjlig liten invändning mot att det är precis samma information som visas i restidsplanerare och på skyltar vid hållplatserna/stationerna som ska användas som underlag för en karta med positioner. Ja, jag skriver det istället för i karttråden, men jag tyckte det var mest relevant att göra det här. Det kanske är uppenbart, inte så det menas, eller redan nämnt i någon av alla trådarna, men ber i så fall om överseende med det.

Ska man resa nånstans, antingen i tanken om man sitter hemma i soffan och planerar, eller i verkligheten om man är ute på stan och flanerar, så bryr man sig inte om ifall det är realtidsinformation eller tidtabellstid som visas. Så länge realtiden inte visar sig avvika från tidtabellstiden! Får man se nästa avgång och de därpå följande avgångarna från påstigningsplatsen så är man nöjd med det. Det är ett helt annat behov än att se de FAKTISKA positionerna för olika turer. Just my two cents!
