Denne siden forklarer hvordan dataene samles inn, beregnes og presenteres.
Forsinkelsesdataene hentes fra Entur sitt sanntids-API for kollektivtrafikk i Norge. API-et leverer posisjons- og statusdata for busser, trikker og andre kollektivtransportmidler i sanntid.
Vår tracker-applikasjon poller API-et hvert 40. sekund og følger hver enkelt avgang fra den blir synlig i API-et til den fullføres, kanselleres eller forsvinner fra feeden.
Viktig: Denne modulen er bygget for redaksjonell varsling og prioritering, ikke som en blind publiseringsfasit. Dataene er forbedret etter en metodisk gjennomgang i mars 2026, men noen komponenter er fortsatt avhengige av hvor komplett realtime-feeden faktisk er.
Beste praksis / målbildet: Målet er schedule deviation per stoppevent, basert på planlagt tid fra GTFS/ruteplan og forventet eller faktisk tid i realtime. For høyfrekvente bylinjer er dette alene ikke nok; da bør man i tillegg måle headway og bussklumping. Denne modulen har nå et eget headway-/bunching-proxy, men det har lavere tillit enn vanlig forsinkelsesmåling fordi det bygger på første observerte passering, ikke en perfekt faktisk avgangstid.
Kan normalt brukes direkte som arbeidsgrunnlag, men bør fortsatt kryssjekkes før publisering.
God til tips og situasjonsforståelse. Viktige tall bør bekreftes i råturer eller mot operatør.
Kan gi retning, men bør ikke brukes som dokumentasjon uten separat kvalitetssikring.
Manglende eller svak dekning. Vises for åpenhetens skyld, men skal ikke tolkes som faktisk driftsprestasjon.
| Problemområde | Status nå | Tillit | Hva det betyr i praksis |
|---|---|---|---|
| 1. Start- og sluttforsinkelse per tur | Løst | Høyere | Dashboardet bruker nå første og siste målte delay, ikke et halevindu som ga falsk “oppstart” og glattet “slutt”. |
| 2. Delay-kilde fra planlagt vs forventet tid | Delvis løst | Middels | Vi henter nå aimed/expected-felter og bruker dem når de finnes. Når upstream ikke sender dem, faller vi fortsatt tilbake på rapportert delay. |
| 3. “DISAPPEARED” som syntetisk sluttmåling | Løst | Høyere | API-gap lagres nå som ukjent sluttmåling i stedet for å bli omgjort til kunstig punktlighet eller forsinkelse. |
| 4. Tidligkjøring som “punktlig” | Løst | Høyere | Punktlighet teller nå bare avganger som ikke er tidlige og som ligger innenfor valgt sen-vindu. |
| 5. Flerdagssnitt som “snitt av dagsnitt” | Løst for hovedendepunkter | Høyere | Linje- og avgangsanalysene bygger nå direkte på turene i perioden. Stoppendepunktet vekter også med faktiske observasjoner. |
| 6. Live-feed som var filtrert for hardt | Delvis løst | Middels | Små forsinkelser filtreres ikke lenger bort i cachelaget, og maksimal alder er strammet inn. Men kvaliteten avhenger fortsatt av realtime-dekningen. |
| 7. Operatører med manglende stop_order | Delvis løst | Middels | Trackerens kvalifisering godtar nå også distinkte stop refs. Dette reduserer underrapportering, og følges nå opp med eksplisitte coverage- og tillitsmål per operatør. |
| 8. Dekning og tillit per operatør | Løst i første versjon | Middels | Dashboardet viser nå sluttmålingsdekning, API-gap og kildebruk per operatør, slik at svak dekning blir synlig før tall brukes journalistisk. |
| 9. Headway og bussklumping for høyfrekvente linjer | Delvis løst | Lav til middels | Modulen materialiserer nå headway-par og kan finne bussklumping historisk. Målet er likevel en proxy, fordi første observerte passering ikke alltid er lik faktisk avgang. |
| 10. GUI som oversolgte presisjon | Løst i denne runden | Tydeligere | Dashboards og metodevisning merker nå tydelig hva som er arbeidsgrunnlag, hva som er middels pålitelig og hva som fortsatt krever manuell kontroll. |
Forsinkelse beregnes nå primært som differansen mellom planlagt og forventet
avgang/ankomst i realtime-feltet når disse tidene finnes i feeden. Hvis upstream ikke leverer
slike tidspunkter, faller vi tilbake på Enturs rapporterte delay-felt.
Dette er nærmere standard schedule deviation-praksis enn den tidligere modellen, men er fortsatt avhengig av hvor godt realtime-feltene faktisk fylles ut av den enkelte operatøren.
Dashboardet viser nå en egen datatillit per operatør. Målet er ikke å rangere drift, men å rangere hvor godt tallene faktisk er målt.
DISAPPEAREDNO_DATADenne komponenten er spesielt viktig før man lager verstinglister eller operatørsammenligninger. Lav tillit betyr ikke nødvendigvis dårlig drift; det kan også bety svak realtime-feed.
Forsinkelsesforplantning måler hvordan forsinkelser utvikler seg gjennom en rute. En positiv delta betyr at forsinkelsen økte underveis, mens en negativ delta betyr at bussen hentet inn forsinkelsen.
Økt forsinkelse
Delta > +0.5 min
Stabil
Delta ±0.5 min
Redusert forsinkelse
Delta < -0.5 min
For høyfrekvente bylinjer er vanlige forsinkelsestall ofte utilstrekkelige. Derfor måler modulen nå også headway, altså tiden mellom to påfølgende busser på samme linje.
Dette er nyttig for å avsløre bylinjer som ser “greie” ut i rene forsinkelsestall, men som i praksis kommer i klumper. Samtidig er dette et proxy-mål og bør leses sammen med dekning, målelag og første observerte stopordre.
En avgang regnes som kansellert når API-et rapporterer status
CANCELLED for den aktuelle turen.
Kanselleringsrate beregnes som antall kansellerte avganger delt på totalt antall planlagte avganger for en gitt periode.
Merk: Noen kanselleringer kan skyldes planlagte endringer (f.eks. innstillinger pga. veiarbeid) som ikke nødvendigvis reflekterer driftsproblemer.
Standardavvik brukes som mål på upålitelighet eller variasjon i forsinkelser for en linje. En linje med høyt standardavvik er vanskelig å planlegge reiser med, fordi forsinkelsen varierer mye fra avgang til avgang.
Dette er nyttig som indikasjon, men bør leses sammen med dekning, antall målte turer og operatørspesifikke datagap.
Vi analyserer forsinkelser per kjøretøy (identifisert med kjøretøy-ID) for å se om enkelte busser systematisk er mer forsinket enn andre.
Dette kan indikere:
Viktig: Høy gjennomsnittsforsinkelse for et kjøretøy betyr ikke nødvendigvis at kjøretøyet er problemet – det kan også skyldes at det kjører ruter med generelt høy forsinkelse.
Ett enkelt forsinket kjøretøy kan påvirke flere avganger på samme linje hvis samme buss kjører flere turer på rad.
For å identifisere slike mønstre grupperer vi avganger etter kjøretøy-ID og ser om samme kjøretøy har flere forsinkede avganger i løpet av dagen.
Hvis et kjøretøy har f.eks. 5 avganger og alle er forsinket, kan dette indikere at én initial forsinkelse "forplantet seg" gjennom hele dagen. Dette er viktig å forstå når man vurderer omfanget av driftsproblemer.
Styrker:
Begrensninger:
Data lagres per dag og kan aggregeres over ulike tidsperioder:
Linje- og avgangsanalysene beregnes nå direkte fra alle turene i perioden, slik at små og store dager ikke veier likt ved en feil. Stoppendepunktet vekter dessuten med faktiske observasjoner i stedet for å bruke enkle dagsnitt av dagsnitt.
Har du spørsmål om hvordan dataene er samlet inn eller beregnet? Ta kontakt med dataavdelingen for ytterligere detaljer.