跳转至

GTFS Schedule最佳做法

这些是General Transit Feed Specification (GTFS) 中描述公共交通服务的推荐做法。 这些实践是根据 GTFS Best Practices working group 成员的经验和[application-specific GTFS practice recommendations](http://www.transitwiki.org/TransitWiki/index.php/Best_practices_for_creating_GTFS）。

有关进一步的背景，请参见《常见问题解答》。

文件结构

实践被组织成四个主要部分。

数据集发布与一般实践

  • 数据集应发布在公共的永久 URL 上，包括 zip 文件名。 （例如，www.agency.org/gtfs/gtfs.zip）。 理想情况下，URL 应可直接下载，无需登录即可访问文件，以便于通过使用软件应用程序进行下载。 虽然建议（也是最常见的做法）公开下载 GTFS 数据集，但如果数据提供商确实需要出于许可或其他原因控制对 GTFS 的访问，则建议使用 API 密钥控制对 GTFS 数据集的访问， 这将有助于自动下载。
  • GTFS数据是迭代发布的，因此在一个稳定的位置上的单个文件总是包含一个（或多个）运输机构的最新官方服务描述。
  • 尽可能在数据迭代过程中保持stop_id、route_id和agency_id的持久标识符（id字段）。
  • 一个GTFS数据集应该包含当前和即将提供的服务（有时称为 "合并的 "数据集）。谷歌 transitfeed工具的合并功能可用于从两个不同的GTFSfeeds中创建一个合并的数据集。
  • 在任何时候，发布的GTFS数据集都应该至少在未来7天内有效，最好是在运营者有信心继续运营该Schedule的情况下。
  • 如果可能，GTFS数据集应至少涵盖未来30天的服务。
  • 从馈送中删除旧服务（过期日历）。
  • 如果服务修改将在 7 天或更短时间内生效，请通过 GTFS-realtime Feed（服务建议或行程更新）表达此服务更改 ）而不是静态 GTFS 数据集。
  • 托管GTFS数据的网络服务器应被配置为正确报告文件修改日期（见HTTP/1.1--第14.29节下的2616号意见请求）。

按文件整理的实践建议

本节显示了按文件和字段组织的做法，与GTFS参考文献一致。

所有文件

字段名 建议
混合大小写 所有面向客户的文本字符串（包括站名、路线名称和路标）都应使用混合大小写（而不是全部大写），在能够显示小写字符的显示器上遵循当地的地名大写惯例。
例子。
布莱顿丘吉尔广场
马恩河畔维利埃
市场街
缩略语 避免在整个资料中使用名称和其他文本的缩写（如St.代表Street），除非一个地点被称为其缩写的名称（如 "肯尼迪机场"）。缩写可能对屏幕阅读器软件和语音用户界面的可访问性造成问题。消耗性软件可以被设计成可靠地将全词转换为缩写来显示，但从缩写转换为全词则容易出现更多的错误风险。

agency.txt

字段名 建议
agency_id 应该被包括在内，即使饲料中只有一个机构。(也见建议包括 agency_id在 routes.txt和 fare_attributes.txt)
agency_phone 应该包括，除非不存在这样的客户服务电话。
agency_email 应包括在内，除非没有这样的客户服务电子邮件。
agency_fare_url 应包括在内，除非该机构是完全免票的。

例子。

  • 公共汽车服务由几个小的公共汽车机构经营。但是有一个大的机构负责调度和售票，并且从用户的角度来看，负责公交服务。这个大的机构应该被定义为feed中的机构。即使数据在内部被不同的小巴士运营商分割，也应该只有一个机构被定义在feed中。

  • 馈送提供者运行票务门户，但有不同的机构实际操作服务，并被用户称为负责。实际运营服务的机构应该被定义为feed中的机构。

stops.txt

字段名 推荐
stop_name 当没有公布的站点名称时，在整个信息源中遵循一致的站点命名惯例。
默认情况下。 stop_name不应包含像 "站 "或 "站 "这样的通用或多余的词，但允许一些边缘情况。
  • 当它实际上是名称的一部分时（联合车站、中央车站
  • 当 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门
市区交通中心市中心交通中心B湾

routes.txt

字段名 建议
agency_id 应该被包括在内，即使饲料中只有一个机构。(参见建议在agency.txt和fare_attributes.txt 中包含agency_id)
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公司		该 路径_long_name应包括品牌（MAX）和具体的路线名称"MAX红线" "MAX蓝线"
"快速乘车"
位于新墨西哥州阿尔布开克的ABQ Ride		ǞǞǞ 路径_长名应包括品牌（Rapid Ride）和具体的路线名称。"快速乘车红线"
"快速乘车蓝线"
route_id 一条指定的路线上的所有车次都应该参考相同的内容。 route_id.
  • 一条路线的不同方向不应划分为不同的价值。 route_id值。
  • 一条路线的不同运营时间段不应划分为不同的数值。 route_id例如，不要在 "市区上午 "和 "市区下午 "创建不同的记录。 routes.txt中创建不同的记录）。
    		•
    如果一个路线组包括不同名称的分支（如1A和1B），请遵循路线中的建议。 分支中的建议来确定。 route_short_name和 route_long_name.
    route_color& route_text_color 应与标牌、印刷品和在线客户信息保持一致（因此，如果其他地方不存在这些信息，则不包括在内）。

    trips.txt

    • __见环形路线的特殊情况。__循环路线是指行程在同一站点开始和结束的情况，与有两个不同终点站的线性路线相反。循环路线必须按照特定的做法来描述。请看环形路线案例。
    • __请看套索路线的特殊情况。__套索路线是线性和环形几何形状的混合体，车辆只在路线的一部分在环形上行驶。拉索路线必须按照特定的做法来描述。请看拉索路线案例。
    字段名 建议
    trip_headsign 不要提供路线名称（匹配 route_short_name和 route_long_name)在 trip_headsign或 stop_headsign领域。
    应该包含目的地、方向和/或其他显示在车头标志上的行程指定文字，这些文字可以用来区分路线中的各个行程。与车辆上显示的方向信息保持一致是确定GTFS数据集中提供的车头标志的首要目标。其他信息只有在不影响这个主要目标的情况下才应包括在内。如果车头标志在行程中发生变化，则应覆盖 trip_headsign与 stop_times.stop_headsign.下面是对一些可能情况的建议。
    路线描述建议
    2A.仅限目的地提供终点站。例如，"交通中心"，"波特兰市中心"，或 "Jantzen海滩">。
    2B.有航点的目的地通过 " 海格特经查林十字"。如果在车辆经过这些航点后，航点被从显示给乘客的头标中删除，请使用 stop_times.stop_headsign来设置一个最新的车头信号。
    2C.带有本地站点的区域地名如果在目的地的城市或行政区内有多个站点，则在到达目的地城市后使用 停止_时间.停止_头标一旦到达目的地城市，就使用
    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 不提供客运服务的无收入(空驶)车次应标记为 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 一般来说，头标值也应该与车站的标志相对应。

    在下面的案例中，"南行 "会误导顾客，因为车站的标志中没有使用这个词。
    在纽约市，对于2号车向南行驶。
    对于 stop_times.txt行。使用 stop_headsign值。
    直到到达曼哈顿曼哈顿和布鲁克林
    直到到达市中心市区和布鲁克林
    直到到达布鲁克林布鲁克林
    一旦到达布鲁克林布鲁克林（New Lots Av）
    在波士顿，红线南行的布伦特里支线。
    对于 stop_times.txtrows:使用 stop_headsign价值。
    直到到达市中心为止往布伦特里方向
    到达市中心后布伦特里
    市区后出城到布伦特里
    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.txt和routes.txt 中包含agency_id)
    如果票价系统无法准确建模，避免进一步的混乱，将其留空。
    包括票价(fare_attributes.txt和 fare_rules.txt)并尽可能准确地建模。在票价不能准确建模的边缘情况下，票价应该表现为更贵而不是更便宜，这样顾客就不会试图用不足的票价上车。如果绝大多数票价不能被正确建模，就不要把票价信息包括在信息源中。

    fare_rules.txt

    字段名 建议
    所有字段 如果票价系统不能被准确地建模，为避免进一步的混乱，将其留空。
    包括票价(fare_attributes.txt和 fare_rules.txt)并尽可能准确地建模。在票价不能准确建模的边缘情况下，票价应该表现为更贵而不是更便宜，这样顾客就不会试图用不足的票价登机。如果绝大多数的票价不能被正确地建模，就不要把票价信息包括在feed中。

    shapes.txt

    字段名 建议
    所有字段 理想的情况是，对于共享的线路（即1号和2号线路在同一段公路或轨道上运营的情况），那么共享部分的线路应该完全匹配。这有助于促进高质量的交通地图绘制。
    路线应遵循车辆行驶的路权中心线。如果没有指定的车道，这可以是街道的中心线，或者是在车辆行驶方向上行驶的道路一侧的中心线。

    路线不应 "锯齿 "到路边停靠点、平台或上车地点。
    shape_dist_traveled 必须在两个方面提供 shapes.txt和 stop_times.txt如果路线包括循环或内联（车辆在一次行程中穿过或走过相同部分的路线）。
    如果车辆在一个行程中回溯或越过路线的各点。 形状_距离_行程重要的是要澄清在线路中的部分点是如何与记录中的记录相对应的。 shapes.txt的记录。 stop_times.txt.
    的 shape_dist_traveled字段允许机构准确指定文件中的站点如何与各自的形状相适应。 stop_times.txt文件中的站点如何与它们各自的形状相匹配。一个常见的值是用于 shape_dist_traveled字段的常用值是车辆从形状的起点开始行驶的距离（想想像里程表的读数）。
  • 路线的排列（在 shapes.txt)应该在一个行程所服务的站点的100米之内。
  • 简化走线，使之 shapes.txt不包含不相干的点（即删除直线段上的多余的点；见关于线路简化问题的讨论）。
    		•

    frequencies.txt

    字段名 建议
    所有字段 实际停靠时间被忽略，因为参考的车次是 frequencies.txt所指的行程，实际停车时间被忽略；对于基于频率的行程，只有各站之间的旅行时间间隔是重要的。为了清晰/可读性，建议在 "频率 "中引用的行程的第一站时间应该从00:00:00开始。 frequencies.txt中引用的行程的第一站时间应该从00:00:00开始（第一 arrival_time00:00:00的第一个值）。
    block_id 可以为基于频率的旅行提供。

    transfers.txt

    transfers.transfer_type可以是 GTFS中定义的四个值之一。这些transfer_type的定义引自下面的GTFS规范，以斜体字表示，并附有额外的实践建议。

    字段名 建议
    transfer_type 0或（空）。这是一个推荐的路线之间的换乘点。
    如果有多个换乘机会，包括一个优越的选择（即一个有额外设施的交通中心或一个有相邻或相连的上车设施/平台的车站），请指定一个推荐的换乘点。
    1: 这是两条路线之间的定时换乘点。出发的车辆应等待到达的车辆，并有足够的时间让乘客在各条线路之间换乘。
    这种换乘类型推翻了可靠地进行换乘的必要间隔。 作为一个例子，谷歌地图假设乘客需要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 停止_A 1 "B"
    行程_1 06:15:00 06:15:00 停_B 2 "C"
    行程_1 06:20:00 06:20:00 停止_C 3 "D"
    行程_1 06:25:00 06:25:00 停止_D 4 "E"
    行程_1 06:30:00 06:30:00 停止_E 5 "A"
    行程_1 06:35:00 06:35:00 停止_A 6 ""
    • 有两个车头标志的循环行程
    trip_id 到达时间 离开时间 stop_id stop_sequence 停车标志
    行程_1 06:10:00 06:10:00 停止_A 1 "出站"
    行程_1 06:15:00 06:15:00 暂停_B 2 "出站"
    行程_1 06:20:00 06:20:00 停止_C 3 "出站"
    行程_1 06:25:00 06:25:00 停止_D 4 "入站"
    行程_1 06:30:00 06:30:00 停止_E 5 "入站"
    行程_1 06:35:00 06:35:00 停止_F 6 "入站"
    旅程_1 06:40:00 06:40:00 停止_A 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.

    拉索路线

    套索路线结合了循环路线和方向性路线的各个方面。

    举例说明。
    地铁路线 (芝加哥)
    公交车 郊区到市中心的路线 (圣艾伯特或 埃德蒙顿)
    CTA棕线 (CTA网站和 公交信息)
    字段名 建议
    trips.trip_id 一个 "车辆往返 "的全部范围（见上面的插图 见上图)包括从A到B到B，再回到A的旅行。
  • A 单一的 trip_id值/记录在 trips.txt
  • 多个 trip_id中的值/记录 trips.txt，连续行驶表示为 block_id.
    		•
    stop_times.stop_headsign 沿着A-B段的站点将在两个方向上通过。 stop_headsign有助于区分旅行方向。因此，为这些旅行提供 stop_headsign建议在这些旅行中使用 "例子"。
    例子。
    "A通过B"
    "A"
    芝加哥交通局的 紫线
    "南行至环线"
    "北行经Loop"
    "北行至林登"
    埃德蒙顿公交服务的公交线路，这里 的39
    "卢瑟福"
    "世纪公园"
    trip.trip_headsign 车次标题应该是对该车次的总体描述，就像时刻表中显示的那样。可以是 "Linden至Linden经Loop"（芝加哥的例子），或 "A至A经B"（一般的例子）。

    分支点

    一些路线可能包括分支。这些分支的路线和站点是共享的，但每个分支也为不同的站点和路线部分服务。分支机构之间的关系可以通过路线名称、标题标志和行程简称来表示，并使用以下的进一步准则。

    字段名 建议
    所有字段 在命名支线时，建议遵循其他乘客信息材料。以下是两种情况的描述和例子。
    如果时刻表和路标代表两条不同的路线（例如1A和1B），那么在GTFS中使用 route_short_name和/或 route_long_name字段。例子。GoDurham Transit 2、2A和2B路在大部分路线上有共同的路线，但它们在几个不同的方面有所不同。
    • 2号线是核心服务，大部分时间运行。
    • 2号线包括在主街的晚上、周日和节假日的偏差。
    • 2A路和2B路周一至周六白天运营。
    • 2B路在偏离共享线路路径的情况下提供额外的站点。
    如果机构提供的信息将分支机构描述为同一条命名的路线，那么请使用 trips.trip_headsign, stop_times.stop_headsign，和/或 trips.trip_short_name字段。例子。GoTriangle 300路根据一天中的不同时间，前往不同的地点。在通勤高峰期，标准路线上会增加额外的路段，以适应进出城市的工人。

    常见问题(FAQ)

    为什么这些GTFS最佳实践很重要？

    GTFS最佳实践的目标是。

    • 改善终端用户在公共交通应用程序中的客户体验
    • 支持广泛的数据互操作性，使软件开发人员更容易部署和扩展应用程序、产品和服务
    • 促进GTFS在各种应用类别中的使用（超出其最初对行程规划的关注）。

    如果没有协调的GTFS最佳实践，各种GTFS应用可能会以不协调的方式建立要求和期望，从而导致不同的要求和特定应用的数据集，并降低互操作性。在发布最佳实践之前，在什么是正确形成的GTFS数据方面，存在较大的模糊性和分歧性。

    它们是如何开发的？谁开发的？

    这些最佳做法是由参与GTFS的17个组织组成的工作组制定的，其中包括应用程序供应商和数据消费者、交通供应商以及广泛参与GTFS的顾问。该工作小组由洛基山研究所召集和推动。

    工作组成员对每个最佳实践进行了投票。大多数最佳实践是以全票通过的。在少数情况下，最佳实践是由大多数组织批准的。

    为什么不直接改变GTFS的引用？

    好问题!对规范、数据使用和需求的研究过程确实引发了对规范的一些修改（见GitHub中已关闭的拉动请求）。与《最佳实践》相比，《规范》的参考修订要受到更严格的审查和评论。然而，仍然需要就一套明确的最佳实践建议达成一致。

    工作组预计，一些GTFS最佳实践最终将成为GTFS核心参考的一部分。

    GTFS验证器工具是否检查与这些最佳实践的一致性？

    目前没有验证器工具检查是否符合所有最佳实践。 各种验证器工具会检查是否符合其中一些最佳实践。 有关 GTFS 验证器工具的列表，请参阅 GTFS Validators。 如果您编写引用这些最佳实践的 GTFS 验证器工具，请发送电子邮件至 specifications@mobilitydata.org。

    我代表一个交通机构。我可以采取什么措施，使我们的软件服务提供商和供应商遵循这些最佳做法？

    请您的供应商或软件服务提供商参考这些最佳实践。我们建议在采购GTFS软件时参考GTFS最佳实践的URL以及核心规格参考。

    如果我发现一个GTFS数据源不符合这些最佳实践，我应该怎么做？

    确定饲料的联系人，使用feed_info.txt中建议的feed_contact_email或feed_contact_url字段（如果存在），或在转运机构或饲料生产商网站上查找联系信息。当向饲料生产商传达该问题时，链接到正在讨论的具体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维护。