⚡ electrical engineering

Recurring Public Transit Schedules: Stable Identification from GTFS and Similarity Analysis

本文介绍了一种利用 H3 路线模式键（route-pattern keys）和相似性度量，从 GTFS 数据中识别并将循环出现的公共交通时刻表形式化为“日类型”（DayTypes）的方法，通过区分微小的时刻偏移与显著的服务变更，从而实现更高效的时刻表同步、车辆调度和需求分配。

原作者： Evgeny Makarov, Georgy Taubkin

发布于 2026-06-16

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Evgeny Makarov, Georgy Taubkin

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

请将公共交通时刻表想象成一个庞大且混乱的图书馆，里面堆满了各种公交和地铁的时间表。如果你看日历，你可能会认为每一天都有独特的时刻表。但实际上，大多数日子都是彼此的副本。周一看起来像其他的周一；周六看起来像其他的周六。而节假日，则是打破这种模式的“特别版”。

问题在于，目前用于分享这些时刻表的标准数字格式（称为 GTFS）并没有以此方式进行组织。它将每一天的每一次行程都列为唯一的，仿佛它们都是互不相同的，这使得计算机很难发现其中的重复模式。这就像一本食谱书，其中“周一的汤”和“周二的汤”被列为完全不同的食谱，尽管它们其实是一模一样的，仅仅是因为页码不同。

这篇论文介绍了一种清理这个“图书馆”并将这些时刻表归类为逻辑“家族”的方法。

核心理念：“DayTypes”（日期类型）

作者将这些家族称为 DayTypes。可以将 DayType 想象成一个“模板”或“模具”。

模板： 系统不再观察 365 天，而是发现其中有 52 天是“周一模板”，52 天是“周六模板”，可能还有 5 天是“元旦模板”。
目标： 通过以这种方式对日子进行分组，规划者可以不再把每一天都视为一个独特的谜题。他们可以洞察全局：“噢，这家机构运行着一个‘工作日’模具、一个‘周末’模具和一个‘节假日’模具。”

“名称”与“现实”之间的矛盾

论文强调了当前存储交通数据时的一个棘手问题。它依赖于行政 ID（如 shape_id 或 stop_id），这些 ID 就像是内部图书馆的目录编号。

类比： 想象一条从 A 点到 B 点的公交线路。有一天，交通机构将该线路的内部目录编号从“Route-123”更改为“Route-456”，尽管公交车停靠的地点和顺序完全没有变化。
旧方法： 计算机会认为“Route-123”和“Route-456”是两辆完全不同的公交车。它会认为时刻表发生了变化，即便乘客的体验并未改变。
新方法（H3 键值）： 作者使用了一种被称为 H3 索引 的巧妙技巧。他们不再信任内部目录编号，而是观察实际的物理地图。他们将每个公交站变成地图上一个微小的、唯一的数字瓷砖（类似于像素）。如果公交车以相同的顺序经过相同的瓷砖，系统就会知道这是同一条线路，无论机构在内部如何称呼它。这使得系统能够“免疫”于行政名称的变化。

“容差”测试：是变化还是仅仅是偏移？

一旦系统对日子进行了分组，它就需要对它们进行比较。作者创建了一个三步走的“尺子”来衡量两个时刻表之间的差异程度：

精确尺子（审计）： 这会检查时刻表是否精确到秒地完全一致。如果一辆车在周一 8:00:00 出发，而在周二 8:00:01 出发，这把尺子会判定：“它们是不同的！”这对于捕捉数据错误或微小的刻意调整非常有用。
灵活尺子（时间容差）： 这是“日常使用”的尺子。它会问：“如果我们允许一个小小的延迟（比如 3 分钟），这些时刻表是否基本上是相同的？”如果车辆在周一 8:00 出发，而在周二 8:02 出发，这把尺子会判定：“足够接近了！它们是同一个时刻表，只是稍微偏移了。”
结构尺子： 这会检查结构是否不同。如果周一有 10 辆车，而周二只有 2 辆；或者周二跳过了一个站点，这把尺子会判定：“这些是完全不同的时刻表”，即使那仅有的几辆车的运行时间很接近。

他们的发现

作者在来自日本和加拿大的真实数据上测试了这个系统。

结果： 他们成功地剥离了杂乱的信息，并找到了隐藏的模式。例如，在加拿大的一座城市中，他们发现了一个清晰的循环，仅包含三种 DayTypes：工作日、周六和周日。在日本的一座城市中，他们发现了一个与一切都完全不同的“元旦” DayType。
惊喜之处： 他们发现，在加拿大，许多在纸面上看起来“完全不同”（因为时间不完全匹配）的时刻表，实际上只是具有微小时间偏移的相同时刻表。然而在日本，一些看起来不同的时刻表确实在结构上是不同的（路线或站点不同），而不仅仅是时间偏移。

为什么这很重要

这篇论文并不是发明了一种新的运行公交车或预测交通的方法。相反，它构建了一个更好的翻译层。

它将杂乱、原始的数据转化为干净、可识别的“DayTypes”。
它让计算机不再会被名称的变化或微小的时间差异所困扰。
它为规划者提供了一份清晰、精简的“时刻表模板”列表供其使用，使比较不同城市、检查错误或进行未来规划变得更加容易。

简而言之，这篇论文提供了一种智能且稳定的方式来组织混乱的公共交通时刻表，将一座名为“每日数据”的资料大山转化为了可以管理的重复模式集合。

技术摘要：循环公共交通时刻表：基于 GTFS 的稳定识别与相似性分析

1. 问题陈述

公共交通时刻表表现出循环的服务结构，即多个日历日期共享相同的面向乘客的时刻表（例如标准工作日），而其他日期则因周末、节假日或特殊事件而不同。然而，通用交通数据规范（GTFS）作为全球性的交通数据标准，并未明确编码这些循环的“类型日”（DayTypes）。相反，GTFS 通过相互依赖的表格（日历、行程、停靠时间、形状）来表示服务，这迫使下游的调度、车辆分配和需求分析模型必须从碎片化的数据中重建循环的供应对象。

核心挑战有两个方面：

识别（Identification）： 如何在不依赖行政标识符（如 shape_id、stop_id，这些标识符在不同版本的 Feed 发布时可能会发生变化）的情况下，从 GTFS 中提取稳定的循环服务类别（DayTypes）。
比较（Comparison）： 如何比较这些提取出的时刻表，以区分严格的时刻表差异、微小的计时偏移（例如 1 分钟延迟）以及实质性的结构性变化（例如线路的增加或移除）。

2. 方法论

2.1. 正式定义

本文形式化了两个关键概念：

线路模式（Route Pattern）： 一种由有序停靠序列和行驶方向定义的面向乘客的服务变体。与作为行政标识符的 GTFS shape_id 不同，线路模式是由物理路径和停靠顺序定义的。
类型日（DayType）： 指具有完全相同运行线路模式及运行时间的日期集合。它严格定义为行程规范的集合： $DayType(d) = \{(p, dep_t, arr_t)\}$ ，其中 $p$ 是线路模式， $dep_t/arr_t$ 是首次出发和最后到达时间。

2.2. 基于 H3 索引的稳定提取

为了确保对行政标识符重标记的稳定性，作者提出了一种使用 H3 分层地理空间索引系统（Uber Technologies, 2018）的提取方法。

线路模式键（Route Pattern Key）： 该方法不使用 shape_id 或 stop_id，而是将有序的停靠点坐标序列转换为 H3 单元格（分辨率 15）序列。该序列作为一个确定性的、稳定的线路模式键。
提取算法：
1. 扩展 GTFS 日历和异常表，为每个日期生成活跃行程列表。
2. 对于每个活跃行程，将其停靠序列转换为基于 H3 的线路模式键。
3. 构建行程规范元组： $(H3\_key, first\_departure, last\_arrival)$ 。
4. 将共享完全相同的行程规范元组集合的日期归为一个单一的类型日（DayType）。
不变性（Invariance）： 这种方法确保了如果两个 GTFS Feed 描述的是同一种物理服务但使用了不同的行政 ID，只要停靠点坐标和顺序未变，提取出的 DayType 分区保持一致。

2.3. 时刻表比较框架

本文引入了一个三层层级指标体系来比较 DayType $A$ 和 $B$ ：

精确指标 ( $d_0$ )：
- 对行程规范集合使用 Jaccard 距离。
- 将线路模式、出发时间或到达时间的任何差异视为不同的 DayType。
- 作为数据质量和有意向的计时调整的严格审计信号。
时间容差指标 ( $d_\epsilon$ )：
- 引入容差参数 $\epsilon$ （例如 1、3 或 5 分钟）。
- 如果两个行程共享相同的线路模式键，且其出发/到达时间差异 $\le \epsilon$ ，则视为 $\epsilon$ -等价。
- 基于最大 $\epsilon$ -等价对的数量计算时间容差 Jaccard 距离。
- 此层级用于判断精确差异是否仅为微小的计时偏移。
结构可比性诊断（Structural Comparability Diagnostics）：
- 为了防止将微小的匹配过度解读为整体时刻表的相似性，该框架计算：
  - 匹配份额 ( $M_\epsilon$ )： 在容差范围内可以进行配对的行程比例。
  - 行程数量不平衡度 ( $Q$ )： 两个 DayType 之间总行程数的相对差异。
  - 未匹配计数 ( $U_\epsilon$ )： 无法进行配对的行程数量。
- 这有助于区分“同一时刻表的计时偏移版本”（高 $M_\epsilon$ ，低 $Q$ ）与“结构性服务变化”（低 $M_\epsilon$ ，高 $Q$ ）。

3. 主要贡献

形式化定义： 将线路模式和 DayType 定义为循环供应对象，区别于内部车辆或人员调度。
稳定提取： 开发了一种使用 H3 线路模式键的 GTFS 提取程序，该程序对行政标识符重标记具有不变性，解决了纵向 GTFS 分析中的关键复现性问题。
比较层级： 提出了一个分离了严格审计（精确）、时间敏感性（时间容差）和结构性变化（诊断）的指标系统，解决了使用单一相似性度量指标的局限性。
下游效用： 提供紧凑的循环时刻表集，可作为时刻表同步、车辆调度、需求分配和偏差诊断模型的输入。
实证验证： 在日本和加拿大的 GTFS 数据集上验证了该框架，证明了在不同网络规模和日历编码策略下的成功提取。

4. 结果与发现

该框架应用于 40 个日本机构和 38 个加拿大机构。

提取成功率： 算法成功识别了所有机构的循环 DayType，无需人工干预，恢复了标准的每周循环（工作日/周六/周日）、节假日例外情况以及单日异常情况。
DayType 数量： 在两个国家，非空 DayType 的中位数数量均为 4。然而，日本机构表现出更高的变异性（最大 39 个）相比于加拿大机构（最大 17 个），反映了日本样本中更细粒度的节假日/季节性日历。
不相交性分析（Disjointness Analysis）：
- 精确不相交性： 大量机构的 DayType 对存在零共享行程的情况（Jaccard 距离 = 1.0）。这种情况在加拿大（36% 的机构）比在日本（15% 的机构）更常见。
- 容差影响： 当应用时间容差（1–5 分钟）时，加拿大许多“精确不相交”的对获得了部分匹配，表明它们是相似结构的计时变体。在日本，精确不相交性更为持久，表明服务体制之间存在更强的结构性分离。
- 结构现实： 尽管在容差下获得了匹配，但中位匹配份额仍然很低（加拿大 6.3%，日本 0%），且伴随高行程数量不平衡度。这证实了许多“不相交”的 DayType 代表了根本不同的服务量或线路集，而非仅仅是偏移的时刻表。
嵌套关系（Nesting）： 在 69% 的日本机构和 58% 的加拿大机构中观察到了完全嵌套（即一个 DayType 是另一个的严格子集），这表明渐进式服务缩减是两地共同的普遍做法。

5. 重要性与主张

本文将其贡献定位为一种方法论表示层，而非一种新的优化算法。其重要性在于：

弥合差距： 它将原始、碎片化的 GTFS 数据连接到下游方法论模型（如赤字函数分析、车辆调度）所需的循环供应对象。
稳定性： 通过将服务识别与行政 ID 解耦，它实现了对跨版本 Feed 发布进行可靠的纵向演化分析。
细致解读： 提出的指标层级防止了将微小的计时噪声误分类为结构性服务变化，同时仍保留了审计精确时刻表偏差的能力。
紧凑表示： 它将大规模、特定日期的时刻表转化为紧凑的循环 DayType 库，从而促进更高效的调度、需求分配和偏差分析。

作者总结道，虽然 GTFS 没有明确定义 DayType，但它们是隐含编码的，并且可以使用该框架进行稳健的提取和比较，为高级交通规划和分析提供了必要的基石。