StreetComplete中餐厅存在性检查与素食选项调查的同步问题分析

问题背景

在开源地图应用StreetComplete中，用户报告了一个关于餐厅调查逻辑的有趣现象：当用户刚刚完成一个餐厅"是否提供素食选项"的调查后，系统又立即询问"该餐厅是否仍然存在"。这种重复提问不仅降低了用户体验，也暴露了应用内部状态管理的一个潜在问题。

技术原理

StreetComplete采用了一套精密的调查机制来维护地图数据的时效性。该系统包含两个关键组件：

1. 特定属性检查：针对单个属性（如素食选项）设置独立的检查日期标记
2. 全局存在性检查：通过survey:date字段记录整个POI的最后调查时间

当用户完成某项调查时，系统会更新相应属性的检查日期。按照设计逻辑，如果某个POI刚刚被调查过（无论调查内容为何），其存在性应该被视为已验证，不应再触发存在性检查。

问题根源

经过技术分析，发现问题出在检查日期更新逻辑的条件判断上。当前代码仅在以下两种情况下会更新检查日期：

1. 当属性值确实发生了变化（previousValue != value）
2. 当该属性已有检查日期记录（hasCheckDateForKey(key)）

这种设计导致了一个漏洞：对于首次设置的属性（如新添加的素食选项），由于既没有值变化也没有历史检查记录，系统不会更新全局检查日期。因此，即使刚刚完成调查，存在性检查仍可能被触发。

解决方案

修复方案应考虑以下技术要点：

1. 扩展条件判断：除了值变化和已有检查记录外，还应考虑POI的整体"可调查状态"
2. 时间戳同步：任何形式的调查活动都应视为对POI存在性的确认
3. 数据完整性：保持与开源地图数据模型的兼容性

最直接的解决方案是修改检查日期更新逻辑，使其在以下情况下触发：

• 属性值发生变化
• 该属性已有检查记录
• POI的存在性检查时间已过期

这种改进既能保持数据准确性，又能避免冗余提问，提升用户体验。

实现影响

该修复将带来以下改进：

1. 用户体验提升：消除不必要的重复提问
2. 数据质量保证：确保调查时间戳的准确性
3. 系统效率优化：减少冗余调查任务

值得注意的是，这种修改不会影响数据贡献的质量，反而会使时间戳记录更加精确，有利于整个开源地图生态系统。

总结

StreetComplete作为一款众包地图应用，其调查逻辑的精细程度直接影响用户体验和数据质量。通过对检查日期同步机制的优化，可以更智能地管理调查流程，避免冗余操作。这一改进展示了开源项目中如何通过用户反馈不断完善核心逻辑，也体现了良好的软件设计如何平衡功能完整性与用户体验。