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