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