Destination som ort
Hej!
Har lagt märke till att man får tillbaks stationsnamn som destination i ResRobot. Detta gör att det blir fel om man kollar på riktiga skyltar som till exempel säger "Buss 61 mot Hornsberg", medan i ResRobot säger den "Buss 61 mot Moa Martinsons torg". Detta kan bli förstås väldigt förvirrande när man reser.
Finns det något sätt att få reda på destination så som bussen faktiskt skyltar? Någon databas eller parameter som jag missat?
Tack!
Mvh Frej
Har lagt märke till att man får tillbaks stationsnamn som destination i ResRobot. Detta gör att det blir fel om man kollar på riktiga skyltar som till exempel säger "Buss 61 mot Hornsberg", medan i ResRobot säger den "Buss 61 mot Moa Martinsons torg". Detta kan bli förstås väldigt förvirrande när man reser.
Finns det något sätt att få reda på destination så som bussen faktiskt skyltar? Någon databas eller parameter som jag missat?
Tack!
Mvh Frej
Följ inlägget
2
följare
trips.trips_headsign som default hur destination skyltas för en viss trip, och sedan kan det skrivas över av stop.stop_headsign om skyltningen ändras under resans gång.
Tack!
Detta är en begränsning av Resrobot och GTFS Sverige 2. Systemet som ligger bakom har inte stöd för destinationsskyltning, och då blir det bara sista hållplatsen som skyltas. Planen är att detta system ska bytas ut kring sommaren 2026, jag vet inte om det kommer lösa problemet på en gång men då kommer vi i alla fall ha möjlighet att lägga till denna information.
I GTFS Regional och GTFS Sweden 3 ska headsign informationen vara rätt. I exemplet du nämner ovan hittar jag tur 14010000688681221 som är kopplad till route_id 9011001006100000. Turen har "Hornsberg" som stop_headsign.
Vissa operatörer skickar inte in denna information, och då blir fältet även tomt i GTFS Regional och GTFS Sweden 3.
Hälsningar,
Bert
Efter senaste ändringen till att använda trip_headsign samt stop_headsign så har jag hittat ett problem som ni kanske har koll på:
Vissa snabb och regionaltåg verkar ha sitt tågnummer inskrivet som stop_headsign. Exempel är SJ Regionaltåg mot Göteborg med trip_id 740177008847000001 (route_id 9011100017700000). Någon anledning varför? Och finns det något sätt att veta när jag ska, och när jag inte ska använda värdet som destinationsskyltning?
Detta är ett känt problem, och vi har just nu en utredning på gång om hur vi ska rätta detta.
Problemet är att vår GTFS export har funnits sen 2018, och har varit stabilt sen dess. Samtidigt har det genom åren kommit in mer data i vårt dataplattform från olika håll och genom olika standarder, och kraven på hur data levereras i vissa andra standarder går lite emot vår interna datamodell och hur vi exporterar detta till GTFS.
När det gäller tåg, specifikt SJ, så är läget just nu att tågnumret finns överallt och att det knappt finns någon annan data. Det är alltså en av problemen som vi kommer försöka att få bukt med.
Internt har vi redan tagit ett antal steg för att kunna hantera specifik information, som tågnummer och turnummer, på ett bättre sätt i vårt dataplattform. Detta ger oss de förutsättningar som behövs för att även kunna förbättra detta i GTFS exporten.
De kommande veckor kommer vi utreda exakt hur vi kan justera vår GTFS export för att exportera data på ett konsistent sätt, oavsätt trafikslag eller indataformat. Det innebär bland annat:
- Att turnumret alltid måste vara tillgängligt i samma kolumn (något som vi i nuläget måste lägga i separata "extra" filer, för att vår datamodell inte matchar med GTFS i turuppdelningen)
- Att tågnumret, om det finns, alltid måste vara tillgängligt i samma kolumn
- Att route_short_name, route_long_name, ... måste vara konsistent, just nu är de omvänd i Gotland och Västerbotten jämfört med övriga regioner.
Just nu finns det alltså inte riktigt något du kan göra åt det här, men om allt går bra kan vi lösa detta i januari eller februari 2026. Innan dess kommer vi gå ut med information om exakt vad som kan förväntas i vilken kolumn från dagen där vi genomför ändringen.
Hälsningar,
Bert
Märkte också det med route_short och long_name häromdagen, bra att ni har koll 😄
Jag fixar en temporär fix för SJ tills det är åtgärdat då. Har ni någon sida med status om problemet? Så jag kan hålla koll på när det är fixat och hur
Tack!
Vi har ingen status om det här, men som sagt kommer alla användare av vår GTFS data nog få ett mejl ett par veckor innan förändringen genomförs. Då kommer vi antagligen även kunna specificera sånt här bättre i dokumentationen på webben.
Hälsningar
Bert
Mvh Frej
Då får man både en statisk data i samma API som man får det som man kan likna med "trip updates" i GTFS världen.