バージョン ツリーでバージョンに編集を行うと、各バージョン間に差が生じ始めます。上位バージョンからの変更を取得し、この変更に現在のバージョンに加えた編集内容をマージするプロセスは、リコンサイルおよびポストと呼ばれます。バージョンの編集が完了したら、そのバージョンに加えた変更内容を別のバージョンにマージすることができます。トラディショナル バージョニングでは、親バージョンや DEFAULT バージョンなど、そのバージョンの上位バージョンに変更内容をマージすることができます。
バージョンの編集を開始した後に、他のユーザーによって上位バージョンに自分の編集と競合するような変更が加えられている場合があります。編集内容をターゲット バージョンにリコンサイルする際に、これらの競合が検出されます。
競合が存在する場合、ArcGIS Pro はまず、編集中のバージョンまたはターゲット バージョンの状態のどちらかを優先して、競合を解決します。どちらを優先するかは、ユーザーの設定によります。競合が最初に解決された後、競合の解決結果を 1 つずつ確認し、必要に応じて解決された状態を変更することができます。たとえば、競合が編集バージョンを優先して解決された場合には、ターゲット バージョンを優先した解決に置き換えることを選択するか、あるいは編集ツールを使用して別の方法で変更することができます。
メモ:
このトピックでは、[バージョニング] タブによるリコンサイルとポストの処理を説明します。また、[バージョンのリコンサイル (Reconcile Versions)] ジオプロセシング ツールを使用するか、[バージョン] ビューを現在表示している場合は、[バージョン] タブにある [リコンサイル/ポスト] ボタン
を使用して、バージョンのリコンサイルとポストを行うこともできます。リコンサイル処理
トラディショナル バージョニングでは、上位バージョンに現在の編集をリコンサイルするには、以下の条件が満たされている必要があります。
- リコンサイルを実行するユーザーは、そのトラディショナル バージョンを編集している唯一のユーザーでなければなりません。
- 他のユーザーがターゲット バージョンを編集していないことが前提となります。ターゲット バージョンがデフォルトの場合は例外です。他のユーザーが編集でも、デフォルトに対してリコンサイルできます。
- リコンサイルを実行するユーザーは、ターゲット バージョンを参照できなければなりません。つまり、ターゲット バージョンに対してパブリックまたはプロテクトの権限が許可されている必要があります。バージョンに許可されている権限がプライベートである場合は、ユーザーはバージョンの所有者またはジオデータベース管理者でなければなりません。
- 編集するユーザーとリコンサイルするユーザーが別であるようなワークフローを使用している場合、リコンサイルを実行するユーザーには、そのバージョンで変更されたすべてのフィーチャクラスおよびテーブルへの完全な権限が必要です。権限がない場合は、リコンサイルを実行することはできません。リコンサイルを実行するユーザーには、変更されたリレーションシップがシンプルかコンポジットかを問わず、リレーションシップの関連先および関連元に完全な権限が必要です。この種のワークフローでは、リコンサイルを実行するユーザーには適切なバージョン権限も必要です。リコンサイルを実行するユーザーは、リコンサイルするバージョンを変更できる、つまり、そのバージョンにパブリックの権限が許可されている必要があります。さらに、ターゲット バージョンを参照できる、つまり、ターゲット バージョンを所有しているか、ターゲット バージョンにパブリックまたはプロテクトの権限が許可されている必要があります。
リコンサイルの操作中の競合の処理方法を変更する場合は、「編集のバージョニング オプション」をご参照ください。
リコンサイル処理を実行するには、[バージョニング] タブの [リコンサイル] コマンドにアクセスするには、[コンテンツ] ウィンドウの [データ ソース別にリスト] ボタン 
をクリックします。リコンサイル処理を開始するには、[バージョニング] タブにある [リコンサイル] ボタンをクリックします。[リコンサイル] ダイアログ ボックスが表示されます。
[リコンサイル] ダイアログ ボックスが表示されたら、以下の情報を指定します。
- ターゲット バージョン。
- 競合の定義方法。次のオプションがあります。
競合を定義するレベル 検出されるケース 行 (オブジェクト単位)
2 人目のユーザーが同じ行またはフィーチャ、あるいはトポロジ的に関連するフィーチャを編集した場合。競合は異なる属性を編集した場合でも発生します。
列 (属性単位)
2 人目のユーザーがフィーチャまたはテーブルの同じ属性を編集した場合。これがデフォルトです。
競合 (コンフリクト) を定義するためのオプション - ArcGIS Pro による競合 (コンフリクト) の解決方法。次のオプションがあります。
競合の解決 説明 編集バージョン (編集しているバージョン) を優先
現在のバージョンの競合するすべてのフィーチャは、ターゲット バージョンの競合するフィーチャよりも優先されます。
ターゲット バージョンを優先
現在のバージョンの競合するすべてのフィーチャは、ターゲット バージョンのフィーチャに置き換えられます。
競合 (コンフリクト) を解決するためのオプション
メモ:
[元に戻す] 操作でリコンサイルの操作を元に戻すことはできません。リコンサイルを元に戻すには、変更を保存しないで破棄します。
上位バージョンにトラディショナル バージョンでの編集をリコンサイルするには、次の操作を実行します。
- [バージョニング] タブの [バージョニング] グループにある [リコンサイル] をクリックします。
[リコンサイル] ダイアログ ボックスが表示されます。
- ターゲット バージョンを選択します。
- 競合を定義する方法を指定します。
- 競合の解決方法 (編集バージョンと他のターゲット バージョンのどちらを優先してすべての競合を解決するか) を指定します。
- [OK] をクリックします。
競合がある場合、ArcGIS Pro はユーザーの設定に応じて解決します。競合が解決された後、競合の解決結果を 1 つずつ確認し、必要に応じて変更を加えることができます。たとえば、競合が編集バージョンを優先して解決された場合には、ターゲット バージョンを優先した解決に置き換えることを選択するか、あるいは編集ツールを使用して別の方法で解決された状態を変更することができます。
リコンサイルによって更新されるのは編集バージョンだけであるため、ArcGIS Pro で競合がないかをチェックすることは可能ですが、変更内容はターゲット バージョンにマージされません。リコンサイルを終了し、競合を確認した後は、ターゲット バージョンに変更内容をポストして、マージ プロセスを完了してください。
競合ビューを使用した競合の確認
リコンサイルによって競合が検出された場合は、[競合] ビューを使用して、それらを対話形式で確認することができます。ビューは、アプリ内の任意の場所にドッキングしたり、フローティングウィンドウとして配置したりできます。これにより、[マップ] ビューを操作しながら、コンテキストを提供し、詳細にデータを確認できます。
競合ビューには、競合しているすべてのクラスとそれらのフィーチャまたは行が表示されます。競合は、データソース、クラス、競合カテゴリ、および ObjectID を使って整理されます。競合クラスは、ジオデータベース全体の競合におけるレイヤーを表します。
競合ビューでは次の操作を実行できます。
- 競合しているフィールドまたは行の特定
- 競合の表示
- 競合を確認済みまたは未確認としてマーク
- フィーチャまたは属性を置換するために使用するバージョンの状態を指定することによる競合の解決
競合は次のような場合に発生します。
- 編集中のバージョン (編集バージョン) とターゲット バージョンの両方で同じフィーチャが更新された場合
- あるバージョンで更新されたフィーチャが、別のバージョンで削除された場合
- トポロジ的に関連するフィーチャまたはリレーションシップ クラスが編集バージョンとターゲット バージョンの両方で変更された場合
競合ビューには、ジオメトリの編集内容を異なる表現で表示するための [競合を表示] セクションも含まれます。[競合を表示] の内容は、アクティブなマップに競合クラスがあるかどうかに応じて異なります。
- アクティブなマップに競合クラスがある場合は、すべてのマップ レイヤー、マップ シンボル、ベースマップが表示されます。
- アクティブなマップに競合クラスがない場合は、競合しているレイヤー、デフォルト シンボルが表示されます。ベースマップは表示されません。
競合しているフィールドまたは行の特定
競合しているフィーチャクラスとフィーチャはすべて、[競合] ビューの左上のリスト ボックスに表示されます。このリストは、すべてのフィーチャクラスの競合の合計数を示します。
オブジェクトのドロップダウン矢印をクリックすると、各フィーチャの競合が表示されます。これらは、次の 3 つのカテゴリに分けられます。
- [更新-削除] - フィーチャは現在のバージョンでは更新済みで、ターゲット バージョンでは削除済みです。
- [削除-更新] - フィーチャは現在のバージョンでは削除済みで、ターゲット バージョンでは更新済みです。
- [更新-更新] - フィーチャは現在のバージョンとターゲット バージョンの両方で更新済みです。
リストで個々のフィーチャの ObjectID を選択すると、[競合] ビューの右の情報グリッドに、フィーチャの現在のバージョン、ターゲット バージョン、共通の上位バージョンの列と属性が表示されます。
競合しているフィーチャのバージョンまたは編集セッションにおける属性と値を表示すると、属性値がバージョン間でどのように異なっているかを確認することができ、保存する値を選択するのに役立ちます。
- 現在のバージョンは、現在のセッションの編集バージョンにおけるフィーチャと属性の状態を表します。
- ターゲット バージョンは、他の編集セッションまたはバージョンで実行された編集によるフィーチャとその属性の状態を表します。これは、[競合] ビューを開いたときに選択したターゲット バージョンです。
- 共通の上位バージョンは、データベース内のフィーチャとその属性の状態を表します。この場合、フィーチャとその属性は編集される前の状態です (編集を保存してからリコンサイルを行った場合は、編集後の状態となります)。
行の左に表示される赤色のインジケーターは競合を表しています。たとえば、フィーチャのジオメトリが各バージョンで編集された場合、Shape フィールドの横に赤色のインジケーターが表示されます。
他の属性フィールドが競合している場合、赤色のインジケーターが行の左に表示されます。いずれかのバージョンでフィーチャが削除されている場合は、そのバージョンの属性値に [<削除>] が表示されます。
フィーチャが編集バージョンに挿入され、競合が発生すると、[ターゲット] バージョンおよび [共通の上位バージョン] に [<存在しませんでした>] が表示されます。
ダイアログ ボックスの下部にある 2 つのボタンでは、すべてのフィールドを表示するか、競合しているフィールドだけを表示するかを切り替えることができます。
メモ:
[競合] ビューにはすべてのフィールドが表示されますが、競合フィルターが適用されたフィールドは競合とは認識されず、赤色のインジケーターは表示されません。
確認済みまたは未確認のマーク
競合しているフィールドまたは行の特定を行った後、フィーチャに確認済みのマークを付けることができます。確認済みのマークが付いたフィーチャは太字で表示されなくなるため、リストで簡単に見分けることができます。
フィーチャの競合を未確認状態に戻したい場合は、[競合] リストの ObjectID を右クリックして、[未確認としてマーク] をクリックします。これにより、フィーチャが再び太字で表示されます。
ビューの上部にある [確認済みの競合のフィルター処理] チェックボックスをオンにすると、ビューをフィルター処理して、まだ確認されていない競合のみを表示できます。
競合の解決
競合を解決する際に、維持するフィーチャと属性の状態を決定します。優先してリコンサイルするバージョンとしてターゲット バージョンと自分の編集バージョンのどちらを選択したかにかかわらず、現在のバージョンの状態 (リコンサイルする前のバージョンでの表示)、ターゲット バージョンの状態 (別の編集ユーザーが行った変更を反映した表示)、共通の上位バージョンの状態 (ターゲット バージョンでのフィーチャまたは属性の状態) の中から、維持する状態を指定することができます。
競合の解決に使用できる置換オプションは 4 つあります。
- 属性の置換:
この競合解決は、フィールド レベルで適用されます。属性に競合がある場合は、現在のバージョンの属性値のみを、現在のバージョン、ターゲット バージョン、または共通の上位バージョンの状態の属性値で置換できます。これを行うには、競合のある属性を右クリックし、メニューからこのオプションをクリックします。
- フィーチャの置換:
この競合解決は、行レベルで適用されます。フィーチャ全体を、現在のバージョン、ターゲット バージョン、または共通の上位バージョンのフィーチャの状態で置換できます。つまり、競合しているすべてのフィールドが置換されます。
- クラス レベルの置換:
フィーチャクラス全体の現在の状態を、現在のバージョン、ターゲット バージョン、または共通の上位バージョンのいずれかの状態で置換し、競合を解決できます。この方法では、競合しているすべてのフィーチャと属性が一度に置換されるため、競合するフィーチャをすばやく更新して置換することができます。[差分] リストに複数のフィーチャが存在する場合は、これらのすべてが選択したバージョンで置換されます。
クラス レベルの置換オプションを選択するには、[差分] リストでフィーチャクラスの名前を右クリックし、使用するバージョンをクリックします。
- 完全な置換:
これはルートレベルの置換です。この置換オプションを使用すると、リスト内の競合しているすべてのフィーチャとフィーチャクラスが指定された状態に置換されます。複数のフィーチャクラスと複数のオブジェクトに競合がある場合は、これらのすべてが選択したバージョンで置換されます。
[差分] リストの上部にあるバージョンおよび接続情報を右クリックし、すべての競合を置換するバージョンをクリックします。
フィールド レベルの競合フィルタリング
トラディショナル バージョニングで作業しているとき、リコンサイル中に競合が検出された際、フィールドまたはフィールド セットに適用される編集を残したい場合があります。リコンサイル中にフィールドで検出された競合を除外したい状況の例を以下に示します。
- 複数の異なるバージョンにおいて、あるフィールドに対する一括更新が実行される場合
- バージョン内で実行された編集に基づき、情報がフィールドに書き込まれる場合
親バージョンと子バージョンで同じ属性が更新されたときに競合が識別されないようにするため、[フィールド競合フィルターの追加 (Add Field Conflict Filter)] ツールを使用して、フィールド セットに競合フィルターを定義できます。フィールド競合フィルターでは、フィーチャクラス内のフィールドまたはフィールド セットを、競合検出からフィルタリングされるものとしてタグ付けできます。競合フィルターが定義されたフィールドのみが編集された場合は、リコンサイルの操作中、競合は返されません。これは、属性で競合を定義した場合のみに適用されます。
メモ:
[競合] ビューにはすべてのフィールドが表示されますが、競合フィルターが適用されたフィールドは競合とは認識されず、赤色のインジケーターは表示されません。
リコンサイルが変化した後に、競合フィルターを持つフィールドに設定される値は、ターゲット バージョンと編集バージョンのどちらを優先してリコンサイルしたかによって異なります。ターゲット バージョンを優先してリコンサイルした場合、競合フィルターを持つフィールドにはターゲット バージョンからの値が含まれます。編集バージョンを優先してリコンサイルした場合、競合フィルターを持つフィールドには編集バージョンからの値が含まれます。
[フィールド競合フィルターの削除 (Remove Field Conflict Filter)] ツールでは、これらのフィールドから競合フィルターを削除できます。ListFieldConflictFilters Python 関数を使用して、フィーチャクラスまたはテーブルに競合フィルターがいつ定義されたかを確認できます。
メモ:
フィーチャクラスまたはテーブルにフィールド競合フィルターが定義されると、10.2.1 より前のリリースの ArcGIS クライアントはフィーチャクラスまたはテーブルを開くことができなくなります。以前のリリースの ArcGIS でデータにアクセスする必要がある場合は、フィールドにフィールド競合フィルターを定義し、バージョンのリコンサイルが終了した後でそのフィルターを削除することができます。
属性ルールを使用した競合の解決
属性ルールを使用すると、編集の操作性を強化して、ジオデータベース データセットのデータ整合性を向上させることができます。即時計算または制限ルールを使用したトラディショナル バージョン対応フィーチャクラスのリコンサイルでは、これらの属性ルールが評価されます。制限ルールに違反した場合、制限ルール エラーが報告され、リコンサイルは失敗します。行ごとに競合をリコンサイルすると、制限ルール エラーを回避できます。
リレーションシップ クラスによる競合の解決
リレーションシップ クラスを使用すれば、関連するオブジェクト間の参照整合性を維持するために役立ちます。バージョン対応データ ソースがリレーションシップ クラスに参加している場合、リコンサイル処理ではこのデータの参照整合性が評価されます。参照整合性の違反がある場合、参加しているフィーチャが競合としてレポートされ、競合ビューで確認できるようになります。
関連元リレーションシップ クラスからフィーチャを削除すると、関連先リレーションシップ クラスからフィーチャを削除するというメッセージが表示される場合があります。このため、リレーションシップ クラスに属しているフィーチャクラスの競合を置換するという一見単純な操作がもたらす影響に注意しなければなりません。
次に、リレーションシップ クラス間で競合が発生する例を示します。
- 親バージョンで、関連先フィーチャを追加し、それを関連元クラスのフィーチャに関連付けます。
- 子バージョンで、新しい関連先フィーチャに関連付けるために使用された、同じ関連元フィーチャを削除します。
- 編集内容をリコンサイルすると、関連元クラスで削除 - 更新の競合が検出されました。
次のような例もあります。
- 電力フィーチャ データセットで、変圧器へのリレーションシップを持つ電柱を削除した結果、関連する変圧器も削除されます。
- 同時に別の編集セッションが開始され、電柱の削除に伴って削除されたばかりの変圧器の属性を、別の編集ユーザーが変更します。
- 編集内容をリコンサイルすると、関連元クラスと関連先クラスで更新 - 削除の競合が検出されました。
この例では、2 人目の編集ユーザーがすべての競合を編集セッションの状態で置換することにした場合、1 人目の編集ユーザーの編集セッションで削除された電柱と変圧器が再作成されます。
変更のポスト
編集内容をターゲット バージョンにポストするには、このバージョンを編集するためのアクセス権を持っている必要があります。つまり、そのバージョンのアクセス プロパティが「パブリック」であるか、ユーザーがジオデータベース管理者である必要があります。
リコンサイルを完了して競合を確認した後、変更をターゲット バージョンにポストするには、[バージョニング] タブの [バージョニング] グループにある [ポスト] をクリックします。
ヒント:
変更をポストしたターゲット バージョンを参照している他のユーザーは、バージョン ワークスペースを更新するまで、ポストされた変更内容を参照できません。
ポスト プロセスに関する補足情報
- 最後に変更をリコンサイルしたときからターゲット バージョンが変更されていない場合のみ、変更をポストできます。ターゲット バージョンが途中で変更されていた場合には、再度リコンサイルを実行してからポストを実行する必要があります。
- 変更がポストされると、現在編集していないバージョンに変更を適用することになるので、ポスト操作を元に戻すことはできません。
- ポストが完了した後、バージョンで引き続き編集を行うことができます。それらの変更をターゲット バージョンに適用するには、リコンサイル、競合の解決、ポストのプロセスを再び実行する必要があります。
ポスト処理の完了によってワークフローが完了した場合は、必要に応じて、編集したバージョンを削除することができます。