バージョンのリコンサイル
このモジュールでは、[リコンサイル/ポスト] ツールを実行して、[Imperial Work Order 1] と [Imperial Work Order 2] という 2 つの名前付きバージョンを、デフォルト バージョンに対して同時にリコンサイルします。
バージョン管理者としてデータにアクセスする
このチュートリアルでは、バージョン管理者としての役割を担います。 バージョン管理者は、バージョン所有者やアクセス権にかかわらず、ブランチ バージョンの表示、編集、管理を行うための無制限のアクセス権を持ちます。 ブランチ バージョニングでは、次のポータル ユーザーがバージョン管理者としての役割を担うことができます。
- Web フィーチャ レイヤーの所有者 (通常はフィーチャ サービスを公開したユーザー)
- 管理者ロールが割り当てられたポータル ユーザー
- すべて管理権限が割り当てられたカスタム ロールを持つポータル ユーザー
このシリーズの最初のチュートリアルである「ブランチ バージョン対応データの準備と公開」でマドリードのデータを公開したことから、最初の定義が当てはまるため、あなたはバージョン管理者として適格です。 データを共有したときと同じ認証情報を使用し、ポータルにサイン インします。
- ArcGIS Pro を起動します。
- [新しいプロジェクト] の下の [テンプレートを使用せずに開始] をクリックします。
- リボンの上部で [サイン インしていません] をクリックし、[サイン イン] をクリックします。
- [ArcGIS サイン イン] ウィンドウに、このシリーズの最初のチュートリアルである「ブランチ バージョン対応データの準備と公開」で使用したポータル アカウントのユーザー名とパスワードを入力します。
- [カタログ] ウィンドウで [ポータル] タブをクリックし、[組織] ボタンをクリックします。
最初のチュートリアルで作成した [Madrid Solar Project] アイテムを含む、組織のポータル アイテムがすべて表示されます。
- [Madrid Solar Project] フィーチャ レイヤー (黄色のアイコン) を右クリックし、[新しく追加] にポインターを合わせて、[マップ] をクリックします。
新しいマップにデータが表示されます。
- [コンテンツ] ウィンドウで、[Madrid Solar Project] の横にある矢印をクリックし、グループ レイヤーを展開します。
グループ レイヤーには、[Buildings] と [Neighborhoods] の 2 つのレイヤーが含まれています。
名前付きバージョンをリコンサイルおよびポストする
前回のチュートリアルである「ブランチ バージョンでの編集」で、[Imperial Work Order 1] と [Imperial Work Order 2] という 2 つの名前付きバージョンを作成しました。 次に、両方のバージョンをリコンサイルし、ポストします。
リコンサイルとは、デフォルト バージョンから変更を取得し、それを現在接続されている名前付きバージョンにマージする処理のことを言います。 リコンサイル処理は、2 つの名前付きバージョンとデフォルト バージョン間の競合を検出します。 ポストとは、変更内容をデフォルト バージョンに送信する処理のことです。
- [コンテンツ] ウィンドウで [データ ソース別にリスト] ボタンをクリックします。
- [コンテンツ] ウィンドウで [Madrid Solar Project] データ ソース ([sde.DEFAULT (Madrid_Solar_Project)] など) をクリックします。
- リボン上の [バージョニング] タブをクリックします。
- [バージョニング] グループで [バージョンの管理] をクリックします。
バージョン ビューが開き、デフォルト バージョンと、前回のチュートリアルで作成された 2 つの名前付きバージョンがリストされます。
名前付きバージョンをそれぞれ個別にリコンサイルし、ポストすることもできますが、代わりに [リコンサイル/ポスト] ツールを使用して同時に処理します。
- [バージョンの管理] グループで [リコンサイル/ポスト] をクリックします。
- [リコンサイル/ポスト] ウィンドウで [ターゲット バージョン] がデフォルト バージョンに設定されていることを確認します。
ブランチ バージョニングの場合、ターゲット バージョンは常にデフォルト バージョンになります。
- [編集バージョン] ボックスで、[Imperial Work Order 1] と [Imperial Work Order 2] のチェックボックスをオンにします。
編集バージョンは、リコンサイルする名前付きバージョンです。
- [競合が検出された場合は中止] チェックボックスをオンにし、[未確認の競合が検出された場合の動作] チェックボックスをオフにします。
このように選択しておくと、競合が検出された場合にリコンサイル処理がキャンセルされます。 これにより、手作業で競合を検証して解決することで、品質保証を実施できるようになります。
注意:
競合を検証したくない状況にある場合は、[未確認の競合が検出された場合の動作] チェックボックスをオンにします。 これを選択すると、ツールの実行時に、前のセッションの既存の競合は失われます。 詳細については、「バージョンのリコンサイル」のドキュメントをご参照ください。
- [競合の定義方法] で、[属性単位 (列)] が選択されていることを確認します。
これにより、同じフィーチャの同じ属性への変更に対してのみ、競合フラグが設定されます。 [オブジェクト単位 (行)] を選択した場合、同じフィーチャに対する変更に対して競合フラグが設定されます (たとえば、同じフィーチャの異なる属性に対する編集内容である場合)。
- [リコンサイル後にバージョンをポスト] チェックボックスと [ポスト後にバージョンを削除] チェックボックスをオンにします。
このように選択すると、リコンサイル処理中に競合が検出されなかった場合、ツールは名前付きバージョンをポストし、削除します。
- [OK] をクリックします。
リコンサイル処理が完了すると、警告メッセージが表示されます。
メッセージの前半は、[Imperial Work Order 1] のバージョンはデフォルト バージョンに対して正常にリコンサイルされ、デフォルト バージョンにポストされ、削除されたことを説明しています。
メッセージの後半は、[Imperial Work Order 2] バージョンのリコンサイル処理中に競合が検出されたことを説明しています。 そのため、リコンサイル処理はキャンセルされ、このバージョンの編集はデフォルト バージョンにポストされませんでした。 このバージョンに接続し、競合を手動で解決する必要があります。
- [閉じる] をクリックします。
[Imperial Work Order 1] バージョンはリコンサイルおよびポスト処理中に削除されたため、バージョン ビューから削除されました。
- バージョン ビューを終了します。
- [コンテンツ] ウィンドウで、[Madrid Solar Project] ワークスペースが [デフォルト] バージョン ([sde.DEFAULT (Madrid_Solar_Project)] など) に接続されていることを確認します。
マップで、Imperial 地区の建物はオレンジ色と赤色でシンボル表示されます。 これは、[Imperial Work Order 1] バージョンからの編集内容がデフォルト バージョンにポストされたためです。
このモジュールでは、バージョン管理者としてポータル アカウントに接続しました。 [リコンサイル/ポスト] ツールを使用し、複数の名前付きバージョンを 1 回のセッションでリコンサイルしました。 1 つ目の名前付きバージョンには競合が見つからなかったので、デフォルト バージョンにポストされ、削除されました。 2 つ目の名前付きバージョンには競合があったため、リコンサイル処理はキャンセルされました。
競合の確認と解決
このモジュールでは、[Imperial Work Order 2] バージョンに対してのみリコンサイル処理を再実行します。 リコンサイル処理は競合を検出します。 競合ビューを使用し、競合を手動で確認し、解決します。
競合を確認する
まず、[Imperial Work Order 2] バージョンに接続します。
- [コンテンツ] ウィンドウで [Madrid Solar Project] ワークスペースを右クリックし、[バージョンの変更] をクリックします。
- [バージョンの変更] ウィンドウで [Imperial Work Order 2] バージョン (たとえば [ADMIN.Imperial Work Oder 2] など) をクリックします。
- [OK] をクリックします。
マップが名前付きバージョンに更新されます。Imperial 地区の建物が、薄いオレンジ色で表される市営スポーツ ビルを除いて、すべて薄い黄色になります。
- リボンの [バージョニング] タブの [リコンサイル] ボタンをクリックします。
前回、複数の名前付きバージョンを同時に処理できることから、[リコンサイル/ポスト] ツールを使用しました。 今回 [リコンサイル] ツールを使用するのは、競合が検出されたときに手動で確認できるからです。
- [リコンサイル] ウィンドウで [競合の定義] が[属性単位 (列)] に設定されていることを確認します。
このリコンサイル処理は、デフォルト バージョンのすべての変更内容を [Imperial Work Order 2] バージョンにマージし、競合が検出された場合に通知します。 建物が両方のバージョンで編集された場合、または建物が 1 つのバージョンで削除されたが、他方のバージョンでは削除されなかった場合に、競合が検出されます。 競合を確認し、解決することができます。
- [OK] をクリックします。
別のウィンドウが表示され、競合が検出され、編集バージョンを優先して解決されたことが示されます。 これはブランチ バージョンのデフォルトの挙動です。 編集バージョンは、現在のバージョンである [Imperial Work Order 1] です。
- [競合を確認しますか] で [はい] をクリックします。
競合ビューが表示されます。 競合が発生しているフィーチャクラスがリストされます。 ここでは、[Buildings] フィーチャクラスがリストされます。 名前の後に [(1)] が付加している場合は、競合が 1 件含まれていることを意味します。
注意:
ブランチ バージョンでは、複数の ArcGIS Pro セッションで競合を確認し、解決できます。 複数の競合がある場合でも、すべての競合を同時に確認し、解決する必要はありません。
- [Buildings] フィーチャクラスの横にある矢印をクリックして展開し、競合を表示します。
競合タイプ [更新-更新] が表示されます。 このタイプの競合は、現在のバージョンとターゲット バージョンの両方でフィーチャが更新されたことを意味します。
- [更新‐更新] を展開します。
競合が発生しているフィーチャの Object ID ([1752]) が表示されます。
- [1752] をクリックします。
情報グリッドは、フィーチャのすべての状態の属性値を表示します。
3 つの状態は以下のとおりです。
- [現在] - [Imperial Work Order 2] バージョン。
- [ターゲット] - [Imperial Work Order 2] バージョンへの編集内容を含むデフォルト バージョン。
- [共通の上位バージョン] - 名前付きバージョンが作成されたときのデータの状態。
情報グリッドから [ターゲット] バージョンと [現在] バージョンの両方に [POT_SOLAR] フィールドの変更が含まれていることがわかります。
- 競合ビューの下部で [競合を表示] の横にある矢印をクリックし、このセクションを展開します。
[競合を表示] ビューアーが開き、競合のあるフィーチャ (1752) が 2 つのマップで選択されていることが表示されます。 フィーチャ 1752 は、市営スポーツ ビルであることがわかります。
左側のマップは [現在] バージョンを示し ([Imperial Work Order 2])、右側のマップは [ターゲット] バージョン (デフォルト) を示します。
[現在] バージョンでは、市営スポーツ ビル以外のすべての建物が、リコンサイル処理において [ターゲット] バージョンの値と色を採用しています。 共通の上位バージョンから作成されたバージョンのうち、2 つではなく 1 つでしか編集されていないため、競合は検出されませんでした。 2 つのマップ間の唯一の違いは、市営スポーツ ビルの色です。これは両方のバージョンで編集されたため競合しています。
前のチュートリアル「ブランチ バージョンでの編集」で、競合の原因となった編集を行っています。 [Imperial Work Order 1] バージョンで [Potencialidad solar] (POT_SOLAR) フィールドを計算するためにバッチ編集を実行しました。 この編集の結果、市営スポーツ ビルの値が 3.65420923 と比較的高くなったため、[ターゲット] マップで赤色でシンボル表示されています。 (レイヤーのシンボルは [Potencialidad solar] フィールドによって決定されます。) [Imperial Work Order 2] バージョンでは、市営スポーツ ビルを手動で編集しました。[Potencialidad solar] 値を 1.876058 に変更したため、[現在] マップの建物の色が薄いオレンジ色でシンボル表示されています。 このように編集された属性は情報グリッドにも表示されます。
競合の解決
次に、市営スポーツ ビルのどのリプレゼンテーションを受け入れるか決定します。 このシナリオでは、[Imperial Work Order 2] バージョンで行った編集内容を維持します。この数値は、2 回目のフィールド調査の結果から得られたからです。 これは、この建物に関する最新のレポートを表します。
- [競合] ビューで [1752] をクリックし、[確認メモの追加] をクリックします。
- [確認メモの追加] ウィンドウに「The correct solar potential value is 1.876058 from the latest survey」と入力します。
確認メモは、複数の競合の確認セッションにわたって維持され、競合の解決に関するコンテキストを提供します。 メモは、複数の管理者が存在する組織で特に有用です。
- [OK] をクリックします。
- [1752] を再度右クリックし、[確認済みとしてマーク] をクリックします。
[競合] リストのテキストの書式設定が、太字から標準に変更されます。
確認されていない競合は太字で表示されるため、確認済みの競合と確認されていない競合を把握することができます。
注意:
ブランチ バージョニングでは、競合はデフォルトで現在の (編集) バージョンを優先して解決されます。 この場合、競合を確認し、現在のバージョンの値が正しい値であると判断したため、これ以上の変更は必要ありません。 しかし、ターゲット (デフォルト) の値が正しいと判断した場合は、フィーチャを再度右クリックし、[ターゲット バージョンで置換] を選択します。
競合ビューの詳細については、「ブランチ バージョンの競合の管理」ドキュメントをご参照ください。
- リボン上の [編集] タブにある [編集の管理] グループで、[保存] をクリックします。
- [編集の保存] ウィンドウで [はい] をクリックします。
- 競合ビューを終了します。
マップで、Imperial 地区のすべての建物がオレンジ色と赤色の陰影で表示されます。 市営スポーツ ビルは薄いオレンジ色です。
このモジュールでは、競合ビューを使用して、リコンサイル操作に基づくフィーチャと属性の現在のリプレゼンテーションを確認しました。 現在のバージョン ([Imperial Work Order 2]) で行った編集を維持することで、競合を確認し、解決しました。
バージョンのポストと削除
このモジュールでは、品質保証プロセスの最終ステップを完了します。[Imperial Work Order 2] バージョンで吟味した編集内容をデフォルト バージョンにポストし、組織全体が使用できるようにします。 バージョンをポストした後、削除します。
名前付きバージョンをポストする
名前付きバージョンをもう一度リコンサイルし、デフォルト バージョンにポストします。
- [コンテンツ] ウィンドウで [Madrid Solar Project] ワークスペースが [Imperial Work Order 2] バージョンに接続されていることを確認します。 ワークスペースをクリックします。
- リボン上の [バージョニング] タブをクリックします。 [バージョニング] グループで [リコンサイル] をクリックします。
バージョンをすでにリコンサイルしたので、このステップは冗長に思えるかもしれません。 しかし、自分が品質保証に当たっている間に、他の編集者がそれぞれのバージョンの編集をデフォルト バージョンにポストした可能性があるため、ポストする前にリコンサイルを繰り返すことが重要です。 新しい編集内容が自分の編集とは異なる場合、リコンサイル操作によって新しい競合を検出できます。
- [リコンサイル] ウィンドウで [競合の定義] が [属性単位] に設定されていることを確認します。 [OK] をクリックします。
[リコンサイル] ウィンドウが閉じます。 新しい競合は検出されなかったことを意味します。 編集をデフォルト バージョンにポストできます。
- [バージョニング] タブの [バージョニング] グループで [ポスト] をクリックします。
ポスト操作により、[Imperial Work Order 2] バージョンの編集内容がデフォルト バージョンにマージされます。 デフォルト バージョンに接続し、編集がマージされたことを確認します。
- [コンテンツ] ウィンドウで [Madrid Solar Project] ワークスペースを右クリックし、[デフォルトに変更] をクリックします。
マップは更新されますが、外観は変わりません。それは、デフォルト バージョンは、前に表示していた [Imperial Work Order 2] バージョンと同じだからです。
- Imperial 地区にズームし、市営スポーツ ビルをクリックします。
ポップアップが表示されるので、[Potencialidad solar] 値が [1.876058] であることを確認します。
- ポップアップを閉じます。
名前付きバージョンを削除する
品質保証を行うバージョン管理者としての最後のステップは、不要になったバージョンを削除することです。
- リボンの [バージョニング] タブの [バージョニング] グループで [バージョンの管理] をクリックします。
- バージョン ビューで [Imperial Work Order 2] バージョンをクリックして選択します。
[Imperial Work Order 1] バージョンは、[リコンサイル/ポスト] 操作の一環としてすでに削除されています。
- リボンの [バージョン] タブの [バージョンの管理] グループで、[削除] をクリックします。
バージョン ビューで、名前付きバージョンが取り消し線とともに表示されます。
- リボンの [バージョンの管理] グループで [保存] をクリックします。
名前付きバージョンは、バージョン ビューに表示されなくなります。 デフォルト バージョンのみが残ります。
- ArcGIS Pro を閉じます。 プロジェクトを保存する必要はありません。
このモジュールでは、有効な編集をデフォルト バージョンにポストすることで、品質保証処理を行いました。 [Imperial Work Order 2] 名前付きバージョンを削除し、バージョン リストをクリーン アップしました。
このチュートリアルでは、[Madrid Solar Project] フィーチャ レイヤーのバージョン管理者としての役割を担いました。 両方の名前付きバージョンをリコンサイルし、片方のバージョンで検出された競合を確認し、解決しました。 編集内容が有効であることを確信してから、デフォルト バージョンにポストし、名前付きバージョンを削除しました。
このチュートリアル シリーズでは、完全なブランチ バージョニング ワークフローを行いました。フィーチャクラスでブランチ バージョニングを有効にし、それを Web フィーチャ レイヤーとしてポータルに公開しました。 2 つの名前付きバージョンを作成し、両方に接続して、それぞれに対して編集を行いました。 その後、名前付きバージョンをリコンサイルし、ポストしました。 編集内容は、デフォルト バージョンに反映され、組織全体で利用できるようになりました。 これで、ブランチ バージョニング処理を同僚に説明する準備ができました。 複数のユーザーにエディターの役割を割り当て、名前付きバージョンの作成と編集の方法を説明します。
これからは、データをロックしたり複製したりせずに、複数のユーザーが同時に編集を行えるため、プロジェクトを迅速に進めることができます。 マドリードのすべての建物の予想日射量を、バージョニングを行わない場合よりもはるかにすばやく知ることができます。