Standard または Advancedのライセンスで利用可能。
ArcGIS は、編集中のバージョンをターゲット バージョンにリコンサイルする際に競合を検出します。競合は次のような場合に発生します。
- 編集中のバージョン (編集バージョン) とターゲット バージョンの両方で同じフィーチャが更新された場合
- あるバージョンで更新されたフィーチャが、別のバージョンで削除された場合
- トポロジ的に関連するフィーチャまたはリレーションシップ クラスが編集バージョンとターゲット バージョンの両方で変更された場合
競合が存在する場合、ArcGIS はまず、編集バージョンまたはターゲット バージョンの状態のどちらかを優先して、競合を解決します。どちらを優先するかは、ユーザーの設定によります。競合が解決された後、競合の解決結果を 1 つずつ確認し、必要に応じて変更を加えることができます。たとえば、競合が編集バージョンを優先して解決された場合には、ターゲット バージョンを優先した解決に置き換えることを選択するか、あるいは編集ツールを使用して別の方法で解決された状態を変更することができます。
対話形式での競合の解決
リコンサイルによって競合が検出された場合は、[競合] ダイアログ ボックスを使用して、それらを対話形式で確認することができます。このダイアログ ボックスには、競合しているすべてのクラスとそれらのフィーチャまたは行が表示されます。このダイアログ ボックスでは、次の操作が可能です。
- 競合しているフィールドまたは行の特定
- 競合の表示
- フィーチャまたは属性を置換するために使用するバージョンの状態を指定することによる競合の解決
競合しているフィールドまたは行の特定
競合しているフィーチャクラスとフィーチャはすべて、[競合] ダイアログ ボックスの左上のリスト ボックスに表示されます。この [競合] リストは、確認済みの競合の合計数と、すべてのフィーチャクラスの競合の合計数を示します。初期状態では、これらの数は同じです。次の例では、合計で 2 つのオブジェクトが競合しており、どちらも未確認のままです。
Conflicts (2/2)
[競合] の下に、競合が含まれているフィーチャクラスと、各フィーチャクラスの競合の数とそれに対する確認済みまたは置換済みの競合の数が表示されます。次の例では、2 つのフィーチャクラスにそれぞれ競合が 1 つ含まれています。
Conflicts (2/2) sde.RJP.ponds (1/1) sde.RJP.lakes (1/1)
各フィーチャクラスに続いて、競合しているフィーチャの ObjectID が表示されます。次の例では、ponds フィーチャクラスの ObjectID 30 と、lakes フィーチャクラスの ObjectID 11 にそれぞれ競合が 1 つ存在します。
Conflicts (2/2) sde.RJP.ponds (1/1) 30 sde.RJP.lakes (1/1) 11
競合の合計数に対する確認済みの競合の割合が 2/2、各フィーチャクラスでは 1/1 のままであることから、オブジェクトが確認または置換されていないことがわかります。また、すべての ObjectID とフィーチャクラスが太字で示されていることでも、競合が確認または置換されていないことがわかります。
オブジェクトに確認済みのマークを付けるか (この後の「確認済みまたは未確認のマーク」をご参照ください)、オブジェクトを置換すると (この後の「競合の解決」をご参照ください)、括弧内の 1 つ目の数字が減り、確認済みのオブジェクトの ObjectID が太字で表示されなくなります。フィーチャクラスのすべての ObjectID に確認済みまたは置換済みのマークが付くと、そのフィーチャクラス名が太字で表示されなくなります。ponds フィーチャクラスと lakes フィーチャクラスの例では、ObjectID 30 に確認済みのマークを付けると、[競合] ダイアログ ボックスのリスト ボックスに次の情報が表示されます。
Conflicts (1/2)
sde.RJP.ponds (0/1)
30
sde.RJP.lakes (1/1) 11 2 つ目の ponds フィーチャ (ObjectID 5) に競合が存在する場合、リストは次のようになります。
Conflicts (2/3) sde.RJP.ponds (1/2) 5
30
sde.RJP.lakes (1/1) 11 上記のリストは、リコンサイル操作の結果として合計で 3 つの競合が検出され、そのうちの 1 つが確認済みまたは置換済みであることを示しています。また、確認済みまたは置換済みの競合フィーチャの ObjectID が 30 で、このフィーチャが ponds フィーチャクラスに含まれていることも示しています。
リストの個々のフィーチャを選択すると、[競合] ダイアログ ボックスの右のリストに、フィーチャのリコンサイル前バージョン、競合バージョン、共通の上位バージョンの列と属性が表示されます。
- リコンサイル前バージョンは、現在のセッションの編集バージョンにおけるフィーチャと属性の状態を表します。
- 競合バージョンは、他の編集セッションまたはバージョンで実行された編集によるフィーチャとその属性の状態を表します。
- 共通の上位バージョンは、データベース内のフィーチャとその属性の状態を表します。この場合、フィーチャとその属性は編集される前の状態です (編集を保存してからリコンサイルを行った場合は、編集後の状態となります)。
フィールド名の左に表示される赤い点は、競合を識別します。たとえば、フィーチャのジオメトリが各バージョンで編集された場合、Shape フィールドの横に赤い点が表示されます。
![[競合] ダイアログ ボックスの使用](GUID-25665FA9-57AD-460A-8F3A-46CC83566AE5-web.png "[競合] ダイアログ ボックスの使用")
他の属性フィールドが競合している場合は、それらの横に赤い点が表示されます。いずれかのバージョンでフィーチャが削除されている場合は、そのバージョンの属性値に「<削除>」が表示されます。
フィーチャが子バージョンに挿入され、競合が発生すると、ターゲット バージョンおよび共通の上位バージョンに「<存在しませんでした>」が表示されます。
ダイアログの下部にある 2 つのボタンでは、すべてのフィールドを表示するか、競合しているフィールドだけを表示するかを切り替えることができます。
競合しているフィーチャのバージョンまたは編集セッションにおける属性と値を表示すると、属性値がどのように異なっているかを確認することができ、保存する値を選択するのに役立ちます。
競合の表示
ダイアログ ボックスの [競合を表示 >>] ボタンをクリックすると、競合している 2 つのフィーチャの形状の状態 (リコンサイル前バージョンと競合バージョン) がダイアログ ボックスの下部に表示されます。
![[<< 競合を表示] ウィンドウの使用](GUID-7C700F52-C9F1-4117-A3F6-A3F1CA87FE3A-web.png "[<< 競合を表示] ウィンドウの使用")
各ジオメトリ表示ウィンドウの下にあるドロップダウン リストを使用して、競合しているフィーチャの 3 種類の状態 (リコンサイル前バージョン、競合バージョン、共通の上位バージョン) を切り替えることができます。これらの表示が異なるのは、競合がフィーチャのジオメトリで発生している場合だけです。
これらの表示の下には、表示にナビゲートして個別属性を表示するためのツールを含むツールバーがあります。
マップ上で競合しているフィーチャの特定のバージョンにズームするには、そのフィーチャをリストで右クリックし、[リコンサイル前バージョンにズーム]、[競合バージョンにズーム]、または [共通の上位バージョンにズーム] をクリックします。
ジオメトリが競合している場合、マップ上に別のジオメトリの状態を表示するには、リスト ボックスで Shape フィールドを右クリックし、[表示設定...] をクリックします。
これにより、[競合表示設定] ダイアログ ボックスが表示されます。マップ上に描画したいジオメトリの状態をオンにします。
[OK] をクリックすると、マップ上で次のように動作します。
- 競合 (ターゲット) バージョンの状態が赤色で表示されます。
- リコンサイル前バージョンの状態が緑色で表示されます。
- 共通の上位バージョンの状態が青色で表示されます。
[競合表示設定] ダイアログ ボックスで上記のようにオプションを選択した場合、マップ上の表示は次のようになります。
[競合表示設定] ダイアログ ボックスで [現在のバージョンを表示] のみをチェックした場合、マップ上の表示は次のようになります。
競合を確認した後は、それらに確認済みのマークを付けるか、置換オプションを選択して競合を解決することができます。
確認済みまたは未確認のマーク
「競合しているフィールドまたは行の特定」で説明したように、フィーチャに確認済みのマークを付けることができます。これは、競合を確認済みであり、この時点では置換オプションを選択しないことを示します。確認済みのマークが付いたフィーチャは太字で表示されなくなるため、リストで簡単に見分けることができます。
フィーチャの競合を未確認状態に戻したい場合は、[競合] リストの ObjectID を右クリックして、[未確認マーク] をクリックします。これにより、フィーチャが再び太字で表示されます。
競合の解決
競合を解決する際に、維持するフィーチャと属性の状態を決定します。優先してリコンサイルするバージョンとしてターゲット バージョンと自分の編集バージョンのどちらを選択したかにかかわらず、リコンサイル前バージョンの状態 (リコンサイルする前のバージョンでの表示)、競合バージョンの状態 (別の編集ユーザーが行った変更を反映した表示)、共通の上位バージョンの状態 (ターゲット バージョンでのフィーチャまたは属性の状態) の中から、維持する状態を指定することができます。
競合の解決に使用できる置換オプションは 5 つあります。
- 属性の置換
この競合解決は、フィールド レベルで適用されます。属性に競合がある場合は、現在のバージョンの属性値のみを、リコンサイル前バージョン、競合バージョン、または共通の上位バージョンの状態のいずれかの属性値で置換できます。これを行うには、競合のある属性を右クリックし、メニューからこのオプションをクリックします。
- フィーチャの置換
この競合解決は、行レベルで適用されます。フィーチャ全体を、リコンサイル前バージョン、競合バージョン、または共通の上位バージョンのフィーチャの状態で置換できます。つまり、競合しているすべてのフィールドが置換されます。
- クラス レベルの置換
フィーチャクラス全体の現在の状態を、リコンサイル前バージョン、競合バージョン、または共通の上位バージョンのいずれかの状態で置換し、競合を解決できます。この方法では、競合しているすべてのフィーチャと属性が一度に置換されるため、競合するフィーチャをすばやく更新して置換することができます。[競合] リストに複数のフィーチャが存在する場合は、これらのすべてが選択したバージョンで置換されます。
クラス レベルの置換オプションを選択するには、[競合] リストでフィーチャクラスの名前を右クリックし、使用するバージョンをクリックします。
- 完全な置換
これはルートレベルの置換です。この置換オプションを使用すると、リスト内の競合しているすべてのフィーチャとフィーチャクラスが指定された状態に置換されます。複数のフィーチャクラスと複数のオブジェクトに競合がある場合は、これらのすべてが選択したバージョンで置換されます。
[競合] リストでフィーチャクラスの名前を右クリックし、すべての競合を置換するバージョンをクリックします。
- ジオメトリのマージ
この競合解決は、Shape 属性に関連し、フィールドレベルで適用されます。ジオメトリをマージするオプションは、Shape フィールドに関連する競合があるときに使用可能です。2 人の編集ユーザーがどちらも同じフィーチャのジオメトリを編集したが、編集したエリアが異なる場合、ジオメトリをマージして両方の編集を適用することによって競合を解決することができます。
「ジオメトリのマージ中にエラーが見つかりました。2 つのジオメトリをマージすることができません。編集リージョンが重複しています。」
ジオメトリック ネットワークでの競合
ネットワーク フィーチャの編集時にジオメトリック ネットワークと論理ネットワークの両方を変更すると、競合が発生することがあります。
たとえば、水道管に給水管を追加した場合、水道管はジオメトリック ネットワークでは物理的に分割されませんが、論理ネットワークでは分割されます。したがって、ユーザーが水道管のジオメトリを直接編集しなくても、水道管のジオメトリは論理的に編集されています。リコンサイルを実行するターゲット バージョンでも水道管が変更されている場合は、新たに追加された給水管によって水道管との競合が発生します。
ジオメトリック ネットワークのフィーチャクラスに関する競合の確認では、[競合] ダイアログ ボックスの [置換後の文字列] コマンドによって、編集セッションで既存のネットワーク トポロジがどのように更新されるのかを理解する必要があります。
水道管の例において、たとえば、2 人のユーザーが水道管を変更します。1 人は属性を変更し、もう 1 人は新しい給水管を接続しました。このような競合の確認では、相違点の調査と、その競合が有効であることの確認だけが必要であり、それ以上の対処は要求されません。水道管には直径に関する正確な属性が設定されており、新しい給水管は水道管に正確に接続されていることを確認するだけです。しかし競合には、たとえばジャンクション フィーチャクラスに関する競合を解決する際、接続されているネットワーク エッジが更新されるなどの複雑なケースも存在します。
フィーチャリンク アノテーションでの競合
フィーチャリンク アノテーションを操作する際には、1 つのルールを念頭に置いておく必要があります。それは、フィーチャリンク アノテーションが関連付けられているフィーチャを置換すると、フィーチャとアノテーションの両方が新規フィーチャと新規アノテーションに置換されることです。このため、2 つのアノテーションが発生しないように新しいアノテーションを編集する必要があります。
たとえば、フィーチャを移動して、そのアノテーションを再配置したときに、競合が発生することがあります。競合バージョンでは同じ編集が実行されており、フィーチャが移動し、アノテーションが回転しています。フィーチャを競合バージョンのフィーチャと置換することにした場合、既存のフィーチャリンク アノテーションが削除され、競合フィーチャが挿入され、新しいアノテーションが作成されます。その後は、必要に応じて新しいアノテーションを移動および回転するなどの編集が必要になります。
あるいは、別のユーザーがジオデータベースの DEFAULT バージョンでフィーチャを削除し、それによって関連するフィーチャリンク アノテーションも削除されたために、競合が発生することもあります。ジオデータベースの子バージョンで、削除されたばかりのアノテーションを編集します。リコンサイルの際、編集バージョンでフィーチャを置換することにした場合、DEFAULT バージョンで削除されたフィーチャが新しいフィーチャリンク アノテーションとともに置換され、かつ編集バージョンのアノテーションが得られるため、同じフィーチャにアノテーションが 2 つ存在することになります。
リレーションシップでの競合
リレーションシップにも、フィーチャリンク アノテーションと同様の依存関係があります。関連元リレーションシップ クラスからフィーチャを削除すると、関連先リレーションシップ クラスからフィーチャを削除するというメッセージが表示される場合があります。このため、リレーションシップ クラスに属しているフィーチャクラスの競合を置換するという一見単純な操作がもたらす影響に注意しなければなりません。
次に、リレーションシップ クラス間で競合が発生する例を示します。
- 関連元クラスの主フィールドを更新した結果、バージョン A のリレーションシップが無効になります。
- 同時に、バージョン B で関連先クラスの関連フィーチャを更新します。
- 関連先クラスは関連元クラスに依存しているため、2 つのバージョンをリコンサイルしたときに競合が検出されます。
次のような例もあります。
- 電力フィーチャ データセットで、変圧器へのリレーションシップを持つ電柱を削除した結果、関連する変圧器も削除されます。
- 同時に別の編集セッションが開始され、電柱の削除に伴って削除されたばかりの変圧器の属性を、別の編集ユーザーが変更します。
- 2 つの編集をリコンサイルしたときに、更新と削除の競合が検出されます。
この例では、2 人目の編集ユーザーがすべての競合を編集セッションの状態で置換することにした場合、1 人目の編集ユーザーの編集セッションで削除された電柱と変圧器が再作成され、2 人目の編集ユーザーの変圧器も作成されるため、変圧器が 2 つになります。2 つの変圧器はぴったり重なっているので、マップを見てもそれに気付かない可能性がありますが、属性テーブルには変圧器のレコードが 2 つ存在します。
トポロジでの競合
トポロジに属しているフィーチャクラスのフィーチャは、他のフィーチャとジオメトリを共有できるため、トポロジ的に関連するフィーチャクラス間で競合を確認するプロセスは、シンプル フィーチャクラスで競合を置換するプロセスとは異なります。また、ジオメトリック ネットワーク、リレーションシップ クラス、フィーチャリンク アノテーションの競合を置換するプロセスとも異なります。
トポロジに属するフィーチャクラスを編集すると、他のトポロジ的に関連するフィーチャも同時に変更されることがあります。変更されたフィーチャは、同じフィーチャクラスに属していることもあれば、他のフィーチャクラスに属していることもあります。編集によって発生した新しいトポロジ エラーの検出プロセスを管理するために、トポロジには編集箇所がダーティ エリアとして記録されます。トポロジのフィーチャを編集すると、トポロジにダーティ エリアが作成されます。
編集した親バージョンと子バージョンをリコンサイルすると、各バージョンのダーティ エリアが整合チェックされていて、エラーがない状態であっても、新しいトポロジ エラーが発生することがあります。このようなトポロジ エラーを検出するために、リコンサイル時に親バージョンの変更内容が子バージョンに反映された後、子バージョンのダーティ エリアがすべてダーティ状態に戻されます。リコンサイルの後、これらのダーティ エリアを再度整合チェックして、エラーを検出することができます。
アクティブなダーティ エリアが含まれていない 2 つのバージョンをリコンサイルした場合も、ダーティ エリアが発生することがあります。子バージョンに存在するダーティ エリアは、整合チェックされているかどうかにかかわらず、バージョンがリコンサイルされた後にダーティ エリアになります。一般に、バージョンをリコンサイルした場合、次のようになります。
- 子バージョンが親バージョンから継承したダーティ エリアは、子バージョンで整合チェックされているかどうかにかかわらず、リコンサイル後にダーティ エリアになります。
- 子バージョンで作成、更新、または削除されたフィーチャに対して作成されたダーティ エリアは、整合チェックされているかどうかにかかわらず、リコンサイル後にダーティ エリアになります。
ネットワーク データセットでの競合
ネットワーク データセットに属するフィーチャクラスを編集すると、接続性 (ネットワーク エレメント間の接続状態) が変わることがあります (ネットワーク エレメントは、道路、高架などを表すことができます)。さらに、ネットワーク データセットに複数のフィーチャクラスが属する場合があるため、あるソース フィーチャクラスを編集すると、他のソース フィーチャクラスから作成されたネットワーク エレメントの接続性が変わる可能性があります。
ネットワーク データセットに複数のフィーチャクラスが属する場合があり、接続性はジオメトリック リレーションシップに部分的に依存しているため、ネットワーク データセットでの競合を確認するプロセスは、トポロジでのプロセスとほぼ同じです。つまり、ネットワーク データセットでもダーティ エリアを使用します。ただし、これらはトポロジ エラーではなく、接続性の変更を検出するプロセスの管理に使用されます。
フィールド レベルの競合フィルタリング
リコンサイル中の競合定義時に、フィールドまたはフィールド セットに適用される編集を回避したい場合があります。リコンサイル中にフィールドにおける競合を回避することが有用となる例は、次のとおりです。
- 複数の異なるバージョンにおいて、あるフィールドに対する一括更新が実行される場合
- バージョン内で実行された編集に基づき、情報がフィールドに書き込まれる場合
フィールド競合フィルターでは、フィーチャクラス内のフィールドまたはフィールド セットを、競合検出からフィルタリングされるものとしてタグ付けできます。これは、[属性による] 競合定義のオプションが選択されている場合にのみ適用されます。フィールドに競合フィルターが定義されている場合、リコンサイル後のフィールド値はリコンサイルが [ターゲット バージョン優先] と [編集バージョン優先] のどちらで実行されたかに基づきます。リコンサイルが [ターゲット バージョン優先] で実行された場合、競合フィルターを持つフィールドにはターゲット バージョンからの値が含まれます。リコンサイルが [編集バージョン優先] で実行された場合、競合フィルターを持つフィールドには編集バージョンからの値が含まれます。
[フィールド競合フィルターの追加] ツールを使用して、フィールド セットに競合フィルターを定義できます。[フィールド競合フィルターの削除] ツールでは、これらのフィールドから競合フィルターを削除できます。ListFieldConflictFilters ジオプロセシング関数を使用して、フィーチャクラスまたはテーブルに競合フィルターがいつ定義されたかを確認できます。