GTFS Regional realtidsdata (beta)

Introduktion

Observera att data som levereras här är i beta-version och kan komma att ändras utan förvarning från en feed till en annan. Vi kommer att fortsätta utveckla vårt NOPTIS- och GTFS-stöd, och feedback från tredjepartsutvecklare tas gärna emot. Dokumentationen kommer att uppdateras kontinuerligt, lämna gärna feedback på API och dokumentation här

Det finns flera skillnader mellan den GTFS-feed som vi redan levererar idag (GTFS Sverige 2) och den feed som beskrivs här. Eftersom dessa baseras på skilda indatakällor kan man inte använda ID:en dem emellan. GTFS Sverige 2-feeden innehåller sammanslagen information från hela Sveriges trafikföretag, medan den NOPTIS-baserade GTFS-feeden i dagsläget innehåller data per trafikföretag. Till exempel så finns det både en ul.zip (baserat på ULs data) och en otraf.zip (baserat på Östgötatrafikens data), till skillnad från sweden.zip som finns idag som innehåller Sveriges trafikföretags data. Detta gör bland annat att de NOPTIS-baserade GTFS-filerna inte behöver använda sig av rikshållplatser som i sweden.zip, utan kan använda sig direkt av trafikföretagens definierade hållplatsområden och hållplatsställen. Den NOPTIS-baserade GTFS-feeden inkluderar inte heller extrafiler utan följer endast GTFS-specifikationerna. Alla feeds inkluderar trafikdata med avgångsdatum senare än tre dygn bakåt i tiden från tidpunkten när det genererades.

GTFS Realtime

GTFS-RT innehåller realtidsdata. GTFS-RT finns tillgängligt som filer i protocol-buffer-formatet. Läs mer om formatet här: https://developers.google.com/protocol-buffers/docs/overview. Vi rekommenderar att man använder ett bibliotek för att underlätta utvecklingen, se till exempel https://github.com/google/gtfs-realtime-bindings. Dokumentation för hur data ska tolkas finns på https://gtfs.org/reference/realtime/v2/. Vi använder oss inte av Extensions för GTFS-R.  

För GTFS-RT finns fyra stycken filer tillgängliga per trafikföretag, en per entitet. Varje trafikföretag har filer som innehåller Trip Updates och Service Alerts. Båda filerna uppdateras samtidigt ungefär varje 15:de sekund.
Samtliga filer borde hämtas med HTTP gzip-komprimering för ytterligare överföringshastighet.

Då detta är ett beta-API kan man förvänta sig nedtid då och då pga undehåll av databaserna.

Noteringar

  • Effect-fältet i Alerts (http://gtfs.org/realtime/#message-alert) kommer alltid att ha värdet "UNKNOWN_EFFECT". Detta beror på att de effect-liknande fälten i NOPTIS-formatet inte matchar väl med de som finns i GTFS-R.
  • ServiceAlerts och TripUpdates uppdateras var 15:e sekund
  • I TripUpdates finns ett attribut som heter uncertainty. I GTFS Regional kan uncertainty endast anta värdet 0 eller uteslutas helt. Värdet 0 ska tolkas som att det är observerad att hållplatsen är passerad. Om uncertainty saknar är det brukar en prognos, som kan ändras.  För att säkerställa att hållplatsen passerats bör man verifiera att attributet uncertainty finns, och att den är 0. Om men glömmer att kolla om det finns, kan din programmeringsspråk tolka ett saknad attribut (Null) som 0, som kan ge fel i din applikation.
  • I TripUpdates finns ett timestamp för varje prognos. Denna timestamp visar när ankomst- eller avgångsprognosen senast uppdaterades.

Metoder:

Du kan hämta vår data genom vanliga HTTP Get requests. Våra servrar skickar HTTP last-modified och HTTP ETag headers, som man kan använda för att se om en fil har ändrats. Vi också har stöd för Conditional Requests, där vår server bara skickar en body om ny information finns. Denna lösningar är standarden på nätet, så du kan återanvända kod mellan Trafiklab och eventuella andra datakällor. Det kan även vara så att din HTTP-bibliotek gör allt för dig, så att du inte ens måste tänka om det och så att filen blir cachad automatiskt. Vi uppmanar att man utnyttjar denna fil för att se om man verkligen behöver hämta filen på nytt.

Obs Klienten måste ha stöd för Gzip eller Deflate komprimering. De flesta HTTP biblioteker har stöd för detta inbyggt, men bland annat i Curl och .NET kan det vara så att man måste lägga till rätt Accept header manuellt. Om HTTP Accept header:n är fel får man en HTTP 406 felkod.

Trafikbolag TripUpdates ServiceAlerts VehiclePositions
Östgötatrafiken

Protocol buffer-format

Protocol buffer-format

Protocol buffer-format
UL

Protocol buffer-format

Protocol buffer-format

Protocol buffer-format
SL

Protocol buffer-format

Protocol buffer-format

N/A
Skånetrafiken

Protocol buffer-format

Protocol buffer-format

Protocol buffer-format
Kalmar länstrafik

Protocol buffer-format

Protocol buffer-format

Protocol buffer-format
X-trafik

Protocol buffer-format

Protocol buffer-format

Protocol buffer-format
Dalatrafik

Protocol buffer-format

Protocol buffer-format

Protocol buffer-format
Värmlandstrafik+Karlstadbuss

Protocol buffer-format

Protocol buffer-format

Protocol buffer-format

      API-Nyckel

      Det krävs en giltig API-nyckel som skickas med som parametern "key" i metodanropen ovan. En API-nyckel får du genom att skapa ett projekt som använder detta API. Mer om hur du skapar och använder API nycklar hittar du här. För att få en API-nyckel så måste du godkänna de licensvillkor som finns för detta API.