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 для бронювання або розблокування. Він допомагає виявити пропозицію; операція оренди є відповідальністю сервісу.
Порівняння залежно від випадку використання
| Потреба | Формат для розгляду |
|---|---|
| Описати заплановані зупинки та маршрути | GTFS Schedule |
| Інтерпретувати заплановані проходження та дні обслуговування | GTFS Schedule |
| Оновлювати проходження або отримувати інформацію про сервіс | GTFS-RT, залежно від опублікованих потоків |
| Локалізувати станції або транспортні засоби спільної мобільності | GBFS, залежно від опублікованих даних |
Приклад дизайну: карта відображає зупинки трамваїв і станції велосипедів. Вона використовує структурні дані для місць і оновлені стани для доступності велосипедів. Обидва шари мають різні вимоги до кешування і оновлення.
Передбачте обмеження кожного джерела
Перевіряйте версії, необов’язкові поля, охоплення і умови використання. Ідентифікатор має сенс лише в контексті: два виробника можуть використовувати однакові рядки для різних сутностей.
Також передбачайте відсутні або застарілі дані. Порожній список із недоступного потоку не слід представляти як відсутність сервісу. Уникайте тихого заміщення невідомої інформації на нуль.
Використовувати потоки безпосередньо чи 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 розблокувати велосипед?
Він описує сервіс та його публічні дані. Оренда здійснюється через можливості, запропоновані оператором.
Чи гарантує стандартний формат повне охоплення?
Ні. Формат визначає структуру; охоплення і опублікована інформація залежать від джерел.