バージョンの競合とトポロジ フィーチャ

このトピックは、ArcEditor および ArcInfo にのみ適用されます。

トポロジに属するフィーチャには、バージョンのリコンサイルによって発生する競合に関して、特殊なロジックはありません。2 つの異なるバージョンで同じフィーチャを編集し、これらのバージョンをリコンサイルすると、それらは競合状態になります。

トポロジの整合チェックの結果として発生する競合の最大の原因は、整合チェックのクラスタ処理の過程でフィーチャが統合されることによる、新しい頂点の追加です。

次に、整合チェック プロセスによって競合がどのように発生するのかを示す例を紹介します。

例 1：各バージョンでの 2 つの隣接ポリゴンの分割

親バージョンのトポロジでエッジを共有するポリゴンは、子バージョンによって継承されます。この場合、親バージョンで 1 つのポリゴンが分割され、これに隣接するポリゴンが子バージョンで分割され、ダーティ エリアが整合チェックされます。ポリゴンを分割すると、元のフィーチャが削除され、2 つの新しいフィーチャに置き換えられます。バージョンをリコンサイルすると、元のポリゴンは両方とも更新と削除による競合として報告されます。つまり、親バージョンで削除されたフィーチャは、子バージョンの整合チェック時にクラスタ処理によって更新されており、子バージョンで削除されたフィーチャは、親バージョンのクラスタ処理によって更新されています。

例 2：大きな公道用地ポリゴンとエッジを共有するポリゴンの分割

この図は、整合チェック プロセスによって追加された頂点のせいで、土地台帳データベースに競合が発生する様子を示しています。この場合、分割された土地区画ポリゴンは、非常に大きな公道用地ポリゴンとエッジを共有しています。

ここで示したような競合は、編集ユーザが異なるエリアを操作するようにワークフローを調整し、ジオデータベース レプリケーションを使用してユーザが編集できる場所とできない場所を制御すれば、回避することができます。さらに、公道用地ポリゴンを小さく分割するようなデータ モデルを設計すると、例 2 で示したような競合を減らすのに役立ちます。