バージョン対応フィーチャクラスのダーティ エリア

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

複数の編集ユーザがフィーチャ データセットとそのトポロジを同時に編集する可能性があります。

• 編集ユーザはそれぞれ、ワークフローに従って編集したトポロジの整合チェックを実施し、個々の編集バージョンでエラーを検出して修正します（または、それらを例外として設定します）。
• 通常、複数の編集バージョンは共通のマスタ バージョン（通称「デフォルト」）にマージされます。
• 各編集バージョンが整合チェックされ、エラーがない状態であっても、バージョンのリコンサイル時に（競合の発生により）新たなトポロジ エラーが発生することがあります。
• このようなエラーに対処するために、バージョン対応のトポロジには、リコンサイル プロセスを制御する特殊なエラー処理/競合検出ルールがあります。

次のセクションでは、ダーティ エリア、エラー、例外、および潜在的な競合（コンフリクト）に対するリコンサイルの結果について説明します。どのケースも、結果は、子バージョンが作成された後の、親バージョンと子バージョンの更新時のリコンサイルに基づいています。子バージョンがリコンサイルされる前に親バージョンが編集されていない場合は、子バージョンの内容がリコンサイルの結果となります。どの例でも、バージョン 2 がバージョン 1 の子として作成されます。次に、バージョン 1 とバージョン 2 が説明されている方法で編集され、バージョン 2 がバージョン 1 に対してリコンサイルされます。この後の例では、次の図を凡例として使用します。

例 1

• 親バージョンおよび子バージョンが作成される前に存在しなかった親バージョンまたは子バージョンのダーティ エリアは、リコンサイル後もダーティのままです。

  

• 親バージョンに存在し、子バージョンで整合チェックされたダーティ エリアは、リコンサイルの結果、ダーティになります。

  

• 親バージョンで作成され、整合チェックされたダーティ エリアは、子バージョンに存在するかどうかに関係なく、リコンサイル後も整合チェック済みのままになります。

  

このように、リコンサイル後も親の元の状態（ダーティ エリアなし）が維持されます。ただし、子バージョンへの更新の結果として、他のダーティ エリアが作成される場合があります。

親バージョンで作成され整合チェックされたダーティ エリアが、リコンサイル後も整合チェック済みのままとなる状況を、さらに次の例 2 および例 3 にも示します。

例 2

例 3

子バージョンのトポロジ フィーチャに対する編集内容は、編集によって生成されたダーティ エリアが子バージョンで整合チェックされていても、リコンサイル後にダーティ エリアになります。ダーティ エリアにならないような編集（属性の更新など）を行った場合も同じです。次の例で、これを具体的に示します。

注意:

次の例ではバージョン 1 とバージョン 2 の両方が編集されていますが、例の中のポリゴン シェープはバージョン 2 のみで変更されます。

例 4

例 5