我有兴趣替换我用于GTFS的当前数据格式，但我听到并从那里读到GTFS文件格式存在缺陷。
大多数时候，我发现你无法以某种方式预测某些事情，例如延迟或某些实时内容。他们说你无法与他们达成“全局”。
所以我要问的是有没有人更有经验的GTFS，因为我只是第一次看到它们，可能在某种应用程序中使用GTFS并可以说出他们在开发时遇到的问题？
也许有人对更好的文件格式提出了建议？或者某些格式的组合？
答案 0 :(得分：2)
如果不了解您的应用程序的要求，很难说GTFS是否适合您的应用程序，但我可以提供一些评论。
如果您的目标是向用户提供实时数据，您应该查看GTFS-realtime，这是专门为发布实时更新而设计的补充数据格式。对于大多数公共交通应用，使用GTFS和GTFS实时馈送确实可以提供有关传输网络的“全貌”，或者足够近。
就GTFS本身而言，我的主要抱怨是它似乎专门设计用于路由规划应用程序，并且将此格式的数据用于任何其他目的可能很困难。例如，虽然GTFS订阅源记录有关转接站点和路由的信息，但并不要求每个站点都有一个规范的条目 - 如果数据跨越多个板块周期，则每个站点几乎总会（看似）重复的条目
如果您正在绘制基于的路线和当人旅行时，这无关紧要，因为对象之间的链接确保您始终生成正确的结果。如果你只是从一个人的位置开始并想知道“附近有哪些交通资源？”，那么可靠地产生一个准确的答案需要一些扭曲。
答案 1 :(得分：1)
这取决于您导入现有Feed的需求。如果是，那么无论如何你需要能够处理它。在我的情况下，导入是必需的，所以我使用相同的数据来源于其他格式，如PDF时间表。否则你需要支持两种格式。如果您不需要它进行导入（或导出），您可以考虑自己的格式：我发现GTFS没有显示实际的网络。
GTFS需要相当多的解释和消化才能最终得到你可以回答计划问题的全貌。
如果它们靠近，如同相距几米，我会合并停在一起，如果10-50米，则假设“琐碎的行走”。这会自动处理组合multipe feed。
除此之外，我将stop_times粗略地从里到外转为创建'链接'表'。最终结果是，对于每个站点，您都有一个离港列表及其目的地。
直到现在最大的问题是GTFS供稿可以从操作员的角度记录行程。乘客可以坐在公共汽车上，如果它从351到285的标志翻转，乘坐新的司机并继续。这意味着您需要知道实际需要将哪些行程视为乘客加入。
我通过让我的GTFS解析器接受一些易于编辑的构造来解决手动输入条目的小问题，例如省略序列号以使其以递增方式生成，并将02.13 + 1识别为26.13。