2

我有兴趣用 GTFS 替换我当前使用的数据格式，但我从这里和那里听到并读到 GTFS 文件格式存在缺陷。

大多数时候，我发现您无法以某种方式预测某些事情，例如延迟或某些实时内容。他们说你不能和他们一起了解“全貌”。

所以我要问的是有没有人对 GTFS 更有经验，因为我只是第一次看到他们，他们可能会在某种应用程序中使用 GTFS，并且可以说出他们在开发过程中遇到的问题？

也许有人对更好的文件格式有建议？还是某些格式的组合？

4

2 回答 2

2

如果不知道您的应用程序的要求是什么，很难说 GTFS 是否适合您的应用程序，但我可以提供一些评论。

如果您的目标是向用户提供实时数据，您应该查看GTFS-realtime，这是一种专门为发布实时更新而设计的补充数据格式。对于大多数公共交通应用程序，一起使用 GTFS 和 GTFS 实时馈送确实可以提供有关交通网络的“全貌”，或者足够接近。

就 GTFS 本身而言，我的主要抱怨是它似乎专为路线规划应用程序而设计，并且将这种格式的数据用于任何其他目的可能很困难。例如，虽然 GTFS 提要记录了有关公交站点和路线的信息，但并不要求这些信息中的每一个都有一个单一的、规范的条目——如果数据跨越多个板期，则几乎总是（看似）每个重复条目.

如果您根据一个人的旅行地点和时间来绘制路线，这并不重要，因为对象之间的链接可确保您始终生成正确的结果。如果您只从一个人的位置开始并想知道“附近有哪些交通资源可用？”，可靠地生成准确的答案需要一些曲解。

于 2015-04-23T10:26:59.533 回答
1

这取决于您对导入现有提要的需求。如果是，那么您无论如何都需要能够处理它。就我而言，导入是必需的，因此我对源自其他格式（如 PDF 时间表）的数据使用相同的方法。否则你需要支持两种格式。如果你不需要它来导入（或导出）你可以考虑你自己的格式：我发现 GTFS 并没有显示实际的网络。

GTFS 需要相当多的解释和消化，才能最终得出可以回答规划问题的全貌。

如果它们很近，我将它们合并在一起，比如相距几米，如果 10-50 米，我会假设“微不足道的步行”。这会自动处理组合多个提要。

除此之外，我将 stop_times 大致由内向外转动以创建一个“链接”表。最终结果是，对于每个站点，您都有一个出发地及其目的地的列表。

迄今为止最大的问题是 GTFS 提要可以从操作员的角度记录行程。如果将车​​头标志从 351 翻转到 285，乘客可以继续坐在公共汽车上，让新司机上车并继续行驶。这意味着您需要知道哪些旅行实际上需要被视为以乘客的形式加入。

我通过让我的 GTFS 解析器接受一些易于编辑的构造来解决手动提要输入的小问题，例如省略序列号以使其增量生成，并将 02.13+1 识别为 26.13。

于 2015-05-10T09:14:47.233 回答