OpenTripPlanner中Flex直达路线被错误过滤的问题分析

问题背景

在OpenTripPlanner的多模式路径规划中，当同时启用Flex直达（无换乘）和公交+Flex接驳模式时，系统会出现一个异常行为：虽然Flex直达路线明显更优（耗时更短），但却被错误地过滤掉了。这个问题在Seattle数据集上被发现并报告。

技术原理

OpenTripPlanner的路径规划算法在处理多模式组合时，会使用一个搜索窗口(Search Window)来限定时间范围。这个机制的核心目的是优化搜索效率，避免计算不合理的路线。搜索窗口的计算会考虑以下因素：

1. 用户请求的最早出发时间(earliestDepartureTime)
2. 搜索窗口时长(searchWindow)
3. 最小公交时间(minTransitTime)

对于公交路线，系统会使用RaptorSearchWindowCalculator来精确计算搜索窗口，确保包含所有可能的公交连接。然而，问题出在OutsideSearchWindowFilter这个过滤组件上。

问题根源

OutsideSearchWindowFilter当前采用了一个过于简化的计算方式：

latestArrivalTime = earliestDepartureTime + searchWindow

这种计算方式没有考虑minTransitTime的影响，导致在以下场景会出现问题：

• 用户请求到达时间：11:00
• Flex直达路线：10:50出发，11:00到达
• 最小公交时间：1小时
• 搜索窗口：1小时

正确计算应为：

• RaptorSearchWindowCalculator会考虑minTransitTime，计算出earliestDepartureTime为9:00
• 但OutsideSearchWindowFilter错误地认为时间窗口是9:00-10:00
• 结果10:50-11:00的Flex直达路线被错误过滤

解决方案

经过开发团队讨论，确定以下解决方向：

1. 搜索窗口机制不应应用于街道直达搜索（包括Flex直达）
2. 直接路线可以时间平移，这与公交路线不同
3. OutsideSearchWindowFilter应仅应用于公交(Raptor)结果

技术实现上将修改过滤逻辑，确保：

• 直达Flex路线不受搜索窗口限制
• 仅公交路线应用严格的时间窗口过滤
• 保持系统整体性能不受影响

影响范围

该问题主要影响：

1. 使用Flex服务的多模式规划
2. 当存在明显更优的直达Flex路线时
3. 特别是当公交路线需要较长时间(minTransitTime较大)的情况

对于纯公交或纯Flex的场景不会出现此问题。

总结

这个问题揭示了OpenTripPlanner在多模式规划中时间窗口处理的一个边界情况。通过区分直达路线和公交路线的过滤逻辑，可以确保系统返回真正最优的路线组合。这也体现了交通规划系统中时间计算精确性的重要性，特别是当多种交通模式组合时。

开发团队正在准备相关修复，将通过精确控制不同模式的时间窗口处理逻辑来解决这个问题，确保用户始终获得最优的路线建议。