# GTFS, GTFS-RT og GBFS: hva er forskjellene?

> Sammenlign GTFS, GTFS-RT og GBFS for å velge dine mobilitetsdata: planlagte tidsplaner, oppdaterte informasjoner, stasjoner og delte kjøretøy.

Source: https://www.roote.ai/no/guides/gtfs-gtfs-rt-og-gbfs-hva-er-forskjellene/
Language: no
Author: ROOTE

GTFS Schedule beskriver det planlagte transporttilbudet. GTFS Realtime, ofte kalt GTFS-RT, gir oppdaterte opplysninger om tjenesten. GBFS beskriver delte mobilitetstjenester, inkludert deres stasjoner og kjøretøy tilgjengelig i de publiserte feedene. Velg format ut fra hvilket problem applikasjonen din skal løse.

Disse formatene organiserer data; de garanterer verken at dataene er tilgjengelige over alt, eller kvaliteten på hver enkelt feed.

## GTFS for å representere det planlagte tilbudet

En GTFS Schedule-pakke samler tabellfiler som beskriver blant annet operatører, stoppesteder, linjer, avganger og deres tider. Kalendere angir hvilke dager de gjelder. Filene er koblet sammen med identifikatorer. [Referanse for GTFS Schedule](https://gtfs.org/documentation/schedule/reference/).

Det lar deg svare på spørsmål som «hvor er dette stoppestedet?» eller «hvilke avganger er planlagt for denne tjenesten?». For å bruke en tidsplan må du tolke kalenderen og relasjonene mellom filene.

Å kun lese en liste over stoppesteder er derfor ikke nok til å rekonstruere avgangene. Omvendt kan en posisjon for et stoppested være nyttig uten å vise tidspunkter.

## GTFS-RT for å oppdatere tjenesteinformasjon

GTFS Realtime kan tilby oppdateringer for avganger, kjøretøyposisjoner og varsler. Oppdateringene gjelder blant annet avgangstider og endringer i tjenesten. Feedene bruker Protocol Buffers, et strukturert serialiseringsformat. [Introduksjon til GTFS Realtime](https://gtfs.org/documentation/realtime/reference/).

En produsent kan publisere enkelte kategorier uten å gi alle andre. Tilstedeværelsen av en posisjonsfeed garanterer ikke estimater for alle stoppesteder.

For brukergrensesnittet, skill mellom planlagt avgang og oppdatert estimat. Vår veileder [teoretiske og sanntids tidsplaner](https://www.roote.ai/no/guides/busstider-teoretiske-eller-sanntid-hva-er-forskjellen/) forklarer denne forskjellen fra brukerens perspektiv.

## GBFS for delt mobilitet

GBFS bruker JSON feed for å beskrive en delt mobilitetstjeneste. Avhengig av system og versjon kan de gi informasjon om stasjoner, deres status, kjøretøy og andre tjenestekarakteristikker. Dokumentasjonen skiller særlig mellom stasjonsinformasjon og tilgjengelighetsstatus. [GBFS dokumentasjon](https://github.com/MobilityData/gbfs/blob/v2.3/gbfs.md).

Skill i applikasjonen mellom relativt stabile lokasjoner og status som endrer seg raskt. Bevar formatversjon og relevant tidsstempel ved tolkning.

En tilgjengelighetsfeed er ikke et API for reservasjon eller opplåsing. Det hjelper med å oppdage tilbudet; selve leieoperasjonen håndteres av tjenesteleverandøren.

## Sammenlign etter brukstilfelle

| Behov | Format å vurdere |
| --- | --- |
| Beskrive planlagte stopp og linjer | GTFS Schedule |
| Tolke planlagte avganger og servicedager | GTFS Schedule |
| Oppdatere avganger eller motta tjenesteinformasjon | GTFS-RT, avhengig av publiserte feed |
| Lokalisere stasjoner eller kjøretøy for delt mobilitet | GBFS, avhengig av publiserte data |

Konstruksjonseksempel: et kart viser trikkeholdeplasser og sykkelstasjoner. Det bruker strukturelle data for steder og oppdatert status for sykkeltilgjengelighet. De to lagene har ulike behov for caching og oppdatering.

## Forutse begrensninger for hver datakilde

Sjekk versjoner, valgfrie felt, dekning og bruksvilkår. En identifikator gir mening kun i sin kontekst: to produsenter kan bruke identiske strenger for forskjellige entiteter.

Forbered også for manglende eller foreldet data. En tom liste fra en utilgjengelig feed skal ikke presenteres som fravær av tjeneste. Unngå å stilletiende erstatte ukjent informasjon med null.

## Bruke feedene direkte eller via et API

En direkte integrasjon gir deg ansvar for innsamling, validering og tolkning av kildene. Et API kan tilby en felles kontrakt, men du må fortsatt lese dekning, advarsler og betingelser.

For et første ROOTE-brukstilfelle, se [hvordan søke etter nærliggende stopp med et API](https://www.roote.ai/no/guides/hvordan-soke-etter-nartransportstopp-med-en-api/). Begynn med behovet i ditt grensesnitt, deretter sjekk hvilke felt som faktisk er tilgjengelige.

## Lese utdrag og velge en arkitektur

I GTFS Schedule knytter et utdrag fra stop_times.txt en tur, et stoppested og et planlagt passeringstidspunkt sammen. Det forkortede eksempelet nedenfor er pedagogisk: det utgjør ikke et komplett GTFS-sett, og dets identifikatorer må kobles til trips.txt, stops.txt og kalenderne.

For GTFS Realtime, let etter den relevante enheten: en TripUpdate kan oppdatere et passeringstidspunkt, en VehiclePosition beskriver en posisjon, og en Alert formidler en tjenesteinformasjon. En kjøretøyposisjon er ikke automatisk en ankomstestimertid. Formatet som sendes er Protocol Buffers; en diagnostisk JSON-representasjon er ikke den refererte binære strømmen.

I GBFS beskriver station_information stasjonene, mens station_status beskriver deres publiserte tilstander. Navnene på enkelte telleverk og tilgjengelige filer varierer etter versjon. JSON-utdraget nedenfor illustrerer GBFS 2.3 og feltene num_bikes_available og num_docks_available; sjekk versjonen før du bruker et eksempel.

Et kart over steder kan starte med strukturelle data. En skjerm for kommende passeringer krever deretter tilsvarende oppdateringer og en eksplisitt planlagt fallback. En skjerm for tilgjengelige sykler må håndtere telleverk, utleiebetingelser og tidsgyldighet. Disse tre skjermbildene deler ikke automatisk samme cache-politikk.

```
# Extrait pédagogique de stop_times.txt
trip_id,arrival_time,departure_time,stop_id,stop_sequence
trip_demo,08:10:00,08:10:00,stop_demo,1

# Extrait pédagogique de station_status en GBFS 2.3
{
  "station_id": "station_demo",
  "num_bikes_available": 3,
  "num_docks_available": 7,
  "is_installed": true,
  "is_renting": true,
  "is_returning": true,
  "last_reported": 1720000000
}
```

[Formatere sykkeltilgjengelighet og dens ferskhet](https://www.roote.ai/no/guides/tilgjengelighet-av-sykkel-i-sanntid-hvordan-vise-i-en-app/)

[Velge et API eller en MCP for ditt produkt](https://www.roote.ai/no/guides/api-eller-mcp-hvilken-velge-for-mobilitetsdata/)

## Vanlige spørsmål

### Inneholder GTFS automatisk sanntidsdata?

Nei. GTFS Schedule representerer det planlagte tilbudet; oppdaterte informasjoner kommer fra andre feed, særlig GTFS-RT.

### Kan GBFS låse opp en sykkel?

Det beskriver tjenesten og dens offentlige data. Leie gjennomføres via funksjoner levert av operatøren.

### Garanti for full dekning med et standardformat?

Nei. Formatet definerer en struktur; dekning og publiserte opplysninger avhenger av kildene.