Nya GTFS Regional

GTFS-RT för SL funkar fortfarande inte. GTFS-RT för Kronoberg funkar inte och har aldrig någonsin gjort vad jag kan minnas. Kommer ni att behålla gamla GTFS Regional om GTFS-RT för SL fortfarande inte funkar efter 1 december?
Robert Rapportera olämpligt innehåll

Kommentarer

  • Hej Robert,

    Vi ber om ursäkt att det tar sån lång tid att få upp SLs realtidsdata i nya API:et, jag fattar att det gör det svårt för att flytta applikationer från den gamla till nya API:et.

    SLs GTFS-RT borde vara tillgängligt i några dager. Vi ska ha gamla API:et kvar så längre SLs realtidsdata inte funkar i nya API:et, och vi lämnar lite tid efter den funkar så att alla kan migrera. Vi kommer inte att ta ner gamla API:et innan 14e december.

    Vi inte har GTFS-RT för Kronoberg, eftersom vi inte ännu får in realtidsdata från dem. Det verkar som det var ett fel i vår dokumentation, vi fixade det.

    Hälsningar,
    Bert
    Bert på Trafiklab
  • Märker att nya API:et funkar nu för SL. Det är dock ett problem och det är att väldigt många turer i nya API:et identifieras med route_id,start_time och direction_id istället för med trip_id, när de i gamla API:et identifieras med trip_id. Det är önskvärt att trip_id finns där det är möjligt. Hur länge kommer ni att ha kvar gamla API:et?
    Robert
  • Det nya API:et är inte alls bra. En kombination av route_id,start_time och direction_id kan inte användas som unik identifierare. Se till exempel tidtabellen https://sl.se/ficktid/vinter/v165.pdf . Det finns två turer mot Liljeholmen som startar 05:50, den ena från Farsta centrum och den andra från Högdalen. I filen som jag laddade ner från det nya API:et angavs båda dessa med samma route_id,start_time och direction_id.
    Jag har återgått till det gamla API:et nu.
    Robert
  • Hej Robert!

    Vilken API menar du när du pratar om "gamla api:et"?

    Om jag kollar på tidstabellen ser jag 2 trips på samma linje, med samma avgångstid och riktning. I sån fall är det korrekt om GTFS Regional anger båda med samma route_id, start_time och direction_id. De 3 fält är ingen unik identifiering, det är bara trip_id som verkligen kan peka till en unik trip. Alla GTFS datasets som vi erbjuder på Trafiklab har trip_ids. Om du menar vår GTFS-RT filer, de bara refererar till en trip_id om de kan länkas till en specifik trip. Om de innehåller en route_id utan trip_id kan de inte blir länkad till en specifik trip. Hur ofta har du detta problem, och om det är GTFS-RT, vilka filer är det?

    Hälsningar,
    Bert
    Bert på Trafiklab
  • Det är GTFS-RT som jag syftar på.

    Jag har undersökt felet närmare och kollat gamla loggar. Felet med turer utan trip_id är inget nytt utan har funnits hela tiden både i nya och gamla api:et och det gäller inte bara SL utan alla aktörer. I det gamla api:et har felet uppstått varje natt vid 3-tiden ungefär. Det är inte exakt samma tid varje natt, och inte exakt samtidigt för de olika aktörerna, men det är alltid ungefär vid 3-tiden. För de turer som drabbas av problemet finns felet kvar tills turen avslutas och försvinner från systemet, dock verkar felet rättas om turen fortfarande finns kvar efter en timme. I det nya api:et är det likadant, men felet uppstår vid 6-tiden istället för vid 3-tiden.
    Robert
  • Hej Robert!

    Gamla API:et uppdateras med ny data kl.3 varje morgon. Nya API:et har en uppdatering av statiskt data kl.4-6. Det kan vara att det uppstår en diskrepans mellan statiska och realtidsdata när dessa uppdateringar sker. I framtiden (när vi stänger ner gamla API:et) kommer vi att flytta uppdateringar av nya API:et så att de händer på samma tid som gamla API:et idag.

    Jag undersöker lite mer om vi kan minimalisera dessa problem efter julledighet.

    Hälsningar och vi önskar dig ett gott nytt år,
    Bert

    Bert på Trafiklab

Kommentera eller skriv ett nytt inlägg

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