ArcGIS Help 10.1 - 競合の確認の概要

このトピックは、ArcGIS for Desktop Standard および ArcGIS for Desktop 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 フィールドの横に赤い点が表示されます。

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

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

競合の表示

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

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

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

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

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

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

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

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

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

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

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

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

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

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

競合の解決

競合を解決する際に、維持するフィーチャと属性の状態を決定します。優先してリコンサイルするバージョンとしてターゲットバージョンと自分の編集バージョンのどちらを選択したかに関わらず、リコンサイル前バージョンの状態（リコンサイルする前のバージョンでの表示）、競合バージョンの状態（別の編集ユーザが行った変更を反映した表示）、共通の上位バージョンの状態（ターゲットバージョンでのフィーチャまたは属性の状態）の中から、維持する状態を指定することができます。

競合の解決に使用できる置換オプションは 5 つあります。

属性の置換
この競合解決は、フィールドレベルで適用されます。属性に競合がある場合は、現在のバージョンの属性値のみを、リコンサイル前バージョン、競合バージョン、または共通の上位バージョンの状態のいずれかの属性値で置換できます。これを行うには、競合のある属性を右クリックし、メニューからこのオプションをクリックします。
フィーチャの置換
この競合解決は、行レベルで適用されます。フィーチャ全体を、リコンサイル前バージョン、競合バージョン、または共通の上位バージョンのフィーチャの状態で置換できます。つまり、競合しているすべてのフィールドが置換されます。
クラスレベルの置換
フィーチャクラス全体の現在の状態を、リコンサイル前バージョン、競合バージョン、または共通の上位バージョンのいずれかの状態で置換し、競合を解決できます。この方法では、競合しているすべてのフィーチャと属性が一度に置換されるため、競合するフィーチャをすばやく更新して置換することができます。[競合] リストに複数のフィーチャが存在する場合は、これらのすべてが選択したバージョンで置換されます。
クラスレベルの置換オプションを選択するには、[競合] リストでフィーチャクラスの名前を右クリックし、使用するバージョンをクリックします。
完全な置換
これはルートレベルの置換です。この置換オプションを使用すると、リスト内の競合しているすべてのフィーチャとフィーチャクラスが指定された状態に置換されます。複数のフィーチャクラスと複数のオブジェクトに競合がある場合は、これらのすべてが選択したバージョンで置換されます。
[競合] リストでフィーチャクラスの名前を右クリックし、すべての競合を置換するバージョンをクリックします。
ジオメトリのマージ
この競合解決は、Shape 属性に関連し、フィールドレベルで適用されます。ジオメトリをマージするオプションは、Shape フィールドに関連する競合があるときに使用可能です。2 人の編集ユーザがどちらも同じフィーチャのジオメトリを編集したが、編集したエリアが異なる場合、ジオメトリをマージして両方の編集を適用することによって競合を解決することができます。
ジオメトリをマージするオプションは、Shape フィールドのショートカットメニューでのみ使用できます。
ジオメトリをマージすると、最終的なフィーチャには両方の編集ユーザが行った編集が反映されます。
一方の編集ユーザによる編集と、他方の編集ユーザの編集の範囲が同じである場合、編集されたエリアが重なります。ジオメトリをマージする方法もありますが、マージを試みても失敗します。このような場合は、次のエラーメッセージが表示されます。
「ジオメトリのマージ中にエラーが見つかりました。2 つのジオメトリをマージすることができません。編集リージョンが重複しています。」

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

トポロジでの競合

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

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

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

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

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

ネットワークデータセットでの競合

ネットワークデータセットに属するフィーチャクラスを編集すると、接続性（ネットワークエレメント間の接続状態）が変わることがあります（ネットワークエレメントは、道路、高架などを表すことができます）。さらに、ネットワークデータセットに複数のフィーチャクラスが属する場合があるため、あるソースフィーチャクラスを編集すると、他のソースフィーチャクラスから作成されたネットワークエレメントの接続性が変わる可能性があります。

ネットワークデータセットに複数のフィーチャクラスが属する場合があり、接続性はジオメトリックリレーションシップに部分的に依存しているため、ネットワークデータセットでの競合を確認するプロセスは、トポロジでのプロセスとほぼ同じです。つまり、ネットワークデータセットでもダーティエリアを使用します。ただし、これらはトポロジエラーではなく、接続性の変更を検出するプロセスの管理に使用されます。

ネットワークデータセットの編集の詳細

競合の確認の概要