参考文档

本文档定义了构成 GTFS 数据集的文件的格式和结构。

目录

  1. 术语定义
  2. 字段类型
  3. 数据集文件
  4. 文件要求
  5. 字段定义

术语定义

此部分定义本文档中通篇采用的术语。

  • 数据集 - 本规范参考定义的完整文件集。更改数据集会创建数据集的新版本。数据集应通过公共的永久网址发布，包括 ZIP 文件名。（例如 https://www.agency.org/gtfs/gtfs.zip）。
  • 记录 - 一种基本的数据结构，由描述单个实体（例如公交公司、车站、路线等）的多个不同字段值组成。在表中表示为行。
  • 字段 - 对象或实体的属性。以列的形式在表格中表示。
  • 字段值 - 字段中的单个条目。在表格中表示为单个单元格。
  • 必需 - 该字段必须包含在数据集中，并且必须在该字段中为每条记录提供一个值。某些必填字段允许空字符串作为值（在本规范中表示为空）。要输入空字符串，只需省略该字段中的逗号之间的所有文本即可。
  • 可选 - 数据集中可以省略该字段。如果包含可选列，则该字段中的某些条目可能为空字符串。要输入空字符串，只需忽略该字段逗号之间的任何文本即可。请注意，省略的字段等同于完全空的字段。
  • 已有条件 - 在特定条件（在字段或文件说明中概述）中，字段或文件是必需的。除上述条件外，此字段或文件是可选的。
  • 服务日 - 服务期是指用于指明路线安排的时间段。服务日的具体定义因代理机构而异，但服务日通常与日历日不对应。如果服务在某一天开始并在第二天结束，则服务天数可能会超过 24:00:00。例如，从星期五 08:00:00 到星期六 02:00:00 的服务，可表示为在单个服务期间 08:00:00 至 26:00:00 运行。

字段类型

  • 颜色 - 编码为六位十六进制数字的颜色。访问 https://htmlcolorcodes.com 以生成有效值（不包括前导“#”）。
    示例：FFFFFF 表示白色，000000 表示黑色，NY 表示 A、C、E 线的 0039A6。
  • 货币代码 - ISO 4217 字母代码货币代码。如需查看当前币种列表，请参阅 https://en.wikipedia.org/wiki/ISO_4217#Active_codes。
    示例：CAD 表示加元，EUR 表示欧元，JPY 表示日元。
  • 日期 - 服务日期，格式为 YYYYMMDD。由于服务日内的时间可能会高于 24:00:00，因此服务日通常包含次日的信息。
    示例：20180913 代表 2018 年 9 月 13 日。
  • 电子邮件 - 一个电子邮件地址。
    示例：example@example.com
  • 枚举 - “说明”列中定义的一组预定义常量的选项。
    示例：route_type 字段包含电车的 0、地铁的 1...
  • ID - ID 字段值是一个内部 ID，不向乘客显示，并且是任意 UTF-8 字符的序列。建议仅使用可打印的 ASCII 字符。一个 .txt 文件中定义的 ID 通常在另一个 .txt 文件中引用。
    示例：stops.txt 中的 stop_id 字段是一个 ID。stop_times.txt 中的 stop_id 字段是引用 stops.stop_id 的 ID。
  • 语言代码 - IETF BCP 47 语言代码。有关 IETF BCP 47 的介绍，请参阅 http://www.rfc-editor.org/rfc/bcp/bcp47.txt 和 http://www.w3.org/International/articles/language-tags/。
    示例：en 表示英语，en-US 表示美式英语，de 表示德语。
  • Latitude - WGS84 纬度，以十进制度数表示。该值必须大于或等于 -90.0 且小于或等于 90.0。
    示例：罗马斗兽场的 41.890169。
  • Longitude - WGS84 经度，以十进制度数表示。该值必须大于或等于 -180.0 且小于或等于 180.0。
    示例：罗马斗兽场的 12.492269。
  • 非负浮点数 - 大于或等于 0 的浮点数。
  • 非负整数 - 大于或等于 0 的整数。
  • 电话号码 - 电话号码。
  • Time - 采用 HH:MM:SS 格式的时间（也接受 H:MM:SS）。该时间以工作日“中午 - 12 小时”为基准（实际上是午夜，夏令时发生变更的日期除外）。如需了解详情，请参阅相关文章。对于午夜后出现的时间，以行程时间表开始当天的 HH:MM:SS 当地时间值的形式，输入大于 24:00:00 的时间。
    例如：14:30:00 表示下午 2:30，或 25:35:00 表示第二天凌晨 1:35。
  • Text - 一串 UTF-8 字符，旨在显示并且必须便于用户理解。
  • 时区 - 位于 https://www.iana.org/time-zones 的 TZ 时区。时区名称绝不会包含空格字符，但可以包含下划线。如需查看有效值列表，请参阅 http://en.wikipedia.org/wiki/List_of_tz_zones。
    示例：Asia/Tokyo、America/Los_Angeles 或 Africa/Cairo。
  • 网址 - 包含 http:// 或 https:// 以及网址中的所有特殊字符的完全限定网址必须正确转义。有关如何创建完全限定网址值的说明，请参阅以下 http://www.w3.org/Addressing/网址/4_URI_Recommentations.html。

数据集文件

此规范定义以下文件：

文件名 必需 定义
agency.txt 必需 使用此数据集表示的公交公司。
stops.txt 必需 停靠车辆上下载客的站点。还定义了车站和车站入口。
routes.txt 必需 公交路线。路线是作为一项服务向乘客显示的一组行程。
trips.txt 必需 每条路线的行程。行程是指在特定时间段内出现的两个或更多经停点。
stop_times.txt 必需 每次行程中，车辆到达和离开车辆的时间。
calendar.txt 视情况要求提供 使用每周时间表以及开始日期和结束日期指定服务日期。除非在 calendar_dates.txt 中定义了所有服务日期，否则必须提供此文件。
calendar_dates.txt 视情况要求提供 calendar.txt 中定义的服务的例外情况。如果省略 calendar.txt，则必须指定 calendar_dates.txt，且必须包含所有服务日期。
fare_attributes.txt 选填 公交公司的路线票价信息。
fare_rules.txt 选填 应用行程价格的规则。
shapes.txt 选填 用于绘制车辆行程路径（有时称为路线对齐方式）的规则。
frequencies.txt 选填 基于行驶路线的行驶间隔（行程时间）或固定时间表服务的压缩表示。
transfers.txt 选填 用于在路线之间中转点建立连接的规则。
pathways.txt 选填 连结多个站点中的站点的通道。
levels.txt 选填 车站内的楼层数。
feed_info.txt 视情况要求提供 数据集元数据，包括发布者、版本和到期时间信息。
translations.txt 选填 公交公司的翻译信息。
attributions.txt 选填 指定应用于数据集的归因。

文件要求

以下要求适用于数据集文件的格式和内容：

  • 所有文件都必须保存为逗号分隔文本。
  • 每个文件的第一行必须包含字段名称。字段定义部分的每个子部分都与 GTFS 数据集内的一个文件对应，并列出可在该文件中使用的字段名称。
  • 所有字段名称都区分大小写。
  • 字段值不能包含制表符、回车符或换行符。
  • 包含引号或逗号的字段值必须用引号括起来。此外，字段值中的每个引号前面都必须加上引号。这与 Microsoft Excel 输出逗号分隔 (CSV) 文件的方式一致。如需详细了解 CSV 文件格式，请参阅 http://tools.ietf.org/html/rfc4180。 以下示例展示了字段值在逗号分隔文件中的显示方式：
    • 原始字段值：Contains "quotes", commas and text
    • CSV 文件中的字段值："Contains ""quotes"", commas and text"
  • 字段值不能包含 HTML 标记、评论或转义序列。
  • 移除字段或字段名称之间的所有多余空格。许多解析器将空格视为值的一部分，这可能会导致错误。
  • 每行必须以 CRLF 或 LF 换行符结束。
  • 文件应采用 UTF-8 编码，以支持所有 Unicode 字符。我们接受包含 Unicode 字节顺序标记 (BOM) 字符的文件。如需详细了解 BOM 字符和 UTF-8，请参阅 http://unicode.org/faq/utf_bom.html#BOM。
  • 所有数据集文件都必须一起压缩。

字段定义

agency.txt

文件：必需

字段名称 类型 必需 说明
agency_id ID 视情况要求提供 标识公交品牌，通常与公交代理机构同义。请注意，在某些情况下（例如，一家代理机构运营多项不同的服务），代理机构和品牌会有所不同。本文用“代理机构”一词代替“品牌”。一个数据集可能包含来自多个代理机构的数据。如果数据集包含多个公交机构的数据，则此字段为必填字段，否则为选填字段。
agency_name 文字 必需 公交公司的全名。
agency_url 网址 必需 公交公司的网址。
agency_timezone 时区 必需 公交公司所在的时区。如果在数据集中指定了多个代理机构，则每个代理机构必须具有相同的 agency_timezone。
agency_lang 语言代码 选填 此公交公司使用的主要语言。此字段可帮助 GTFS 使用方为数据集选择大写规则和其他特定于语言的设置。
agency_phone 电话号码 选填 指定代理机构的语音电话号码。此字段是一个字符串值，用于提供代理机构服务区域的典型电话号码。可以而且应该包含标点符号，以便对号码的数字进行分组。允许使用可拨号文本（例如 TriMet 的 503-238-RIDE），但该字段不得包含任何其他描述性文本。
agency_fare_url 网址 选填 允许乘客在线购买车票或机票的其他交通工具的网页网址。
agency_email 电子邮件 选填 代理机构的客户服务部门正在主动监控电子邮件地址。此电子邮件地址应作为直接联系点，以便乘客能够联系到公交公司的客服代表。

stops.txt

文件：必需

字段名称 类型 必需 说明
stop_id ID 必需 标识站点、站点或站点入口。

“车站入口”这一术语指的是车站入口和站点出口。站点、车站或车站入口统称为位置。多条路线可使用同一停靠站。
stop_code 文字 选填 用于标识乘客位置的简短文本或数字。这些代码通常用于基于电话的公交信息系统中，或印在标识牌上，以便让乘客更轻松地获取特定位置的信息。如果 stop_code 是面向公众的，则可与 stop_id 相同。对于未向乘客提供代码的地点，此字段应留空。
stop_name 文字 视情况要求提供 营业地点的名称。请使用当地居民和游客可以理解的当地语言。

如果营业地点是寄养区域 (location_type=4)，stop_name 应包含代理机构显示的寄养区域名称。可以是只包含一个字母（例如某些欧洲城际火车站）或“轮椅登机区”（纽约市地铁）或“小火车头”（巴黎 RER）等文字。

有条件地要求：
• 必须为经停点 (location_type=0)、车站 (location_type=1) 或入口/出口 (location_type=2) 的位置。
• 是通用节点 (location_type=3) 的位置。
stop_desc 文字 选填 提供实用、高质量的信息的地点说明。不要直接复制营业地点的名称。
stop_lat 纬度 视情况要求提供 营业地点的纬度。

有条件地要求：
• 必须为经停点 (location_type=0)、车站 (location_type=1) 或出入站 (location_type=2) 的地点。
• 对于通用节点 (location_type=3) 或登机区域 (location_type=4) 的位置，此位置是可选的。
stop_lon 经度 视情况要求提供
zone_id ID 视情况要求提供 标识经停点的费用区域。如果您使用 fare_rules.txt 提供机票价格信息，则必须填写此字段，否则此字段为选填字段。如果此记录表示车站或车站的入口，则会忽略 zone_id。
stop_url 网址 选填 营业地点相关网页的网址。此值应不同于 agency.agency_url 和 routes.route_url 字段值。
location_type 枚举 选填 位置类型：
• 0（或为空）：停止（或平台）。乘客登上或离开公交车辆的位置。在 parent_station 中定义时，平台称为“平台”。
• 1：站点。包含一个或多个平台的物理结构或区域。
•2：入口/退出。乘客可以从街道进入或离开车站的位置。如果入口/出口属于多个站点，可以通过通往两个站点的通道链接到该站点，但数据提供商必须从其中一个站点作为父级站点。
•3：通用节点。车站内的位置，不匹配任何其他 location_type，可用于关联 pathways.txt 中定义的路径。
• 4：登机区。平台上的特定位置，乘客可在这里上车和/或轻型车辆。
parent_station 引用“stops.stop_id”的 ID 视情况要求提供 定义 stops.txt 中定义的不同位置之间的层次结构。其中包含父站位置的 ID，如下所示：
• 停靠/平台 (location_type=0)：parent_station 字段包含站点的 ID。
•车站 (location_type=1)：此字段必须为空。
•入口/出口 (location_type=2) 或通用节点 (location_type=3)：parent_station 字段包含站点 ID (location_type=1)
• 登机区域 (location_type=4)：parent_station 字段包含平台 ID。

有条件要求：
• 对于进入 (location_type=2)、通用节点 (location_type=3) 或登机区域 (location_type=4) 的位置，是必需参数。
• 对于站点/站台 (location_type=0)，这是选填项。
• (location_type=1)。location_type=3
stop_timezone 时区 选填 营业地点的时区。如果某个营业地点有父站，则会继承父站的时区，而不是应用其自己的时区。stop_timezone 中的空站和无子站可继承 agency.agency_timezone 指定的时区。如果提供了 stop_timezone 值，则应将 stop_times.txt 中的时间输入为自 agency.agency_timezone 指定时区的午夜以来的时间。这样可确保无论行程跨越哪个时区，行程中的时间值始终会在行程过程中增加。
wheelchair_boarding 枚举 选填 指明某个位置是否可以使用轮椅登机服务。有效选项包括：

对于无子站：
0 或空 - 没有有关停靠点的无障碍信息。
1 - 此停靠站内的部分车辆可让坐轮椅的乘客搭乘。
2 - 此站不可使用轮椅通道。

对于子站：
0 或空 - 如果从父站指定了子站，则其将继承父站的 wheelchair_boarding 行为。
1 - 有一些从站外到特定停靠站/站台的无障碍通道。
2 - 没有从站外到特定停靠站/站台的无障碍路径。

对于车站入口/出口：
0 或为空 - 车站入口将从父级站点沿用其 wheelchair_boarding 行为（如果为父级站点指定了行为）。
1 - 站台设有无障碍通道。
2 - 没有从站点入口到站点/站台的无障碍通道。
level_id 引用“levels.level_id”的 ID 选填 营业地点的级别。多个未关联的电台可以使用同一级别。
platform_code 文字 选填 站台（属于车站的停靠站）的平台标识符。该名称应仅用于平台标识符（例如，G 或 3。不应包含“平台”或“轨道”（或 Feed 中特定语言的等效项）等字词。这样，Feed 消费者就更容易将平台标识符国际化，并将其本地化为其他语言。

routes.txt

文件：必需

字段名称 类型 必需 说明
route_id ID 必需 标识路线。
agency_id 引用“agency.agency_id”的 ID 视情况要求提供 指定路线的代理机构。如果数据集为 agency.txt 中多个代理机构提供的路线提供了数据，则此字段为必填字段；否则，此字段是可选的。
route_short_name 文字 视情况要求提供 路线的简称。这通常是一个简短的抽象标识符，如“32”、“100X”或“Green”，供乘客用于标识路线，但未提供路线服务的任何地点。必须指定 route_short_name 和/或 route_long_name（如果适用）。
route_long_name 文字 视情况要求提供 路线的全名。此名称通常比 route_short_name 更具描述性，通常包含路线的目的地或车站。必须指定 route_short_name 和/或 route_long_name（如果适用）。
route_desc 文字 选填 提供实用、优质信息的路线说明。不要直接复制路线名称。
例如：“A”列车在皇后区 Inwood-207 St、Manhattan 和 Far Rockaway-Mott Avenue 之间运行。另外，大约在早上 6 点到午夜时分，额外的“A”列车在 Inwood 207 St 和 Lefferts Boulevard 之间运行（列车通常在 Lefferts Blvd 和 Far Rockaway 之间交替）。
route_type 枚举 必需 指明路线使用的交通方式。有效选项包括：

0 - 电车、有轨电车、轻轨。都市区域中的任何轻轨或路面水平系统。
1 - 地铁，地铁。都市区域中的任何地下轨道系统。
2 - 轨道交通。用于城市之间或远距离运输。
3 - 公交车。用于近距离和远距离公交路线。
4 - 轮渡。用于近距离和远距离船运服务。
5 - 电车电车。用于电梯行驶在车辆下方的街道级别的轨道车，例如旧金山的缆车。
6 - 高空缆车、悬挂式缆车（例如：吊厢索道、空中电车）。一种使用一根或多根缆绳悬挂小屋、汽车、空中缆车或椅子的有线电视传输服务。
7 - 缆索铁路。为陡峭坡面设计的任何轨道系统。
11 - 无轨电车。使用杆子从升降线中获取电力的电动公交车。
12 - 单轨列车。一种轨道，由一条轨道或一条横梁组成。
route_url 网址 选填 关于特定路线的网页网址。此值应该不同于 agency.agency_url 值。
route_color 颜色 选填 路线颜色标识与面向公众的材料相匹配。如果省略或留空，则默认为白色 (FFFFFF)。在黑白屏幕上查看时，route_color 与 route_text_color 之间的颜色差异应该可以提供足够的对比度。
route_text_color 颜色 选填 在 route_color 背景上绘制的文本使用的清晰颜色。如果省略或留空，则默认为黑色 (000000)。在黑白屏幕上查看时，route_color 与 route_text_color 之间的颜色差异应该可以提供足够的对比度。
route_sort_order 非负整数 选填 按非常适合向客户展示的方式对路线进行排序。应该先显示 route_sort_order 值较小的路由。
continuous_pickup 枚举 选填 指明乘客是否可以沿车辆行驶路径的任何位置上车。shapes.txt 会描述该路线的每次行程。有效选项包括：

0 - 持续停止上车。
1 或为空 - 无需连续停止上车。
2 - 必须致电代理机构，才能安排持续停止自提。
3 - 必须与司机协调，以安排连续停止上车。

在 routes.txt 中定义的默认连续提货行为可在 stop_times.txt 中替换。
continuous_drop_off 枚举 选填 指明乘客是否可以沿公交车辆沿途的任何点离开车辆。该路径由 shapes.txt 描述该路线的每次行程。有效选项包括：

0- 连续停止下车。
1 或空 - 无持续停止下车。
2 - 必须请代理机构安排连续停止下车。
3 - 必须与司机协调，以安排持续停止下车。

在 stop_times.txt 中定义的默认连续下车行为可以在 stop_times.txt 中替换。

trips.txt

文件：必需

字段名称 类型 必需 说明
route_id 引用“routes.route_id”的 ID 必需 标识路线。
service_id 引用 calendar.service_id 或 calendar_dates.service_id 的 ID 必需 标识一组服务可在一条或多条路线上提供服务的日期。
trip_id ID 必需 用于标识行程。
trip_headsign 文字 选填 标牌上显示的文字，向乘客标识行程的目的地。此字段用于区分同一路线上的不同服务模式。如果标牌在行程中发生变化，则可以通过为 stop_times.stop_headsign 指定值来替换 trip_headsign。
trip_short_name 文字 选填 面向公众的文字，用于标识乘客的行程，例如，用于标识通勤铁路行程的车号。如果乘客通常不依赖行程名称，请将此字段留空。如果提供 trip_short_name 值，该 ID 应在工作日内唯一标识行程；不应将其用于目的地名称或有限/明确标识。
direction_id 枚举 选填 指明行程的行驶方向。此字段不用于路线；在发布时间表时，它提供了一种按方向分隔行程的方法。有效选项包括：

0 - 单向出行（例如出境旅行）。
1 - 反向行程（例如，入境旅行）。
示例：trip_headsign 和 direction_id 字段可以一起使用，为一组行程指定各个方向的行程名称。trips.txt 文件可能包含用于时间表的以下记录：
trip_id,...,trip_headsign,direction_id
1234,...,Airport,0
1505,...,Downtown,1
block_id ID 选填 标识行程所属的代码块。代码块由单个行程或使用同一车辆进行的许多连续行程（由共享服务天数和 block_id 定义）组成。block_id的行程日期不同，因而具有不同的街区。请参阅以下示例
shape_id 引用“shapes.shape_id”的 ID 视情况要求提供 标识用于描述行程的车辆行程路径的地理空间形状。

必须提供条件
：如果行程在路线级别或停止时间级别定义了连续行为，则此字段为必填字段。
否则为选填字段。
wheelchair_accessible 枚举 选填 表示轮椅通道。有效选项包括：

0 或为空 - 没有此行程的无障碍信息。
1 - 此次行程使用的车辆可容纳至少一名轮椅乘客。
2 - 本次行程无法容纳轮椅乘客。
bikes_allowed 枚举 选填 指明是否允许使用自行车。有效选项包括：

0 或为空 - 没有与此次行程有关的自行车信息。
1 - 此次行程使用的车辆可容纳至少一辆自行车。
2 - 本次行程中不允许骑自行车。

示例：屏蔽时间和服务日

以下示例是有效的，其中一周中的每一天都使用不同的块。

route_id trip_id service_id block_id （首次停止时间） （上次停止时间）
red trip_1 mon-tues-wed-thurs-fri-sat-sun red_loop 22:00:00 22:55:00
red trip_2 fri-sat-sun red_loop 23:00:00 23:55:00
red trip_3 fri-sat red_loop 24:00:00 24:55:00
red trip_4 mon-tues-wed-thurs red_loop 20:00:00 20:50:00
red trip_5 mon-tues-wed-thurs red_loop 21:00:00 21:50:00

上表中的备注：

  • 例如，在周五到周六早上，一辆车会运营trip_1、trip_2和trip_3（晚上 10:00 到中午 12:55）。请注意，上次行程发生在周六凌晨 12:00 至中午 12:55，但属于星期五“服务日”，因为时间是 24:00:00 到 24:55:00。
  • 周一、周二、周三和周四，晚上 8:00 到 10:55，有一辆车在trip_1、trip_4和trip_5运营。

stop_times.txt

文件：必需

字段名称 类型 必需 说明
trip_id 引用“trips.trip_id”的 ID 必需 用于标识行程。
arrival_time 时间 视情况要求提供 针对路线中的特定行程的特定停靠站所达到的时间。如果经停点没有单独的到达和离开时间，请为 arrival_time 和 departure_time 输入相同的值。对于在服务当天午夜后发生的时间，以行程时间表开始当天的 HH:MM:SS 当地时间形式输入大于 24:00:00 的时间值。

如果车辆严格遵守指定的到达时间和出发时间，则视为已安排停留时间。如果此停靠站不是时间点，建议提供估算或插值时间。如果未提供，则可以将 arrival_time 留空。此外，请表示插值时间通过 timepoint=0 提供。如果插值时间以 timepoint=0 表示，则必须使用 timepoint=1 表示时间点。为所有到达时间站的到达时间提供到达时间。必须为行程中的第一个和最后一个停靠站指定到达时间。
departure_time 时间 视情况要求提供 从路线上的特定行程的特定停靠站出发的时间。对于在服务当天午夜后发生的时间，请以 HH:MM:SS 当地时间形式输入时间大于 24:00:00 的时间，该时间是行程时间表开始当天。如果经停点没有单独的到达和离开时间，请为 arrival_time 和 departure_time 输入相同的值。如需详细了解如何正确使用时间点，请参阅 arrival_time 说明。

departure_time 字段应尽可能指定时间值，包括各时间点之间的非约束性估计时间或插值时间。
stop_id 引用“stops.stop_id”的 ID 必需 标识服务站。行程期间服务的所有经停点都必须在 stop_times.txt 中具有记录。提及的地点必须是站点，不得是车站或入口。同一站内可多次提供同一站内服务，且多个行程和路线服务可在同一站内服务。
stop_sequence 非负整数 必需 特定行程的停靠站顺序。值必须随行程而增大，但不必是连续的。
示例：行程中的第一个地点可以具有 stop_sequence=1，行程中的第二个地点可以具有 stop_sequence=23，第三个地点可以具有 stop_sequence=40，依此类推。
stop_headsign 文字 选填 标牌上显示的文字，向乘客标识行程的目的地。当标牌在不同停靠站之间发生更改时，此字段会替换默认的 trips.trip_headsign。如果显示整个行程的标牌，请改用 trips.trip_headsign。

为一个 stop_time 指定的 stop_headsign 值不适用于同一行程中的后续 stop_time。如果您要针对同一行程中的多个 stop_time 替换 trip_headsign，则必须在每个 stop_time 行中重复使用 stop_headsign 值。
pickup_type 枚举 选填 指明提货方法。有效选项包括：

0 或空 - 按计划定期自提。
1 - 无法自提。
2 - 必须通过电话与代理机构联系才能安排自提。
3 - 必须与司机协调，才能安排自提。
drop_off_type 枚举 选填 表示还车方法。有效选项包括：

0 或空 - 定期安排的还车。
1 - 不支持下车点。
2 - 必须请电话代理机构安排下车点。
3 - 必须与司机协调，以便安排下车点。
continuous_pickup 枚举 选填 指明乘客是否可以沿车辆行驶路径的任何位置上车。路径由 shapes.txt 描述，从该 stop_time 到行程的 stop_sequence 中的下一个 stop_time。有效选项包括：

0 - 持续停止上车。
1 或为空 - 无需连续停止上车。
2 - 必须致电代理机构才能安排持续自提。
3 - 必须与司机协调，以安排持续停止上车。

stop_times.txt 中指定的持续提货行为会覆盖 routes.txt 中定义的任何行为。
continuous_drop_off 枚举 选填 指明乘客是否可以在行程的shapes.txt（从该stop_time到行程 stop_sequence中的下一个 stop_time）期间沿车辆行驶路径的任一点下车。

0 - 持续停止下车。
1 或空 - 无持续停止下车。
2 - 必须请代理机构安排连续下车。
3 - 必须与司机协调，以便安排持续下车。

stop_times.txt 中指定的持续下车行为会覆盖 routes.txt 中定义的任何行为。
shape_dist_traveled 非负浮点数 选填 从相关记录（从本记录中指定的第一个停靠点到停靠点）沿实际形状行驶的实际距离。此字段用于指定在行程期间任意两个经停点之间绘制的形状的多少。必须采用 shapes.txt 中使用的单位。用于 shape_dist_traveled 的值必须随 stop_sequence 一起增加；它们不能用于显示路线的反向行程。
示例：如果公交从形状起点到停靠点之间的距离为 5.25 公里，则 shape_dist_traveled=5.25。
timepoint 枚举 选填 指明车辆是否严格遵守站点的到达和出发时间，或者是大概时间和/或插值时间。此字段允许 GTFS 生产者提供插值停止时间，同时指明时间是近似时间。有效选项包括：

0 - 时间会被视为近似时间。
1 或为空 - 时间会被视为精确时间。

calendar.txt

文件：已有条件要求

字段名称 类型 必需 说明
service_id ID 必需 用于为一条或多条路线提供服务的日期唯一标识一组日期。每个 service_id 值最多只能在 calendar.txt 文件中出现一次。
monday 枚举 必需 指明在 start_date 和 end_date 字段指定的日期范围中的所有星期一是否提供服务。请注意，特定日期的例外情况可能列在 calendar_dates.txt 中。有效选项包括：

1 - 在相应日期范围内的所有星期一均提供服务。
0 - 在该日期范围内，星期一不提供服务。
tuesday 枚举 必需 与 monday 相同的方式（适用于星期二）
wednesday 枚举 必需 与 monday 相同的方式，星期三除外
thursday 枚举 必需 与 monday 相同的方法（星期四除外）
friday 枚举 必需 函数的工作方式与 monday 相同，但适用于星期五
saturday 枚举 必需 此函数与 monday 采用相同方式，但星期六除外。
sunday 枚举 必需 函数与 monday 相同，但适用于星期日。
start_date 日期 必需 服务间隔的起始日。
end_date 日期 必需 服务间隔的结束日期。服务天数包含在间隔时间内。

calendar_dates.txt

文件：已有条件要求

calendar_dates.txt 表可以按日期明确启用或停用服务。它可以通过以下两种方式使用：

  • 建议：将 calendar_dates.txt 与 calendar.txt 结合使用，以定义 calendar.txt 中定义的默认服务模式的例外情况。如果服务通常比较规律，但对明确日期稍作调整（例如，为了配合特别活动服务或上学计划），则这是一种不错的方法。在本例中，calendar_dates.service_id 是引用 calendar.service_id 的 ID。
  • 备选方案：省略 calendar.txt，并在 calendar_dates.txt 中指定每个服务日期。这样一来，服务可以有很大的差异，而且服务时间不会很安排正常。在本例中，service_id 是 ID。
字段名称 类型 必需 说明
service_id 引用 calendar.service_id 或 ID 的 ID 必需 识别一个或多个路由发生服务异常时的日期。如果将 calendar.txt 和 calendar_dates.txt 结合使用，每个 (service_id, date) 对在 calendar_dates.txt 中只能出现一次。如果 calendar.txt 和 calendar_dates.txt 中都出现 service_id 值，calendar_dates.txt 中的信息会修改 calendar.txt 中指定的服务信息。
date 日期 必需 发生服务异常的日期。
exception_type 枚举 必需 指明服务在 date 字段中指定的日期是否可用。有效选项包括：

1 - 服务已在指定日期添加。
2 - 移除了指定日期的服务。
示例：假设某路线中包含一组可在假期使用的行程，以及另一组可在所有其他日期使用的行程。一个 service_id 可以对应于常规服务时间表，另一个 service_id 可以对应于节假日时间表。对于特定节假日，可以使用 calendar_dates.txt 文件将节假日添加到节假日 service_id，并从常规 service_id 中移除节假日。

fare_attributes.txt

文件：可选

字段名称 类型 必需 说明
fare_id ID 必需 标识机票价格等级。
price 非负浮点数 必需 价格，采用 currency_type 指定的单位。
currency_type 货币代码 必需 用于支付机票费用的币种。
payment_method 枚举 必需 指明必须支付机票费用的时间。有效选项包括：

0 - 机票含车费。
1 - 必须在上车前支付费用。
transfers 枚举 必需 指明此机票价格允许的中转次数。将该字段留空可能属于例外情况，即必填字段不得为空。有效选项包括：

0 - 此机票价格不允许中转。
1 - 乘客可转一次。
2 - 乘客可中转两次。
空 - 可无限次换乘。
agency_id 引用“agency.agency_id”的 ID 视情况要求提供 标识机票的相关代理机构。对于在 agency.txt 中定义多个代理机构的数据集，此字段为必需字段，否则为选填字段。
transfer_duration 非负整数 选填 转移过期前的时间长度（以秒为单位）。如果为 transfers=0，此字段可用于指示票券的有效期，也可将其留空。

fare_rules.txt

文件：可选

fare_rules.txt 表用于指定 fare_attributes.txt 中应用于行程的票价。大多数费用结构都组合采用以下某些规则：

  • 费用取决于起始车站或目的地车站。
  • 费用取决于路线经过的区域。
  • 费用取决于路程采用的路线。

如需查看演示如何使用 fare_rules.txt 和 fare_attributes.txt 指定票价结构的示例，请参阅 GoogleTransitDataFeed 开源 Wiki 中的 https://code.google.com/p/googletransitdatafeed/wiki/FareExample。

字段名称 类型 必需 说明
fare_id 引用“fare_attributes.fare_id”的 ID 必需 标识机票价格等级。
route_id 引用“routes.route_id”的 ID 选填 标识与机票价格等级关联的路线。如果存在多个具有相同费用属性的路由，请在 fare_rules.txt 中为每个路线创建一条记录。
例如：如果费用等级“b”在路线“TSW”和“TSE”上有效，则 fare_rules.txt 文件将包含费用等级的以下记录：
fare_id,route_id
b,TSW
b,TSE
origin_id 引用“stops.zone_id”的 ID 选填 标识源区域。如果费用等级有多个出发地，请在 fare_rules.txt 中为每个 origin_id 创建一条记录。
例如：如果费用等级“b”对源自区域“2”或区域“8”的所有行程有效，则 fare_rules.txt 文件将包含费用等级的以下记录：
fare_id,...,origin_id
b,...,2
b,...,8
destination_id 引用“stops.zone_id”的 ID 选填 标识目的地区域。如果费用等级具有多个目的地区域，请在 fare_rules.txt 中为每个 destination_id 创建一条记录。
示例：您可以结合使用 origin_id 和 destination_id 字段来指定费用等级“b”适用于区域 3 和 4 之间的行程，以及针对区域 3 和 5 之间的行程，fare_rules.txt 文件将包含费用等级的以下记录：
fare_id,...,origin_id,destination_id fare_id,...,origin_id,destination_id fare_id,...,origin_id,destination_id fare_id,...,origin_id,destination_id fare_id,...,origin_id,destination_id fare_id,...,origin_id,destination_id fare_id,...,origin_id,destination_id
contains_id 引用“stops.zone_id”的 ID 选填 标识使用指定票价等级时乘客将进入的区域。在某些系统中用于计算正确的票价等级。
示例：如果费用等级“c”与通过区域 5、6 和 7 的 GRT 路线上的所有行程相关，fare_rules.txt 将包含以下记录：
fare_id,route_id,...,contains_id
c,GRT,...,5
c,GRT,...,6
c,GRT,...,7
由于所有 contains_id 区域都必须匹配才能应用费用，因此经过区域 5 和 6 但未通过区域 5 且不具有区域 5 的行程需遵循价格。如需了解详情，请参阅 GoogleTransitDataFeed 项目 Wiki 中的 https://code.google.com/p/googletransitdatafeed/wiki/Fareexamples。

shapes.txt

文件：可选

形状用于描述车辆沿路线对齐时经过的路径，在文件 shapes.txt 中定义。形状与行程相关联，由车辆按顺序经过的一系列点组成。形状不需要精确地停靠停靠点的位置，但行程中的所有停靠点都应该位于该行程的形状小范围内，也就是说，靠近连接形状点的直线段。

字段名称 类型 必需 说明
shape_id ID 必需 标识形状。
shape_pt_lat 纬度 必需 形状点的纬度。shapes.txt 中的每条记录都表示用于定义形状的形状点。
shape_pt_lon 经度 必需 形状点的经度。
shape_pt_sequence 非负整数 必需 形状点连接形成形状的序列。值必须随行程而增大，但不必是连续的。
例如：如果形状“A_shp”的定义中有三个点，shapes.txt 文件可能会包含以下记录来定义形状：
shape_id,shape_pt_lat,shape_pt_lon,shape_pt_sequence
A_shp,37.61956,-122.48161,0
A_shp,37.64430,-122.41070,6
A_shp,37.65863,-122.30839,11
shape_dist_traveled 非负浮点数 选填 从形状的第一个点到本记录中指定的点，沿形状行驶的实际距离。供行程规划人员在地图上显示形状的正确部分。值必须随 shape_pt_sequence 一起增加；不能用来显示路线的反向行程。距离单位必须与 stop_times.txt 中使用的单位一致。
例如：如果公交车沿上述为 A_shp 定义的三个点前行，则其他 shape_dist_traveled 值（此处以公里为单位）将如下所示：
shape_id,shape_pt_lat,shape_pt_lon,shape_pt_sequence,shape_dist_traveled
A_shp,37.61956,-122.48161,0,0
A_shp,37.64430,-122.41070,6,6.8310
A_shp,37.65863,-122.30839,11,15.8765

frequencies.txt

文件：可选

frequencies.txt 文件表示按照常规行驶间隔（行程之间的时间）运营的行程。此文件可用于表示两种不同类型的服务。

  • 基于频率的服务 (exact_times=0) 是指服务并非一整天都会遵循固定的时间表。运营商会试图严格保持行程的预定行驶方向。
  • 基于时间表的服务 (exact_times=1) 的压缩表示形式，在指定时间段内，行程的完全相同。在基于时间表的服务运营商中，尽量严格遵守时间表。
字段名称 类型 必需 说明
trip_id 引用“trips.trip_id”的 ID 必需 用于标识应用指定行驶方向的行程。
start_time 时间 必需 第一辆具有指定行驶方向的车辆第一站的离开时间。
end_time 时间 必需 服务在行程中的第一个停靠站更改为不同行驶方向（或停止）的时间。
headway_secs 非负整数 必需 由 start_time 和 end_time 指定的时间间隔内，自同一行程的同一经停点（离开）开始之间的间隔时间（以秒为单位）。同一行程可以有多条车道，但不得重叠。新车道的行驶时间可能会与前一个车道的结束时间完全相同。
exact_times 枚举 选填 指明行程的服务类型。如需了解详情，请参阅文件说明。有效选项包括：

0 或空 - 基于频率的行程。
1 - 基于时间表的行程，全天具有相同的行程进度。在本例中，end_time 值必须大于上次所需的行程 start_time 但小于上次所需的行程 start_time + headway_secs。

transfers.txt

文件：可选

计算行程时，使用 GTFS 的应用会根据允许的时间和停止近程来插入传输。transfers.txt 文件为所选转移作业指定其他规则和替换项。

字段名称 类型 必需 说明
from_stop_id 引用“stops.stop_id”的 ID 必需 标识路线之间的连接开始的站点或站点。如果此字段引用了站点，则转移规则将应用于其所有子站点。
to_stop_id 引用“stops.stop_id”的 ID 必需 标识路线之间的连接终点的停靠点或车站。如果此字段表示站点，则换乘规则适用于所有子站。
transfer_type 枚举 必需 表示指定（from_stop_id、to_stop_id）对的连接类型。有效选项包括：

0 或空 - 建议在路线之间换乘。
1 - 两条路线之间的定时配送点。离开的车辆将等待到达，并留出足够的时间让乘客在路线之间换乘。
2 - 转移需在到达和出发之间至少留出一定时间，以确保建立联系。转移所需的时间由 min_transfer_time 指定。
3 - 无法在不同地点的路线之间换乘。
4 - 乘客可以乘坐同一辆车，在一段行程中换乘（“座位换乘”）。
5 - 不允许在连续的行程之间换乘座位。乘客必须下车后再重新上车。
min_transfer_time 非负整数 选填 指定站点之间的中转点之间必须经过的秒数。min_transfer_time 应足以允许典型乘客在两个站点之间移动（包括缓冲时间），以允许每条路线上的计划变化。

pathways.txt

文件：可选

GTFS 路径扩展功能使用图示描述地铁或火车，其中包含节点（位置）和边缘（路径）。

从入口（以“location_type=2”表示的位置节点）到平台（以“location_type=0”表示的位置节点）处，乘客将穿过人行道、票务大门、楼梯等（这些边缘以路径表示）。提案还会添加另一种类型的地点，即“通用节点”这种通用地点，以表示用户可通过不同的人行道从人行横道进入的情况。

警告：车站中的路径必须详尽无遗。因此，只要一个站点的站台或节点（属于站点）有与之关联的路径，我们便会假定该站点具有关于其路径的详尽描述。因此，请遵循以下常识规则：

  • 没有悬挂位置：如果站内的任何位置设有步道，则所有位置都应有步道（带有登机区域的平台除外）。
  • 没有锁定的平台：每个平台必须通过某些路径链连接到至少一个入口。在现实生活中，在极少数的情况下，您不能外出。
  • 没有提供登入区的平台提供路径：具有登入区的平台被视为父级对象，而不是点。它可能没有指定路径。所有途径均应作为寄宿区。
字段名称 类型 必需 说明
pathway_id ID 必需 pathway_id 字段包含唯一标识路径的 ID。系统使用 pathway_id 作为此记录的内部标识符（例如，数据库中的主键），因此 pathway_id 必须是数据集唯一的。
不同的路径可以从同一 from_stop_id 指向同一 to_stop_id。例如，当两个自动扶梯并排列为相反方向时，或者当楼梯在附近且电梯从同一位置转到同一位置时，就会出现这种情况。
from_stop_id 引用“stops.stop_id”的 ID 必需 开发者在线课程开始的位置。它包含一个 stop_id，用于标识 stops.txt 文件中的平台、进入/退出、通用节点或登机区域。
to_stop_id 引用“stops.stop_id”的 ID 必需 开发者在线课程的结束位置。它包含一个 stop_id，用于标识 stops.txt 文件中的平台、进入/退出、通用节点或登机区域。
pathway_mode 枚举 必需 指定（from_stop_id、to_stop_id）对之间的路径类型。此字段的有效值包括：
• 1：人行道
• 2：楼梯
• 3：移动人行道/旅行者
• 4：自动扶梯
• 5：电梯
• 6：费用门口：跨越车站的入口通道（通常需在各个付款站之间或各付款站之间彼此独立）。这些信息可用于避免那些使用需要乘客进行非必要付款的快捷方式的车站供乘客到达目的地，例如指引乘客在地铁站内搭乘公交。
• 7：出口关口：表示出口所在的区域不再需要付款证明，而该地区不再需要付款证明。
is_bidirectional 枚举 必需 指明路径的使用方向：
• 0：单向路径，只能在 from_stop_id 到 to_stop_id 之间使用。
• 1：双向，可以双向使用。

检票门 (pathway_mode=6) 和出口门 (pathway_mode=7) 不能是双向的。
length 非负浮点数 选填 从起点位置（在 from_stop_id 中定义）到目标位置（在 to_stop_id 中定义）的水平长度（以米为单位）。

建议为人行道 (pathway_mode=1)、票价入口 (pathway_mode=6) 和出口口 (pathway_mode=7) 使用此字段。
traversal_time 正整数 选填 从起点位置（在“from_stop_id”中定义）到目标位置（在“to_stop_id”中定义）所需的平均步行时间（以秒为单位）。

建议将此字段用于移动人行道 (pathway_mode=3)、自动扶梯 (pathway_mode=4) 和电梯 (pathway_mode=5)。
stair_count 非 null 整数 选填
stair_count 为负值意味着乘客从from_stop_id走到to_stop_id。

对于楼梯 (pathway_mode=2)，建议填写此字段。
max_slope 浮点值 选填 路径的最大斜率。此字段的有效值包括：
• 0 或（空）：没有斜率。
•浮动：路径的斜率，正值表示向上，负值表示向下。

此字段只能用于人行道 (pathway_type=1) 和移动人行道 (pathway_type=3)。

例如：在美国，0 分 0.083 米（0.083 米），因此在手推轮椅上的最大斜率为 0.083（也称为 8.3%）。
min_width 正浮点数 选填 路径的最小宽度（以米为单位）。

如果最小宽度小于 1 米，则强烈建议填写此字段。
signposted_as 文字 选填 物理标牌中的一串文字，对公交乘客可见。该字符串可用于向用户提供文本路线，例如“遵循符号”。
reversed_signposted_as 文字 选填 与 signposted_as 字段相同，但当采用反向路径（即从 to_stop_id 到 from_stop_id）时。

level.txt

文件：可选

请描述一个电台的不同级别。与 pathways.txt 结合使用时，此功能尤为实用，是电梯 (pathway_mode=5) 所必需的权限，用于要求用户乘坐电梯到“Mezzanine”或“Platform”级别。

字段名称 类型 必需 说明
level_id ID 必需 可从 stops.txt 引用的级别的 ID。
level_index 浮点值 必需 会员级别数值指数，表示该会员级别相对于其他会员地点的相对位置（假定索引值较高，该级别位于级别较低的地方）。

地平面应设置指数 0，地平面以上为以正指数表示的楼层，以低于地面的楼层为负指数。
level_name 文字 选填 楼层的可选名称（与建筑物或车站内使用的楼层字母/编号一致）。适用于“电梯间路线”设置（例如“搭乘电梯到“Mezzanine”或“Platforms”或“-1”）。

Feed_info.txt

文件：已有条件要求

此文件包含有关数据集本身的信息，而不是数据集描述的服务。在某些情况下，数据集的发布者与代理机构不同。如果提供了 translations.txt，则此文件是必需的。

字段名称 类型 必需 说明
feed_publisher_name 文字 必需 发布数据集的组织全名。该值可能与其中一个 agency.agency_name 值相同。
feed_publisher_url 网址 必需 数据集发布组织网站的网址。该值可能与其中一个 agency.agency_url 值相同。
feed_lang 语言代码 必需 此数据集中默认文字的语言。此设置可帮助 GTFS 使用方为数据集选择大小写规则和其他语言专用设置。

若要定义其他语言，请使用 translations.txt 中的 language 字段。

多语言数据集可能是默认语言版本，并且支持多种语言的原始文本。在这种情况下，请在 feed_lang 字段中使用 ISO 639-2 语言代码 mul。为 translations.txt 数据集中使用的每种语言提供译文。如果数据集中的所有原始文本都使用同一语言，请勿使用 mul。

例如，瑞士的数据集可能会设置填充有不同语言的站点名称的原始 stops.stop_name 字段。每个充电站的名称都会按照其所在地理位置的主流语言进行书写。站名包括日内瓦语（代表日内瓦市）、苏黎世（德语区苏黎世）和比尔/比恩语（代表双语城市比尔/比耶内）。设置 feed_lang=mul，并在 translations.txt 中提供以下翻译：
  • 德语：“Genf”、“Zürich”和“Biel”
  • 法语：“Genève”、“Zurich”和“Bienne”
  • 意大利语：“Ginevra”、“Zurigo”和“Bienna”
  • 英语：“Geneva”、“Zurich”和“Biel/Bienne”
default_lang 语言代码 选填 定义数据使用者不知道乘客所用的语言。它通常定义为英语 en。
feed_start_date 日期 选填 此数据集提供完整可靠的服务时间表信息，从 feed_start_date 天开始到 feed_end_date 天结束。如果不可用，这两个天可以留空。如果同时指定两者，则 feed_end_date 日期不得早于 feed_start_date 日期。建议数据集提供商在此时间段之外提供时间安排数据，以便为将来可能出现的服务提供建议，但数据集使用者应注意其非权威性。如果 feed_start_date 或 feed_end_date 超出 calendar.txt 和 calendar_dates.txt 中定义的有效日历日期，则数据集明确声明在 feed_start_date 到 feed_end_date 范围之内没有服务，但未包含在有效日历日期内。
feed_end_date 日期 选填 请参阅此表中的 feed_start_date 行。
feed_version 文字 选填 指明其 GTFS 数据集的当前版本的字符串。使用 GTFS 的应用可显示此值，以帮助数据集发布商确定是否已纳入最新的数据集。
feed_contact_email 电子邮件 选填 用于接收关于 GTFS 数据集和数据发布实践的电子邮件地址。feed_contact_email 是处理 GTFS 的应用的技术联系人。通过 agency.txt 提供客户服务联系信息。
feed_contact_url 网址 选填 联系信息、网络表单、支持台或其他与 GTFS 数据集和数据发布做法相关的沟通工具的网址。feed_contact_url 是处理 GTFS 的应用的技术联系人。通过 agency.txt 提供客户服务联系信息。

翻译.txt

文件：可选

字段名称 类型 必需 说明
table_name 枚举 必需

定义包含要翻译的字段的数据集表。允许使用以下值：

  • agency
  • stops
  • routes
  • trips
  • stop_times
  • feed_info
  • pathways
  • levels
  • attributions
field_name 文字 必需

提供要翻译的字段的名称。可以翻译类型为“文本”的字段，而包含“网址”、“电子邮件”和“电话号码”类型的字段可以在此处以正确的语言提供这些资源。
language 语言代码 必需

提供翻译语言。

如果此语言与 feed_info.txt 中 feed_lang 的语言相同，该字段的原始值就是没有特定翻译语言的默认值。

例如，在瑞士，双语州的城市正式称为“Biel/Bienne”，但简称为“Bienne”（法语）和“Biel”（德语）。
translation 文本、网址、电子邮件地址或电话号码 必需 提供指定 field_name 的翻译值。
record_id ID 视情况要求提供

定义与要翻译的字段对应的记录。record_id 中的值必须是数据集表中的主 ID，如下表所示：

table_name record_id
agency agency_id
stops stop_id
routes route_id
trips trip_id
stop_times trip_id
pathways pathway_id
levels level_id
attributions attribution_id

以下条件决定了如何使用此字段：

  • table_name 等于 feed_info 时禁止。
  • 如果定义了 field_value，则禁止使用此属性。
  • 如果 field_value 为空，则此项是必需的。
record_sub_id ID 视情况要求提供

当 record_id 中引用的表没有唯一 ID 时，帮助转换包含该字段的记录。record_sub_id 中的值是数据集表的次要 ID，如下表所示：

table_name record_sub_id
agency NONE
stops NONE
routes NONE
trips NONE
stop_times stop_sequence
pathways NONE
levels NONE
attributions NONE

以下条件决定了如何使用此字段：

  • table_name 等于 feed_info 时禁止。
  • 如果定义了 field_value，则禁止使用此属性。
  • 如果 table_name 等于 stop_times 且定义了 record_id，则必需。
field_value 文本、网址、电子邮件地址或电话号码 视情况要求提供

无需使用 record_id 和 record_sub_id 来定义需要转换的记录，可以使用 field_value 定义要翻译的值。使用时，如果 table_name 和 field_name 标识的字段包含的值与 field_value 中定义的值完全相同，系统就会应用转换。

该字段必须与 field_value 中定义的值完全匹配。如果只有一部分值与 field_value 匹配，则不会应用转换。

如果两条转换规则与同一记录匹配，一条具有 field_value 规则，另一条具有 record_id 规则，则需要使用 record_id 规则。

以下条件决定了如何使用此字段：

  • table_name 等于 feed_info 时禁止。
  • 如果定义了 record_id，则禁止使用此属性。
  • 如果 record_id 为空，则此项是必需的。

Attributions.txt

文件：可选

字段名称 类型 必需 说明
attribution_id ID 选填 识别数据集或其子集的归因。此字段对于翻译非常有用。
agency_id ID 参考 选填 归因所适用的代理机构。如果定义了一个 agency_id、route_id 或 trip_id 归因，其他字段必须为空。如果未指定，则归因会应用于整个数据集。
route_id ID 参考 选填 此字段的作用与 agency_id 相同，不同之处在于归因适用于路由。同一路线可应用多个归因。
trip_id ID 参考 选填 此字段的作用与 agency_id 相同，不同之处在于归因适用于行程。同一行程可采用多种归因方式。
organization_name 文字 必需 数据集所属的组织的名称。
is_producer 枚举 选填 组织的角色是提供方。允许的值包括：
• 0 或空：组织没有此角色。
•1：组织具有此角色。
必须至少将 is_producer、is_operator 或 is_authority 中的一个字段设置为 1。
is_operator 枚举 选填 功能与 is_producer 相同，不过组织的角色是运算符。
is_authority 枚举 选填 功能与 is_producer 相同，除非组织的角色是权限。
attribution_url 网址 选填 组织的网址。
attribution_email 电子邮件 选填 组织的电子邮件地址。
attribution_phone 电话号码 选填 组织的电话号码。