全局视野下的快速验证：LiveBus 多伦多实时公交地图开发记录

2026 年 1 月 11 日，我上线了 LiveBus，一个面向多伦多的实时公交地图。

上线后，我在小红书和 Reddit 的 r/toronto 发了介绍帖。24 小时内，LiveBus 有近 3000 次访问；Reddit 帖子获得了 26 万次浏览和 1300 次点赞。一周后，推广帖热度已经过去，日均访问量仍然稳定在 500 左右。

这篇文章记录 LiveBus 从想法到上线的过程，也顺带写下后续还想补上的功能。

1. 起因：为什么开发 LiveBus

做完 2026 世界杯可视化地图应用 后，我想再做一个更贴近日常生活的多伦多本地项目。

去年 7 月，我看到一则新闻：多伦多大学博士生 Andrew Ilersich 做了 TTCmap，把 TTC 地铁的服务变更和中断信息放到一张实时交互地图上。市面上已经有不少公交应用，但 TTCmap 的轻量、直观和实用给我留下了很深的印象。

TTCmap 主要关注地铁服务变更和中断信息。作者也提到，未来可能会把功能扩展到公交车（Bus）和街车（Streetcar）网络。

为了避免和 TTCmap 做重复的事，我把方向放在车辆实时位置和到站时间预测（ETA）上。TTC 目前还没有公开地铁实时位置数据，所以公交和街车成了更合适的切入点。LiveBus 就是从这个想法开始的。

2. 功能构想与设计取舍

常坐 TTC 的人应该都遇到过这种情况：短信或应用显示车还有 5 分钟到，结果等了很久还是没来。造成偏差的原因很多，不能完全避免。但如果看 ETA 的同时也能看到车在哪里，用户至少可以自己判断这条预测靠不靠谱。这就是 LiveBus 最核心的体验：把“车”和“站”的信息放在一起交叉验证。

实时公交应用的数据来源大多离不开 TTC 官方或第三方 API。很多应用也能同时显示车辆和站点信息。所以 LiveBus 的重点不是“拿到别人没有的数据”，而是把已有数据用更直接的方式呈现出来。我把开发重点放在三件事上：响应要快，信息要直观，交互不要绕。

于是核心功能就很清楚了：地图上显示实时车辆位置；点击站点查看 ETA；用户可以把车辆位置和站点到站时间放在同一个空间里判断。

设计上，我不想把 LiveBus 做成一个大而全的交通应用。它只回答两个问题：车在哪？还要等多久？拿出手机，打开就看，判断完就走。

基于这个目标，LiveBus 做成了渐进式 Web 应用（PWA）。不用下载安装，浏览器打开即可使用；如果经常用，也可以添加到手机桌面。

3. 类似应用调研

动手开发前，我先看了一圈已有的实时公交应用。范围限定在有地图界面的实时公交工具，重点看四件事：

• 是否显示车辆实时位置和行进方向
• 是否显示站点 ETA
• 是否能同时理解多条线路
• 手机上用起来是否顺手

下面的评测基于常规搜索和简单试用，不代表每个应用的完整能力，只作为开发 LiveBus 时的参考。

3.1 TTC官方网站

TTC 官方实时公交地图功能很全：可以显示车辆实时位置、行进方向和站点 ETA，也能同时展示多条线路的车辆和站点。不过用户需要先手动选择要看的线路。

底图使用 Google Maps，可以顺手查看实时路况，用来辅助判断到站时间；缺点是地图交互速度偏慢。

移动端体验一般。弹窗信息很多，屏幕空间很快被占满。

3.2 Transit

Transit 是 TTC 官方合作应用，优势是能自动检测并显示公交车、街车的计划外改道。

它可以显示选定线路的路线图、车辆实时位置和各站点 ETA，界面也比较成熟。缺点是大部分功能需要付费订阅。

3.3 Transit Now

Transit Now 可以显示选定路线的线路图、该路线上的实时车辆位置（含行进方向），以及每个站点的预计到达时间。界面清楚，功能也比较完整。

和 TTC 官网一样，它也用 Google Maps 作为底图，平移和缩放略慢；但它没有把查看实时路况的功能开放给用户，也不能同时显示多条线路。

3.4 My TTC

My TTC 的功能和 Transit Now 很接近，但在选定路线后，不能方便地切换到不同站点。

3.5 TTC Watch

TTC Watch 可以在地图上显示公交站点、站点 ETA 和车辆实时位置（含行进方向）。底图看起来是 Apple Maps，不能查看路况。它支持多线路显示，但和 TTC 官网一样，需要用户手动添加。

3.6 totransit

totransit 可以显示选定线路上每辆车的实时位置（含行进方向），但不提供站点 ETA。

3.7 umo

umo 可以展示选定线路的路线图、每辆车的实时位置（含行进方向，甚至“停车中”状态），以及各站点 ETA。界面直观，操作也不复杂。

但用户必须先通过文字界面选定线路和站点。即使一个站点服务多条线路，也只能看到当前选定线路在该站的 ETA。

3.8 Citymapper

Citymapper 主要做行程规划。用户可以点击任意站点查看 ETA，但它不展示车辆实时位置。

3.9 小结

综上，市面上已有不少成熟应用，为 TTC 乘客提供了丰富选择。但它们大多需要用户先手动选择线路，再查看车辆信息。

目前还没有一款应用能从宏观视角出发，基于用户位置，自动展示周边所有运行中的车辆和站点，无需选择线路，打开即用，一览全局。

这就是 LiveBus 要填补的空白。

4. LiveBus 的功能与定位

4.1 主要功能

1. 全城实时全景：打开应用后，地图会显示多伦多正在运行的公交车和街车。无需选择线路，先看到整个城市的公交运行状态。车辆位置每 10 秒刷新一次。

2. 基于用户位置的“车”和“站”展示：授权位置后，地图会自动缩放到用户所在街区，显示附近车辆和站点。用户可以点击任意车辆或站点查看信息，也可以把车辆位置和 ETA 放在一起判断“车什么时候来”。

3. 地铁站点参考层：地铁站点作为可选图层显示在地图上，方便换乘时参考。为了保持界面干净，默认关闭，用户需要时可以打开。

4.2 主要特色

LiveBus 去掉了层层嵌套的菜单。用户不需要先选线路、再选方向、再选站点；车辆和站点直接出现在地图上。想看车就点车，想看站就点站。地图可以自由缩放和平移，信息弹窗点开就能看。

4.3 “不做”什么

1. 行程规划：Google Maps 和 TTC 官方推荐的 Triplinx 已经做得很好。LiveBus 只关注“车在哪”，不重复做路线规划。

2. 官方延误和服务警示：TTCmap 在这方面做得很好。当用户在 LiveBus 上看到某个站没有 ETA、附近也看不到车时，自然会去 TTC 官网或 TTCmap 查是否有服务中断。这种被问题触发的信息获取方式已经够用。

3. 展示公交线路图：点击车辆或站点后，如果能显示相关运行线路，会很有帮助。但 TTC 有大量支线和临时调整，处理不好反而容易误导用户。所以这个功能暂时不做，留到后面再评估。

4.4 主要服务人群

LiveBus 不试图服务所有人。它更适合下面两类用户：

1. 视觉导向型用户：更习惯通过地图理解信息，而不是在文字列表和多级菜单中来回跳转。LiveBus 以地图为核心，缩放和平移可以帮助用户快速把握全局。

2. 熟悉路网的日常通勤者：已经知道自己要坐哪条线、往哪个方向走，不需要完整行程规划，只想确认“车到哪了”。对不熟悉多伦多路网的用户来说，LiveBus 更适合作为 Google Maps 等规划工具的补充。

5. 数据来源

5.1 公交数据

1. 车辆实时位置。使用 TTC 官网提供的 Vehicle Positions 实时数据。

2. 站点位置。TTC 官方公布了几个版本的站点数据，并且都在更新。LiveBus 选择了最精简的 TTC Routes and Schedules 数据。这个数据目前硬编码在代码中，设置了每月更新机制，也可以手动更新。

3. 每个站点的预计到达时间（ETA）数据。当前使用 Umo IQ（原 NextBus API）提供的 API。它的好处是查询简单，支持按站点获取 ETA；缺点是第三方数据源的稳定性可能不如 TTC 官方数据。后续可以考虑迁移到 TTC 官方 GTFS-RT 数据。

5.2 地图底图

我注意到 TTCmap 的底图从 Google Maps 换成了 Protomaps PMTiles。这种自托管地图底图符合 LiveBus 的轻量化思路。于是我也下载了地图瓦片，并托管在 Cloudflare R2 上，加载效率明显更好。

同样出于轻量化考虑，LiveBus 使用 Leaflet 构建地图。

6. 开发心得

6.1 使用体验与验证

从日常使用来看，LiveBus 运行稳定，响应快，数据更新也及时，基本达到了最初的设计目标。

一些不常见的情况也验证了这个设计。比如下图中，ETA 显示有三辆车几乎同时到站。光看文字，用户可能会怀疑是不是数据出错了。

但在地图上马上就能看到答案：不远处确实有三辆车几乎同时驶来。

偶尔也会遇到“车”和“站”信息不一致的情况。下图里，车辆已经离站不远，但 ETA 还显示 22 分钟，显然有一边的数据不对。这恰好说明交叉验证有价值：当信息互相矛盾时，用户可以自己判断，也可以去 TTC 官网 确认是否有服务中断。

数据源的局限和后续优化，会在下一节继续写。

6.2 避免数据滥用

使用开放数据，也要对数据源负责。为了避免频繁请求给上游服务器造成负担，LiveBus 做了分层缓存：车辆位置在服务端缓存 10 秒，ETA 数据也缓存 10 秒。缓存有效期内，用户请求直接由缓存响应，不会打到上游。车辆位置请求如果同时来自多个用户，服务端也会合并成一次上游请求，进一步减少压力。

6.3 首次定位速度

首次打开 LiveBus 时，浏览器可能需要 3 到 5 秒获取用户位置。手机上尤其明显，因为 GPS 需要一点时间“热身”。为了不让用户盯着空白等待，LiveBus 会先显示多伦多全景地图，等定位完成后再跳到用户所在街区。以后可以考虑先用网络信息粗略估算位置，让地图更快靠近用户，再用 GPS 精确定位。

7. 后续计划

7.1 数据源优化与功能迭代

ETA 数据源：目前站点 ETA 来自第三方 Umo IQ，还不能确定它和 TTC 官方数据在准确度上哪个更好。TTC 官网提供了更完整的 GTFS-RT 数据，包括 Trip Updates、Modified Trip Updates、Trip Modifications 等。LiveBus 后续会继续研究是否迁移。

线路显示：点击车辆或站点后显示运行线路，会是一个很实用的功能。等相关数据的可靠性验证清楚后，可以考虑加入。

载客量信息：TTC 提供 实时公交车载客量数据。当多辆车接近同一站点时，载客量可以帮助用户选择更空的一辆。LiveBus 计划后续接入。

7.2 界面优化

LiveBus 还有一些细节可以继续打磨，比如显示车辆 ID 和站点 ID、优化字体层级、改进弹窗排版等。这些都不是大动作，但会直接影响日常使用体验。

8. 结语

LiveBus 的成型，离不开 TTC 和多伦多市的开放数据，也离不开 TTCmap 等众多优秀项目的启发。开源社区的分享精神，让这类"小工具"得以快速落地。

每个人处理信息的方式不同。有人喜欢文字列表，有人更习惯地图。我明显属于后者：我喜欢在一张地图上看到车辆、站点和 ETA 之间的关系，然后自己判断下一步怎么走。

LiveBus 的诞生，很大程度上是为了满足我自己的使用要求和习惯。我会在日常通勤中频繁使用 LiveBus。如果它恰巧也给其他 TTC 搭乘者带来便利，那就太好了。