为什么图书角不会将贡献同步回 OpenStreetMap

听起来显然不错的功能 当我介绍 Book Corners 时，我解释说它的大部分初始数据都来自 OpenStreetMap。 OSM 为该项目提供了一个有用的起点，已经在世界各地绘制了数千个公共书柜的地图。图书角还直接接受用户提供的新图书馆。人们可以提交地点和照片，贡献在审核后就会公开。当 OSM 丢失其中一份提交材料时，图书角应该能够将其补回，这似乎是公平的。这个想法并不是要创建一个不受控制的后台同步过程。我想到的工作流程是故意谨慎的：提交库的人将明确允许贡献。管理员将首先审查该库。图书角将在 OSM 中搜索可能的重复项。管理员将预览正在发送的确切数据。在管理员确认之前什么都不会写。从软件开发的角度来看，这看起来像是一个可管理的集成：添加同意、跟踪贡献状态、构建预览、使用 OSM 进行身份验证，并通过其 API 创建新功能。代码并不是困难的部分。贡献数据不仅仅是 API 调用 一旦我开始正确研究实现，我发现写入 API 只是工作的一小部分。由于信息来自 Book Corners 数据库，OSM 可以将其视为外部数据导入。由于软件会准备并提交更改，因此它也可能属于脚本辅助或自动编辑的规则，即使管理员会审查每个单独的库。遵循 OSM 导入指南和自动编辑行为准则的保守解释将需要的不仅仅是专用帐户和 OAuth 令牌。在第一次制作贡献之前，我需要： 创建并维护一个专用的 OSM 导入帐户。在 OSM Wiki 上发布详细的导入计划。记录数据源、许可、字段映射、重复检测、软件、质量检查、变更集策略和回滚过程。在 OSM 社区论坛上提出提案。联系受捐款影响的相关当地社区。等待审核期并解决任何问题。在导入帐户、计划、讨论和变更集之间保持永久链接。保留联系方式并选择退出，以应对未来的问题或投诉。还有重要的许可问题。用户向 OSM 发送库的许可并不自动等同于拥有根据与 OSM 兼容的条款发布事实信息的足够明确的权利。面向用户的解释和同意需要涵盖这种区别，包括确认信息不是从不兼容的来源复制的。这些要求并不是一次性完成后就可以忘记的。他们围绕帐户、记录的流程、社区反馈、失败和潜在的恢复建立持续的责任。我理解为什么存在这些规则 OpenStreetMap 是一个共享的全局数据库。错误的导入可能会创建数千个重复项，覆盖更好的本地知识，或者引入一旦其他人编辑了相同对象就很难消除的错误。从这个角度来看，要求文档、许可清晰度、重复处理、负责任的运营商和社区讨论是合理的。 OSM 社区必须保护地图的质量，良好的意愿并不能保证良好的数据。图书角本身就受益于这种数据质量。期望 OSM 在没有保障措施的情况下接受来自外部服务的更改是虚伪的。同时，这个过程也有实际成本。它要求一个小项目不仅成为 API 客户端，而且成为记录导入程序的运营商。这可能适合导入大型数据集的组织，但对于小批量功能来说这是一个相当大的承诺，其唯一目的是将一些经过仔细审查的公共书柜贡献给公共资源。运营工作胜过价值 图书角的目的很简单：帮助人们发现小型免费图书馆并与他人分享新图书馆。运营 OSM 贡献渠道并不是该目的的核心。它将增加凭证、生产保障、审计和协调代码、社区流程、许可工作和长期支持义务。每个部分都是单独防御的，但它们一起使这个功能比我最初预期的要大得多。还有机会成本。花在操作此集成上的时间没有花在改进图书馆发现、审核、照片、可访问性、翻译或移动体验上。这些改进直接帮助图书角用户，并且对于小型项目来说更容易维持。我从回馈的感觉开始