OpenStreetMapのバージョニングを処理する方法は？

より一般的な意味での地理空間データの管理のトピックは、ここまでに出てきました。バージョン管理のトピックもそこで言及されましたが、実際には対処されていません。

データベースは組織内からのみ更新されるため、従来の地理空間データの収集と保守では、バージョン管理を内部で処理するだけで済みます。これは、OpenStreetMapなどのクラウドソースジオデータベースには当てはまりません。そこでは、誰でもやって来て、オブジェクトを追加、変更、または削除できます。OpenStreetMapでは、これは基本的な方法で処理されます。各オブジェクトには整数のバージョン番号があり、最新バージョンのオブジェクトのみがライブデータベースに公開されます。データベースは楽観的ロックを使用するため、ユーザーは投稿を手動でアップロードするときに発生するすべての競合を解決する必要があります。

編集者（JOSM、Potlatch）による人間の貢献が唯一の貢献モードである限り、これはすべて合理的に機能しますが、そうではありません。オープンな公共部門のデータのインポートがますます行われています。これらは、より複雑なバージョン管理の問題を引き起こします。次のシナリオを検討してください。

1. オープンな公共部門のデータセットから建物オブジェクトをインポートしています
2. 建物は、人間の貢献者（属性、ジオメトリ、またはその両方）によるいくつかの変更を受け取ります
3. 公共部門のデータの新しいバージョンが利用可能になり、インポートされます。

現在、ステップ3で、コミュニティの変更を受け取った各建物が新しいインポートと手動でマージされない限り、人間の貢献は失われます。

OpenStreetMapはこの状況にどのように対処できますか？ソフトウェア開発で分散バージョン管理を検討する必要がありますか？分散空間データのメンテナンスに対処するために、DVCのメソッドをどのように適合させることができますか？

GISデータの非破壊編集を実装する人を夢見ていました。計算は集中しますが、RDBMSに実装するのは難しくありません。

データのスナップショットから始めます。変更は編集として保存され、元のデータは変更されません。あなたの例では、建物は最初に公共部門のデータから取得されます。ユーザーが編集を行うと、変更または差異は別のテーブルに保存されます。誰かがその機能を表示すると、元の画像と適用された編集が表示されます。後続の編集は、新しいフィーチャシェイプとオリジナルと以前のすべての編集との間で計算された差です。

これにより、きめ細かいレベルで元に戻すことができます。それは本質的にバージョン管理が行うことです。非破壊編集の良い例は、AppleのApertureです。Apertureにインポートされたデジタル画像は直接変更されません。レベルの変更、鮮明化、ぼかしなどは編集として保存され、画像を操作するときにその場で適用されます。変更はすぐに削除できます。

もちろん、実稼働環境で配布および使用するためにDBのスナップショットを作成します。これは、開発および編集専用です。

見てみましょうバージョンのPostGIS、pgVersionとファクトポストアイデアと可能な解決策のために。これらは、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/Osmosis

Changsets：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で更新されます

これには、VCSが個別の属性の変更に簡単に対処できるように、データをオブジェクトごとに1つ、おそらくjsonのような形式に複数のファイルに分割する必要があります。

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

情報を10億個のファイルに分割することは、どのシステムにとっても多すぎることを知っています。代わりに、VCSのコアを使用し、OSMデータを処理して、バージョン管理可能な形式でVCSに供給する必要があります。（または、ファイルシステムをモックできます）。

これが機能することを保証することはできません。