我在替换目前使用的GTFS格式的数据，但我从这里和那里听到并读到了GTFS文件格式存在的缺陷。GTFS有哪些问题？
大多数情况下，我看到你不能以某种方式预测一些事情，如延迟或某些实时的东西。他们说你无法与他们一起获得“全貌”。
所以我问的是，有没有人对GTFS有更多的经验，因为我只是第一次看到它们，可能在某种应用中可能使用GTFS，并可以告诉他们在开发时遇到的问题？
也许有人对更好的一种文件格式有什么建议？或者一些格式的组合？
很难说GTFS是否适合您的应用程序而不知道您的应用程序的要求是什么，但我可以提供一些评论。
如果你的目标是向用户提供实时数据，你应该看看GTFS-realtime，这是一种补充数据格式，专门用于发布实时更新。对于大多数公共交通应用而言，将GTFS和GTFS实时馈送结合在一起确实可以提供关于公交网络的“全貌”，或者足够接近。
就GTFS本身而言，我的主要抱怨是，它似乎专门设计了的路线规划应用程序，并且以这种格式将数据用于任何其他目的可能很困难。例如，虽然GTFS Feed记录了有关公交站点和路线的信息，但如果数据跨越多个董事会时段，则不要求每个站点都有一个单一的规范条目—，但几乎总是会有（似乎）重复的条目。
如果你基于绘制的路线上其中当一个人旅行，因为对象之间的联系，确保你总是产生正确的结果。这并不重要。如果您只从一个人的位置开始，想知道“附近有哪些交通资源可用？”，可靠地提供准确的答案需要一些扭曲。
这取决于您导入现有Feed的需求。如果是，那么你需要能够以任何方式处理它。在我的情况下，导入是必需的，所以我使用相同的数据来源于其他格式，如PDF时间表。否则，你需要supoprt两种格式。如果你不需要导入（或导出），你可以考虑你自己的格式：我发现GTFS没有揭示实际的网络。
GTFS需要一些解释和消化才能最终得出整个图片，您可以回答规划问题。
如果它们靠近，就像相隔几米一样，我会合并在一起，并且如果10-50米，假设“平凡步行”。这会自动处理multipe feed的组合。
除此之外，我将stop_times大致从内向外转为创建“链接表”。最终的结果是，每个站点你都有一个出发列表和他们的目的地。
直到现在最大的问题是GTFS提要可以从操作员的角度记录旅行。如果将头目从351转换为285，乘客可以保持坐在公交车上，在车上乘坐新驾驶员并继续行驶。这意味着你需要知道什么旅行实际上需要被视为以乘客的方式加入。
我解决了一个小问题，通过让我的GTFS解析器接受一些易于编辑的构造，比如忽略序列号让它逐步生成，并将02.13 + 1识别为26.13，从而解决了手动馈入条目的小问题。
首先，谢谢你的回答。在你写下最后一段之前，一切都很好？为了帮助我理解，你能告诉我一些什么样的标准来定义“附近有哪些交通资源可用？” ？ – dimrizo
下面是一个例子。假设你想回答，“距离我目前所在地最近的五个交通站点是什么？”仅使用GTFS数据很难回答，因为单个交通车站在“stops”表中可能有多个相应的记录。您必须确定哪个记录对您发布查询的时间有效，但GTFS中没有定义简单的“有效期”字段 - 您必须从Feed提供的时间表信息后退。但请注意，如果您只是生成旅行计划，则这都不是问题。 –
很酷。谢谢。 – dimrizo