Book Corners从OpenStreetMap获取初始数据，并允许用户提交新图书馆。尽管设计了谨慎的同步流程（需用户同意、管理员审核、查重、预览确认），但最终决定不将用户贡献同步回OpenStreetMap。

好的，以下是根据您的要求，对原文主要内容进行的中文重述，已保留关键细节并删减了与主题无关的内容：

标题：为什么 Book Corners 不会将用户贡献同步回 OpenStreetMap

Book Corners 项目最初从 OpenStreetMap（OSM）获取了大量公共书柜数据。同时，它也允许用户直接提交新的书柜位置和照片，经审核后公开。项目方曾认为，将这些用户贡献回馈给 OSM 是公平合理的，并设计了一套谨慎的工作流程：用户明确授权、管理员审核、查重、预览数据，最后才由管理员确认提交。从技术角度看，这似乎只是一个简单的 API 集成。

然而，深入研究后发现，向 OSM 写入数据远不止调用 API 那么简单。由于数据来自外部数据库，且提交过程有软件辅助，这很可能被 OSM 视为“数据导入”或“自动化编辑”，需要严格遵守其导入指南和自动化编辑行为准则。这意味着在首次提交前，项目方需要：创建并维护专用导入账号、在 OSM Wiki 上发布详细的导入计划、记录数据来源与许可、字段映射、查重方法、软件、质量检查、变更集策略和回滚流程；在社区论坛发起提案、联系受影响的本地社区、等待审核并解决所有问题；还要永久保留导入账号、计划、讨论和变更集之间的链接，并提供联系和退出机制。

此外，还存在许可问题：用户允许 Book Corners 使用其提交的数据，并不等同于项目方有权将这些事实信息以 OSM 兼容的许可协议发布出去。用户协议需要明确涵盖这一区别，并确认数据并非来自不兼容的来源。

这些要求并非一次性工作，而是持续的运营责任，包括账号维护、流程文档、社区反馈、错误处理和可能的回滚。

项目方理解这些规则存在的必要性。OSM 是一个共享的全球数据库，糟糕的导入可能造成大量重复、覆盖更好的本地知识或引入难以清除的错误。要求文档、许可澄清、重复处理、责任人和社区讨论是合理的。Book Corners 本身也受益于 OSM 的数据质量，因此不能期望 OSM 在没有保障的情况下接受外部服务的数据。

但另一方面，这套流程对小型项目来说成本高昂。它要求项目方不仅是一个 API 客户端，还要成为有文档的导入项目运营者。对于只打算贡献少量经过仔细审核的公共书柜的功能来说，这是一个巨大的承诺。

Book Corners 的核心目标是帮助人们发现和分享免费图书馆。运营 OSM 贡献管道并非其核心任务，会带来凭证管理、生产安全、审计、社区流程、许可工作和长期支持义务。这些投入的时间本可用于改进图书馆发现、审核、照片、无障碍、翻译或移动端体验，这些改进能直接惠及用户，也更易于小型项目维持。

项目方最初认为回馈数据是“正确且公平”的事，但经过调查后，认为仅凭善意不足以承担一项开放式的运营责任。

因此，项目方决定无限期暂停 OSM 回写功能的开发。Book Corners 将继续标注来自 OSM 的数据，但用户直接贡献的书柜将只保留在 Book Corners 内，不会自动或手动创建对应的 OSM 对象。目前没有任何数据从 Book Corners 写入 OSM 生产环境，因此暂停无需禁用或迁移现有集成。

如果未来出现真正轻量级的工作流程，或者 Book Corners 的贡献规模和价值足以证明该流程的合理性，项目方可能会重新考虑。另一种可能是开发一个用户驱动的工作流，在现有的 OSM 编辑器中打开一个建议功能，但这仍需与社区讨论，而非试图绕过规则。

目前，负责任的选择是不构建和运营一个没有信心妥善支持的功能。这次经历提醒我们，外部集成不仅涉及技术，还涉及组织和社会契约，有时这些契约的成本比代码更高。在部署前发现这一点是有益的，即使结果令人失望。项目方仍然相信向共享开放项目回馈数据是有价值的，也理解 OSM 为何如此谨慎地保护其数据库。但对于当前规模的 Book Corners 来说，收益与责任之间的平衡并不成立。因此，这是一个选择不发布的功能。

根据评论内容，总结如下：

主要观点与论据：

1. OSM数据质量门槛的必要性（支持方）

   • 评论1：OSM需要提交门槛以防止垃圾数据（"A project like OSM would be bombarded with spam and junk submissions if it didn’t have these barriers"）
   • 评论8：理解OSM指南是为了保证数据质量（"it makes sense that OSM has guidelines like this in place to ensure the data quality stays, well, quality"）

2. OSM限制的弊端（反对方）

   • 评论3：OSM"artificially limiting itself by not allowing streamlined paths to data contributions"
   • 评论4：建议OSM应能接收"signals"而非直接编辑

3. 替代方案与建议

   • 评论10：提出通过Notes API、MapRoulette挑战或GeoJSON导出等方式提交数据
   • 评论12：建议建立"单一事实源"（Single Point of Truth），如Bleau.info模式
   • 评论13（作者回应）：已提供OBDL许可的GeoJSON下载，但仍认为OSM提交流程过于复杂

4. 对数据共享的期待

   • 评论2：希望有通用方式共享地理空间数据（"I wish there was a generally accepted way to share geospatial data and POI data against OSM IDs"）
   • 评论5：质疑公开地图位置的必要性，认为社区级信息已足够

平衡性说明： 评论呈现明显分歧：一方认可OSM的质量控制，另一方认为其流程阻碍贡献。作者（评论13）在尊重OSM规则的同时，提供了替代数据获取方式。