Расписание становится частью цифровой поездки
Приложение строит поездку из остановок, рейсов и пересадок. GTFS Schedule описывает плановое движение, GTFS Realtime — изменения рейсов, предупреждения и положение транспорта. Маршрут зависит от того, насколько согласованы эти сведения.
Пример: пересадка в праздничный день
Представим вымышленную поездку: человек едет автобусом до трамвая в понедельник, который объявлен выходным. Основное расписание описывает обычную рабочую неделю, а исключение в календаре не опубликовано. Планировщик строит технически корректный маршрут по неверным для этого дня сведениям. Ошибки формата нет, но поездка не состоится как обещано.
Проверка должна начинаться с календаря обслуживания, а затем переходить к конкретному рейсу и пересадке. В таком случае обновление карты или точности координат автобуса не решит основную проблему. Пример показывает, почему качество транспортных данных нельзя оценивать только успешной загрузкой файла.
Идентификаторы связывают план с реальностью
Чтобы текущее сообщение относилось к нужному рейсу, системы должны одинаково понимать его идентификатор. Если при каждой выгрузке без причины меняются обозначения остановок и маршрутов, получателю приходится заново устанавливать связи. Рекомендации GTFS Realtime отдельно обращают внимание на сохранение идентификаторов между обновлениями потока.
Для команды публикации полезно проверять изменение справочников как отдельную операцию. Переименование остановки, временный перенос посадки и создание нового объекта — разные события. Если они выглядят одинаково, история распадается, предупреждения привязываются неверно, а приложения могут показывать рядом старую и новую остановки.
Свежесть не равна наличию ответа
Сервис может успешно отдавать файл с давно не обновлявшимися позициями. Поэтому наблюдать нужно время самих данных, охват рейсов и наличие пропусков. Зелёный индикатор доступности адреса не подтверждает, что пассажир получает актуальную информацию. В рекомендациях GTFS свежести потока уделено отдельное внимание.
При исчезновении текущих сведений приложение должно понятно перейти к плану либо обозначить неизвестность. Нарисованный на карте автобус без указания давности наблюдения создаёт ложную определённость. Издатель и потребитель данных должны заранее договориться, как распознают устаревание и что показывают человеку.
Проверять маршрут от двери до двери
Выберите несколько поездок с разными условиями: пересадка, последний вечерний рейс, выходной день и временно перенесённая остановка. Сопоставьте опубликованное расписание, предупреждения и фактическую организацию движения. Отдельно проверьте, соответствует ли направление маршрута стороне улицы, на которой предлагается ждать.
Автоматическая проверка схемы полезна для обязательных полей и связей между файлами. Наблюдение на месте отвечает на другой вопрос: отражают ли данные услугу, которую получает пассажир. Эти проверки дополняют друг друга. Прохождение одной нельзя использовать как доказательство результата другой.
Обновление должно иметь хозяина
Расписание меняют перевозчики, временные ограничения вводят службы, а файлы публикует отдельная команда. Опишите, кто сообщает об изменении, кто вносит его и кто проверяет появление в используемом приложении. Последний этап важен: опубликованные сведения могут ещё не попасть в маршрут, который видит человек.
