Hur fångar man inställda turer i SIRI?
Hej! Vi använder NeTEx Regional + SIRI för att jämföra data från flera kollektivtrafikhuvudmän.
Vi förstår inte hur vi ska fånga inställda turer på ett pålitligt sätt.
Vi lyckas fånga några, men ytterst få inställda turer med dessa regler för SIRI-ET:
- siri:Cancellation is true for the siri:EstimatedVehicleJourney.
- siri:Cancellation is true for the siri:RecordedCall or siri:EstimatedCall of every stop point.
Vi anar att det antingen är för att de flesta inställda turer aldrig dyker upp i SIRI-ET, eller för att de flesta inställda turer ser ut på något annat sätt.
Finns det något sätt att fånga inställda turer med NeTEx Regional + SIRI? Eller behöver man komplettera med GTFS-RT eller annan källa för att fånga inställda turer på ett pålitligt sätt?
Vi förstår inte hur vi ska fånga inställda turer på ett pålitligt sätt.
Vi lyckas fånga några, men ytterst få inställda turer med dessa regler för SIRI-ET:
- siri:Cancellation is true for the siri:EstimatedVehicleJourney.
- siri:Cancellation is true for the siri:RecordedCall or siri:EstimatedCall of every stop point.
Vi anar att det antingen är för att de flesta inställda turer aldrig dyker upp i SIRI-ET, eller för att de flesta inställda turer ser ut på något annat sätt.
Finns det något sätt att fånga inställda turer med NeTEx Regional + SIRI? Eller behöver man komplettera med GTFS-RT eller annan källa för att fånga inställda turer på ett pålitligt sätt?
Följ inlägget
1
följare
Det stämmer att en EstimatedVehicleJourney med Cancellation = true anger att en hel tur är inställd. När hela turen är inställd markeras inte alltid enskilda hållplatslägen, så Cancellation kan stå kvar som false på ingående Calls. Därför kan ditt andra villkor filtrera bort svar om du kombinerar det med att turen ska vara markerad som inställd. En tur kan fortfarande gå som planerat men ha inställda avgångar eller ankomster, så följande villkor behöver kontrolleras separat för att fånga alla fall:
- RecordedCall har Cancellation satt till true
Angående frågan om du behöver komplettera med GTFS Regional Realtime är det inte nödvändigt. APIerna byggs av samma realtidsdata så de täcker samma info.Säg till om vi kan hjälpa till med något mer!
Hälsningar,
Linnea
Tack för svar!
Vi använder redan de tre villkoren separat, så det borde inte vara problemet.
Vår utmaning ligger snarare i att inställda turer inte alltid dyker upp i SIRI-ET överhuvudtaget. Vi baserar detta på att vi under 30h bara fångat 8 inställelser totalt för SL, Skånetrafiken och Östgötatrafiken.
Vi misstänker att det hänger ihop med vilket tidsintervall SIRI-ET-flödet täcker, alltså hur långt fram turer publiceras och hur länge de ligger kvar. Några frågor som skulle hjälpa oss:
1. Hur långt fram i tiden publiceras turer i SIRI-ET? Om en tur ställs in innan den kommit med i flödet, publiceras den då som inställd när den väl kommer in i tidsintervallet, eller kan den falla bort helt?
2. Hur länge ligger en inställd tur kvar i flödet? Försvinner den direkt när den markerats som inställd, vid planerad avgångstid eller vid planerad ankomsttid?
3. Vad händer om en inställelse registreras i efterhand, t.ex. flera timmar efter att turen skulle ha gått? Publiceras den då i SIRI-ET, eller ligger turen redan utanför tidsintervallet så att inställelsen bara syns i andra källor?
4. Skickas en inställd tur bara i en leverans, eller upprepas den i varje leverans så länge den ligger inom tidsintervallet?
5. Finns det något rekommenderat sätt att få en komplett bild av alla inställda turer under ett trafikdygn, t.ex. via historisk data eller ett annat API?
Tack för din hjälp!
Tack för dina frågor, här kommer lite svar som jag hoppas kan hjälpa er:
- Avgångar publiceras max fyra timmar fram i våra SIRI-ET flöden. Det som publiceras är det vi tar emot ifrån producenters realtidsleveranser, så levererar de inställda avgångar syns de när turen visas i flödet. Turer börjar ofta visas runt avgångstiden vid första hållplatsen.
- Alla avgångar ligger kvar max 10 minuter efter de passerats (eller planerats om inget fordon passerar). En inställd avgång försvinner alltså 10 minuter efter planerad avgångstid.
- Ställs en avgång in senare än tio minuter efter sin planerade avgångstid kommer den inte ut i SIRI-ET.
- All bevakad realtidstrafik som producenter levererar visas i SIRI-ET inom tidsfönstret jag beskrev i svaren på fråga 1 & 2. Uppdateringar kommer ut i filen varje gång du hämtar den för trafik inom det fönstret.
- Vill du se historik för hela trafikdygn kan du använda APIet KoDa. Där finns arkiv med alla TripUpdates-filer som publicerats under ett dygn för en producent. Det är GTFS Regional Realtime men de byggs som sagt på samma grunddata. Inställda turer hittas på trip.schedule_relationship = CANCELED.
Jag kontrollerade trafiken för SL, Skånetrafiken och Östgötatrafiken i vår realtidsdatabas två dagar bak och nästan all deras inställda trafik markeras på enskilda avgångar på planerade turer.Återkom gärna om du har fler frågor!
Hälsningar,
Linnea
Lite olyckligt för vårt use case där vi behövde den totala mängden inställelser, även de som registrerats mer än 10 minuter efter avgång. Utan det så kan vi inte se skillnad på en tur som utfördes utan att generera realtidsinformation och en tur som var inställd (om den ställdes in sent). Det verkar som ganska många inställelser rapporteras in sent, då trafikföretag först försöker rädda turen.