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

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

ArcSDE ジオデータベース内のネットワーク データセットの作業を始める前に覚えておくべき主な点として、次のようなものがあります。

• ネットワーク データセットのソース フィーチャは、編集を行う前にバージョン対応登録する必要があります。

  レガシー:

  ArcGIS 10 よりも前は、ネットワーク データセットをバージョン対応にすることはできませんでした。これは、ソース フィーチャクラスを単なるフィーチャクラスとして編集できたことを意味します。つまり、ソース フィーチャクラスをバージョン対応登録し、編集を元に戻したりやり直したりする機能付きで編集することも、バージョン非対応データのまま、編集を元に戻したりやり直したりする機能なしで編集することもできました。

  しかし、ArcGIS 10 のリリースにより、バージョン対応登録しなければ、ソース フィーチャを編集することはできなくなりました。

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

• バージョン対応登録されているかいないかにかかわらず、ネットワーク データセットを削除することは可能です。

完全を期すため、このトピックの概念図では、任意の編集と構築のリコンサイルとポストを行うための、親バージョンと子バージョンの作成から始まるプロセス全体を示しています。ただし、常に親バージョンの作成から始まるとは限らないため、既存の子バージョンとその親バージョンが同じ状態を共有したときに子バージョンが作成される手順を考えることができます。

図では構築済みのネットワーク データセットを親バージョンにポストする方法を示していますが、ダーティ エリアのあるネットワークのポストも完全に有効です。ただし、この場合はおそらく、最後にネットワーク データセットを構築するために、親バージョンの編集権限が必要になります。

各図で使用する凡例は次のとおりです。

ソース フィーチャの編集を行わないリコンサイルとポスト

このセクションでは、ネットワーク データセットの編集、構築、リコンサイル、ポストを伴うさまざまなバージョニングのシナリオで、ダーティ エリアがどのように作用するかを説明します。各シナリオでは、プロセスからソース フィーチャの編集を除外しています（編集は次のセクションで説明します）。このセクションの目的は、ダーティ エリアのないネットワーク データセットが構築されるのはどのワークフローであるかについて基本的に理解することです。

シナリオ 1:親バージョンで作成され、構築されるダーティ エリア

子バージョンが親バージョンからダーティ エリアを継承したと仮定します。続いて、親バージョンでネットワーク データセットが構築されます。最後に、子バージョンでリコンサイル操作が実行されます。ダーティ エリアは子バージョンで削除されます（他の編集は行われていないと仮定します）。

シナリオ 2:親バージョンで作成され、子バージョンで構築されるダーティ エリア

このシナリオは、子バージョンが親バージョンからダーティ エリアを継承する点では上のシナリオと同じです。ただし、続いてネットワークが親バージョンではなく、子バージョンで構築されます。構築操作の後でリコンサイルすることにより、ダーティ エリアが親バージョンから再び作成されます。構築されたネットワークを親バージョンにポストするには、ポストする前に子バージョンを再構築する必要があります。

シナリオ 3:親バージョンで作成され、親バージョンと子バージョンの両方で構築されるダーティ エリア

このシナリオは、上の 2 つのシナリオを組み合わせたものです。子バージョンは、親バージョンからダーティ エリアを再び継承します。リコンサイルの前に、子バージョンと親バージョンは別々に構築されます。リコンサイル プロセスによって、子バージョンはクリーンな状態に保たれます。

ソース フィーチャの編集を行うリコンサイルとポスト

上の各シナリオでは、ソース フィーチャを編集せずにネットワーク データセットを構築する処理に注目しました。次のシナリオでは、ソース フィーチャの編集が行われ、結果として発生したダーティ エリアが削除されます。

シナリオ 4: 親バージョンと子バージョンで異なるソース フィーチャの編集

このシナリオでは、子バージョンの作成前にネットワークが構築されます。子バージョンの作成後、道路のソース フィーチャクラスが編集され、マップの南側に道路が追加されます。その間に親バージョンが編集され、北側に道路が追加されます。これにより、これら 2 つのバージョンにはマップの相対する側にダーティ エリアができます。リコンサイル プロセスにより、編集内容と関連するダーティ エリアが子バージョンに移されます。ここでネットワークが構築されるため、ネットワークはダーティ エリアがない状態で親バージョンにポストできます。

詳細:

上の図のネットワーク データセットは、リコンサイルの直前には親バージョンでも子バージョンでも構築されていません。しかし、この時点で両バージョンで構築されていた場合は、次の図のように、リコンサイルによってマップの南側にダーティ エリアが再び作成されます。これは、リコンサイル プロセスによって親バージョンの状態が子バージョン内で可視化され、マージ プロセスが発生するためです。子バージョンの編集は、親バージョンにとって新しいものになるため、これらの編集の接続性を、リコンサイルした親データで再構築する必要があります。

シナリオ 5: 親バージョンと子バージョンで交差する新しいソース フィーチャ

このシナリオでは、子および親のソース フィーチャを編集した後でネットワーク データセットを再構築する必要がある別の理由を説明します。ここでは、親バージョンと子バージョンで行われた変更が交差しています。ネットワークのそれぞれのバージョンがクリーンであっても、リコンサイルによってダーティ エリアが作成されます。これは、交差するフィーチャの接続性を決定する必要があるからです。