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

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

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

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

Един набор GTFS Schedule събира таблични файлове, описващи операторите, спирките, линиите, курсовете и техните преминавания. Календарите посочват конкретните дни. Файловете са свързани чрез идентификатори. Референция GTFS Schedule.

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

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

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

GTFS Realtime може да предоставя актуализации на курсовете, позиции на превозни средства и предупреждения. Актуализациите на курсовете обхващат преминавания и промени в услугата. Потоковете използват Protocol Buffers, структуриран формат за сериализация. Въведение в GTFS Realtime.

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

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

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

GBFS използва JSON потоци за описание на услуга за споделена мобилност. В зависимост от системата и версията, те могат да съдържат информация за станции, тяхното състояние, превозни средства и други характеристики на услугата. Документацията ясно различава информация за станциите и състоянията на наличност. Документация GBFS.

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

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

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

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

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

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

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

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

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

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

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

В 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
}

Форматиране на наличността на велосипеди и тяхната актуалност

Избор на API или MCP за вашия продукт

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

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

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

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

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

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

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