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

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

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

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

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

例に対する凡例

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

例 1

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

    デフォルト バージョンおよび子バージョンのダーティ エリアはリコンサイル後もダーティのままです。

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

    子バージョンで整合チェックされたデフォルト バージョンのダーティ エリアは、リコンサイル後もダーティのままです。

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

    デフォルト バージョンで作成され、整合チェックされたダーティ エリアは、リコンサイル後も整合チェック済みのままになります。

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

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

例 2

リコンサイル後に整合チェックされたダーティ エリア。

例 3

リコンサイル後に整合チェックされたダーティ エリア。

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

注意:

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

例 4

リコンサイル後に生成されたダーティ エリア。

例 5

リコンサイル後に生成されたダーティ エリア。


このトピックの内容
  1. 例 1
  2. 例 2
  3. 例 3
  4. 例 4
  5. 例 5