Statisk GTFS Skånetrafiken ej uppdaterad i tid (GTFS-RT med nya trips)
Varje dag dyker nya trips upp i Skånetrafikens GTFS-RT flöden. Men statisk GTFS som är en dag gammal innehåller inte dessa nya Best practice är minst 7 dagars framförhållning på statisk GTFS - annars ska "trippen" göras med ADDED och inte SCHEDULED.
Följ inlägget
2
följare
Turer som läggs in som ADDED i GTFS-RT saknar mycket av informationen som finns i statisk GTFS. Det gäller attributions, shapes, stop_headsign, pickup_type, drop_off_type, timepoint, booking_rules och transfers. Vissa av dessa har experimentellt stöd i GTFS-RT, men Trafiklab har inte det. De andra går inte att lägga in i GTFS-RT alls.
Ett annat problem är att Trafiklab lägger in turer i TripUpdates först när fordonet står vid första hållplatsen. Om man lägger turer som ADDED går de alltså inte att se att de kommer köras förrän precis innan. Då blir det bättre framförhållning om man lägger in turerna i statisk GTFS natten innan. Det skulle förstås gå att lösa genom att turerna läggs in som ADDED i GTFS-RT med en gång när det har bestämts att turerna ska köras, men vet inte om Trafiklab klarar det.
Det som däremot skulle vara bra, och som borde vara ganska lätt att ordna, är att lägga in feed_version i GTFS-RT, så att man kan veta när det GTFS-static har uppdaterats. Skrev om det i https://support.trafiklab.se/org/trafiklabse/d/trip_id-andras-for-din-tur-gtfs-regional/#c4876289
TripUpdates borde synas tidigare och med samtliga stops' om leverantören känner till det. Det är en "best practice" att en ADDED ska synas i GTFS-RT med så mycket information och så tidigt som möjligt (med andra ord samtliga stops till exempel), men Trafiklab eller operatörerna här i fråga i Sverige verkar inte riktigt följa det.
Vi publicerar TripUpdates så fort att vi får in dem, de flesta realtidssystem börjar dock endast skicka turer när föraren anmäler sig på turen. Det är upp till operatörer att i dessa fall skapa upp turer i deras realtidssystem i förväg. När förstärkningsturer eller liknande läggs in i realtid brukar det också vara beslut som tas då, så det är naturligt att dessa ADDED turer dyker upp typ när de påbörjas.
När det gäller avgränsningen mellan statiska och realtidsdata så beror detta på hur rutinerna ser ut hos trafikhuvudmannen (tex skånetrafiken i detta fall) om vad som ska in i de planerade data och när det blir realtidsdata. Som Robert påpekar så är det endast best practices, och finns det anledningar till varför man kan avvika från dem. Datat läggs upp på det sättet som passar den operativa verksamheten bäst, det är inget vi kan eller vill ändra på för att följa best practices i GTFS standarden. Den enda riktlinjen är att turer som påbörjas samma trafikdag måste komma in i realtidsdatat, eftersom att det inte sker några uppdateringar av de statiska GTFS data under dagen. Sen är det såklart en nice-to-have om förändringar i de planerade data finns i god tid, det är något som kollektivtrafikmyndigheterna också håller med om.
Angående feed_id håller vi med att det vore bra, vi kollar om vi kan implementera detta. Det finns dock inget estimat om när detta kan vara på plats.
Hälsningar,
Bert
Min synpunkt kanske mer ska riktas till Skånetrafiken som systematiskt varje dag kommer med nya SCHEDULED som kräver ny statisk data varje dag.
Förvisso är det precis du Bert och Robert säger att det bara är en best practice att ha bättre framförhållning på statisk data versus när en SCHEDULED börjar dyka upp i realtidsdata - men även best practicies vore bra om dom följs. Men jag tar det med Skånetrafiken.