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

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

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

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

Рекомендации GTFS — пожалуйста, следуйте рекомендациям так, как если бы они были обязательными.

Загрузка GTFS-каналов — пожалуйста, следуйте этой процедуре для загрузки GTFS-канала.

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

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

Объем

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

Переводы

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

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

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

Примеры

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

Время остановок

В stop_times.txt необходимо указать как arrival_time, так и departure_time.

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

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

Станционные сооружения

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

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

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

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

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

Расширение для продажи билетов Google Transit

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

GTFS-Fares v1

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