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

Процесс внесения изменений в спецификацию

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

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

  1. Создать ветку git с обновлением всех соответствующих частей определения протокола, спецификации и файлов документации (за исключением переводов).
  2. Создайте запрос на поставку на сайте https://github.com/google/transit. Запрос на исправление должен содержать расширенное описание исправления. Создатель запроса становится его защитником.
  3. После того, как заявка зарегистрирована, она должна быть объявлена её защитником в списке рассылкиGTFS Changes, включая ссылку на заявку. После объявления запрос на исправление считается предложением. Запрос на исправление также должен быть отредактирован и содержать ссылку на объявление в Google Groups, чтобы их можно было легко сопоставить.
  4. Поскольку сторонник является соавтором, он должен подписать Лицензионное соглашение соавтора до того, как запрос будет принят.
  5. Далее следует обсуждение этого предложения. В качестве единственного форума для обсуждения должны использоваться комментарии к Pull-запросам.
  6. Обсуждение длится столько, сколько адвокат считает нужным, но должно быть не менее 7 календарных дней.
  7. Адвокат отвечает за своевременное обновление предложения (т.е. pull request) на основе комментариев, с которыми он согласен.
  8. В любой момент time защитник может заявить об отказе от предложения.
  9. Сторонник может призвать к голосованию по версии предложения в любой момент time после первоначального 7-дневного интервала, необходимого для обсуждения.
  10. Прежде чем призывать к голосованию, по крайней мере, один производитель GTFS и один потребитель GTFS должны реализовать предложенное изменение. Ожидается, что производитель (производители) GTFS включит изменение в публичный канал GTFS и предоставит ссылку на эти данные в комментариях к заявке, а потребитель (потребители) GTFS предоставит ссылку в комментариях к заявке на приложение, которое использует изменение нетривиальным образом (т.е. поддерживает новую или улучшенную функциональность).
  11. Голосование длится минимальный период, достаточный для того, чтобы покрыть 7 FULL календарных дней и 5 FULL швейцарских рабочих дней. Голосование заканчивается в 23:59:59 UTC.
  12. Сторонник должен объявить конкретное time end голосования в start голосования.
  13. В период голосования разрешены только редакционные изменения предложения (опечатки, формулировки могут быть изменены, если это не меняет смысла).
  14. Любой желающий может проголосовать "да/нет" в форме комментария к pull request, и голоса могут быть изменены до end периода голосования. Если голосующий меняет свой голос, рекомендуется сделать это, обновив первоначальный комментарий к голосованию, зачеркнув его и написав новый голос.
  15. Голоса, отданные до start периода голосования, не учитываются.
  16. Об открытии и закрытии голосования должно быть объявлено в списке рассылки.
  17. Предложение принимается, если за него единогласно проголосовало не менее 3 человек.
  18. Голос автора предложения не учитывается при подсчете 3 голосов. Например, если автор предложения X создал запрос на исправление и проголосовал "за", а пользователи Y и Z проголосовали "за", это будет считаться как 2 голоса "за".
  19. Голоса против должны быть мотивированными и в идеале предоставлять действенную обратную связь.
  20. Если голосование провалилось, то сторонник может продолжить работу над предложением или отказаться от него. Любое решение сторонника должно быть объявлено в списке рассылкиGTFS Changes.
  21. Если сторонник продолжает работу над предложением, то новое голосование может быть назначено в любой момент time.
  22. Любой запрос на поставку, остающийся неактивным в течение 30 календарных дней, будет закрыт. Когда запрос на исправление закрыт, соответствующее предложение считается отмененным. Сторонник может в любое time вновь открыть запрос на поддержку, если он хочет продолжить или поддержать разговор.
  23. Если предложение принято:
  24. Google обязуется объединить проголосованную версию запроса (при условии, что участники подписали CLA) и выполнить запрос в течение 5 рабочих дней.
  25. Переводы не должны быть включены в исходный запрос на исправление. Google несет ответственность за обновление соответствующих переводов на поддерживаемые языки, однако запросы на исправление Translation от сообщества приветствуются и будут приняты, как только будут устранены все замечания редакции.
  26. Окончательный результат запроса (принят или отклонен) должен быть объявлен в той же ветке Google Groups, где был первоначально объявлен запрос.

Руководящие принципы

Для того чтобы сохранить первоначальное видение GTFS, был установлен ряд руководящих принципов, которые следует учитывать при расширении спецификации:

Каналы должны быть просты в создании и редактированииМы
выбрали CSV в качестве основы для спецификации, потому что его легко просматривать и редактировать с помощью программ электронных таблиц и text редакторов, что полезно для небольших агентств. Его также легко генерировать из большинства языков программирования и баз данных, что полезно для издателей больших фидов.

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

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

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

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

История пересмотра

14 марта 2023 г.

26 июля 2022 года

  • Добавлены трансферы из поездки в поездку с возможностью посадки в кресло. См. обсуждение

17 мая 2022 года

22 октября 2021 г.

05 октября 2021 года

  • Добавлены переходы от поездки к поездке и от маршрута к маршруту. См. обсуждение

15 сентября 2021 г.

  • Разрешает двунаправленность проездных ворот (pathway_mode=6). См. обсуждение.

13 сентября 2021 г.

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

27 августа 2021 г.

4 января 2021 г.

  • Уточнено описание stop_times.stop_id. См. обсуждение.
  • Определены положительные и ненулевые знаки полей. См. обсуждение.

2 октября 2020 г.

  • Изменен тип поля frequencies.headway_secs с неотрицательного на положительное целое число. См. обсуждение.

25 мая 2020 г.

  • Определены pathways.txt, levels.txt и attributions.txt как переводимые таблицы. Добавлены рекомендации по переводу многоязычных значений signposted_as. См. обсуждение.

13 мая 2020 г.

  • Добавлены значения continuous_pickup и continuous_drop_off в routes.txt и stop_times.txt. Изменено значение shape_id с "Необязательно" на "Условно обязательно". См. обсуждение.

24 марта 2020 г.

  • Определено поле text и добавлено tts_stop_name в файл stops.txt. См. обсуждение.

5 февраля 2020 года

  • Добавлены route_types троллейбуса и монорельса. См. обсуждение.

9 января 2020 г.

26 декабря 2019 г.

  • Обновлены определения для канатного трамвая и канатной дороги в route_type. См. обсуждение.

20 декабря 2019 г.

Август 26, 2019

  • Указано, что остановки stop_lat и stop_lon должны располагаться там, где пассажиры ожидают посадки в vehicle. См. обсуждение.

9 июля 2019 г.

  • Добавлены лучшие практики по time arrival и departure. См. обсуждение.
  • Добавлена лучшая практика использования головных знаков. См. обсуждение.
  • Добавлена лучшая практика использования stop_id. См. обсуждение.

25 июня 2019 г.

  • Уточнена связь между точками Shape и остановками. См. обсуждение.

4 апреля 2019

Март 27, 2019

Февраль 6, 2019

  • Редакционные и форматирующие изменения для ясности. См. обсуждение.

2 октября 2018

14 сентября 2018 г.

Сентябрь 4, 2018

  • Унифицированы определения agency_lang и feed_lang. См. обсуждение.

27 августа 2018 г.

  • Обновлен CHANGES.md и дата последней правки. См. обсуждение.

22 августа 2018 г.

  • Добавлены поля feed_contact_email и feed_contact_url в файл feed_info.txt. См. обсуждение.

11 декабря 2017 года

15 марта 2017 г.

  • Уточнено, что голос автора предложения не учитывается в общем количестве голосов. См. обсуждение.
  • Уточнено, что перед объявлением голосования, по крайней мере, один производитель GTFS и один потребитель GTFS должны реализовать предлагаемое изменение. См. обсуждение.

7 февраля 2017 г.

  • Уточнена связь между block_id и service_id. См. обсуждение.
  • Уточнено, что обслуживание на основе частоты начинается с момента departure vehicle. См. обсуждение.
  • Уточнены описания stop_id и stop_code. См. обсуждение.

11 декабря 2017 г.

  • Добавлено поле route_sort_order в файле routes.txt. См. обсуждение.

27 ноября 2016 г.

  • Добавлен вход на станцию как stops.location_type. См. обсуждение.

2 сентября 2016 г.

  • Обновлена документация для добавления agency_id в файл fare_attributes.txt. См. обсуждение.

16 марта 2016 г.

3 февраля 2016 г.

  • Добавлено предложение agency_email в agency.txt в спецификацию: parent_station

2 февраля 2015 г.

  • Добавлено предложение stop_times.txt 'timepoint' в спецификацию: обсуждение

17 февраля 2014 г.

15 октября 2012 г.

Добавлено предложение trips.txtwheelchair_accessible' к спецификации: обсуждение

20 июня 2012 г.

  • Добавлено предложение 'wheelchair_boarding' в спецификацию: обсуждение

2 февраля 2012 г.

  • Добавлено предложение 'stop_timezone' в спецификацию: обсуждение

18 января 2012 г.

  • Перенесена документация со старого сайта code.google.com на новый сайт developers.google.com.

26 сентября 2011 г.

  • Добавлено предложение 'feed_info' в спецификацию: обсуждение

6 сентября 2011 г.

30 марта 2009 г.

  • Новый раздел о том, как сделать транзитный канал общедоступным. Ранее это не обсуждалось в группе, потому что это не совсем изменение интерпретации или записи данных. Однако некоторые из сотрудников Google решили, что было бы информативно включить обсуждение использования GTFS не в Google, поскольку появляется все больше приложений, которые могут использовать данные GTFS.
  • Уточнения формата CSV: обсуждение.
  • Дополнительное руководство по выбору контрастных цветов в описаниях полей route_color и route_text_color.
  • trip_short_name, как предложено и проверено в этих темах: a и b.
  • Исправлена незначительная ошибка в примерах данных, включенных в end документа (придание остановке S7 родительской_станции S8).
  • Добавлена информация "agency_lang" к образцу данных в end документа, как предложила Марси во время периода комментариев: обсуждение.
  • Обновлена ссылка на канал GTFS компании OCTA в боковой панели.
  • См. оригинальное резюме.

26 февраля 2009 г.

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

7 августа 2008 г.

  • Восстановлено поле stop_url, которое было случайно опущено в версии от 6 августа.
  • Добавлен agency_phone к образцу данных
  • Добавлено упоминание о соглашении об использовании данных при отправке фида в Google.

6 августа 2008 г.

  • Добавлен файл transfers.txt, позволяющий издателям фидов предоставлять подсказки о предпочтительном поведении при передаче(первоначальное предложение).
  • Добавлены поля location_type и parent_station в файл stops.txt, позволяющие группировать остановочные пункты в станции(первоначальное предложение).
  • Добавлено поле agency_phone для предоставления голосового телефонного номера агентства(первоначальное предложение)
  • Добавлен раздел "Тестирование ваших фидов" с упоминанием инструментов тестирования с открытым исходным кодом
  • Добавлены пояснения относительно формата CSV, agency_timezone, agency_lang, route_color, route_text_color, arrival_time, departure_time, calendar.txt против calendar_dates.txt, таблиц тарифов и frequencies.txt
  • Добавлена ссылка на документ с историей фидов, а также исправлены некоторые ссылки на публичные фиды.
  • Обновлены изображения примеров для отображения текущего пользовательского интерфейса Google Maps
  • Обновлены/исправлены примеры данных в документе

29 февраля 2008 г.

  • Добавлено поле stop_code в файле stops.txt, позволяющее указывать коды остановок для пассажиров(первоначальное предложение).
  • Уточнены описания route_short_name и route_long_name в routes.txt
  • Уточнены описания arrival_time и departure_time в файле stop_times.txt
  • Исправлены опечатки в разделе "Образцы данных

20 ноября 2007 г.

  • Уточнено описание block_id
  • Изменен язык, чтобы уменьшить акцент на Google Transit (поскольку приложения, не связанные с Google, используют GTFS, а маршрутизация транспорта теперь является интегрированной функцией Google Maps), а также исправлены различные опечатки.
  • Обновлены скриншоты примеров, чтобы отразить представление полей GTFS в текущем пользовательском интерфейсе Google Maps
  • Обновлен контактный адрес электронной почты Google для поставщиков транзитных данных
  • Обновлено форматирование

5 октября 2007 г.

  • Изменены параметры stop_sequence и shape_pt_sequence, позволяющие использовать любые возрастающие неотрицательные целые числа
  • Уточнены описания и исправлены опечатки

31 мая 2007 г.

  • Обновлен стиль страницы, HTML стал чище и доступнее
  • Добавлены ссылки на примеры публичных фидов и другие полезные сайты
  • Удалены примеры из описаний отдельных полей

9 апреля 2007 г.

  • Добавлен раздел об отправке фида.
  • Добавлен пример фида демонстрационного транзитного агентства.
  • Добавлено примечание, что calendar.txt может быть опущен, если все даты обслуживания определены в calendar_dates.txt.
  • Сделано необязательным поле agency_id в фидах, содержащих только одно агентство. Это позволяет существующим фидам без agency_id оставаться действительными.
  • Добавлена более полная спецификация полей agency_url, stop_url и route_url, а также дополнительные примеры значений для этих полей.
  • Добавлены 6 (гондола) и 7 (фуникулер) в качестве допустимых значений route_type.

8 марта 2007 г.

  • Небольшая правка для перемещения поля stop_url из файла stop_times.txt, где оно было неверно указано в обновлении от 28 февраля, в файл stops.txt, где ему самое место.

5 марта 2007 г.

  • Незначительная правка для уточнения описания поля route_long_name.

28 февраля 2007 г.

  • Добавление файла frequencies.txt для поддержки расписания на основе пути.
  • Теперь разрешено использовать несколько агентств в одном канале. Также добавлено новое поле agency_id в agencies.txt и routes.txt, позволяющее указать, какой маршрут обслуживается каким агентством.
  • Добавление URL-адресов для каждого маршрута и каждой остановки.
  • Добавление поля direction_id в файле trips.txt.
  • Поддержка смены указателей в середине маршрута с добавлением поля stop_headsign в файле stop_times.txt.
  • Поддержка цветов маршрутов с добавлением необязательных параметров route_color и route_text_color в файле routes.txt.
  • Удалена возможность указания остановок с помощью адресов улиц. Предыдущая версия спецификации позволяла указывать местоположение транзитной остановки с помощью уличного адреса в полях stop_street, stop_city, stop_region, stop_postcode и stop_country. Теперь местоположение остановки должно быть указано с помощью полей stop_lat для latitude и stop_lon для longitude, что более удобно для большинства приложений.
  • Добавление типа канатной vehicle для поля route_type в routes.txt.
  • См. краткое описание изменений в оригинальной записи блога Headway.

29 ноября 2006 г.

  • Добавлена поддержка информации о Shape trip через файл shapes.txt
  • Уточнено определение stop_sequence
  • Пометки pickup_type и drop_off_type стали необязательными.

31 октября 2006 г.

  • Добавлена поддержка информации о стоимости проезда
  • Удалены даты из имен отдельных файлов
  • Изменены определения значений route_type
  • Позволяет публиковать несколько файлов фидов в одно и то же time, если их периоды обслуживания не пересекаются
  • Исправлен block_id в файле trips.txt, чтобы он был правильно помечен как Optional.
  • Замечено, что заголовки столбцов должны быть включены

29 сентября 2006 г.

  • Небольшая правка для исправления пары ошибок в примерах.

25 сентября 2006

  • Первоначальная версия.