Лучшая практика составления GTFS Schedule¶

Это рекомендуемые практики для описания услуг общественного транспорта в General Transit Feed Specification (GTFS). Эти рекомендации были обобщены на основе опыта членов GTFS Best Practices working group и application-specific GTFS practice recommendations.

Для получения дополнительной информации см. раздел Часто задаваемые вопросы.

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

Практики организованы в четыре основных раздела:

Публикация наборов данных и общие практики: Эти практики относятся к общей структуре набора данных GTFS и к тому, как публикуются наборы данных GTFS.
Рекомендации по практике, организованные по файлам: Рекомендации организованы по файлам и полям в GTFS, чтобы облегчить сопоставление практик с официальными ссылками GTFS.
Практические рекомендации, организованные по случаям: В особых случаях, таких как петлевые маршруты, может потребоваться применение практики в нескольких файлах и полях. Такие рекомендации объединены в данном разделе.

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

Наборы данных должны публиковаться по общедоступному постоянному URL-адресу, включая имя zip-файла. (например, www.agency.org/gtfs/gtfs.zip). В идеале URL-адрес должен быть доступен для прямой загрузки без необходимости входа в систему для доступа к файлу, чтобы облегчить загрузку путем использования программных приложений. Хотя рекомендуется (и это наиболее распространенная практика) сделать набор данных GTFS доступным для открытой загрузки, если поставщику данных необходимо контролировать доступ к GTFS по лицензированию или по другим причинам, рекомендуется контролировать доступ к набору данных GTFS с помощью ключей API. что облегчит автоматическую загрузку.
ДанныеGTFS публикуются итерациями, так что в одном файле в стабильном месте всегда содержится последнее официальное описание услуг для транзитного агентства (или агентств).
Поддерживать постоянные идентификаторы (поля id) для stop_id, route_id и agency_id во всех итерациях данных, когда это возможно.
Один набор данных GTFS должен содержать текущие и предстоящие услуги (иногда его называют "объединенным" набором данных). Для создания объединенного набора данных из двух разных фидов GTFS можно использовать функцию слияния инструмента Google transitfeed.
- В любое время опубликованный набор данных GTFS должен быть действителен как минимум на ближайшие 7 дней, а в идеале - до тех пор, пока оператор уверен, что Schedule будет действовать.
- Если возможно, набор данных GTFS должен охватывать как минимум следующие 30 дней обслуживания.
Удалите старые услуги (просроченные календари) из фида.
Если изменение услуги вступит в силу через 7 дней или меньше, сообщите об этом изменении услуги через фид GTFS-realtime (рекомендации по услугам или обновления о поездках), а не статический набор данных GTFS.
Веб-сервер, на котором размещаются данные GTFS, должен быть настроен на корректное сообщение даты модификации файла (см. HTTP/1.1 - Запрос на комментарии 2616, раздел 14.29).

Рекомендации по практике, упорядоченные по файлам¶

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

Все файлы¶

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

agency.txt¶

Имя поля	Рекомендация
`agency_id`	Должен быть включен, даже если в ленте присутствует только одно агентство. (См. также рекомендацию по включению `agency_id` в `routes.txt` и `fare_attributes.txt`)
`agency_phone`	Должен быть включен, если не существует телефона службы поддержки клиентов.
`agency_email`	Должен быть включен, если не существует телефона службы поддержки клиентов.
`agency_fare_url`	Должен быть включен, если только агентство не является полностью безбилетным.

Примеры:

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

stops.txt¶

Имя поля Рекомендация

stop_name Если нет опубликованного названия остановки, следуйте последовательным соглашениям об именовании остановок во всем фиде.

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

Когда это фактически является частью названия (Union Station, Central Station.
Когда stop_name является слишком общим (например, если это название города). "Станция", "Терминал" или другие слова делают смысл понятным.

stop_lat & stop_lon Расположение остановок должно быть максимально точным. Места остановок должны иметь погрешность не более не более четырех метров по сравнению с фактическим положением остановки.

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

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

parent_station & location_type

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

Станция или терминал должны быть определены как запись в stops.txt с location_type = 1.
Каждое посадочное устройство должно быть определено как остановка с location_type = 0. Сайт parent_station поле должно ссылаться на stop_id станции, на которой находится объект посадки.

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

Название родительской станции	Название дочерней остановки
Станция Чикаго Юнион	Станция Чикаго Юнион Стейшн Платформа 19
Терминал Сан-Франциско Ферри Билдинг	Терминал Сан-Франциско Ферри Билдинг Выход E
Центр транзитных перевозок в центре города	Центр транзитных перевозок в центре города Bay B

routes.txt¶

Имя поля Рекомендация

agency_id Должен быть включен, даже если в фиде только одно агентство. (См. также рекомендацию включать agency_id в agency.txt и fare_attributes.txt)

route_short_name Включите route_short_name если имеется краткое обозначение услуги. Это должно быть общеизвестное пассажирское название услуги, не длиннее 12 символов.

route_long_name

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

Основной путь движения или коридор
Название маршрута	Форма	Агентство
"N"/"Judah"	`короткое_имя_маршрута`/ `имя_длинного_маршрута`	Мунив Сан-Франциско
"6"/"ML King Jr Blvd"	`имя_короткого_маршрута`/ `имя_длинного_маршрута`	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" TriMet, в Портленде, штат Орегон	The `имя_маршрута` должна включать бренд (MAX) и обозначение конкретного маршрута.	"Красная линия MAX" "Синяя линия MAX"
"Rapid Ride" ABQ Ride, в Альбукерке, Нью-Мексико	The `имя_длинного_маршрута` должен включать марку (Rapid Ride) и конкретное обозначение маршрута.	"Rapid Ride Red Line" "Rapid Ride Blue Line"

route_id Все поездки на данном маршруте должны быть одинаковыми. route_id.
Различные направления маршрута не должны разделяться на разные route_id значения.
Различные периоды работы маршрута не должны разделяться на разные значения. route_id т.е. не следует создавать разные записи в routes.txt для услуг "Downtown AM" и "Downtown PM").

Если группа маршрутов включает ветки с разными названиями (например, 1A и 1B), следуйте рекомендациям в маршруте ветки для определения route_short_name и route_long_name.

route_color & route_text_color Должны соответствовать вывескам, печатной и онлайн-информации для клиентов (и, следовательно, не включаться, если они не существуют в других местах).

trips.txt¶

См. особый случай для кольцевых маршрутов: Петлевые маршруты - это случаи, когда поездки начинаются и заканчиваются на одной и той же остановке, в отличие от линейных маршрутов, которые имеют две разные конечные остановки. Петлевые маршруты должны быть описаны в соответствии со специальной практикой. См. случай с петлевыми маршрутами.
См. специальный случай для лассо-маршрутов: Маршруты Lasso - это гибрид линейного и петлевого маршрутов, при котором транспортные средства движутся по петле только на протяжении части маршрута. Маршруты лассо должны быть описаны в соответствии со специальной практикой. См. пример маршрута Лассо.

Имя поля Рекомендация

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. Направление с пунктом назначения и путевыми точками	через пункт назначения ( "На север через Чаринг-Кросс в Хайгейт")>.

Не начинайте указатель со слов "To" или "Towards".

direction_id

Используйте значения 0 и 1 последовательно во всем наборе данных.

Если 1 = выезд на красный маршрут, то 1 = выезд на зеленый маршрут.
Если 1 = движение на север по маршруту X, то 1 = движение на север по маршруту Y.
Если 1 = по часовой стрелке на маршруте X, то 1 = по часовой стрелке на маршруте Y.

stop_times.txt¶

Петлевые маршруты: Петлевые маршруты требуют особого внимания к времени остановки. (См.: Случай маршрута петли)

Имя поля Рекомендация

pickup_type & drop_off_type Неприбыльные (deadhead) поездки, которые не обеспечивают обслуживание пассажиров, должны быть отмечены значением pickup_type и drop_off_type значение 1 для всех 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 В целом, значения головных знаков также должны соответствовать знакам на станциях.

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

В Нью-Йорке для 2 поезда, следующего в южном направлении:
Для `stop_times.txt` rows:	Использовать `stop_headsign` значение:
Пока не достигнут Манхэттен	`Манхэттен и Бруклин`
Пока не будет достигнут центр города	`Даунтаун и Бруклин`
Пока Бруклин не достигнут	`Бруклин`
Когда Бруклин будет достигнут	`Бруклин (New Lots Av)`

В Бостоне для Красной линии, идущей в южном направлении, для ветки Braintree:
Для `stop_times.txt` ряды:	Использовать `stop_headsign` значение:
Пока не будет достигнут центр города	`Въезд в Брейнтри`
После достижения Даунтауна	`Braintree`
После Даунтауна	`Выход в Брейнтри`

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

calendar.txt¶

Имя поля	Рекомендация
Все поля	Включая а `calendar.service_name` поле может также повысить читаемость GTFS, хотя это не принято в спецификации.

calendar_dates.txt¶

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

fare_attributes.txt¶

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

fare_rules.txt¶

Имя поля Рекомендация

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

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

shapes.txt¶

Имя поля	Рекомендация
Все поля	В идеале, для общих маршрутов (т.е. в случае, когда маршруты 1 и 2 работают на одном участке проезжей части или пути) общая часть маршрута должна точно совпадать. Это способствует созданию высококачественной транзитной картографии.
	Выравнивания должны проходить по осевой линии полосы отвода, по которой движется транспортное средство. Это может быть либо осевая линия улицы, если нет выделенных полос, либо осевая линия той стороны проезжей части, по которой движется транспортное средство. Выравнивание не должно "упираться" в бордюр, платформу или место посадки.
`shape_dist_traveled`	Должны быть предусмотрены оба варианта `shapes.txt` и `stop_times.txt` если выравнивание включает в себя петли или инкрустацию (транспортное средство пересекает или проезжает по одному и тому же участку выравнивания за одну поездку). Если транспортное средство повторяет или пересекает маршрут в разных точках в течение поездки, `форма_расстояния_пройденного_пути` важно уточнить, как части точек в `shapes.txt` соответствуют записям в `stop_times.txt`.
	The `shape_dist_traveled` поле позволяет агентству точно указать, как остановки в `stop_times.txt` файле вписываются в соответствующую форму. Обычным значением, используемым для `shape_dist_traveled` является расстояние от начала фигуры, пройденное транспортным средством (представьте себе что-то вроде показаний одометра). Выравнивание маршрута (в `shapes.txt`) должны находиться в пределах 100 метров от мест остановок, которые обслуживает поездка. Упростите выравнивание так, чтобы `shapes.txt` не содержало лишних точек (т.е. удалите лишние точки на отрезках прямых линий; см. обсуждение проблемы упрощения линий).

frequencies.txt¶

Имя поля Рекомендация

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

block_id Может быть предоставлено для поездок, основанных на частоте.

transfers.txt¶

transfer.transfer_type может быть одним из четырех значений, определенных в GTFS. Эти определения transfer_type цитируются из Спецификации GTFS ниже, курсивом, с дополнительными практическими рекомендациями.

Имя поля	Рекомендация
`transfer_type`	0 или (пусто): Это рекомендуемый пункт пересадки между маршрутами. Если существует несколько возможностей пересадки, которые включают в себя лучший вариант (например, транзитный центр с дополнительными удобствами или станция с прилегающими или соединенными посадочными устройствами/платформами), укажите рекомендуемый пункт пересадки.
	1: Это пересадочный узел между двумя маршрутами. Ожидается, что отъезжающее транспортное средство будет ждать прибывающее, при этом у пассажира будет достаточно времени для пересадки с одного маршрута на другой. Этот тип пересадки отменяет требуемый интервал для надежного осуществления пересадок. Например, Google Maps предполагает, что пассажирам требуется 3 минуты для безопасной пересадки. Другие приложения могут принимать другие значения по умолчанию.
	2: Этот трансфер требует минимального количества времени между прибытием и отправлением для обеспечения соединения. Время, необходимое для пересадки, задается параметром `min_transfer_time`. Укажите минимальное время пересадки, если существуют препятствия или другие факторы, увеличивающие время движения между остановками.
	3: Пересадки между маршрутами в этом месте невозможны. Укажите это значение, если пересадки невозможны из-за физических барьеров или если они небезопасны или затруднены из-за сложных дорожных переходов или пробелов в пешеходной сети.
	Если пересадки между маршрутами разрешены, то последняя остановка прибывающего маршрута должна совпадать с первой остановкой отправляющегося маршрута.

feed_info.txt¶

Необходимо включить файлfeed_info.txt со всеми указанными ниже полями.

Имя поля	Рекомендация
`feed_start_date` & `feed_end_date`	Должен быть включен
`feed_version`	Должен быть включен
`feed_contact_email` & `feed_contact_url`	Укажите хотя бы одно

Практические рекомендации, организованные по кейсам¶

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

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

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

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

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

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

Примеры моделирования круговых поездок:

Круговая поездка с меняющимся указателем для каждой остановки

trip_id	время_прибытия	время_отправления	stop_id	stop_sequence	знак_остановки
поездка_1	06:10:00	06:10:00	стоп_а	1	"B"
поездка_1	06:15:00	06:15:00	стоп_B	2	"C"
поездка_1	06:20:00	06:20:00	стоп_С	3	"D"
поездка_1	06:25:00	06:25:00	стоп_D	4	"E"
поездка_1	06:30:00	06:30:00	стоп_Е	5	"A"
поездка_1	06:35:00	06:35:00	стоп_А	6	""

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

trip_id	время_прибытия	время_отправления	stop_id	stop_sequence	знак_остановки
поездка_1	06:10:00	06:10:00	стоп_а	1	"исходящий"
поездка_1	06:15:00	06:15:00	стоп_б	2	"исходящий"
поездка_1	06:20:00	06:20:00	стоп_С	3	"исходящий"
поездка_1	06:25:00	06:25:00	stop_D	4	"входящий"
поездка_1	06:30:00	06:30:00	стоп_Э	5	"входящий"
поездка_1	06:35:00	06:35:00	стоп_Ф	6	"входящий"
поездка_1	06:40:00	06:40:00	стоп_а	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.

Маршруты Лассо¶

Маршруты Lasso сочетают в себе аспекты кольцевого и направленного маршрута.

Примеры:
Маршруты метро (Чикаго)
Автобусные маршруты из пригорода в центр города (Сент-Альберт или Эдмонтон)
Коричневая линия CTA (Сайт CTA и TransitFeeds)

Имя поля Рекомендация

trips.trip_id Полный объем "кругового рейса транспортного средства" (см. иллюстрацию выше) состоит из поездки из A в B в B и обратно в A. Полный объем поездки транспортного средства туда и обратно может быть выражен:
A один trip_id значение/запись в trips.txt
Множество trip_id значения/записи в trips.txt, при этом непрерывный путь обозначается block_id.

stop_times.stop_headsign

Остановки на участке А-В будут пройдены в обоих направлениях. stop_headsign облегчает различение направления движения. Таким образом, обеспечение stop_headsign рекомендуется для этих поездок.example_table:

Примеры:
"A через B"
"A"

Чикагское транзитное управление Фиолетовая линия
"На юг через Петлю"
"Северное направление через Loop"
"Северное направление на Линден"

Автобусные линии Эдмонтонской транзитной службы, здесь 39
"Резерфорд"
"Century Park"

trip.trip_headsign Заголовок поездки должен представлять собой глобальное описание поездки, как показано в расписаниях. Это может быть "Linden to Linden via Loop" (пример Чикаго), или "A to A via B" (общий пример).

Ответвления¶

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

Имя поля	Рекомендация
Все поля	При наименовании маршрутов-ветвей рекомендуется руководствоваться другими информационными материалами для пассажиров. Ниже приведены описания и примеры двух случаев:
	Если в расписании и на уличных указателях представлены два маршрута с разными названиями (например, 1А и 1В), то представьте это как таковое в GTFS, используя поля `route_short_name` и/или `route_long_name` поля. Пример: GoDurham Transit маршруты 2, 2А и 2В имеют общее расположение на большей части маршрута, но они различаются по нескольким аспектам. Маршрут 2 является основным и работает большую часть времени. Маршрут 2 включает отклонение от маршрута на Главной улице по вечерам, воскресеньям и праздникам. Маршруты 2А и 2В работают в дневное время с понедельника по субботу. Маршрут 2В обслуживает дополнительные остановки, отклоняясь от общего маршрута.
	Если предоставленная агентством информация описывает филиалы как один и тот же маршрут, используйте поля `trips.trip_headsign`, `stop_times.stop_headsign`и/или `trips.trip_short_name` поля. Пример: GoTriangle маршрут 300 ходит в разные места в зависимости от времени суток. В часы пик к стандартному маршруту добавляются дополнительные участки, чтобы обслужить работников, въезжающих в город и выезжающих из него.

Часто задаваемые вопросы (FAQ)¶

Почему эти лучшие практики GTFS важны?¶

Целями Передовой практики GTFS являются:

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

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

Как они были разработаны? Кто их разрабатывал?¶

Эти лучшие практики были разработаны рабочей группой из 17 организаций, участвующих в GTFS, включая поставщиков приложений и потребителей данных, поставщиков транзитных услуг и консультантов, имеющих обширное участие в GTFS. Рабочая группа была созвана и проведена Институтом Роки Маунтин.

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

Почему бы просто не изменить ссылку на GTFS?¶

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

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

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

В настоящее время ни один инструмент проверки не проверяет соответствие всем передовым практикам. Различные инструменты проверки проверяют соответствие некоторым из этих рекомендаций. Список инструментов проверки GTFS см. в разделе GTFS Validators. Если вы пишете инструмент проверки GTFS, который ссылается на эти рекомендации, отправьте электронное письмо по адресу specifications@mobilitydata.org.

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

Обратитесь к своему поставщику или поставщику программных услуг, чтобы он ознакомился с передовым опытом. Мы рекомендуем ссылаться на URL "Лучшие практики GTFS ", а также на основные спецификации при закупке программного обеспечения, GTFS.

Что мне делать, если я заметил, что поток данных GTFS не соответствует этим Передовым практикам?¶

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

Я хотел бы предложить изменение/дополнение к Передовой практике. Как мне это сделать?¶

Отправьте электронное письмо по адресу specifications@mobilitydata.org или откройте проблему или запрос на включение в GitHub GTFS Best Practices repo.

Как мне принять участие?¶

Пишите по адресу specifications@mobilitydata.org.

О данном документе¶

Цели¶

Целями поддержания Передовой практики GTFS являются:

Поддержка большей совместимости транзитных данных
Улучшить потребительский опыт конечного пользователя в приложениях для общественного транспорта
облегчить разработчикам программного обеспечения развертывание и масштабирование приложений, продуктов и услуг.
Содействие использованию GTFS в различных категориях приложений (за пределами первоначального фокуса на планировании поездок).

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

Приложения и практика GTFS развиваются, поэтому время от времени в этот документ может потребоваться внесение поправок. Чтобы предложить поправку к этому документу, откройте запрос на включение в GTFS Best Practices GitHub repository и поддержите это изменение. Вы можете отправить любые комментарии по электронной почте на адрес specifications@mobilitydata.org.

Ссылка на данный документ¶

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

Если приложение, GTFS, предъявляет требования или рекомендации к практике формирования данных GTFS, которые не описаны здесь, рекомендуется опубликовать документ с такими требованиями или рекомендациями в дополнение к этим общим лучшим практикам.

Рабочая группа по лучшей практикеGTFS¶

Рабочая группа по лучшей практике GTFS была созвана Институтом Роки Маунтин в 2016-17 годах и состояла из поставщиков общественного транспорта, разработчиков приложений GTFS, консультантов и научных организаций для определения общей практики и ожиданий в отношении данных GTFS:

Сегодня этот документ поддерживается компанией MobilityData.