Hack For Sweden
Jag deltar nästa helg på Hack for Sweden. Då jag kommer att använda trafiklab, som överlag varit en mycket positiv erfarenhet, märkte jag ett problem i hur data returneras från SL:s störningsinfo.
http://console.apihq.com/sl-storningsinformation
fältet aDetails är en sträng i nästan alla fall, men i ett fall är "aDetails": {}, alltså ett objekt. Vore mycket uppskattat om detta löstes innan helgen,
Följ inlägget
0
följare
Hej!
SL är inte med som arrangör av Hack for Sweden men man kanske ändå får använda sig av deras API i utvecklande av appar?
När det gäller att fält ibland blir tomma object är tyvärr inget vi kan ordna innan helgen men vi är medvetna om att det blir på detta sätt i vissa fall.
Lycka till på Hackatonet.
/Martin
Jag har liknande erfarenheter med realtid2. Man kan inte veta vad som kommer i ett fält utan måste testa innan man använder något tyvärr. Dokumentationen ger heller ingen fingervisning om ett fält är en sträng eller en lista av strängar. Alternativt kanske till och med en lista där fältet förekommer upprepade gånger kan förekomma?
För egen del har det varit MYCKET testande, samt insamlande av mycket data under veckor för att ha en chans att hitta de vanligaste egenheterna. Tyvärr så har man ändå inte ett helt tätt system, eftersom man ju bara vet vad man sett komma förut, inte vad som kan komma i framtiden. Se till att du testar för det du förväntar dig, och lagrar rådatan i de fall du inte förstod den så du kan förbättra allt eftersom.
Hej Peter Atterfjäll,
Det är lite sent svarat, men har du några konkreta förbättringsförslag för dokumentationen som går att genomföra? Är det några speciella fält som är otydligt dokumenterade?
Har du några förslag på vad som kan tilläggas i dokumentationen, för att minska mängden testande för insamling av data som du beskriver? Skulle t.ex. en lista med exempel-SiteId'n, på siter där det finns en stor variation av data hjälpt dig i din implementation?
Det finns många saker som skulle förenkla användandet av APIet. Ett par saker som jag tror skulle vara relativt enkla att ordna, och som ju är högaktuellt nu inför bytet till Realtid3:
1) Det är relativt tydligt vilken data som kommer, men otydligt vad den innebär. Ett par exempel.
Journeydirection. Att den skiljer på de två riktningarna hos en linje är ju uppenbart, men finns där något system? Om jag skall kunna använda den parametern ut mot användaren måste jag ju förstå och förklara för användaren, men jag har inte lyckats hitta någon förklaring.
En annan är ImportanceLevel. Om vi bortser från att jag sett stopp i trafiken märkt som level 0, vilket ju måste ha varit ett misstag, så finns det ingen förklaring vilken nivå som är vad. Om jag är intresserad endast av trafikpåverkande händelser, vilken nivå skall jag filtrera på? Att det är halt på perrongen, eller att tåget är kort är inte kritisk information i de flesta fall.
Consequesnce är en sträng där jag efter en månads insamlade tror jag hittat de olika alternativen, men jag kan ju inte veta om jag missat något viktigt för att det inte hänt ännu...
Så rent generellt skulle jag vilja se mer detaljerad information om varje fält så man tydligt vet hur det kan användas och vad som kan förväntas.
2) Det vore suveränt om det kunde finnas en testserver som i round robin skickar alla möjliga kombinationer av konstiga meddelanden, samt även några normala. Man kan låsa det så att man endast frågar på T-centralen som ju har alla typer av trafik, men där vill man se alla typer av deviations, och även om det kan finnas flera deviations på samma tur...Kanske 50 eller 100 olika svar som går runt runt. jag funderade ett tag på att bygga ihop något sådant själv baserat på all den data jag samlade in från min server, men jag hade ju ändå bara täckt in de fall jag sett. Allra bäst vore om något på SL (eller vem som nu är bäst lämpad) skulle kunna sätta sig ner och se till att alla möjliga kombinationer är med. En variant vore att helt enkelt definiera en station som inte finns, t.ex. 9999, och låta den skicka ut dessa olika obskyra kombinationer (baserad på T-centralen eller på en helt artificiell station med alla trafiktyper)
3) När man utvecklar och testar är det ju ganska enkelt att få ordning på det normala. Konsollen är suverän när man börjar, men man måste vara extremt ihärdig för att se några deviations eller speciella situationer. Mer tid borde ägnas åt att beskriva just dessa ovanliga situationer som ju troligen är det en App är mest intresserad av. Om allt är normalt behövs kanske inte ens Appen. Detta har ju mycket gemensamt med punkt 2 ovan.
4) Jag förstår att inte all information finns i flödet från tunnelbanan, men det vore fantastiskt om ni kunde hitta ett sätt att skapa den så att man fick samma information för alla trafikslag. Jag har själv funderat på om jag skulle kunna skapa ordinarie resp förväntad avgångstid för tunnelbanan t.ex., men för det behövs något som håller det samman, som t.ex. tåg och bussnummer. Jag vet inte om tillgång till detta finns så man (helst ni) kan matcha data mot tidtabeller och skapa de värden som inte finns med i flödet. Att unikt kunna definiera varje buss eller tåg vore suveränt även av andra skäl, jag har en del trevliga idéer som skulle kunna förbättra stämningen och miljön på kollektivtrafiken, men det kräver att jag vet exakt var jag är (på vilken buss etc). Kan gärna prata om det den 10e om du är där.
5) Vi har ju sett att tillgängligheten varit låg på R2, men det har blivit betydligt bättre. Vad jag dock sett några gånger är fel värden. Första gången var på 7an (spårvagnen). Där visade APIet och skylten samma tid, men 1 eller två minuter innan avgång visade plötsligt APIet att det var 6 minuter kvar. Spårvagnen avgick enligt skylten och då visade APIet att det var 4 minuter kvar till avgång. Idag hände något liknande med linje 17 från Hammarbyhöjden. Jag använder dagligen min App för att avgöra om jag skall gå fort eller inte. Enligt APIet var det 4 minuter kvar till avgång när jag kom fram så jag såg skylten, men på skylten stod det 1 minut. Detta verkar vara ett ovanligt fenomen, men är nästan värre än när man inte får något svar alls. Man måste kunna lite på den information man får. Nu medan jag skriver inser jag att det ju finns ett fält som talar om när informationen är ifrån som jag inte tittar i. kanske är det så att APIet skickat ut gammal information om den inte fått någon ny? Värdet av information mer än 60 (eller 30) sekunder gammalt är av tveksamt värde i detta API, och för att bedöma åldern måste både er och min klocka gå exakt rätt. Så skulle föredra att man åtminstone kunde välja att om ingen färsk information finns, så får man ingen. Om n i skickar ut 'gammal' information vore det bästa om ni räknade ner tiden (så man slipper synka klockorna) men indikerade med en flagga att tiden är framräknad och ev också angav hur många sekunder gammal information uppgifterna bygger på.
p.s. Första versionen av min App ligger för review hos Apple sedan snart en vecka. Jag misstänker att det kan bli en runda eller två, men finns en liten chans att den är ute till den 10e :-) d.s.
Framförallt bör svar alltid följa samma schema. Som jag tidigare skrev returneras tomma strängar som {} istället för "", vilket försvårar parsning.
Har ni kollat på Googles format? https://developers.google.com/transit/gtfs-real...
Jag säger inte att det är bättre, men har i alla fall ganska mycket information om vad som är vad.
Håller helt med Fabian, man måste hela tiden kolla vad man fått innan man utgår ifrån att man kan läsa. Om man inte gör rätt så kraschar i alla fall IOS.
@Peter
Tack för svaret.
Ska höra mig för om det går att få med detta in i dokumentationen, samt kolla på punkt 2. Borde inte vara några större problem att få med detta. Men det finns lite annat med ganska hög prio just nu, så det kommer ta lite tid för mig att kolla på detta.
Gällande punkt 1)
Jag ska kolla på en bättre förklaring.
Men har du sett Deviations där det står att det är halt på spåret? Jag har för mig att det är endast trafikpåverkande informaton som står i dem. T.ex. "Stannar ej vid Rotebro pga växelfel.". Sen så vad jag vet så är det ImportanceLevel 7-9 på dessa som används.
Gällande punkt 2)
Kan ju påpeka dock att det finns fler intressanta scenarios än Tcentralen. T.ex. Alvik(SiteId: 9112) som är den enda stationen med 3st lokalbanor(1+1 tvärbana + 1 nockebybana).
Gällande punkt 3)
Men om det finns en exempelstation som man kan använda istället är det ju bra.
Gällande punkt 4)
Gällande punkt 5)
Btw, vad händer den 10:e, som du skrev i punkt4?
@Fabian
Jag tror att problemet med tomma strängar som blir till objekt kan ha med en generell .xml till .json konvertering. Jag har för mig att trafiklab gör just en sådan konvertering för störningsinformation. Men är inte helt säker.