Требования ГТФС

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

Требования по умолчанию

Статическая ссылка GTFS — применяются все требования по умолчанию.

Рекомендации GTFS . Следуйте рекомендациям, если они необходимы.

Загрузка фидов GTFS . Чтобы загрузить фид GTFS, выполните следующие действия.

Обновления. Обратите внимание, что после загрузки каналов их можно обновить, следуя процедуре, описанной здесь . Как правило, полное распространение этих обновлений фида может занять 2–3 дня.

Дополнительные требования

Объем

• Один фид GTFS должен охватывать одну страну или часть страны. Поездки, пересекающие границы страны, должны быть представлены в отдельных лентах для всего континента. Если фид GTFS охватывает что-то большее, чем страна, свяжитесь с командой Travel Transport .
  • Размер файлов в zip-файле GTFS не должен превышать 4 ГБ. Файлы большего размера обычно являются признаком неправильной практики, например, игнорирования параметров сжатия, предлагаемых frequencies.txt или аналогичных функций. Это может вызвать проблемы во время обработки. Если вы считаете, что вам нужны файлы размером более 4 ГБ, обратитесь к команде Travel Transport по адресу [e-mail] .
  • Данные за весь будущий период работы сервисов в фиде GTFS должны предоставляться при каждом обновлении данных GTFS. Сегментация услуг по разным периодам времени не приемлема.
• Все даты для данного оператора должны содержаться в одном фиде.

Переводы

• Переводы могут быть предоставлены через translations.txt и потребуются в странах, где:
  • Информация пользователям может предоставляться в различных алфавитах или в алфавитах, отличных от латиницы.
  • Информация пользователям может предоставляться на нескольких языках, или если организации могут использовать разные названия на этих языках (например, Брюссель/Брюссель/Брюссель).
• Сущности для перевода
  • названия агентств/остановок/маршрутов
  • указатели поездки/остановки

Названия маршрутов, краткие названия поездок и указатели.

• Головные знаки должны быть указаны для всех рейсов либо в trips.txt (если главный знак остается неизменным на протяжении всей поездки), либо в stop_times.txt (если главный знак меняется на разных этапах поездки).
• Обозначения должны соответствовать информации, которую пользователи могут найти на земле. Например, указатели, отображаемые на транспортном средстве или на вывесках.
• Если у маршрута есть имя, оно должно быть указано как long_name в routes.txt .
• Если маршрут имеет определенный номер или буквенно-цифровой идентификатор, который применяется ко всем поездкам по этому маршруту и ​​в обоих направлениях, его необходимо указать как короткое_имя в routes.txt .
• Если поездки внутри маршрута имеют индивидуальные идентификаторы (например, номера поездов), такие идентификаторы необходимо указывать в виде кратких названий поездок.
• Для услуг междугородной связи, не имеющих номеров и названий маршрутов, выбор названия маршрута становится проблематичным. Общее правило в таких ситуациях заключается в том, что сочетание названия маршрута и головного знака должно помочь пользователю однозначно идентифицировать транспортное средство. Например, название эксплуатационной организации может использоваться в качестве названия маршрута, а пункт назначения поездки (если он указан на транспортном средстве) должен использоваться в качестве указателя поездки.

Примеры

• Экспресс-поезд 11071 Индийских железных дорог Камаяни из Мумбаи в Варанаси. Примечание: номер 11071 обозначает конкретную поездку на поезде из Мумбаи в Варанаси, а не сам маршрут.
  • маршруты.txt:
    • короткое_имя: <пусто>
    • длинное_имя: Камаяни Экспресс
  • trips.txt:
    • trip_short_name: 11071
    • фирменный знак: Варанаси
• Автобус из Буэнос-Айреса в Кордову, которым управляет Chevallier Bus. Примечание. На автобусе, который обслуживает эту услугу, не отображается конкретное название маршрута. Вместо этого на видном месте отображается название эксплуатационного агентства и пункт назначения. У этой конкретной поездки нет индивидуального номера/идентификатора, который отличал бы ее от других поездок, выполняемых тем же агентством или по тому же маршруту. В этом случае допустимо использовать «Шевалье» как в качестве названия агентства (в agencies.txt ), так и в качестве длинного_имя маршрута (в routes.txt ). В качестве головного знака следует использовать пункт назначения. trip_short_name должно оставаться пустым.
  • маршруты.txt:
    • короткое_имя: <пусто>
    • длинное_имя: Шевалье
  • trips.txt:
    • trip_short_name: <пусто>
    • фирменный знак: Кордова

Остановить время

Оба прибытия_время и время отправления должны быть указаны в stop_times.txt .

Структура поездки

• Междугородние поездки, обслуживающие несколько городов/районов, должны осуществляться сквозным образом без сегментации (например, A->B->C, а не [A->B,A->C,B->C]), где A, B, C — городские районы. Например, автобус дальнего следования, следующий из Буэнос-Айреса в Кордову, с остановкой в ​​Росарио, следует представлять как поездку с остановками в этих трех городах, а не как три поездки «Буэнос-Айрес – Росарио», «Буэнос-Айрес – Кордова». и «Росарио – Кордова»
• В тех случаях, когда поставщик данных не может получить информацию о правильной структуре поездки, сегментированные поездки между городами могут предоставляться в индивидуальном порядке. Если такие поездки между городами имеют несколько точек посадки или высадки в пределах города (района города), сегментация по остановкам не допускается — все точки посадки и все точки высадки должны быть перечислены в таблице. Одна поездка.

Структуры станции

Для крупных станций, имеющих несколько платформ/отсеков, в фиде должны быть указаны отношения станция-платформа, а конкретные отсеки/платформы должны быть идентифицированы через поле Platform_code в stops.txt . Транспортные средства, которые постоянно отправляются или прибывают на определенную площадку или платформу, должны быть связаны с этой стоянкой или платформой в фиде GTFS. Если платформа отправления/прибытия или бухта меняются в разные дни/время отправления, эта информация может быть предоставлена ​​в режиме реального времени GTFS.

Местоположение станций/остановок

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

Дополнительные расширения GTFS

Требуется только для партнеров, которые хотят предоставлять информацию о ценах и наличии путем внедрения партнерских API.

Расширение Google Transit Ticketing

• Партнеры должны внедрить спецификацию расширения Google Transit Ticketing , которая является подмножеством расширения GTFS-Ticketing.
• Мы предъявляем следующие требования к билетным идентификаторам:
  • Идентификаторы билетов должны быть стабильными (т. е. разрешаться нечастое изменение по уважительной причине). В случаях изменения идентификаторов билетов потребуется обратная совместимость (минимальный период не менее 1 недели).
  • Для определения параметров SegmentKey в API-запросах необходимы ticketing_trip_id (в trips.txt ) и ticketing_stop_id (в ticketing_identifiers.txt ). Резервный вариант stop_sequence не поддерживается , поскольку он нестабилен.

GTFS-Тарифы v1

В справочнике Static GTFS указаны необязательные файлы fare_attributes.txt и fare_rules.txt . Если партнер интегрируется с партнерскими API, эти файлы не следует предоставлять.