Standard または Advancedのライセンスで利用可能。
複数の編集ユーザーがフィーチャ データセットとそのトポロジを同時に編集する可能性があります。
- 編集ユーザーはそれぞれ、ワークフローに従って編集したトポロジの整合チェックを実施し、個々の編集バージョンでエラーを検出して修正します (または、それらを例外として設定します)。
- 通常、複数の編集バージョンは共通のバージョン (通常はデフォルトと呼ばれます) にマージされます。
- 各編集バージョンが整合チェックされ、エラーがない状態であっても、バージョンのリコンサイル時に (競合の発生により) 新たなトポロジ エラーが発生することがあります。
- このようなエラーに対処するために、バージョン対応のトポロジには、リコンサイル プロセスを制御する特殊なエラー処理/競合検出ルールがあります。
次のセクションでは、ダーティ エリア、エラー、例外、および潜在的な競合 (コンフリクト) に対するリコンサイルの結果について説明します。 どのケースも、結果は、子バージョンが作成された後の、親 (デフォルト) バージョンと子バージョンの更新時のリコンサイルに基づいています。 子バージョンがリコンサイルされる前に親 (デフォルト) バージョンが編集されていない場合は、子バージョンの内容がリコンサイルの結果となります。 どの例でも、バージョン 2 がバージョン 1 (デフォルト) の子として作成されます。 次に、説明されている方法で両方のバージョンを編集した後、バージョン 1 (デフォルト) に対してバージョン 2 をリコンサイルします。 この後の例では、次の図を凡例として使用します。
注意:
ブランチ バージョニングの場合、たとえば次の例では、バージョン 1 がデフォルトで、バージョン 2 がデフォルトの子になります。例 1
- 親 (デフォルト) バージョンおよび子バージョンが作成される前に存在しなかった親 (デフォルト) バージョンまたは子バージョンのダーティ エリアは、リコンサイル後もダーティのままです。
- 親 (デフォルト) バージョンに存在し、子バージョンで整合チェックされたダーティ エリアは、リコンサイルの結果、ダーティになります。
- 親 (デフォルト) バージョンで作成され、整合チェックされたダーティ エリアは、子バージョンに存在するかどうかに関係なく、リコンサイル後も整合チェック済みのままになります。
このように、リコンサイル後も親 (デフォルト) の元の状態 (ダーティ エリアなし) が維持されます。 ただし、子バージョンへの更新の結果として、他のダーティ エリアが作成される場合があります。
親 (デフォルト) バージョンで作成され整合チェックされたダーティ エリアが、リコンサイル後も整合チェック済みのままとなる状況を、さらに次の例 2 および例 3 にも示します。
例 2
例 3
子バージョンのトポロジ フィーチャに対する編集内容は、編集によって生成されたダーティ エリアが子バージョンで整合チェックされていても、リコンサイル後にダーティ エリアになります。 ダーティ エリアにならないような編集 (属性の更新など) を行った場合も同じです。 下の例はこれを図で示したものです。
注意:
次の例ではバージョン 1 とバージョン 2 の両方が編集されていますが、例の中のポリゴン シェープはバージョン 2 のみで変更されます。
例 4
例 5
