首页 › weekly › 公交出行开源底座:6个小众神器

公交出行开源底座:6个小众神器

概述:这期为什么不挖AI,去挖公交车

连挖这么多期下来,AI 工具链、自托管全家桶、终端神器基本被翻了个底朝天。这期刻意换到一条极少被中文圈写过的赛道:公共出行的开源数据底座。你手机上「下一班地铁还有 3 分钟」的背后,藏着一套全世界通用的开放数据标准 GTFS,以及围绕它长出来的完整开源流水线——标准制定、数据体检、接口逆向、城市级到站平台、众包导航 App。这批仓库没有万星光环,却是无数交通部门、出行 App 和地图厂商每天都在吃的基础粮,二次开发和接单空间清晰。覆盖标准、质检、接入、平台、产品五个层级,其中四个仓库 Star 还在两千以下,属于典型的闷声干活型选手。文中星数均为撰写时(2026-09)的约数,以仓库页面实时数据为准。


1. MobilityData/gtfs-spec | 数百星 | 开放治理,持续演进

一句话定位:给全世界的公交、地铁、轮渡定一门通用数据语言——GTFS 规范的「法典」本体。

解决什么痛点:每家公交公司的时刻表格式五花八门,Excel、PDF、私有数据库应有尽有。做一个跨城市的出行 App,理论上要接一百种接口。GTFS(General Transit Feed Specification)源起于谷歌早年把公交时刻表搬进地图的尝试,后来被推成全球开放标准:把一座城市的公交网络拆成 stops、routes、trips、stop_times、calendar 等十来张 CSV 表,打成一个 zip 就能完整描述「哪条线、几号线、几点几分从哪个站台发车」。

核心亮点:这个仓库的看点不在代码量,而在「立法现场」本身——票价、无障碍设施、换乘路径、多语言翻译等扩展仍在通过公开的 RFC 流程演进,任何交通公司和开发者都能提修改意见,由 MobilityData 基金会主持治理。一个字段怎么改,背后是全球几百套系统的兼容权衡,克制得近乎保守,这正是它能活二十年的原因。

上手难度:⭐⭐(读懂即可,不用写代码)

适用人群:出行 App 开发者、政府数据开放部门、数据工程师。变现思路:帮中小城市和巴士公司把 Excel 时刻表清洗成合规 GTFS feed,是一門旱涝保收的数据服务;懂规范的人在国内公共交通数字化项目里也是稀缺角色。


2. MobilityData/gtfs-validator | 数百星 | 官方出品,流水线刚需

一句话定位:GTFS 数据的官方体检仪,feed 发出去之前的最后一道关卡。

解决什么痛点:GTFS 本质是手填的 CSV,人间错误密度极高——一个 stop_id 引用写错,整条线路在所有 App 里直接「查无此车」;发车时间跨午夜没处理,末班车永远显示昨天的。靠人肉检查一座城市的几百条线路不现实。

核心功能拆解:Java 实现的规则引擎,内置上百条规则,按 ERROR / WARNING / INFO 三级输出结构化的问题报告,精确到文件、行号和实体 ID。提供命令行和网页两种用法,可以单次体检一个 zip,也可以挂进 CI——不少国家的交通数据门户已经把它嵌进发布流水线,不合格的 feed 直接打回重交。想给某个城市或交通公司搭数据门户,这套校验环节几乎是现成的基础件。

上手难度:⭐⭐⭐(会跑 Java/Docker,能看懂规则报告)

适用人群:做政府交通数据平台的服务商、GTFS 数据生产者。变现思路:数据治理外包——「发布前体检 + 修复建议」可以包装成年度服务费模式,客户粘性极强。


3. derhuerst/hafas-client | 千级星 | 小而美,十分钟上手

一句话定位:把欧洲几十家公交公司的封闭接口,逆向封装成一个统一的 JavaScript API。

解决什么痛点:欧洲大陆的公共交通系统普遍跑在德国 HaCon 公司的 HAFAS 平台上——德国铁路、柏林公交、各地联盟各有各的网页和 App,数据锁死在各自围墙里。想查「从汉堡到柏林下一班火车晚点没有」,得一家一家去爬。

核心功能拆解:npm i hafas-client,五行代码就能查到柏林下一个发出的地铁班次。它的设计精髓在 profile 机制:每个运营商对应一个适配文件,把各自的接口差异(鉴权方式、报文字段、实时数据格式)挡在同一套 Promise API 之后——查时刻表、查实时延误、查换乘方案、查站点附近的到达信息,函数签名完全一致。社区多年持续新增 profile,是德语区无数通勤工具、聊天机器人和数据可视化的隐形发动机。单维护者长期打磨,文档里连每个接口的坑都写得清清楚楚,是小而美仓库的教科书样本。

上手难度:⭐⭐(会 npm 就能跑)

适用人群:独立开发者、数据爱好者。变现思路:做德语区通勤提醒 Bot、企业差排班工具,或者把查询能力封装成付费 API——用户付费意愿在通勤场景里非常成熟。


4. schildbach/public-transport-enabler | 数百星 | 安卓阵营的老兵底座

一句话定位:一套 Java 写的公交协议适配层,多款知名开源通勤 App 背后的发动机。

解决什么痛点:移动端做公交查询,最重的活不是 UI,而是适配各个地区五花八门的公交信息系统协议。这个库把好几套主流协议的解析、请求构造、实时数据抽取全部封装好,App 开发者只需要面向一个统一的数据模型写界面。

核心功能拆解:它最出名的身份是 Öffi 和 Transportr 这两款欧洲老牌开源通勤 App 的底层引擎,覆盖数以十计的国家和城市,从时刻表查询、实时延误到中断通告一应俱全。代码里能看到大量对真实接口怪癖的防御性处理——这正是这类适配层多年踩坑攒下的护城河,后来者想绕开它从零写一遍,代价远比看起来高。适合作为安卓通勤类产品的私有化底座,也适合研究「多协议数据接入层」该怎么设计。

上手难度:⭐⭐⭐⭐(Java 库,需要自己搭应用层)

适用人群:安卓开发者、出海工具团队。变现思路:面向欧洲、中东等市场做白标通勤 App,把「城市开通」做成按城市收费的运营服务。


5. OneBusAway | 千级星(含服务端全家桶) | 长期社区维护

一句话定位:开源实时到站平台的鼻祖——「下一班车还有几分钟」这件事的开源答案。

解决什么痛点:商业到站预报系统报价高昂,中小城市根本装不起。OneBusAway 起源于西雅图的大学研究项目,后来交给社区和各城市自主运营,把实时到站能力做成了任何人都能部署的开源平台,北美多个城市用它给市民提供官方到站服务。

核心功能拆解:整体是「服务端 + App」结构:服务端把 GTFS 时刻表和车辆实时位置聚合成到站预测,通过开放 API 输出;乘客端 App 显示到站倒计时、车辆在地图上的实时位置,还能设「到站闹钟」——快到站了提醒你出门,冬天等车场景里是刚需功能。仓库链接给到安卓端,服务端各模块在 OneBusAway 组织下同源维护,官网有完整的部署文档。这套「时刻表 + 实时流 = 预测」的架构,也是理解整个出行数据行业的最佳教材。

上手难度:⭐⭐⭐⭐(服务端是 Java 全家桶,部署有分量)

适用人群:智慧城市集成商、交通信息化团队。变现思路:给二三线城市做公交数字化整体方案——开源底座免授权费,赚部署、定制和运维的钱,模式已被反复验证。


6. trufi-association/trufi-app | 数百星 | Star 最低,故事最硬

一句话定位:官方没有公交数据的城市,怎么做出导航?玻利维亚人给出的答案是:志愿者坐车把线路「踩」出来。

解决什么痛点:在玻利维亚科恰班巴,公共交通主力是私营小巴 trufi,没有官方时刻表、没有线路图,谷歌地图一片空白,新来的人和本地人一样抓瞎。发达世界的开源方案在这里全部失效——不是软件问题,是没有数据。

核心功能拆解:Trufi 协会的打法是先用最土的办法解决数据:志愿者实地坐车记录走向和站点,众包整理成线路数据集,再用自己的跨平台 App 提供换乘导航;数据生产、校验、导航展示整套流程全部开源,任何一座「数据空白城市」都可以照抄这套模式起步。它提醒所有做地图和出行的人:这个星球上大多数城市的公交,其实都没有被数字化。对国内团队来说,这套模式平移到园区班车、景区接驳、县城乡村公交等「封闭场景」,就是现成的产品模板。

上手难度:⭐⭐⭐(定制 App 需要前端开发,数据采集靠运营)

适用人群:新兴市场创业者、公益科技团队、做封闭场景接驳的企业。变现思路:园区/景区/县域的「小巴导航」整体交付,数据采集运营 + App 定制双收费。


横向对比

仓库 层级 Star(约) 上手难度 适用场景
gtfs-spec 数据标准 数百 ⭐⭐ 读懂全球公交数据语言
gtfs-validator 数据质检 数百 ⭐⭐⭐ feed 发布流水线、数据治理
hafas-client 接口接入 千级 ⭐⭐ 欧洲实时数据聚合、快速原型
public-transport-enabler 接口接入 数百 ⭐⭐⭐⭐ 安卓通勤 App 底座
OneBusAway 城市平台 千级 ⭐⭐⭐⭐ 城市级实时到站服务
trufi-app 终端产品 数百 ⭐⭐⭐ 无官方数据城市、封闭场景

数据怎么流:一张图看懂这条开源栈

flowchart TD
    A["GTFS 数据标准"] --> B["gtfs-validator 体检"]
    B --> C["城市数据门户"]
    A --> D["hafas-client 接入"]
    A --> E["协议适配层"]
    D --> F["通勤App与机器人"]
    E --> F
    C --> G["OneBusAway 到站平台"]
    C --> H["Trufi 众包导航"]

本期之最

参考来源

  1. MobilityData/gtfs-spec — GTFS 规范本体与公开治理流程
  2. GTFS 官网 — 标准文档、案例与生态总览
  3. derhuerst/hafas-client — 各运营商 profile 列表与 API 用法
  4. OneBusAway 官网 — 项目背景、部署文档与使用城市
  5. Trufi Association — 众包公交数据模式介绍
  6. schildbach/public-transport-enabler — 支持的协议与覆盖范围说明

[!tip] 51学通信知识星球 星主:爱卫生(微信:gprshome201101)——公众号「51学通信」创办者,19 年通信行业运维与讲师经验,著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书(各大电商平台有售)。 星球定位:深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域,主打运维岗位与信令分析。 当前规模:5200 篇主题 / 990 个回答,198 元/年。 加入福利:加入星球后请加爱卫生微信,拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题,另有群内分享。 AI 加持:51学通信知识星球已作为 skill 接入 WorkBuddy,使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例,做总结、找文档和 PPT 等场景全覆盖。

51学通信知识星球海报-扫码加入