# GTFS, GTFS-RT és GBFS: miben különböznek?

> Hasonlítsa össze a GTFS, GTFS-RT és GBFS adatokat a mobilitási adatok kiválasztásához: tervezett menetrendek, frissített információk, megosztott állomások és járművek.

Source: https://www.roote.ai/hu/guides/gtfs-gtfs-rt-es-gbfs-miben-kulonboznek/
Language: hu
Author: ROOTE

A GTFS Schedule a tervezett közlekedési kínálatot írja le. A GTFS Realtime, gyakran GTFS-RT néven ismert, frissített közlekedési információkat közvetít. A GBFS a megosztott mobilitási szolgáltatásokat írja le, különösen a megállóhelyeket és az elérhető járműveket a közzétett adatfolyamok alapján. Válassza ki a formátumot az alkalmazás által megoldandó kérdés alapján.

Ezek a formátumok az adatokat szervezik; nem garantálják azok mindenhol való elérhetőségét sem az egyes adatfolyamok minőségét.

## GTFS a tervezett kínálat ábrázolásához

A GTFS Schedule egy olyan fájlkészlet, amely táblázatos formában tartalmaz többek között üzemeltetőket, megállóhelyeket, vonalakat, járatokat és azok áthaladási időpontjait. A naptárak jelzik az érintett napokat. A fájlokat azonosítók kapcsolják össze. [GTFS Schedule referenciák](https://gtfs.org/documentation/schedule/reference/).

Ezzel válaszolhatunk például arra a kérdésre, hogy „hol található ez a megálló?” vagy „milyen haladások várhatók ezen a szolgáltatáson?”. A menetrend kiaknázásához értelmezni kell a naptárat és a fájlok közötti kapcsolatokat.

Önállóan egy megállóhely-lista olvasása nem elég a haladások rekonstruálásához. Fordítva pedig egy megállóhely pozíciója hasznos lehet menetrend megjelenítése nélkül is.

## GTFS-RT a szolgáltatás információinak frissítéséhez

A GTFS Realtime képes járatfrissítéseket, járműpozíciókat és figyelmeztetéseket szolgáltatni. A járatfrissítések többek között a haladásokra és a szolgáltatás változásaira vonatkoznak. Az adatfolyamok a Protocol Buffers struktúrált sorosító formátumot használják. [GTFS Realtime bevezető](https://gtfs.org/documentation/realtime/reference/).

Egy adatközlő bizonyos kategóriákat közzétehet anélkül, hogy az összes többit szolgáltatná. Egy pozíció adatfolyam jelenléte nem garantálja az összes megállóhely becslését.

A felületen különbséget kell tenni a tervezett haladás és a frissített becslés között. Útmutatónk [elméleti és valós idejű menetrendekről](https://www.roote.ai/hu/guides/menetrendek-buszoknal-elmeleti-es-valos-ido-kulonbseg/) ezt a különbséget a felhasználó szempontjából magyarázza.

## GBFS a megosztott mobilitáshoz

A GBFS JSON adatfolyamokat használ a megosztott mobilitási szolgáltatás leírására. A rendszer és verzió függvényében kérhetők le az állomások, azok állapota, a járművek és egyéb szolgáltatási jellemzők. A dokumentáció különválasztja az állomásinformációkat és az elérhetőségi állapotokat. [GBFS dokumentáció](https://github.com/MobilityData/gbfs/blob/v2.3/gbfs.md).

Az alkalmazásban válassza szét a viszonylag stabil helyszíneket és a gyorsan változó állapotokat. Az értelmezés során őrizze meg a formátum verzióját és az releváns időbélyeget.

Az elérhetőségi adatfolyam nem foglalási vagy feloldási API. Segít a kínálat megismerésében; a bérlést a szolgáltatás végzi.

## Összehasonlítás esettől függően

| Igény | Vizsgálandó formátum |
| --- | --- |
| Megállók és tervezett vonalak leírása | GTFS Schedule |
| Várható haladások és szolgáltatási napok értelmezése | GTFS Schedule |
| Haladások frissítése vagy szolgáltatási információk fogadása | GTFS-RT, a közzétett adatfolyamok szerint |
| Megosztott mobilitási állomások vagy járművek helymeghatározása | GBFS, a közzétett adatok szerint |

Tervezési példa: egy térkép megjelenít villamosmegállókat és kerékpárkölcsönző állomásokat. Szerkezeti adatokat használ a helyszínekhez és frissített állapotokat a kerékpárok elérhetőségéhez. A két réteg eltérő gyorsítótárazási és frissítési igényekkel bír.

## Tervezze meg minden forrás korlátait

Ellenőrizze a verziókat, az opcionális mezőket, a lefedettséget és a felhasználási jogokat. Egy azonosító csak a saját kontextusában értelmezhető: két adatközlő ugyanazt a karakterláncot különböző entitásokhoz is használhatja.

Készüljön fel hiányzó vagy elavult adatokra is. Egy üres lista egy elérhetetlen adatfolyamból nem jelent szolgáltatás-hiányt. Kerülje az ismeretlen információ csendes nullára cserélését.

## Használjon közvetlen adatfolyamokat vagy API-t

A közvetlen integráció megköveteli, hogy Ön gyűjtse össze, ellenőrizze és értelmezze a forrásokat. Egy API közös szerződést kínálhat, de mindig ellenőrizze a lefedettséget, figyelmeztetéseket és feltételeket.

Első ROOTE esettanulmányhoz tekintse meg a [közeli megállók keresése API-val](https://www.roote.ai/hu/guides/hogyan-keressunk-kozelben-levo-jaratokat-api-val/) útmutatót. Kezdje az interfész szükségleteivel, majd ellenőrizze a ténylegesen elérhető mezőket.

## Részletek olvasása és egy architektúra kiválasztása

A GTFS Schedule-ban a stop_times.txt egy kivonata összekapcsol egy járatot, egy megállót és egy tervezett áthaladást. Az alábbi egyszerűsített példa oktató jellegű: nem egy teljes GTFS csomag, és az azonosítók a trips.txt, stops.txt és a naptárak felé kapcsolódnak.

A GTFS Realtime esetében keresd a hasznos entitást: egy TripUpdate frissíthet egy áthaladást, egy VehiclePosition leírja a pozíciót, és egy Alert szolgáltatási információt közöl. A járműpozíció nem automatikusan érkezési becslés. A továbbított formátum Protocol Buffers; a diagnosztikai JSON reprezentáció nem az alapértelmezett bináris adatfolyam.

A GBFS-ben a station_information leírja az állomásokat, míg a station_status a közzétett állapotukat. Egyes számlálók nevei és a rendelkezésre álló fájlok a verziótól függően változnak. Az alábbi JSON kivonat a GBFS 2.3-as verzióját és a num_bikes_available, valamint num_docks_available mezőket mutatja; használat előtt ellenőrizd a verziót.

A helyszíni térkép strukturális adatokkal kezdődhet. Egy következő járatokat mutató képernyő pedig a megfelelő frissítéseket és explicit terv szerinti visszaállást igényel. Egy elérhető kerékpárokat mutató képernyőnek kezelnie kell a számlálókat, kölcsönzési feltételeket és az időbeli érvényességet. Ezek a három képernyő nem feltétlenül osztják meg automatikusan ugyanazt a gyorsítótárazási szabályt.

```
# 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
}
```

[Kerékpár elérhetőség és frissesség formázása](https://www.roote.ai/hu/guides/valosideju-kerekpar-elerhetoseg-alkalmazasban-megjelenites/)

[API vagy MCP választása a termékedhez](https://www.roote.ai/hu/guides/api-vagy-mcp-melyiket-valasszuk-mobilitasi-adatok-integralasahoz/)

## Gyakran ismételt kérdések

### Tartalmaz automatikusan valós idejű adatokat a GTFS?

Nem. A GTFS Schedule a tervezett kínálatot képviseli; a frissített információk más adatfolyamokat, például a GTFS-RT-t illetnek.

### Lehet-e GBFS-sel kerékpárt feloldani?

A GBFS leírja a szolgáltatást és annak nyilvános adatait. A bérlés az üzemeltető által kínált funkciókon keresztül történik.

### Garantálja-e a szabványos formátum a teljes lefedettséget?

Nem. A formátum struktúrát határoz meg; a lefedettség és a közölt információk a forrásoktól függenek.