Рекомендации по работе с GTFS

Основные рекомендации

Инструкции по описанию услуг общественного транспорта в общей спецификации фидов систем общественного транспорта (GTFS) основываются на опыте участников рабочей группы GTFS Best Practices Working Group и советах по созданию приложений, использующих данные GTFS. Подробная информация доступна в ответах на часто задаваемые вопросы.

Структура документа

Рекомендации разделены на три основные группы:

Часто задаваемые вопросы

Почему важно использовать рекомендации по работе с GTFS?

Эти рекомендации разработаны для достижения следующих целей:

  • повышение удобства пользования приложениями для общественного транспорта;
  • широкая совместимость данных, позволяющая разработчикам ПО легко развертывать и масштабировать приложения, продукты и сервисы;
  • использование этих рекомендаций в других приложениях, помимо решений, ориентированных на планирование поездок.

Отсутствие единых рекомендаций при разработке клиентских приложений, использующих данные GTFS, может привести к возникновению разрозненных требований и ожиданий, а также плохо совместимых наборов данных для конкретных приложений. До того как были выпущены рекомендации, существовали серьезные разногласия и двусмысленность в определении того, что представляют собой правильно сформированные данные GTFS.

Как и кем разрабатывались рекомендации?

Составлением этих рекомендаций занималась рабочая группа из 17 организаций, активно использующих GTFS, включая разработчиков приложений, потребителей данных, транспортных перевозчиков и консультантов. Группа была создана на базе и при содействии организации Rocky Mountain Institute.

Для утверждения каждой рекомендации проводилось отдельное голосование. Практически все рекомендации были приняты единогласно, и лишь некоторые были одобрены большинством голосов.

Почему нельзя просто изменить справочное руководство по GTFS?

Хороший вопрос! В ходе изучения руководства, процедуры передачи данных и других процессов потребовалось внести некоторые изменения в спецификацию (см. закрытые pull-запросы в GitHub). Обычно поправки в руководство подлежат более строгому рассмотрению, чем рекомендации. Тем не менее существовала необходимость в создании четкого набора рекомендаций.

Рабочая группа считает, что со временем некоторые из них станут частью основного справочного руководства по GTFS.

Проверяют ли валидаторы GTFS соответствие этим рекомендациям?

В настоящее время ни один валидатор не проверяет соответствие всем рекомендациям. Для проверки отдельных рекомендаций используются различные инструменты. Список доступных валидаторов GTFS опубликован на странице тестирования фидов. Если вы разработаете валидатор GTFS для проверки соответствия этим рекомендациям, отправьте письмо по адресу gtfs@rmi.org.

Я представляю транспортное агентство. Какие шаги необходимо предпринять, чтобы разработчики и поставщики ПО следовали рекомендациям?

Порекомендуйте поставщику или разработчику, у которого вы планируете приобрести программное обеспечение с поддержкой GTFS, ознакомиться с этими рекомендациями: предоставьте им ссылки на рекомендации по работе с GTFS и основное руководство со спецификациями.

Что делать, если фид данных GTFS не соответствует рекомендациям?

Контактные данные лица для решения проблемы с фидом могут быть указаны в поле feed_contact_email или feed_contact_url в feed_info.txt (при наличии). Также эту информацию можно узнать на сайте транспортного агентства или поставщика фида. В сообщении о несоответствии предоставьте ссылку на конкретный пункт рекомендаций по работе с GTFS. См. раздел о предоставлении ссылок на этот документ.

Как предложить изменение или дополнение к рекомендациям?

Можно отправить письмо по адресу gtfs@rmi.org, а также задать вопрос или создать pull-запрос в репозитории рекомендаций по работе с GTFS в GitHub.

Как принять участие в создании рекомендаций?

Отправьте письмо по адресу gtfs@rmi.org.

Публикация наборов данных и общие рекомендации

Общие рекомендации
Наборы данных следует публиковать по общедоступному постоянному URL, который включает имя ZIP-файла, например https://www.agency.org/gtfs/gtfs.zip. Предпочтительно, чтобы файл можно было скачать по URL-адресу напрямую без необходимости вводить данные для доступа, чтобы ускорить загрузку программными средствами. Это является общепринятой практикой. Несмотря на это, поставщик данных может контролировать доступ для лицензирования или по другим причинам с помощью ключей API, что позволит загружать файл автоматически.
Данные GTFS публикуются в виде итераций, поэтому каждый файл, находящийся в одном и том же месте, всегда будет содержать актуальное официальное описание услуг, предоставляемых транспортным агентством или агентствами.
По возможности используйте постоянные идентификаторы (поля с идентификаторами) для stop_id, route_id и agency_id во всех итерациях.
Один набор данных GTFS должен содержать сведения о текущих или будущих услугах. Иногда такие наборы называются "объединенные наборы данных". Функция объединения, доступная в инструменте transitfeed от Google, позволяет создавать объединенный набор данных из двух фидов GTFS.
  • Опубликованный набор данных GTFS должен быть постоянно доступен как минимум в течение 7 дней, а в идеале – до тех пор, пока оператор точно знает, что расписание будет продолжать действовать.
  • По возможности набор данных GTFS должен содержать актуальные сведения в течение 30 дней, на протяжении которых предоставляется сервис.
Удалите ненужные сервисы из фида, например просроченные календари.
Если изменения, внесенные в сервис, вступят в силу через 7 дней или раньше, используйте для их публикации фид GTFS в реальном времени (рекомендации по сервисному обслуживанию или обновления маршрутов) вместо статического набора данных GTFS.
Веб-сервер, на котором размещаются данные GTFS, должен быть правильно настроен, чтобы передавать корректные сведения о дате изменения файла (см. раздел 14.29 в документе HTTP/1.1 - Request for Comments 2616 LINK).

Рекомендации, сгруппированные по файлам

В этом разделе описаны рекомендации, сгруппированные по файлам и полям в соответствии со справочным руководством по GTFS.

Все файлы

Название поля Рекомендация
Смешанный регистр Во всех текстовых строках, которые видит пользователь на дисплеях с поддержкой отображения символов нижнего регистра, (например, в названиях остановок, станций, маршрутов и на маршрутоуказателях) должен использоваться смешанный регистр, а не исключительно верхний регистр, в соответствии с местными правилами написания топонимов.
Примеры:
Пушкинская площадь
Ростов-на-Дону
Арбатский переулок
Аббревиатуры Не используйте аббревиатуры в фидах и других текстах (например, пишите "улица" вместо "ул."), за исключением случаев, когда для обозначения места принято использовать сокращенное название (например, МКАД). ПО для озвучивания написанного текста и речевые интерфейсы разрабатываются для четкого воспроизведения полных слов, а при преобразовании аббревиатур в слова могут возникнуть ошибки.

agency.txt

Название поля Рекомендация
agency_id Требуется использовать, даже если в фиде указано только одно агентство (см. также рекомендации по указанию данных в поле agency_id в routes.txt и fare_attributes.txt).
agency_lang Требуется использовать.
agency_phone Требуется использовать, за исключением случаев, когда у агентства нет номера телефона службы поддержки.
agency_email Требуется использовать, за исключением случаев, когда у агентства нет адреса электронной почты службы поддержки.
agency_fare_url Требуется использовать, за исключением случаев, когда агентство предоставляет услуги бесплатно.

Примеры:

  • Несколько небольших агентств занимаются автобусными перевозками. Также есть одно крупное агентство, которое составляет расписание, продает билеты и поэтому отвечает за предоставление услуг с точки зрения пассажиров. Следовательно, в фиде требуется указать только это агентство, даже если данные внутри системы распределяются между небольшими агентствами.
  • Поставщик фида управляет порталом по продаже билетов. Также есть разные агентства, которые занимаются транспортными перевозками и являются ответственными за предоставление этих услуг с точки зрения пассажиров. Соответственно, эти агентства должны быть указаны в фиде.

stops.txt

Название поля Рекомендация
stop_id Для обозначения остановок, которые находятся в разных местах (т. е. в местах, обозначенных специальными знаками, с навесами или другими указателями для остановки на маршруте, по которому следует транспортное средство, а также в местах, расположенных на противоположных сторонах перекрестка или с разными платформами либо автобусными карманами, даже если они находятся рядом с друг другом) необходимо указывать разные stop_id.
stop_id – это внутренний идентификатор, не предназначенный для пассажиров.
Используйте одинаковые stop_id для соответствующих остановок во всех итерациях (см. Публикация наборов данных и общие рекомендации).
stop_name Данные в поле stop_name должны совпадать с официальным названием остановки, станции или посадочной платформы, т. е. с той информацией, которая указана в расписании, на сайте и/или непосредственно на месте.
Если эти сведения отсутствуют, следуйте единым правилам наименования остановок во всем фиде.
Не используйте аббревиатуры в названиях остановок, за исключением мест, которые принято называть в сокращенной форме. См. "Аббревиатуры" (пункт 2) в разделе Все файлы.
Укажите названия остановок в смешанном регистре, следуя местным правилам написания топонимов и учитывая рекомендации по заполнению текстовых полей, которые видны пользователю.
По умолчанию в поле stop_name не должно быть общих или ненужных слов, таких как "вокзал" или "станция", за исключением случаев,
  • когда эти слова являются частью названия (например, Белорусский вокзал)
  • Если поле stop_name содержит слишком обобщающее название (например, название города), можно использовать слова "вокзал", "станция", "остановка" или другие дескрипторы, чтобы точно передать значение.
stop_lat и stop_lon Местоположение станций и остановок должно быть указано максимально точно. Погрешность координат может составлять не более четырех метров по сравнению с фактическим местоположением.
Местоположение остановок и станций следует указывать в соответствии с преимущественным правом движения пешехода, т. е. там, где пассажир садится в транспортное средство (с правильной для него стороны улицы).
Если одно местоположение одновременно указано в отдельных фидах данных (т. е. разные агентства используют одну и ту же остановку или посадочную платформу), необходимо указать, что оно является общим. Для этого введите одинаковые координаты в поля stop_lat и stop_lon для обеих остановок.
stop_code Требуется указывать stop_code, если в фиде GTFS используются номера остановок или короткие идентификаторы, которые видны пассажирам.
parent_station и location_type На многих вокзалах есть различные виды мест для посадки пассажиров. Например, автобусные карманы, платформы, причалы, выходы на посадку и т. д. В таком случае поставщики фидов должны описать взаимосвязь между вокзалом и местами для посадки (также называемые дочерними остановками).
  • Вокзал следует обозначить как запись в файле stops.txt с указанием location_type = 1.
  • Каждое место для посадки должно быть обозначено как остановка с указанием location_type = 0. В поле parent_station должен использоваться идентификатор вокзала stop_id, где находится место для посадки.
Используйте названия, которые хорошо знакомы пассажирам и благодаря которым они могут легко найти нужный вокзал и место для посадки (автобусный карман, платформу, причал, выход на посадку и т. д.).
Название вокзала Название дочерних остановок
Белорусский вокзал Белорусский вокзал, платформа 3
Северный речной вокзал Северный речной вокзал, причал 1
Московский автовокзал Московский автовокзал, перрон 5

routes.txt

Название поля Рекомендация
agency_id Требуется использовать, если этот идентификатор указан в agency.txt.
route_short_name Используйте route_short_name, если есть краткое описание услуги. Это должно быть общеизвестное название, содержащее не более 12 символов.
route_long_name Как описано в основной спецификации: Это название обычно более информативно, чем route_short_name, и часто включает название пункта назначения или остановки. Требуется указать хотя бы одно название (route_short_name или route_long_name) либо оба по возможности. Если у маршрута нет длинного названия, введите короткое route_short_name и используйте пустую строку в качестве значения для этого поля.

Примеры длинных названий приведены ниже.

Основной транспортный путь или коридор
Название маршрута Форма Агентство
N/Judah route_short_name/
route_long_name
Muni в Сан-Франциско
6/ML King Jr Blvd route_short_name/
route_long_name
TriMet в Портленде, штат Орегон
6/Nation - Étoile route_short_name/
route_long_name
RATP в Париже, Франция
U2/Pankow – Ruhleben route_short_name/
route_long_name
BVG в Берлине, Германия
Описание услуги
Hartwell Area Shuttle
Длинное название route_long_name не должно содержать короткое route_short_name.
При добавлении данных в поле route_long_name используйте полное описание услуги. Примеры:
Услуга Рекомендация Примеры
Маршруты скоростных трамваев MAX Light Rail
компании TriMet в Портленде, штат Орегон
Поле route_long_name должно содержать название бренда (MAX) и маршрута. Линия MAX Red Line
Линия MAX Blue Line
Автобусные перевозки Rapid Ride
транспортного департамента ABQ Ride в Альбукерке, штат Нью-Мексико
Поле route_long_name должно содержать название бренда (Rapid Ride) и маршрута. Линия Rapid Ride Red Line
Линия Rapid Ride Blue Line
route_id У всех линий маршрута должен быть одинаковый идентификатор route_id.
  • Для направлений маршрута нельзя использовать разные значения в поле route_id.
  • Нельзя использовать разные значения в поле route_idдля обозначения интервалов движения транспорта по маршруту, т. е. в файле routes.txt не должно быть разных записей для дневного и ночного расписания.
Если группа маршрутов содержит ветки с отдельными названиями маршрутов (например, 1A и 1B), следуйте рекомендациям по описанию веток, чтобы правильно указать названия в полях route_short_name и route_long_name.
route_color и route_text_color Цвет маршрута и текста, связанного с ним, должен совпадать с цветом, который используется на информационных табло, сайтах и в печатных материалах при наличии.

trips.txt

  • Подробная информация доступна в разделе о кольцевых маршрутах. На кольцевых маршрутах поездки начинаются и заканчиваются на одной и той же остановке или станции, в отличие от линейных маршрутов, у которых есть два отдельных пункта для отправления и прибытия. Описывайте кольцевые маршруты в соответствии с рекомендациями, указанными здесь.
  • Подробная информация доступна в разделе о петлевых маршрутах. Структура петлевых маршрутов совмещает линейные и кольцевые характеристики, т. е. транспортные средства движутся по кругу только на определенном отрезке маршрута. Описывайте петлевые маршруты в соответствии с рекомендациями, указанными здесь.
Название поля Рекомендация
trip_headsign Не вводите названия маршрутов, совпадающих с названиями в полях route_short_name и route_long_name, в поля trip_headsign или stop_headsign.
Это поле должно содержать информацию о пункте назначения и маршруте и/или другой текст, который отображается на маршрутоуказателе транспортного средства для обозначения различных направлений маршрута. Сведения о направлении движения в наборах данных GTFS должны полностью совпадать с информацией, отображаемой на маршрутоуказателях транспортных средств. Можно указывать дополнительные данные, если они не противоречат основным. Если во время рейса информация на маршрутоуказателях меняется, замените trip_headsign на stop_times.stop_headsign. Ниже приведены рекомендации для некоторых случаев.
Пример таблицы
Описание маршрута Рекомендация
2A. Только для пункта назначения Укажите пункт назначения, например "Трензит-сентер", "Портленд Сити Сентер" или "Янцен-бич".
2B. Пункты назначения с путевыми точками До <пункта назначения> через <путевую точку>. Например, "Хайгейт через Чарджинг-кросс". Если путевые точки больше не отображаются на маршрутоуказателях после того, как транспортное средство проезжает их, используйте поле stop_times.stop_headsign, чтобы показывать обновленные данные.
2C. Название пункта назначения с местными остановками Если в городе или районе будет несколько остановок до прибытия в пункт назначения, используйте stop_times.stop_headsign.
2D. Только для направления Указывайте направление с помощью слов "в северном направлении", "прибытие", "по часовой стрелке" и т. д.
2E. Направление с пунктом назначения Указывайте <направление> до <пункта назначения>, например "В южном направлении до Сан-Франциско".
2F. Направление с пунктом назначения и путевыми точками Указывайте <направление> через <путевую точку> до <пункта назначения>. Например, "В северном направлении через Чаринг-кросс до Хайгейта".
Не используйте такие слова, как "до", в начале текста, отображаемого на маршрутоуказателе.
direction_id Если рейсы по маршруту выполняются в противоположных направлениях, обозначьте эти группы рейсов в поле direction_id с помощью значений 0 и 1.
Используйте значения 0 и 1 в наборе данных в соответствии с рекомендациями, указанными ниже.
  • Если 1 = прибытие для маршрута по красной линии, то 1 = отправление для маршрута по зеленой линии.
  • Если 1 = в северном направлении до маршрута X, то 1 = в северном направлении до маршрута Y.
  • Если 1 = по часовой стрелке по маршруту X, то 1 = по часовой стрелке по маршруту Y.

stop_times.txt

Для ввода данных о кольцевых маршрутах в поле stop_times существуют специальные инструкции, описанные в разделе о кольцевых маршрутах.

Название поля Рекомендация
pickup_type и drop_off_type Для обозначения некоммерческих (бесплатных) рейсов, во время которых не предоставляются услуги по обслуживанию пассажиров, должно использоваться значение 1 в полях pickup_type и drop_off_type для всех строк stop_times.
Во время коммерческих рейсов для обозначения внутренних временных точек, используемых для мониторинга эксплуатации транспортных средств и мест, таких как гаражи, не предназначенных для пассажиров, необходимо использовать pickup_type = 1 (посадка недоступна) и drop_off_type = 1 (высадка недоступна).
timepoint Необходимо ввести данные в timepoint. В этом поле определяется расписание остановок stop_times, которое оператор будет строго соблюдать (timepoint=1), а также указывается приблизительное время для других остановок (timepoint=0).
arrival_time и departure_time В полях arrival_time и departure_time по возможности должны быть указаны временные значения, включая неточное оценочное или интерполированное время между контрольными временными точками.
stop_headsign

Значения stop_headsign имеют приоритет над значениями trip_headsigntrips.txt). Значения stop_headsign необходимо предоставить, когда текст, отображаемый на маршрутоуказателе, изменяется во время рейса. Значения stop_headsign не переносятся для обозначения последующих остановок, поэтому их следует повторить, если текст на маршрутоуказателе остается прежним. В целом значения маршрутоуказателей должны соответствовать информации, доступной на остановках или станциях.

В приведенных ниже примерах текст "В южном направлении" может ввести пассажиров в заблуждение, так как он не используется на знаках и табло, расположенных на остановке или станции.

В городе Нью-Йорке, поезд метро 2, в южном направлении
Для строк stop_times.txt: Используйте значение stop_headsign:
До прибытия на Манхеттен Manhattan & Brooklyn
До прибытия в центр Downtown & Brooklyn
До прибытия в Бруклин Brooklyn
По прибытии в Бруклин Brooklyn (New Lots Av)
В Бостоне, для маршрута Red Line в южном направлении, для ветки до Брейнтри
Для строк stop_times.txt: Используйте значение stop_headsign:
До прибытия в центр Inbound to Braintree
По прибытии в центр Braintree
После прибытия в центр Outbound to Braintree
shape_dist_traveled Значение shape_dist_traveled необходимо указать для маршрутов, которые идут по кругу или накладываются друг на друга (когда транспортное средство пересекает одно и то же место или проезжает по кругу в рамках одного рейса). См. рекомендации по использованию shapes.shape_dist_traveled.

calendar.txt

Название поля Рекомендация
Все поля В calendar_dates.txt можно указывать ограниченное количество исключений для расписания. Для настройки сервиса с регулярным расписанием необходимо использовать calendar.txt.
Использование поля calendar.service_name повысит уровень восприятия данных GTFS, однако это не требуется согласно спецификации.

calendar_dates.txt

Название поля Рекомендация
Все поля В calendar_dates.txt можно указывать ограниченное количество исключений для расписания. Для настройки сервиса с регулярным расписанием необходимо использовать calendar.txt.
Использование поля calendar.service_name повысит уровень восприятия данных GTFS, однако это не требуется согласно спецификации.

fare_attributes.txt

Название поля Рекомендация
Все поля Идентификатор agency_id должен быть указан в fare_attributes.txt, если он используется в поле agency.txt.
Если невозможно точно смоделировать систему тарифов, оставьте это поле пустым, чтобы не вводить пассажиров в заблуждение.
Укажите тарифы (fare_attributes.txt и fare_rules.txt) и смоделируйте их как можно точнее. В крайнем случае, когда невозможно точно смоделировать тариф, укажите более дорогой вариант, чтобы пассажиры не пытались сесть в транспортное средство по неправильному тарифу. Если большинство тарифов не получается смоделировать корректно, не указывайте эту информацию в фиде.

fare_rules.txt

Название поля Рекомендация
Все поля Идентификатор agency_id должен быть указан в fare_attributes.txt, если он используется в поле agency.txt.
Если невозможно точно смоделировать систему тарифов, оставьте это поле пустым, чтобы не вводить пассажиров в заблуждение.
Укажите тарифы (fare_attributes.txt и fare_rules.txt) и смоделируйте их как можно точнее. В крайнем случае, когда невозможно точно смоделировать тариф, укажите более дорогой вариант, чтобы пассажиры не пытались сесть в транспортное средство по неправильному тарифу. Если большинство тарифов не получается смоделировать корректно, не указывайте эту информацию в фиде.

shapes.txt

Название поля Рекомендация
Все поля Траектории движения транспортных средств, чьи маршруты пересекаются (например, маршрут 1 и маршрут 2 проходят по одним и тем же рельсам или трассе), по возможности должны совпадать в точности. Это позволит создавать высококачественные схемы движения общественного транспорта.
Траектории должны проходить по центральной части пути с преимущественным правом проезда, по которому движется транспортное средство. Это может быть центральная часть улицы, если нет выделенных полос, или центральная линия проезжей части в направлении движения транспортного средства.

Траектории не должны резко сворачивать к остановке, платформе или месту посадки.
shape_dist_traveled

Это поле необходимо использовать в файлах shapes.txt и stop_times.txt, если траектории движения идут по кругу или накладываются друг на друга (например, когда транспортное средство пересекает одну и ту же траекторию или проезжает по кругу в рамках одного рейса).

Маршрут, проходящий по одинаковой траектории

Если во время рейса транспортное средство движется по той же траектории или пересекает ее в определенных точках, в поле shape_dist_traveled важно указать, как эти точки в файле shapes.txt соотносятся с записями в stop_times.txt.

В поле shape_dist_traveled агентство может точно описать схему пройденного расстояния и указать, как остановки в файле stop_times.txt формируют соответствующие фигуры. Значение, которое необходимо использовать в поле shape_dist_traveled, – это расстояние от начала фигуры, пройденное транспортным средством, (аналогично показаниям одометра).
  • Траектории (в файле shapes.txt) должны проходить в пределах 100 метров от остановок, вдоль которых проходит маршрут.
  • Упростите траектории, чтобы в файле shapes.txt не было лишних точек, т. е. удалите ненужные точки на прямых отрезках (см. раздел об упрощении отображения линий).

feed_info.txt

Требуется использовать файл feed_info.txt со всеми полями, указанными ниже.

Название поля Рекомендация
feed_start_date и feed_end_date Требуется использовать
feed_version Требуется использовать
feed_contact_email и feed_contact_url Укажите хотя бы одно из них

frequencies.txt

Название поля Рекомендация
Все поля Фактическое время остановок для рейсов, указанных в файле frequencies.txt, игнорируется. Для рейсов, основанных на частоте движения, учитываются только интервалы времени между остановками. Чтобы пассажирам было удобно воспринимать информацию, время первой остановки, указанной в файле frequencies.txt, должно начинаться с 00:00:00 (первое значение 00:00:00 в поле arrival_time).
block_id Это поле можно использовать для обозначения рейсов, основанных на частоте движения.

transfers.txt

Поле transfers.transfer_type может быть представлено одним из четырех значений, описанных в рекомендациях по работе с GTFS. Перечисленные ниже определения для transfer_type взяты из спецификации GTFS. Также мы добавили более детальные разъяснения.

Название поля Рекомендация
transfer_type 0 или (пусто) – рекомендуемая точка пересадки между маршрутами.

Если есть несколько точек пересадки, включая главный транспортный узел (например, пересадочный центр с соответствующей инфраструктурой или вокзал с прилегающими или соединенными платформами либо местами для посадки), необходимо указать рекомендуемый пункт пересадки.

1 – точка скоординированной по времени пересадки между двумя маршрутами. Транспорт должен отправиться отсюда только после того, как на остановку прибудет другое транспортное средство и пройдет достаточно времени, чтобы пассажиры могли пересесть.

Этот тип имеет приоритет над требуемым интервалом, чтобы обеспечить комфортную пересадку. Например, на Google Картах указано, что пассажирам требуется 3 минуты, чтобы успеть совершить пересадку. В других приложениях по умолчанию могут быть предложены другие значения.

2 – для этого типа пересадки необходимо, чтобы между прибытием и отправлением у пассажира оставался хотя бы минимальный запас времени. Время, требуемое для пересадки, указывается в поле min_transfer_time.

Укажите минимальное время пересадки, если есть факторы, которые могут увеличить время движения между остановками.

3 – пересадка между маршрутами в этой точке невозможна.

Укажите это значение, если пересадки невозможны из-за физических препятствий или если они небезопасны из-за отсутствия пешеходных переходов либо из-за других сложных дорожных условий.

Если между рейсами разрешены пересадки с указанием посадочного места, то последняя остановка прибывающего рейса, должна совпадать с первой остановкой отправляющегося рейса.

Рекомендации, сгруппированные по конкретным случаям

В этом разделе описаны конкретные случаи и последствия, которые могут возникнуть в результате изменений файлов и полей.

Кольцевые маршруты

На кольцевых маршрутах рейсы начинаются и заканчиваются в одном и том же месте (иногда в транспортно-пересадочном пункте). Транспортные средства двигаются по кругу, а пассажирам не требуется их покидать на конечной остановке.

Ниже изображен кольцевой маршрут. Транспортное средство возвращается в исходную точку, делая круг за один рейс. На некоторых кольцевых маршрутах предлагаются рейсы в одном направлении, а на других – в двух.
Кольцевой маршрут

Следовательно, на маршрутоуказателях необходимо показывать корректные данные, чтобы пассажиры видели, в каком направлении движется транспортное средство.

Чтобы сообщить, что направление движения изменилось, укажите stop_headsigns в файле stop_times.txt. stop_headsign описывает направление рейсов, отправляющихся с соответствующей остановки. Добавив stop_headsigns для каждой остановки, вы сможете обновлять информацию на маршрутоуказателе во время рейса.

Не указывайте один круговой рейс в файле stop_times.txt для маршрута, который проходит между двумя точками (например, когда один и тот же автобус движется по маршруту туда и обратно). Вместо этого разделите рейс на два отдельных направления.

Примеры моделирования круговых рейсов

Круговой рейс с маршрутоуказателем, обновляемым для каждой остановки

Trip_id arrival_time departure_time stop_id stop_sequence stop_headsign
trip_1 06:10:00 06:10:00 stop_A 1 "B"
trip_1 06:15:00 06:15:00 stop_B 2 "C"
trip_1 06:20:00 06:20:00 stop_C 3 "D"
trip_1 06:25:00 06:25:00 stop_D 4 "E"
trip_1 06:30:00 06:30:00 stop_E 5 "A"
trip_1 06:35:00 06:35:00 stop_A 6 ""

Круговой рейс с двумя маршрутоуказателями

Trip_id arrival_time departure_time stop_id stop_sequence stop_headsign
trip_1 06:10:00 06:10:00 stop_A 1 "outbound"
trip_1 06:15:00 06:15:00 stop_B 2 "outbound"
trip_1 06:20:00 06:20:00 stop_C 3 "outbound"
trip_1 06:25:00 06:25:00 stop_D 4 "inbound"
trip_1 06:30:00 06:30:00 stop_E 5 "inbound"
trip_1 06:35:00 06:35:00 stop_F 6 "inbound"
trip_1 06:40:00 06:40:00 stop_A 7 ""
Название поля Рекомендация
trips.trip_id Смоделируйте полный круговой маршрут туда и обратно в рамках одного рейса.
stop_times.stop_id Укажите первую/последнюю остановку дважды в файле stop_times.txt для кольцевого маршрута (см. пример ниже). Часто первые и последние остановки являются только точками отправления и прибытия, т. е. транспортное средство не проходит через них, двигаясь по кругу. Эти остановки также требуется указать в файле.
trip_id stop_id stop_sequence
9000 101 1
9000 102 2
9000 103 3
9000 101 4
trips.direction_id Если транспортное средство двигается по кольцевому маршруту в противоположных направлениях (т. е. по и против часовой стрелки), для идентификатора direction_id необходимо использовать 0 или 1.
trips.block_id Непрерывные кольцевые маршруты обозначаются с помощью одинакового идентификатора block_id.

Петлевые маршруты

Петлевые маршруты состоят из элементов кольцевого и линейного маршрутов.

Ниже приведен пример петлевого маршрута из пункта А в пункт B, состоящий из трех отрезков:
  • прямой отрезок из пункта А в пункт B;
  • круг, который начинается и заканчивается в пункте B;
  • прямой отрезок из пункта B в пункт A.
Петлевой маршрут
Примеры:
Схема чикагского метрополитена (Chicago)
Автобусные маршруты из пригорода в центр города, например для Сент-Альберта (St. Albert) или Эдмонтона (Edmonton)
Коричневая линия чикагского метрополитена CTA Brown Line (сайт CTA и TransitFeeds)
Название поля Рекомендация
trips.trip_id Путь транспортного средства по петлевому маршруту (см. изображение выше) начинается в пункте А, проходит через пункт B, делая круг, и возвращается в пункт A. Для обозначения полного цикла движения транспортного средства туда и обратно можно использовать следующие значения:
  • одно значение/запись trip_id в файле trips.txt;
  • несколько значений/записей trip_id в файле trips.txt и block_id для указания непрерывности поездки.
  • stop_times.stop_headsign Транспортное средство движется по участку A–B вдоль остановок в обоих направлениях. Значение stop_headsign позволяет показывать актуальные данные о направлении движения на маршрутоуказателе. Следовательно, для рейсов, указанных ниже, рекомендуется использовать stop_headsign.
    Примеры:
    A через B
    A
    Фиолетовая линия Purple Line чикагского метрополитена Chicago Transit Authority
    "В южном направлении по кругу"
    "В северном направлении через круг"
    "В северном направлении до станции "Линден"
    Автобусные маршруты компании Edmonton Transit Service (например, маршрут 39)
    Остановка "Резерфорд"
    Остановка "Сенчери-парк"
    trip.trip_headsign Название рейса на маршрутоуказателе должно содержать общее описание маршрута и совпадать с информацией, которая отображается в расписании. Допустим, "Из Линдена в Лиден по кругу" (чикагский метрополитен) или "Из A до A по кругу B" (общий пример).

    Ветки

    Некоторые маршруты могут включать ветки. На них могут быть расположены как общие остановки, так и отдельные для каждой ветки. Через них также могут проходить общие и индивидуальные траектории движения. Связь между ветками можно указать с помощью названий маршрута, маршрутоуказателей и сокращенных названий рейсов в соответствии с рекомендациями, перечисленными ниже.

    Ниже представлены три возможные конфигурации веток маршрутов. Главная траектория движения обозначена черным цветом, а ветки – золотистым.
    Конфигурации веток маршрутов
    Название поля Рекомендация
    Все поля При обозначении веток маршрутов необходимо учитывать, какие названия используются в информационных ресурсах, доступных для пассажиров (см. два примера ниже).
    Если в расписании и табло, установленных на улице, используются два отдельных названия маршрутов (например, 1A и 1B), укажите их в полях route_short_name и/или route_long_name в соответствии с рекомендациями по работе с GTFS. Например, маршруты 2, 2A и 2B, обслуживаемые перевозчиком GoDurham Transit, проходят по одной и той же траектории практически вдоль всего маршрута, однако имеют ряд отличий, описанных ниже.
    • Маршрут 2 – это главный маршрут, движение по которому обеспечивается практически без перерывов.
    • Движение по маршруту 2 изменяется во время Main Street Nights и других праздников, а также по воскресеньям.
    • Движение по маршрутам 2A и 2B обеспечивается в дневное время с понедельника по субботу.
    • Маршрут 2B обслуживает дополнительные остановки, отклоняясь от общей траектории движения.
    Если в информации, предоставленной агентством, для обозначения веток указано одно и то же название маршрута, используйте поля trips.trip_headsign, stop_times.stop_headsign и/или trips.trip_short_name. Например, транспортные средства двигаются по маршруту GoTriangle 300 в разных направлениях в зависимости от времени суток. В часы пик к стандартному маршруту добавляются ветки, чтобы жители могли быстрее добираться на работу в город или возвращаться домой.

    О документе

    Цели

    Ниже перечислены цели, для достижения которых разработаны рекомендации:

    • более широкая совместимость данных, связанных с использованием общественного транспорта;
    • повышение удобства пользования приложениями для общественного транспорта;
    • оптимизация данных, позволяющая разработчикам ПО легко развертывать и масштабировать приложения, продукты и сервисы;
    • использование рекомендаций в других приложениях, помимо решений, ориентированных на планирование поездок.

    Как предлагать поправки и изменения в опубликованные рекомендации

    Приложения и рекомендации по работе с GTFS меняются, поэтому этот документ следует обновлять время от времени. Чтобы предложить поправку к этому документу, отправьте обоснование предлагаемого дополнения и pull-запрос в репозиторий GitHub для рекомендаций по работе с GTFS. Также свои предложения можно отправить по адресу specifications@mobilitydata.org.

    Предоставление ссылок на этот документ

    Предоставляйте поставщикам фидов ссылки на этот документ с рекомендациями, чтобы они правильно формировали данные GTFS. Для каждой рекомендации существует ссылка привязки. Нажмите на рекомендацию, чтобы получить URL-адрес ссылки привязки на странице.

    Если для работы приложения, использующего данные GTFS, существуют требования и инструкции, которые не описаны здесь, необходимо опубликовать документ, дополняющий общие рекомендации по работе с GTFS.

    Рабочая группа GTFS Best Practices Working Group

    Рабочая группа GTFS Best Practices Working Group была создана на базе организации Rocky Mountain Institute в 2016–2017 гг. В нее входят компании-перевозчики, разработчики приложений, использующих данные GTFS, консультанты и сотрудники научно-образовательных комплексов. В ее состав входят:

    В настоящее время разработкой этого документа занимается международная организация MobilityData.