競合の確認の概要

このトピックは、ArcEditor および ArcInfo にのみ適用されます。

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 に競合が存在します。

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 フィールドの横に赤い点が表示されます。

他の属性フィールドが競合している場合は、それらの横に赤い点が表示されます。いずれかのバージョンでフィーチャが削除されている場合は、そのバージョンの属性値に「<削除>」が表示されます。

競合しているフィーチャのバージョンまたは編集セッションにおける属性と値を表示すると、属性値がどのように異なっているかを確認することができ、保存する値を選択するのに役立ちます。

競合の表示

ダイアログ ボックスの [競合を表示>>] ボタンをクリックすると、競合している 2 つのフィーチャの形状の状態（リコンサイル前バージョンと競合バージョン）がダイアログ ボックスの下部に表示されます。

各ジオメトリ表示ウィンドウの下にあるドロップダウン リストを使用して、競合しているフィーチャの 3 種類の状態（リコンサイル前バージョン、競合バージョン、共通の上位バージョン）を切り替えることができます。これらの表示が異なるのは、競合がフィーチャのジオメトリで発生している場合だけです。

これらの表示の下には、表示をナビゲートして個別属性を表示するためのツールが含まれたツールバーがあります。

マップ上で競合しているフィーチャの特定のバージョンにズームするには、そのフィーチャをリストで右クリックし、[リコンサイル前バージョンにズーム]、[競合バージョンにズーム]、または [共通の上位バージョンにズーム] をクリックします。

ジオメトリが競合している場合、マップ上に別のジオメトリの状態を表示するには、リスト ボックスで Shape フィールドを右クリックし、[表示設定...] をクリックします。

これにより、[競合表示設定] ダイアログ ボックスが表示されます。マップ上に描画したいジオメトリの状態をオンにします。

[OK] をクリックすると、マップ上で次のように動作します。

• 競合（ターゲット）バージョンの状態が赤色で表示されます。
• リコンサイル前バージョンの状態が緑色で表示されます。
• 共通の上位バージョンの状態が青色で表示されます。

[競合表示設定] ダイアログ ボックスで上記のようにオプションを選択した場合、マップ上の表示は次のようになります。

[競合表示設定] ダイアログ ボックスで [現在のバージョンを表示] のみをチェックした場合、マップ上の表示は次のようになります。

競合を確認した後は、それらに確認済みのマークを付けるか、置換オプションを選択して競合を解決することができます。

確認済みまたは未確認のマーク

「競合しているフィールドまたは行の特定」で説明したように、フィーチャに確認済みのマークを付けることができます。これは、競合を確認済みであり、この時点では置換オプションを選択しないことを示します。確認済みのマークが付いたフィーチャは太字で表示されなくなるため、リストで簡単に見分けることができます。

フィーチャの競合を未確認状態に戻したい場合は、[競合] リストの ObjectID を右クリックして、[未確認マーク] をクリックします。これにより、フィーチャが再び太字で表示されます。

競合の解決

• 属性の置換
• フィーチャの置換
• クラス レベルの置換
• 完全な置換
• ジオメトリのマージ

  この競合解決は、Shape 属性に関連し、フィールドレベルで適用されます。ジオメトリをマージするオプションは、Shape フィールドに関連する競合があるときに使用可能です。2 人の編集ユーザがどちらも同じフィーチャのジオメトリを編集したが、編集したエリアが異なる場合、ジオメトリをマージして両方の編集を適用することによって競合を解決することができます。

  ジオメトリをマージするオプションは、Shape フィールドのショートカット メニューでのみ使用できます。
  ジオメトリをマージすると、最終的なフィーチャには両方の編集ユーザが行った編集が反映されます。
  一方の編集ユーザによる編集と、他方の編集ユーザの編集の範囲が同じである場合、編集されたエリアが重なります。ジオメトリをマージするオプションは使用可能ですが、マージを試みても失敗します。このような場合は、次のエラー メッセージが表示されます。

ジオメトリック ネットワークでの競合

ネットワーク フィーチャの編集時にジオメトリック ネットワークと論理ネットワークの両方を変更すると、競合が発生することがあります。

たとえば、水道管に給水管を追加した場合、水道管はジオメトリック ネットワークでは物理的に分割されませんが、論理ネットワークでは分割されます。したがって、ユーザが水道管のジオメトリを直接編集しなくても、水道管のジオメトリは論理的に編集されています。リコンサイルを実行するターゲット バージョンでも水道管が変更されている場合は、新たに追加された給水管によって水道管との競合が発生します。

ジオメトリック ネットワークのフィーチャクラスに関する競合の確認では、[競合] ダイアログ ボックスの [置換後の文字列] コマンドによって、編集セッションで既存のネットワーク トポロジがどのように更新されるのかを理解する必要があります。

水道管の例において、例えば、2 人のユーザが水道管を変更します。1 人は属性を変更し、もう 1 人は新しい給水管を接続しました。このような競合の確認では、相違点の調査と、その競合が有効であることの確認だけが必要であり、それ以上の対処は要求されません。水道管には直径に関する正確な属性が設定されており、新しい給水管は水道管に正確に接続されていることを確認するだけです。しかし競合には、例えばジャンクション フィーチャクラスに関する競合を解決する際、接続されているネットワーク エッジが更新されるなどの複雑なケースも存在します。

フィーチャリンク アノテーションでの競合

フィーチャリンク アノテーションを操作する際には、1 つのルールを念頭に置いておく必要があります。それは、フィーチャリンク アノテーションが関連付けられているフィーチャを置換すると、フィーチャとアノテーションの両方が新規フィーチャと新規アノテーションに置換されることです。このため、2 つのアノテーションが発生しないように新しいアノテーションを編集する必要があります。

たとえば、フィーチャを移動して、そのアノテーションを再配置したときに、競合が発生することがあります。競合バージョンでは同じ編集が実行されており、フィーチャが移動し、アノテーションが回転しています。フィーチャを競合バージョンのフィーチャと置換することにした場合、既存のフィーチャリンク アノテーションが削除され、競合フィーチャが挿入され、新しいアノテーションが作成されます。その後は、必要に応じて新しいアノテーションを移動および回転するなどの編集が必要になります。

あるいは、別のユーザがジオデータベースの DEFAULT バージョンでフィーチャを削除し、それによって関連するフィーチャリンク アノテーションも削除されたために、競合が発生することもあります。ジオデータベースの子バージョンで、削除されたばかりのアノテーションを編集します。リコンサイルの際、編集バージョンでフィーチャを置換することにした場合、DEFAULT バージョンで削除されたフィーチャが新しいフィーチャリンク アノテーションとともに置換され、かつ編集バージョンのアノテーションが得られるため、同じフィーチャにアノテーションが 2 つ存在することになります。

リレーションシップでの競合

リレーションシップにも、フィーチャリンク アノテーションと同様の依存関係があります。関連元リレーションシップ クラスからフィーチャを削除すると、関連先リレーションシップ クラスからフィーチャを削除するというメッセージが表示される場合があります。このため、リレーションシップ クラスに属しているフィーチャクラスの競合を置換するという一見単純な操作がもたらす影響に注意しなければなりません。

次に、リレーションシップ クラス間で競合が発生する例を示します。

• 関連元クラスの主フィールドを更新した結果、バージョン A のリレーションシップが無効になります。
• 同時に、バージョン B で関連先クラスの関連フィーチャを更新します。
• 関連先クラスは関連元クラスに依存しているため、2 つのバージョンをリコンサイルしたときに競合が検出されます。

次のような例もあります。

• 電力フィーチャ データセットで、変圧器へのリレーションシップを持つ電柱を削除した結果、関連する変圧器も削除されます。
• 同時に別の編集セッションが開始され、電柱の削除に伴って削除されたばかりの変圧器の属性を、別の編集ユーザが変更します。
• 2 つの編集をリコンサイルしたときに、更新と削除の競合が検出されます。

この例では、2 人目の編集ユーザがすべての競合を編集セッションの状態で置換することにした場合、1 人目の編集ユーザの編集セッションで削除された電柱と変圧器が再作成され、2 人目の編集ユーザの変圧器も作成されるため、変圧器が 2 つになります。2 つの変圧器はぴったり重なっているので、マップを見てもそれに気付かない可能性がありますが、属性テーブルには変圧器のレコードが 2 つ存在します。

トポロジでの競合

トポロジに属しているフィーチャクラスのフィーチャは、他のフィーチャとジオメトリを共有できるため、トポロジ的に関連するフィーチャクラス間で競合を確認するプロセスは、シンプル フィーチャクラスで競合を置換するプロセスとは異なります。また、ジオメトリック ネットワーク、リレーションシップ クラス、フィーチャリンク アノテーションの競合を置換するプロセスとも異なります。

トポロジに属するフィーチャクラスを編集すると、他のトポロジ的に関連するフィーチャも同時に変更されることがあります。変更されたフィーチャは、同じフィーチャクラスに属していることもあれば、他のフィーチャクラスに属していることもあります。編集によって発生した新しいトポロジ エラーの検出プロセスを管理するために、トポロジには編集箇所がダーティ エリアとして記録されます。トポロジのフィーチャを編集すると、トポロジにダーティ エリアが作成されます。

編集した親バージョンと子バージョンをリコンサイルすると、各バージョンのダーティ エリアが整合チェックされていて、エラーがない状態であっても、新しいトポロジ エラーが発生することがあります。このようなトポロジ エラーを検出するために、リコンサイル時に親バージョンの変更内容が子バージョンに反映された後、子バージョンのダーティ エリアがすべてダーティ状態に戻されます。リコンサイルの後、これらのダーティ エリアを再度整合チェックして、エラーを検出することができます。

アクティブなダーティ エリアが含まれていない 2 つのバージョンをリコンサイルした場合も、ダーティ エリアが発生することがあります。子バージョンに存在するダーティ エリアは、整合チェックされているかどうかにかかわらず、バージョンがリコンサイルされた後にダーティ エリアになります。一般に、バージョンをリコンサイルした場合、ダーティ エリアは次のようになります。

• 子バージョンが親バージョンから継承したダーティ エリアは、子バージョンで整合チェックされているかどうかにかかわらず、リコンサイル後にダーティ エリアになります。
• 子バージョンで作成、更新、または削除されたフィーチャに対して作成されたダーティ エリアは、整合チェックされているかどうかにかかわらず、リコンサイル後にダーティ エリアになります。