OpenTripPlanner中实时公交到站状态检测的技术实现

在公共交通规划系统OpenTripPlanner中，实时监控公交车辆的到站状态是一个关键功能。开发者在实际使用中发现，当通过GTFS GraphQL API重新获取行程段(leg)数据时，系统无法准确判断乘客上下车站点是否被跳过的问题。

问题背景

公共交通系统在运行过程中，可能会因为各种原因临时取消某些站点的停靠。对于行程规划系统而言，准确识别这些变更对提供可靠的路线建议至关重要。当前版本的OpenTripPlanner虽然提供了realtimeState字段来标识行程段的实时状态，但这个字段仅存在于行程段(leg)层级，而没有细化到具体的上下车呼叫(call)层级。

技术挑战

开发者最初尝试使用pickupType和dropoffType字段来判断站点状态，但当呼叫被取消时，系统会抛出枚举值无效的异常。这是因为当前的PickupDropoffType枚举类型没有包含"CANCELLED"这个可能的值，导致序列化失败。

解决方案

经过技术团队的深入分析，最终决定在boarding和alighting呼叫对象中增加realtimeState字段。这个方案具有以下优势：

1. 与现有的Transmodel API保持一致性
2. 避免修改现有枚举类型可能带来的兼容性问题
3. 提供更细粒度的状态监控能力

实现细节

新增的realtimeState字段将能够反映以下几种状态：

• 按计划停靠(SCHEDULED)
• 跳过停靠(SKIPPED)
• 取消停靠(CANCELLED)
• 未知状态(UNKNOWN)

这种设计使得客户端应用能够：

• 精确识别每个站点的实际停靠情况
• 提供更准确的行程变更通知
• 改善用户体验，避免不准确的路线建议

技术影响

这项改进对系统架构的影响包括：

1. GraphQL schema需要相应更新
2. 数据获取逻辑需要适配新的字段
3. 客户端应用需要处理新增的状态类型

最佳实践建议

对于开发者使用这个新功能，建议：

1. 在行程规划结果展示中明确标注被跳过的站点
2. 考虑提供替代路线建议当关键站点被取消时
3. 在用户界面中区分计划停靠和实际停靠状态

这项改进显著提升了OpenTripPlanner在实时公交场景下的可靠性，为终端用户提供更精准的出行信息服务。