Vilken datakälla anger att en specifik SL-avgång är inställd?
Hej,
Jag utvecklar en app som använder SL:s öppna data via Trafiklab och försöker förstå hur inställda tunnelbaneavgångar ska identifieras på ett säkert sätt.
I ett konkret fall vid Skärholmen, linje 13 mot Norsborg, visade SL-appen två avgångar som “Inställd” (planerade 00:39 och 00:42), medan SL Departures-data som vår backend hade tillgång till fortfarande angav avgångarna som försenade/EXPECTED och inte inställda.
Vi har även kontrollerat GTFS-RT TripUpdates, VehiclePositions och SL Deviations, men har ännu inte kunnat hitta en entydig cancellation-signal för just dessa avgångar.
Min fråga är därför:
Med vänliga hälsningar
Adam Karim
Jag utvecklar en app som använder SL:s öppna data via Trafiklab och försöker förstå hur inställda tunnelbaneavgångar ska identifieras på ett säkert sätt.
I ett konkret fall vid Skärholmen, linje 13 mot Norsborg, visade SL-appen två avgångar som “Inställd” (planerade 00:39 och 00:42), medan SL Departures-data som vår backend hade tillgång till fortfarande angav avgångarna som försenade/EXPECTED och inte inställda.
Vi har även kontrollerat GTFS-RT TripUpdates, VehiclePositions och SL Deviations, men har ännu inte kunnat hitta en entydig cancellation-signal för just dessa avgångar.
Min fråga är därför:
- Vilken datakälla eller vilket fält bör användas för att avgöra att en specifik tunnelbaneavgång är inställd?
- Kan SL-appen använda en annan källa än SL Departures/GTFS-RT/Deviations för denna information?
- Finns det något särskilt state, journey.state, schedule_relationship, stop-level-status eller annat fält som ska tolkas som inställd?
- Hur bör man hantera fall där Departures fortfarande visar EXPECTED/NORMALPROGRESS, men SL-appen redan visar “Inställd”?
- Finns det någon rekommenderad och dokumenterad metod för att koppla cancellation-status till rätt avgång vid en specifik station?
Med vänliga hälsningar
Adam Karim
Följ inlägget
2
följare
Inställda turer hittas i SLs GTFS Regional Realtime, i TripUpdates. En inställd tur har trip.schedule_relationship satt till CANCELED.
En inställd tur saknar ofta trip_id, så den behöver matchas på andra fält:
- Stop_id i stops.txt matchas mot turens stop_time_update
Här är ett exempel på en inställd tur med ett par stopp i TripUpdates:entity {
id: "14050001986631085"
trip_update {
trip {
start_time: "16:52:09"
start_date: "20260929"
route_id: "9011001001100000"
schedule_relationship: CANCELED
direction_id: 1
}
stop_time_update {
stop_sequence: 11
arrival {
delay: 35
time: 1790694020
}
departure {
delay: 68
time: 1790694089
}
stop_id: "9022001003251001"
}
stop_time_update {
stop_sequence: 12
arrival {
delay: 36
time: 1790694141
}
departure {
delay: 66
time: 1790694201
}
stop_id: "9022001003261001"
}
}
Trots att turen är inställd har hållplatserna kvar sina ankomst- och avgångstider. Så kolla på turens status så hittar du de inställda avgångarna.
Om du vill använda SLs egna APIer kan du hitta info i SL Transport. Där har varje departure fältet state, och när det har värdet CANCELLED är avgången inställd.
Trots inställda avgångar kan turens state visas som NORMALPROGRESS, så inställda turer kontrolleras på avgångs-nivå.
Du kan också läsa fältet consequence på avgångens deviations. Om värdet där är CANCELLED är avgången inställd.
Hälsningar,
Linnea
Det finns även rapporter med missmatch i korrelering mellan trip updates och vehicle positions vad gäller olika vehicle id på samma trip.