StreetComplete中店铺营业时间与存在性检查的协同机制分析

问题背景

在StreetComplete应用中，用户报告了一个看似矛盾的现象：当为店铺添加营业时间信息后，系统会立即询问"该店铺是否仍然存在"。从用户直觉来看，既然能够更新营业时间，店铺显然应该仍然存在，因此这个后续询问显得多余。

技术原理剖析

经过深入分析，发现这种现象源于StreetComplete中两个独立检查机制的运作方式：

1. 营业时间检查机制：

   • 触发条件：检查店铺最后修改日期或check_date:opening_hours标签（取较早者）
   • 完成操作后：会设置check_date:opening_hours为当天日期

2. 存在性检查机制：

   • 触发条件：检查店铺最后修改日期或check_date/survey:date等变体标签（取较早者）
   • 确认存在后：会设置check_date为当天日期

问题根源

问题的本质在于这两个检查机制使用不同的标签进行判断：

• 营业时间检查优先级别更高，因此会先被触发
• 完成营业时间检查后，只更新了check_date:opening_hours标签
• 存在性检查并不关注check_date:opening_hours，而是查看check_date或最后修改日期
• 如果之前存在survey:date等标签，且日期较早，存在性检查仍会被触发

解决方案探讨

技术团队提出了以下改进思路：

1. 标签联动更新机制：

   • 当任何check_date:*标签被设置为当天日期时，同时更新通用的check_date标签
   • 优点：逻辑上合理，因为更新任何专项检查日期都意味着确认了元素存在
   • 注意事项：需要考虑特殊情况，如建筑多边形上的店铺标签

2. 优先级调整：

   • 调整存在性检查的优先级，使其在营业时间检查之前
   • 优点：更符合用户操作逻辑
   • 缺点：可能影响其他场景下的用户体验

3. 缓存同步机制：

   • 确保元素修改后的时间戳能及时更新到任务缓存中
   • 优点：解决潜在的数据同步问题
   • 缺点：实现复杂度较高

技术实现建议

基于现有分析，最合理的解决方案是第一种方案——实现标签联动更新。这种方案：

1. 保持了现有检查机制的独立性
2. 符合数据逻辑（专项检查隐含了存在性确认）
3. 实现难度相对较低
4. 对用户体验改善明显

实施时需要注意处理特殊情况，如建筑多边形上的店铺标签等边界情况，确保不会因为联动更新导致错误的数据推断。

总结

StreetComplete中不同检查机制间的独立性虽然保证了功能的模块化，但也可能带来用户体验上的小问题。通过合理的标签联动机制，可以在保持系统架构清晰的同时，提升用户操作的流畅性。这一改进不仅适用于店铺场景，也可推广到其他类似的存在性检查与专项检查并存的场景中。