Standard または Advancedのライセンスで利用可能。
トポロジに属するフィーチャには、バージョンのリコンサイルによって発生する競合に関して、特殊なロジックはありません。2 つの異なるバージョンで同じフィーチャを編集し、これらのバージョンをリコンサイルすると、それらは競合状態になります。
トポロジの整合チェックの結果として発生する競合の最大の原因は、整合チェックのクラスター処理の過程でフィーチャが統合されることによる、新しい頂点の追加です。
次に、整合チェック プロセスによって競合がどのように発生するのかを示す例を紹介します。
メモ:
ブランチ バージョニングの場合、たとえば次の例では、バージョン 1 がデフォルトで、バージョン 2 がデフォルトの子になります。例 1: 各バージョンでの 2 つの隣接ポリゴンの分割
親 (デフォルト) バージョンのトポロジでエッジを共有するポリゴンは、子バージョンによって継承されます。この場合、親 (デフォルト) バージョンで 1 つのポリゴンが分割され、これに隣接するポリゴンが子バージョンで分割され、ダーティ エリアが整合チェックされます。ポリゴンを分割すると、元のフィーチャが削除され、2 つの新しいポリゴン フィーチャに置き換えられます。バージョンをリコンサイルすると、元のポリゴンは両方とも更新と削除による競合として報告されます。つまり、親 (デフォルト) バージョンで削除されたフィーチャは、子バージョンの整合チェック時にクラスター処理によって更新されており、子バージョンで削除されたフィーチャは、親 (デフォルト) バージョンのクラスター処理によって更新されています。
例 2: 大きな公道用地ポリゴンとエッジを共有するポリゴンの分割
この図は、整合チェック プロセスによって追加された頂点のせいで、土地台帳データベースに競合が発生する様子を示しています。この場合、分割された土地区画ポリゴンは、非常に大きな公道用地ポリゴンとエッジを共有しています。
ここで示したような競合は、編集ユーザーが異なるエリアを操作するようにワークフローを調整し、ジオデータベース レプリケーションを使用してユーザーが編集できる場所とできない場所を制御すれば、回避することができます。さらに、公道用地ポリゴンを小さく分割するようなデータ モデルを設計すると、例 2 で示したような競合を減らすのに役立ちます。