跳转至

规范修订过程

GTFS规范不是一成不变的。相反，它是一个开放的规范，由公交机构、开发商和其他使用GTFS的利益相关者社区开发和维护。预计这个由GTFS数据的生产者和消费者组成的社区将提出扩展规范以实现新功能的建议。为了帮助管理这个过程，我们制定了以下程序和指南。

官方规范、参考资料和文件都是用英文写的。如果Translation不同的语言与英文原文不同，则以后者为准。所有的交流都用英语进行。

  1. 创建一个git分支，更新协议定义、规范和文档文件的所有相关部分（翻译除外）。
  2. 在https://github.com/google/transit 上创建拉动请求。拉动请求必须包含对补丁的扩展描述。拉动请求的创建者成为_拥护者_。 3.一旦拉动请求被注册，它必须由其倡导者在GTFS变更邮件列表中宣布，包括拉动请求的链接。一旦宣布，该拉动请求就被视为一项提案。 拉动请求也应该被编辑，以包含一个指向Google Groups公告的链接，这样它们就可以很容易地被交叉引用了。
  3. 由于倡导者是一个贡献者，他们必须在拉动请求被接受之前签署贡献者许可协议。 下面是对该提案的讨论。拉动请求的评论应作为唯一的讨论论坛。
  4. 讨论持续的时间，只要倡导者认为有必要，但必须至少是7个日历日。
  5. 倡导者负责根据他们同意的评论及时更新提案（即拉动请求）。
  6. 在任何time，倡导者都可以声称提案被放弃。
  7. 倡导者可以在讨论所需的最初7天间隔之后的任何time点要求对提案的一个版本进行投票。
  8. 在要求投票之前，至少有一个GTFS生产者和一个GTFS消费者应实施提议的改变。 希望GTFS生产者在面向公众的GTFS馈送中包含该变更，并在拉动请求的评论中提供该数据的链接，而且GTFS消费者在拉动请求的评论中提供一个链接，以非微不足道的方式利用该变更（即支持新的或改进的功能）的应用程序。
  9. 投票持续的最短时间足以涵盖7个FULL日历日和5个FULL瑞士工作日。投票在23:59:59 UTC结束。
  10. 倡导者应在投票start时宣布具体的end time。
  11. 在投票期间，只允许对提案进行编辑性修改（错别字，只要不改变含义，措辞可以改变）。
  12. 任何人都可以以评论的形式对拉动请求投赞成/反对票，并且在投票期end前可以改变投票。 如果一个投票者改变了她的投票，建议通过删除投票内容并写上新的投票来更新原始投票评论。
  13. 投票期start前的投票不予考虑。
  14. 投票的开始和结束必须在变更邮件列表中公布。
  15. 如果至少有3票一致同意，则该提案被接受。
  16. 提案人的投票不计入3票的总数。例如，如果提案人X创建了一个拉动请求并投了赞成票，而用户Y和Z也投了赞成票，这将被算作2张赞成票。
  17. 反对票应是有动机的，最好能提供可操作的反馈。
  18. 如果投票失败了，那么倡导者可以选择继续该提案的工作，或者放弃该提案。 倡导者的任何决定都必须在变更邮件列表中宣布。
  19. 如果倡导者继续提案的工作，那么可以在任何time要求进行新的投票。
  20. 任何在30天内不活动的拉动请求将被关闭。当一个拉动请求被关闭时，相应的提案被认为是被放弃了。如果倡导者希望继续或保持对话，他们可以在任何time重新打开拉动请求。
  21. 如果提案被接受。
  22. 谷歌承诺合并拉动请求的投票版本（前提是贡献者已经签署了CLA），并在5个工作日内执行拉动请求。
  23. 翻译不得包含在原始拉动请求中。 谷歌负责最终将相关翻译更新为支持的语言，但欢迎来自社区的纯Translation拉动请求，一旦所有编辑意见得到解决，就会被接受。
  24. 拉动请求的最终结果（接受或放弃）应该在最初宣布拉动请求的同一Google Groups主题上宣布。

指导原则

为了保持GTFS的最初愿景，我们制定了一些指导原则，以便在扩展该规范时加以考虑。

饲料应易于创建和编辑**
我们选择CSV作为规范的基础，因为它易于使用电子表格程序和text器查看和编辑，这对小型机构很有帮助。它也可以直接从大多数编程语言和数据库中生成，这对大型信息源的发布者很有帮助。

馈送应该容易解析馈送
读者应该能够以尽可能少的工作提取他们正在寻找的信息。对Feed的修改和添加应该尽可能广泛有用，以尽量减少Feed的读者需要实现的代码路径的数量。(然而，应该优先考虑使创建更容易，因为最终会有更多的馈送发布者而不是馈送读者）。

该规范是关于乘客信息的
GTFS主要关注的是乘客信息。也就是说，该规范应该包括能够帮助乘客使用电动工具的信息，这一点是首要的。交通机构可能希望在系统之间内部传输大量的面向运营的信息。GTFS不是为了这个目的，可能有其他面向运营的数据标准可能更合适。

对规范的修改应该是向后兼容的当向规范添加功能时
，我们希望避免做出会使现有馈送无效的修改。我们不希望为现有的信息源发布者创造更多的工作，直到他们想为他们的信息源增加功能。此外，只要有可能，我们希望现有的分析器能够继续阅读新的饲料的旧部分。

不鼓励投机性的功能每一个
新的功能都会增加创建和阅读饲料的复杂性。因此，我们要注意只添加我们知道是有用的功能。理想情况下，任何建议都会通过为使用新功能的真实交通系统生成数据，并编写软件来读取和显示数据来进行测试。请注意，GTFS允许通过增加官方解析器和验证器所忽略的额外的列和文件来扩展格式，所以建议可以很容易地在现有的feeds上进行原型化和测试。

修订历史

2023年3月14日

  • 增加了票价媒体。见讨论。

2022年7月26日

  • 增加了行程与行程之间的转车，有座位选择。 见讨论

2022年5月17日

  • GTFS-Fares V2基础实现。 见讨论

10月22日，2021年

  • 增加了主id和外id字段。 见讨论

2021年10月5日

  • 增加了行程到行程和路线到路线的转移。 见讨论

2021年9月15日

  • 允许票价门（pathway_mode=6）是双向的。见讨论。

2021年9月13日

  • 更新了stop_name的最佳做法。见讨论。

2021年8月27日

2021年1月4日

  • 澄清了stop_times的描述。stop_id。参见讨论。
  • 定义了正数和非零的字段符号。参见讨论。

2020年10月2日

  • 将frequencies.headway_secs的字段类型从非负数改为正整数。参见讨论。

2020年5月25日

  • 定义了pathways.txt、levels.txt和attributions.txt为可翻译的表格。添加了翻译多语言signposted_as值的建议。参见讨论。

2020年5月13日

  • 在routes.txt和stop_times.txt中增加了continuous_pickup和continuous_drop_off。将shape_id从 "Optional"改为 "Conditionally required"。见讨论。

2020年3月24日

  • 定义了text字段，并在stops.txt 中添加了tts_stop_name。参见讨论。

2020年2月5日

  • 增加了无轨电车和单轨电车route_types。参见讨论。

2020年1月9日

  • 添加了translations.txt。参见讨论。

2019年12月26日

  • 更新了route_type中的缆车和空中电梯的定义。见讨论。

2019年12月20日

  • 添加了attributions.txt。见讨论。

2019年8月26日

  • 规定stop_lat和stop_lon的位置是乘客等待上车vehicle地方。参见讨论。

2019年7月9日

  • 增加了arrival和departure time最佳实践。参见讨论。
  • 增加了车头标志的最佳做法。参见讨论。
  • 添加了stop_id的最佳做法。见讨论。

2019年6月25日

  • 澄清了Shape点和站点的关系。见讨论。

2019年4月4日

  • 在stops.txt中增加了platform_code字段。见讨论。

2019年3月27日

  • 增加了pathways.txt和levels.txt。见讨论。

2019年2月6日

  • 为清晰起见做了编辑和格式上的修改。 参见讨论。

2018年10月2日

  • 因数化的字段类型。见讨论。

2018年9月14日

  • 增加了 "Conditionally required"的概念。参见讨论。

2018年9月4日

  • 统一了agency_lang和feed_lang的定义。参见讨论。

2018年8月27日

  • 更新了CHANGES.md和最后修订日期。参见讨论。

2018年8月22日

  • 在feed_info.txt文件中增加了feed_contact_email和feed_contact_url字段。参见讨论。

2017年12月11日

  • 在routes.txt中添加了route_sort_order。请参见讨论。

2017年3月15日

  • 澄清了提案人的投票不计入总数。参见讨论。
  • 明确了在召集投票之前，至少有一个GTFS生产者和一个GTFS消费者应该实现提议的修改。参见讨论。

2017年2月7日

  • 澄清了block_id和service_id 的关系。参见讨论。
  • 澄清了基于频率的服务从vehicle departure时开始。见讨论。
  • 澄清了stop_id和stop_code的描述。参见讨论。

2017年12月11日

  • 在routes.txt文件中增加了route_sort_order字段。参见讨论。

2016年11月27日

  • 增加了车站入口作为stops.location_type。见讨论。

2016年9月2日

  • 更新了文件，在fare_attributes.txt 中增加了agency_id。参见讨论。

2016年3月16日

2016年2月3日

  • 在agency.txt中添加了agency_email，建议加入规范：讨论

2015年2月2日

  • 添加了stop_times.txt'timepoint'建议到规范中：讨论

2014年2月17日

  • 添加trips.txt'bikes_allowed' 提案到规范中：讨论

2012年10月15日

  • 添加trips.txt wheelchair_accessible' 提案到规范：讨论

2012年6月20日

  • 在规范中添加了'wheelchair_boarding'建议：讨论

2012年2月2日

  • 在规范中添加了'stop_timezone'建议：讨论

2012年1月18日

  • 将文档从旧的code.google.com迁移到它们在developer.google.com的新位置。

2011年9月26日

  • 在规范中添加了'feed_info'建议：讨论

2011年9月6日

  • 在规范中添加了'agency_fare_url'建议：讨论
  • 在规范中添加了 "exact_times "建议：讨论。

2009年3月30日

  • 新增了一个关于公开提供交通信息的部分。这一点以前没有在小组里讨论过，因为严格来说，这并不是对数据的解释或编写方式的改变。然而，谷歌的一些人认为，包括对GTFS的非谷歌用途的讨论会很有意义，因为有越来越多的应用程序可以利用GTFS数据。
  • CSV格式的澄清：讨论。
  • 关于如何在route_color和route_text_color字段的描述中选择对比的颜色的额外指导。
  • 在这些主题中提出并测试的trip_short_name：a和b。
  • 修正了文件end的样本数据中的一个小错误（把S7站作为父站S8）。
  • 根据Marcy在评论期间的建议，在文件end的样本数据中添加了 "agency_lang "信息：讨论。
  • 更新了侧边栏中OCTA的GTFSfeed的链接。
  • 见原始摘要。

2009年2月26日

  • 删除了大部分针对谷歌的feed提交说明，因为目前还有许多其他的应用程序在消费GTFS数据。
  • 修正了侧边栏中指向橙县OCTA公共馈送的断裂链接。

2008年8月7日

  • 恢复了stop_url字段，该字段在8月6日的版本中被意外地省略了。
  • 在样本数据中增agency_phone_number
  • 在向Google提交feed时，增加了对数据使用协议的提及。

2008年8月6日

  • 增加了transfers.txt文件，允许feed发布者提供关于首选传输行为的提示(原始建议）。
  • 在stops.txt中增加了location_type和parent_station字段，允许将停车点归入车站原始提议）。
  • 增加了agency_phone字段，用于提供一个机构的语音电话号码原始提案）。
  • 增加了 "测试你的报文 "一节，提到了开源的测试工具
  • 增加了对CSV格式、agency_timezone、agency_lang、route_color、route_text_color、arrival_time、departure_time、calendar.txt与calendar_dates.txt、票价表和frequencies.txt的说明。
  • 增加了链接到馈送历史文件，并更正了一些公共馈送链接
  • 更新了示例图片以描述当前的谷歌地图用户界面
  • 更新/修正了文件中的样本数据

2008年2月29日

  • 在stops.txt中增加了 stop_code 字段，允许指定面向乘客的车站代码原始提案）。
  • 澄清了routes.txt中的route_short_name和route_long_name的描述。
  • 澄清了stop_times.txt中的 arrival_time 和 departure_time 的描述。
  • 修正了样本数据部分的错别字

2007年11月20日

  • 澄清了block_id的描述
  • 修改了语言，不再强调Google Transit（因为非Google应用程序正在使用GTFS，而且交通路线选择现在是Google Maps的一个综合功能），并修正了各种错别字
  • 更新了截图示例，以反映GTFS字段在当前谷歌地图用户界面中的表现形式。
  • 更新了交通数据提供者的谷歌联系电子邮件地址
  • 更新了格式

2007年10月5日

  • 修改了stop_sequence和shape_pt_sequence，允许任何增加的非负整数。
  • 澄清了描述并修正了错别字

2007年5月31日

  • 更新了页面风格，使HTML更简洁，更容易访问
  • 增加了公共馈电实例和其他有用网站的链接
  • 删除了个别字段描述中的例子

2007年4月9日

  • 增加了关于提交信息源的部分。
  • 增加了示范交通机构馈送的例子。
  • 增加了注意，如果所有的服务日期都在calendar_dates.txt中定义，可以省略calendar.txt。
  • 在只包含一个机构的馈送中，使agency_id字段成为可选项。这允许现有的feeds没有agency_id而保持有效。
  • 增加了agency_url、stop_url和route_url的更全面规范，以及这些字段的额外示例值。
  • 增加了6（Gondola）和7（Funicular）作为有效的route_type值。

2007年3月8日

  • 稍作编辑，将stop_url字段从stop_times.txt（在2月28日的更新中，该字段被错误地指定为stop_times.stops.txt）移至stops.txt，即它所属的位置。

2007年3月5日

  • 稍作编辑，澄清了route_long_name字段的描述。

2007年2月28日

  • 增加了frequencies.txt，以支持基于航向的时间表。
  • 现在允许多个机构出现在同一个信息源中。还在 agencies.txt 和routes.txt中增加了新的agency_id字段，让你可以指定哪条线路是由哪个机构运营的。
  • 增加了每条路线和每站的URLs。
  • 在trips.txt中增加了direction_id字段。
  • 在stop_times.txt中增加了stop_headsign字段，支持行程中的车头标志变更。
  • 在routes.txttxt中增加了可选的routes_color和routes_text_color，支持路线颜色。
  • 删除了使用街道地址指定站点的功能。上一版本的规范允许你在stop_street、stop_city、stop_region、stop_postcode和stop_country字段中使用街道地址来提供交通站点的位置。现在，必须用stop_lat表示latitude，stop_lon表示longitude，这对大多数应用来说更有用。
  • 在routes.txt中的route_type字段中增加了缆车vehicle类型。
  • 见原始的Headway博客文章的变化总结。

November 29, 2006

  • 通过shapes.txt增加了对trip Shape信息的支持
  • 澄清了stop_sequence的定义
  • 将pickup_type和drop_off_type标记为可选。

2006年10月31日

  • 增加了对票价信息的支持
  • 删除了个别文件名中的日期
  • 改变了route_type值的定义
  • 允许在time发布多个feed文件，只要它们的服务期不重叠。
  • 修正了trips.txt中的block_id，使其正确标记为可选。
  • 注意到必须包括列标题

2006年9月29日

  • 稍作编辑，修正了例子中的几个错误。

2006年9月25日

  • 初始版本。