实时轨道生成导致有效驾驶点在轨道之间未分配

观察到的行为

原始路线层中存在一条驾驶路线，但服务器生成的轨迹层中缺少连续的一段。只读数据库检查发现，33个连续的点已成功存储，但第二天它们仍然具有 track_id IS NULL。它们的 anomaly 值为 NULL，因此生成查询的 anomaly IS NOT TRUE 条件包含了它们。 选定的点大约每 54-55 秒记录一次。缺失区域内的连续距离为 581-1958 米。上传延迟并非原因：附件中最大的正向到达延迟为 4 秒。还观察到了小的负差值，因此这些是设备和服务器时钟的近似比较。 前一个轨迹在相对时间 +00:54 结束。下一个轨迹在 +34:49 开始，生成的轨迹边界之间的间隔为 33 分钟 55 秒。其前两个点之间的距离仅为 6 秒和 192 米。这两个点组成了一条轨迹，而前 33 个点仍未分配。 附件中包含 37 个点：轨道 A 的最后两个点、33 个未分配的点和轨道 B 的前两个点。其余的路程被省略。原始轨道 ID 已被替换为 A/B 别名。所有绝对时间戳都被同时移动到随机选择的时间段内；相对间隔和路线几何结构保持不变。 ## 预期行为 连续驾驶中的有效点不应永久地被排除在生成的轨迹中，仅仅因为正常的记录样本之间的移动距离超过距离阈值。如果这些点在实时处理过程中被意图分割，则后续的追赶过程应重新考虑现有轨迹之间的未分配点。 ## 想疑的机制，由数据库观察和源代码审查支持 1. Tracks::IncrementalGenerator 仅从最近六小时中选择未跟踪的点。轨道 A 的已分配端点因此无法作为下一个点的种子，即使该下一个点仅相距 104 米。 2. Track.segment_points_in_sql 在连续选定点之间的距离超过配置的阈值时开始新的区段。然后 HAVING count(*) >= 2 会丢弃每个单个区段。所有 33 个中间点都符合此模式。 3. 新轨道 …