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

Standard または Advanced ライセンスで利用可能。

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

• 編集ユーザーはそれぞれ、ワークフローに従って編集したトポロジーの検証を実施し、個々の編集バージョンでエラーを検出して修正します (または、それらを例外として設定します)。

• 通常、複数の編集バージョンは共通のバージョン (通常はデフォルトと呼ばれます) にマージされます。

• 各編集バージョンが検証され、エラーがない状態であっても、バージョンのリコンサイル時に (競合の発生により) 新たなトポロジー エラーが発生することがあります。

• このようなエラーに対処するために、バージョン対応のトポロジーには、リコンサイル プロセスを制御する特殊なエラー処理/競合検出ルールがあります。

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

注意:

ブランチ バージョニングの場合、たとえば次の例では、バージョン 1 がデフォルトで、バージョン 2 がデフォルトの子になります。

例 1

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

  

• デフォルト バージョンに存在し、子バージョンで検証されたダーティー エリアは、リコンサイルの結果、ダーティーになります。

  

• デフォルト バージョンで作成され、検証されたダーティー エリアは、子バージョンに存在するかどうかに関係なく、リコンサイル後も検証済みのままになります。

  

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

デフォルト バージョンで作成され検証されたダーティー エリアが、リコンサイル後も検証済みのままとなる状況を、さらに次の例 2 および例 3 にも示します。

例 2

例 3

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

注意:

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

例 4

例 5