Händelser vid hållplats för skärskild linje går inte ut rätt i SIRI SX.
I gtfs-rt går vissa meddelanden ut med referens till både hållplats och linje i samma informed_entity vilket tolkas som att det gäller endast när den linjen angör hållplatsen. Utan denna information blir man tvungen att förutsätta att ett meddelande för en hållplats gäller för varje bus som angör vilket inte alltid kommer stämma med verkligheten.
I era SIRI SX strömmar går dessa ut som flera referenser till samma hållplats en gång per linje, utan att varje linje nämns. Det ska dock vara möjligt att stödja denna information även i SIRI enligt följande:
https://github.com/entur/profile-examples/blob/master/siri/situation-exchange/siri-sx-for-stop-by-specific-lines.xml
Ni verkar dessutom stödja detta när det gäller indata så det kanske har blivit ett fel vid konvertering från specifikt Noptis Roi.
I era SIRI SX strömmar går dessa ut som flera referenser till samma hållplats en gång per linje, utan att varje linje nämns. Det ska dock vara möjligt att stödja denna information även i SIRI enligt följande:
https://github.com/entur/profile-examples/blob/master/siri/situation-exchange/siri-sx-for-stop-by-specific-lines.xml
Ni verkar dessutom stödja detta när det gäller indata så det kanske har blivit ett fel vid konvertering från specifikt Noptis Roi.
Följ inlägget
1
följare
Ursäkta sent svar. Detta låter som en bug på vår sida, förstår jag dig rätt att du saknar information om linje under <Affects> i en Siri-SX ptSituationElement? Minns du vilken operatör du använde när du hittade detta och har du kanske t om en bild med ett exempel på detta fel? Det skulle underlätta för oss, men vi kommer oavsett att kolla på detta! Tack för att du uppmärksammat det.
Mvh
Sofie
Ja det är rätt förstått, Jag hittade problemet för UL men jag tror även att det förekom för SL. Jag tror även att det ibland ser ut som nedan i SIRI fast att det då inte finns någon referens till linjen i GTFS-RT heller. Alltså att endast ett antal identiska StopPlace referenser, I dessa fall har det dock stämt överens med UL:s hemsida så det kanske inte är något fel då givet att den inte bygger på eran data.
SIRI SX:
GTFS-SA:
Har kört ett python program för att kunna läsa GTFS-RT protobuf
Mvh
Sofie
Detta har nu också åtgärdats och det ska gå att få ut både hållplats och linje i ett element.
Mvh
Sofie
Jag har en fråga till om händelserna, är det så att ni endast skickar vidare händelser vars <StartTime> har passerats?
Jag har märkt ett antal gånger att det på UL:s hemsida finns fler inställda tåg en vad som kommer ut i SIRI feeden. Hemsidan brukar då säga att meddelandet gäller den tid tåget är i trafik vilket verkar korrekt, även fast resenären vill veta detta i förtid. De planerade avvikelserna kommer inte heller upp men de är kanske från ett annat system.
Mvh
Sigurd
Jag var tvungen att kolla upp detta lite mer men ja det är som du säger, vi skickar bara vidare händelser vars <StartTime> har passerat.
Vi kommer kolla vidare på detta om det är möjligt för oss att släppa något på den begränsningen. Tack!
Mvh
Sofie
Jag har nu haft möjlighet att kolla på hur detta fungerar med OpenTripPlanner. Det vissar sig att OTP inte gillar att meddelandena har AffectedStopPlace istället för AffectedStopPoint som specificeras i den nordiska profilen? och som fanns i exempel meddelandet jag länkade i mitt första inlägg.
Jag har skälv nu löst detta genom att bearbeta SIRI datan innan jag skickar den vidare till OTP. Trots det så jag undrar varför ni valt att göra på detta viss då det blir mer arbete att implementera för mottagaren eftersom att eran och EnTurs data skiljer sig, vilket inte borde eftersträvas, särskilt då ni båda använder den nordiska profilen.
Med vänliga hälsningar Sigurd
P.S. menar inte att på negativt vis ifrågasätta erat tillvägagångssätt jag vill bara förstå. Jag är väldigt tacksam att ni tagit er tid på att fixa detta.
Hej igen,
Normalt sett vill vi gärna göra så lite modifikation på datat som möjligt och valde när vi implementerade detta att skicka ut det på samma sätt som det kommer in till oss. När vi får in StopPoints så skickar vi ut det som StopPoints (se bild nedan) och när vi får in StopAreas så skickar vi ut det som StopAreas. Jag har tagit upp detta dock och vi kommer se över om vi kan bryta ner det till StopPoints i de fallen det kommer in som StopAreas när vi får tid, men tyvärr kan vi inte prioritera upp detta just nu.
Mvh
Sofie
Jag tror att du missförstått mig jag menar inte att dela upp stop arean på alla stop points bara att det i profilen är tillåtet att referera till en stop area AffectedStopPoint. Jag har dock full förståelse för att detta inte är en prioritering.
Mvh
Sigurd
Jaha okej, men då är problemet fortfarande att vi inte har informationen om vilken stopPoint det berör (då vi bara får in stopArea) och det blir lite rörigt att behöva leta upp den korrekta utan att komplicera till flödet.
Mvh
Sofie
<AffectedStopPoints>
<StopPointRef>SE:005:StopPlace:9021005000147000</StopPointRef>
</AffectedStopPoint>
Hoppas detta är tydligt nog
Mvh Sigurd
Tack igen.
Mvh
Sofie