StreetComplete品牌地点名称处理机制的技术解析

在StreetComplete应用中，关于品牌地点名称处理机制存在一个值得探讨的技术问题。当用户为连锁品牌（如德国超市EDEKA）添加地点时，应用目前无法保留或设置个性化的地点名称，这影响了数据标注的灵活性。

问题的核心在于应用对品牌预设的处理方式。当用户选择EDEKA作为品牌时，应用会自动填充品牌名称（brand=EDEKA）和对应的Wikidata标识（brand:wikidata=Q701755），但同时会强制覆盖原有的name标签，将其设置为"EDEKA"。这种行为在连锁店具有个性化名称（如"EDEKA Schreiber"）时会造成数据丢失。

深入分析发现，问题的根源在于StreetComplete使用的数据源nsi-id-presets.json缺少关键信息。相比之下，iD编辑器使用的nsi.json文件包含了preserveTags字段，能够指示哪些标签应该保留不被覆盖。例如，EDEKA的配置中包含"preserveTags": ["^name"]，这正是iD能够正确处理个性化名称的原因。

技术解决方案需要分两步实施：首先需要推动Name Suggestion Index项目在nsi-id-presets.json中包含preserveTags信息；其次需要在osmfeatures库中添加对这些信息的解析支持。当检测到preserveTags包含"^name"时，应用应显示名称输入字段，允许用户修改预设名称。

这个问题也揭示了更深层的技术架构考虑。目前StreetComplete和Go Map!!使用的是简化版的nsi-id-presets.json，而更完整的nsi.json可能更适合作为数据源。迁移到更完整的数据格式将带来更好的功能支持，但同时也需要考虑兼容性和迁移成本。

对于开发者而言，这个案例展示了开源地理数据应用中品牌标注处理的复杂性。合理的解决方案需要平衡数据一致性（保持品牌统一标识）和灵活性（允许地点个性化）。branch标签的使用也是值得考虑的技术方案之一，它可以明确区分连锁品牌的总部和分部关系。