如何处理OpenStreetMap中的版本控制？

在此之前，已经提出了从更一般的意义上管理地理空间数据的主题。在那里也提到了版本控制的主题，但并未真正涉及。

传统的地理空间数据收集和维护只需要在内部处理版本控制，因为数据库只能从组织内部进行更新。在众包的地理数据库（例如OpenStreetMap）中，情况并非如此。在那里，任何人都可以出现并添加，修改或删除对象。在OpenStreetMap中，这是基本的处理方式：每个对象都有一个整数版本号，并且只有最高版本的对象才在实时数据库中公开。数据库使用开放式锁定，因此用户必须解决手动上传文稿时发生的所有冲突。

只要通过编辑人员（JOSM，Potlatch）进行的人工贡献是唯一的贡献方式，那么所有这些都可以很好地工作，但不是。越来越多地进行公开公共部门数据的导入。这些使版本控制问题更加复杂。请考虑以下情形：

1. 正在从开放的公共部门数据集中导入建筑对象
2. 该建筑物由人工贡献者进行了一些修改（属性，几何或两者）
3. 一个新版本的公共部门数据可用并被导入。

当前，在第3步中，除非将接受社区修改的每个建筑物手动与新的导入项合并，否则人类的贡献将会丢失。

OpenStreetMap如何处理这种情况？我们需要在软件开发中研究分布式版本控制吗？DVC的方法如何适应于分布式空间数据维护？

我梦见有人对GIS数据实施无损编辑。它是计算密集型的，但在RDBMS中实现起来并不难。

从数据快照开始。任何更改均保存为编辑，原始数据保持不变。在您的示例中，建筑物最初来自公共部门数据。当用户进行编辑时，更改或差异将保存在单独的表中。当某人查看功能时，将获得原始功能以及应用的所有编辑。后续编辑是新要素形状与原始特征以及所有先前编辑之间的计算差值。

这使您能够进行细粒度的撤消。本质上，这是版本控制的作用。苹果的Aperture是无损编辑的一个很好的例子。Aperture中导入的数字图像不会直接修改。处理图像时，级别的变化，锐化，模糊等将作为编辑存储并即时应用。任何更改都可以立即删除。

当然，您将为数据库制作快照以在生产环境中分发和使用。这仅用于开发和编辑。

看一下VersionGIS PostGIS，pgVersion和Post Facto的想法和可能的解决方案。这些是在PostgreSQL数据库中实现的版本控制系统。

OSM使用Postgres和Postgis来保留数据库快照。

在自己的服务器和数据库上实现

http://wiki.openstreetmap.org/wiki/Databases#Choice_of_DBMS

数据库（plantet.osm）每周更新一次 http://wiki.openstreetmap.org/wiki/Planet_dump

渗透是用来“它具有从数据库和文件读取的组件，向数据库和文件写入的组件，用于将变更集导出和应用到数据源的组件”

http://wiki.openstreetmap.org/wiki/渗透

变更集：http ://wiki.openstreetmap.org/wiki/Osmosis/Detailed_Usage#Changeset_Derivation_and_Merging

我虽然对这个问题有一个想法，但并未对其进行测试。它可能起作用：

使用版本控制系统，例如Mercurial或Git。Mercurial将更容易，因为它可以轻松创建匿名分支。

现在，从初始修订版开始，为公共数据集导入创建一个分支。因此，将有2个分支：

1. 主线（OSM）
2. 公开数据集X

从公共数据集的导入应在分支2中完成，然后合并到OSM分支中。

您的方案可能是这样的：

• 对象不存在
• 然后将其导入并合并到分支1中
• 然后在主线中进行修改，包括几何图形
• 它再次在分支2中导入
• 当它合并到分支1中时，只有在分支2中更新的数据才在分支1中更新

这可能需要将数据拆分为多个文件（每个对象一个），并可能拆分为json之类的格式，以便VCS可以轻松处理对单独属性的更改。

{
     id: 1357
     lat: 1,
     lon: 2,
     tags: {
          'building': 'entrance'
     }
     type: 'node',
}
{
     nodes: [
         1357,
         2468
     ],
     tags: {
         building: 'yes',
     }
     type: 'way',
}

我知道，将信息分割成十亿个文件对于任何系统来说都是太多了。相反，应使用VCS的核心，并应以可版本化的形式处理OSM数据并将其馈入VCS。（或者可以模拟文件系统）。

我不能保证这会起作用。