全局视野下的快速验证：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）网络。

为避免功能重叠，我决定专注于车辆的实时位置与到站时间预测（ETA）。并且鉴于 TTC 尚未开始分享地铁的实时位置数据，我决定将公交和街车作为切入点，着手开发 LiveBus。

2. 功能构想与设计理念

常坐 TTC 的人可能都遇到过这样的情形：通过短信或应用查询到站时间，结果车辆并未如期而至。造成这种偏差的原因很多，不能完全避免。但如果能在查看 ETA 的同时，也能直接看到车辆的实时位置，用户就可以自行判断信息是否可靠——这正是 LiveBus 想要实现的交叉验证体验。

市面上的实时公交应用，数据来源都是 TTC 官方或第三方 API。这些应用中很多也能实现"车"与"站"的交叉验证。LiveBus 将吸取各家所长，既然数据源大同小异，就在展示方式上做文章，围绕快速响应、直观呈现、交互友好三个原则展开开发。

这样的构想明确了 LiveBus 的核心功能：以地图为载体，实时展示公交车辆位置；点击站点即可查看预计到达时间（ETA）。用户可通过"车"与"站"的信息互相印证，更有把握地判断到站时间。

设计上追求轻量、易用、直观——不追求大而全，只解决"车在哪"和"还要等多久"两个核心问题。拿出手机，一目了然，随查随走。

基于此理念，LiveBus 采用渐进式 Web 应用（PWA）构建。无需下载安装，浏览器打开即用；也可添加到桌面，一键启动。

3. 他山之石：类似应用调研

动手开发之前，先调研一下市面上已有的类似应用。评测范围限定为有地图界面的实时公交应用，重点关注以下几个维度：

• 能否显示车辆实时位置及行进方向
• 能否显示站点 ETA
• 能否同时显示多条线路
• 交互友好程度

以下评测基于常规搜索和简单试用，不一定能全面反映各应用的真实能力，仅作为参考。

3.1 TTC官方网站

TTC 官方提供的实时公交地图，功能强大：能展示车辆实时位置、行进方向，以及各站点的 ETA。能同时展示多条线路的车辆和站点，但需要用户提前选定要查看的线路。

底图采用 Google Maps，用户可随时查看由 Google 提供的实时路况，交叉验证到站时间；但地图交互速度较慢。

移动端体验一般，弹窗信息过于丰富，挤占了屏幕空间。

3.2 Transit

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

功能上，能展示用户选定线路的路线图、车辆实时位置、各站点 ETA，界面设计感强。大部分功能需要付费订阅。

3.3 Transit Now

此应用能显示用户选定路线的线路图、该路线上的实时车辆位置（含行进方向）、该路线上每个站点的预期到达时间。界面清晰，功能强大。

如同 TTC 官方网站一样，该应用也采用 Google Maps 底图，平移缩放都略显缓慢，却没有把查看实时路况的功能留给用户。没有同时显示多条线路的功能。

3.4 My TTC

此应用在功能上与 Transit Now 高度相似，但是在选定的路线上，无法切换到不同的站点。

3.5 TTC Watch

此应用能在地图上显示公交站点、站点 ETA、车辆实时位置（含行进方向）。底图似乎采用 Apple Maps，无法查看路况。可以同时显示多条线路，但跟 TTC 官网一样，需要用户手动添加。

3.6 totransit

该网站能显示用户选定线路上每辆公交车的实时位置（含行进方向），但不提供站点 ETA。

3.7 umo

该应用能展示用户选定线路的路线图、每辆车的实时位置（含行进方向，甚至"停车中"状态），以及各站点 ETA。界面直观，操作简便。

用户必须先通过文字界面选定线路和站点。此外，即使某站点服务多条线路，也只能显示当前选定线路在该站的 ETA。

3.8 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。这个数据源的优势在于简便直接，支持按站点查询，缺点在于数据来源来自第三方，稳定性可能不如官网，将来可以考虑替换成 TTC 官网数据。

5.2 地图底图

我注意到 TTCmap 的地图底图从最初的 Google Maps 变成了 Protomaps PMTiles。这样的自托管地图底图方案，符合 LiveBus 的轻量化原则。于是进行了效仿，将地图瓦片整体下载后自托管在 Cloudflare R2 上，获得了显著的效率提升。

同样本着轻量化原则，LiveBus 采用 Leaflet 进行构建。

6. 开发心得

6.1 使用体验与验证

从日常使用来看，应用运行稳定，响应迅速，数据更新及时，实现了设计目标。

一些非常规的状况也得到了验证，比如下图显示根据 ETA，有三辆车几乎同步驶来。用户可能会怀疑是不是数据出了问题。

带着怀疑，用户马上就能在地图上验证。果然，在不远处，真的有三辆车几乎同步驶来。见下图。

偶尔会遇到"车"与"站"信息不一致的情况。下图中，车距离站已经不远了，但 ETA 显示还有 22 分钟，显然哪里出了问题。而这恰恰也体现了交叉验证的价值：当信息存疑时，用户可以自行甄别，或前往 TTC 官网 确认是否有服务中断。

关于数据源的局限性和优化方向，将在下文进一步探讨。

6.2 避免数据滥用

采用开源数据意味着要对数据源负责。为避免频繁请求给服务器造成负担，LiveBus 实现了分层缓存机制：车辆位置数据在服务端缓存 10 秒，ETA 数据同样缓存 10 秒。在缓存有效期内，用户请求由缓存响应，不会触达上游服务器。对于车辆位置请求，当多个用户同时请求时，服务端会合并为一次上游请求，进一步降低对数据源的压力。

6.3 首次定位速度

首次打开 LiveBus 时，浏览器可能需要三至五秒钟来获取用户位置。这在手机上尤为明显，因为 GPS 需要时间"热身"。为了不让用户干等，LiveBus 先显示多伦多全景地图，待定位完成后再自动跳转到用户所在的社区。将来可能先根据网络信息粗略估算位置，让地图更快显示在用户附近，再逐步精确定位。

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 等众多优秀项目的启发。开源社区的分享精神，让这类"小工具"得以快速落地。

每个人处理信息的方式不同。有人偏好文字列表，有人偏好地图可视化。我属于后者，喜欢在一张地图上看到实时车辆和站点的互动，直观又高效。

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