Перейти к содержанию

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

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

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

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

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

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

  • Наборы данных должны быть опубликованы на общедоступном, постоянном URL, включая имя zip-файла. (например, GTFS/GTFS.zip">GTFS. В идеале, 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 feed (сервисные рекомендации или обновления поездок), а не через статический набор данных 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

Имя поля Рекомендация
route_short_name Включите route_short_name если имеется краткое обозначение услуги. Это должно быть общеизвестное пассажирское название услуги, не длиннее 12 символов.
route_long_name Определение из ссылки на спецификацию: Это имя обычно является более описательным, чем краткое_название_маршрута и часто включает конечный пункт или остановку маршрута. По крайней мере, одно из имя_короткого_маршрута или имя_длинного_маршрута должно быть указано, или, возможно, оба, если это уместно. Если маршрут не имеет длинного названия, укажите короткое_имя_маршрута и используйте пустую строку в качестве значения для этого поля.
Примеры типов длинных названий приведены ниже:
Основной путь движения или коридор
Название маршрутаФормаАгентство
"N"/"Judah"короткое_имя_маршрута/
имя_длинного_маршрута
Мунив Сан-Франциско
"6"/"ML King Jr Blvd"имя_короткого_маршрута/
имя_длинного_маршрута
TriMetв Портленде, Ор.
PHP?nompdf=m6">"6"/"Nation - Étoile"имя_короткого_маршрута/
имя_длинного_маршрута
RATPв Париже, Франция.
"U2"/"Панков - Рухлебен".короткое_имя_маршрута-
имя_длинного_маршрута
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 (нет возможности высадки).
    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 должно быть включено в fare_attributes.txt если это поле включено в agency.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_idstop_idstop_sequence
    90001011
    90001022
    90001033
    90001014
    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. Если вы написали инструмент валидатора GTFS, который ссылается на эти Лучшие практики, пожалуйста, напишите по адресу specifications@mobilitydata.org.

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

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

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

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

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

    Напишите по электронной почте specifications@mobilitydata.org или откройте проблему или запрос на исправление в GTFS-best-practices">репозитории GitHub GTFS Best Practices.

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

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

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

    Цели

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

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

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

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

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

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

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

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

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

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