# GTFS, GTFS-RT и GBFS: какви са разликите?

> Сравнете GTFS, GTFS-RT и GBFS, за да изберете данни за мобилност: планирани разписания, актуализирана информация, станции и споделени превозни средства.

Source: https://www.roote.ai/bg/guides/gtfs-gtfs-rt-i-gbfs-kakvi-sa-razlikite/
Language: bg
Author: ROOTE

GTFS Schedule описва планираната транспортна оферта. GTFS Realtime, често наричан GTFS-RT, предава актуализирана информация за услугата. GBFS описва услугите за споделена мобилност, включително техните станции и наличните превозни средства според публикуваните потоци. Изберете формата в зависимост от въпроса, който вашето приложение трябва да реши.

Тези формати организират данните; те не гарантират тяхната наличност навсякъде или качеството на всеки поток.

## GTFS за представяне на планираната оферта

Един набор GTFS Schedule събира таблични файлове, описващи операторите, спирките, линиите, курсовете и техните преминавания. Календарите посочват конкретните дни. Файловете са свързани чрез идентификатори. [Референция GTFS Schedule](https://gtfs.org/documentation/schedule/reference/).

Той позволява да отговорите на въпроси като „къде се намира тази спирка?“ или „кой курс е планиран за тази услуга?“. За да използвате разписание, трябва да интерпретирате календара и връзките между файловете.

Само четенето на списък със спирки не е достатъчно за възстановяване на преминаванията. Обратно, позицията на спирка може да бъде полезна и без показване на разписания.

## GTFS-RT за актуализиране на информацията за услугата

GTFS Realtime може да предоставя актуализации на курсовете, позиции на превозни средства и предупреждения. Актуализациите на курсовете обхващат преминавания и промени в услугата. Потоковете използват Protocol Buffers, структуриран формат за сериализация. [Въведение в GTFS Realtime](https://gtfs.org/documentation/realtime/reference/).

Един производител може да публикува определени категории без да предоставя всички останали. Наличието на поток с позиции не гарантира прогнози за всички спирки.

За интерфейса разграничете планираното преминаване от актуализираната оценка. Нашето ръководство [теоретични и реално време разписания](https://www.roote.ai/bg/guides/razpisanie-na-avtobusite-kakva-e-razlikata-mezhdu-teoretichni-i-realno-vreme/) обяснява тази разлика от гледна точка на потребителя.

## GBFS за споделена мобилност

GBFS използва JSON потоци за описание на услуга за споделена мобилност. В зависимост от системата и версията, те могат да съдържат информация за станции, тяхното състояние, превозни средства и други характеристики на услугата. Документацията ясно различава информация за станциите и състоянията на наличност. [Документация GBFS](https://github.com/MobilityData/gbfs/blob/v2.3/gbfs.md).

Разделяйте в приложението си относително стабилните местоположения от състоянията, които се променят бързо. Запазвайте версията на формата и съответния времеви печат при тълкуване.

Потокът на наличности не е API за резервация или отключване. Той помага за откриване на офертата; операцията по наем е отговорност на съответната услуга.

## Сравняване според случая на използване

| Нужда | Формат за разглеждане |
| --- | --- |
| Описание на планирани спирки и линии | GTFS Schedule |
| Тълкуване на планирани преминавания и дни на обслужване | GTFS Schedule |
| Актуализиране на преминаванията или получаване на информация за услугата | GTFS-RT, според публикуваните потоци |
| Локализиране на станции или превозни средства за споделена мобилност | GBFS, според публикуваните данни |

Пример за дизайн: карта показва трамвайни спирки и велосипедни станции. Тя използва структурни данни за местоположенията и актуализирани състояния за наличността на велосипедите. Двата слоя имат различни нужди от кеширане и обновяване.

## Предвидете ограниченията на всеки източник

Проверявайте версиите, незадължителните полета, покритието и правата за използване. Един идентификатор има смисъл само в своя контекст: два производителя могат да използват еднакви низове за различни обекти.

Планирайте и за липсващи или изтекли данни. Празен списък от недостъпен поток не трябва да се представя като липса на услуга. Избягвайте безшумно заместване на непозната информация с нула.

## Използване директно на потоци или чрез API

Директната интеграция ви оставя отговорни за събирането, валидирането и тълкуването на източниците. API може да предложи общ договор, но винаги трябва да четете неговото покритие, предупреждения и условия.

За първи случай на използване с ROOTE вижте [как да търсите спирки наблизо с API](https://www.roote.ai/bg/guides/kak-da-tarsim-blizkite-prestani-s-api-roote/). Започнете с нуждата на вашия интерфейс и след това проверете реално наличните полета.

## Четене на откъси и избор на архитектура

В GTFS Schedule, откъс от stop_times.txt свързва едно пътуване, спирка и планирано преминаване. Учебният пример по-долу е опростен: той не представлява пълен GTFS комплект и неговите идентификатори трябва да бъдат свързани с trips.txt, stops.txt и календарите.

За GTFS Realtime, потърсете полезния обект: TripUpdate може да актуализира едно преминаване, VehiclePosition описва позиция, а Alert предава информация за услугата. Позицията на превозно средство не е автоматично оценка за пристигане. Предаваният формат е Protocol Buffers; JSON представяне за диагностика не е референтният бинарен поток.

В GBFS, station_information описва станциите, докато station_status описва техните публикувани състояния. Имената на някои броячи и наличните файлове се променят според версията. JSON откъсът по-долу илюстрира GBFS 2.3 и неговите полета num_bikes_available и num_docks_available; проверявайте версията преди да използвате пример.

Карта на местоположения може да започне със структурни данни. Екран с предстоящи преминавания изисква съответните актуализации и изрично планирано резервно решение. Екран с налични велосипеди трябва да управлява броячи, условия за наемане и временна валидност. Тези три екрана не споделят автоматично една и съща кеш политика.

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

[Форматиране на наличността на велосипеди и тяхната актуалност](https://www.roote.ai/bg/guides/nalichnost-na-kolichkite-v-realno-vreme-kak-da-se-pokaje-v-prilozhenie/)

[Избор на API или MCP за вашия продукт](https://www.roote.ai/bg/guides/api-ili-mcp-izbor-za-integraciya-na-danni-za-mobilnost/)

## Често задавани въпроси

### Съдържа ли GTFS автоматично данни в реално време?

Не. GTFS Schedule представлява планираната оферта; актуализираната информация идва от други потоци, включително GTFS-RT.

### Позволява ли GBFS отключване на велосипед?

Той описва услугата и нейните публични данни. Наемането се управлява чрез възможностите, предоставени от оператора.

### Гарантира ли стандартният формат пълно покритие?

Не. Форматът дефинира структура; покритието и публикуваната информация зависят от източниците.