ネットワーク データセットのダーティ エリアおよびバージョン対応

複数の担当者がネットワーク データセットのソース フィーチャを同時に編集できます。このトピックでは、バージョンをリコンサイルする際、ネットワーク データセットのダーティ エリアがどのように処理されるかについて説明します。

このトピックで紹介する各例のイラストは、子バージョンの作成以降に親バージョンと子バージョンが両方とも更新され、その後で、それらをリコンサイルする場合を表しています。親バージョンが編集されていない状態で子バージョンをリコンサイルした場合、子バージョンの内容がリコンサイル結果となります。どの例でも、バージョン 2 がバージョン 1 の子として作成されます。次に、説明されている方法で両方のバージョンを編集した後、バージョン 1 に対してバージョン 2 をリコンサイルします。各シナリオで使用する凡例は次のとおりです。

注意:

• ネットワーク データセットがバージョン対応登録されている場合は、スキーマを変更できません。スキーマを変更するには、ネットワーク データセットのバージョン対応登録を解除する必要があります（スキーマ変更には、ソースの追加と削除、接続性ルール、ポリシー、高度な設定の変更、属性または属性エバリュエータの追加、削除、変更、ルート案内の設定変更などが含まれます）。ただし、バージョン対応登録されていても、ネットワーク データセットを削除することは可能です。
• ジオデータベースのネットワーク データセットがバージョン対応登録されている場合、編集セッション内でのみ再構築できます。

ダーティ エリアのリコンサイル

• 親バージョンまたは子バージョンで、そのバージョンが作成される前に存在していなかったダーティ エリアは、リコンサイル後もダーティのままになります。
• 親バージョンに存在しており、子バージョンで構築されたダーティ エリアは、リコンサイル後にダーティになります。
• 親バージョンで作成および構築されたダーティ エリアは、子バージョンに存在するかどうかに関係なく、リコンサイル後も構築されます。
• 親バージョンと子バージョンがダーティであり、両方とも構築された場合、リコンサイル後も構築済状態になります。

親バージョンで作成されたダーティ エリアのリコンサイル

次の図が示すように、親バージョンでソース フィーチャを編集（ジオメトリの更新、属性の更新、フィーチャの挿入、またはフィーチャの削除）し、ネットワークを構築した場合は、リコンサイル後にネットワークを再構築する必要がありません。

子バージョンで作成されたダーティ エリアのリコンサイル

次の図が示すように、子バージョンでソース フィーチャを編集（ジオメトリの更新、属性の更新、フィーチャの挿入、またはフィーチャの削除）し、ネットワークを構築した場合は、リコンサイル後もダーティ エリアのままとなります。