従来のバージョン対応登録が行われたデータを使用する編集可能なフィーチャ サービスを含むマップをダウンロードしてオフラインで取得すると、公開済みデータで使用されているバージョンから新しいジオデータベース バージョンが作成されます。クライアントが編集内容をフィーチャ サービスと同期すると、編集内容はこの新しいバージョンに適用されます。その結果、編集内容を公開済みバージョンに適用し、他のユーザーと共有するためのリコンサイルおよびポスト プロセスが追加で必要になります。
マップに読み取り専用フィーチャ サービス (フィーチャ サービスで検索と同期のみが有効化されている) が含まれており、そのフィーチャ サービスにバージョン対応登録されたデータが含まれている場合、マップをダウンロードしたときにバージョンは作成されません。同様に、分散コラボレーション ワークフロー中にデータがコピーされたときに、バージョンは作成されません。クライアントは、これらの場合にフィーチャ サービスと同期すると、ソース データに対して行われた任意の編集内容にアクセスできます。
フィーチャ サービスが読み取り専用 (クエリと同期のみが有効) の場合でも、公開時にジオデータベースに接続するデータベース ユーザーは、データを編集する権限を持つ必要があります。
フィーチャ サービスの所有者または ArcGIS Server 管理者が、特定の編集可能なフィーチャ サービスに対するトラディショナル バージョンの作成方法を選択できるようにするために、以下の 2 つのオプションが提供されています。公開者は、フィーチャ サービスの公開時にこれらのオプションを設定します。
オフライン マップごとのバージョンの作成
これがデフォルトのオプションです。このオプションでは、編集可能なフィーチャ サービスを含むマップをオフラインで取得するたびに、公開済みバージョンからバージョンが生成されます。バージョン名には、以下が含まれています。
- マップをダウンロードしたユーザーの名前
- フィーチャ サービスの名前
- 一意の識別子 (ID)
これら 3 つの要素によって、バージョン名が一意であることが保証されます。たとえば、ユーザー Bob がフィーチャ サービス NetFS を含むマップをダウンロードした場合、作成されるバージョン名は Bob_NetFS_1404578882000 になります。同じユーザーがこのマップを複数回ダウンロードした場合 (たとえば、複数のデバイスからダウンロードした場合)、そのユーザーが各デバイスから同期するときに、別々のバージョンが使用されます。そのため、あるデバイスから、他のデバイスで行われた編集内容にアクセスすることはできません。ただし、新しくダウンロードされたマップは、公開済みバージョンでの最新データになります。多くのマップがダウンロードされている場合、多数のマップ バージョンが存在することになります。ダウンロードされたマップが、オフライン編集に使用されているアプリケーションから削除されると、それらのバージョンをリコンサイルしてポストし、削除することができます。
メモ:
フィーチャ サービスをポータルとフェデレートされていない ArcGIS Server サイトで公開した場合、またはサイン インしないでデータにアクセスする場合、マップ バージョン名は Esri_Anonymous_<フィーチャ サービス名>_<ID> になります。
ユーザーごとのバージョンの作成
このオプションでは、編集可能なフィーチャ サービスを含むマップをダウンロードするユーザーごとに、バージョンが生成されます。たとえば、10 名のユーザーが同じマップをダウンロードすると、10 個のバージョンが生成されます。各バージョンは個々のユーザーに固有であり、そのバージョン名はユーザー名とサービス名で構成されます (たとえば: Joe_InspectionFS)。ユーザーがマップを (たとえば、複数のデバイスから) 複数回ダウンロードした場合、そのユーザーが各デバイスから同期するときに、同じバージョンが使用されます。つまり、1 つのデバイスから、他のデバイスでの編集内容にアクセスすることができます。ただし、新しくダウンロードしたマップは、ユーザーのバージョンが最後にリコンサイルされた時点での最新データになります。ユーザーのバージョンは、ユーザーがダウンロードしたマップを保持している限り残ります。
メモ:
このオプションを使用する場合、ArcGIS Server サイトをポータルとフェデレートするか、ArcGIS Server でユーザー アカウントを構成する必要があります。これを行わないと、作成されるマップ バージョン名は Esri_Anonymous_<フィーチャ サービス名> になり、そのポータルに接続しているすべてのユーザーが同じバージョンを使用することになります。
各ユーザーのためにバージョンを作成するオプションは、ブランチ バージョン対応登録されているデータに適用されません。
例
以下のセクションでは、前の 2 つのセクションで説明したバージョンのオプションを使用したワークフローの例を示します。
- ワークフロー 1: データを保守するためのマップのダウンロード
- ワークフロー 2: 短期間のプロジェクトのためのマップのダウンロード
- ワークフロー 3: 進行中のプロジェクトのためのマップのダウンロード
以下の表で、各ワークフローの構成要素を比較します。
ワークフロー 1 | ワークフロー 2 | ワークフロー 3 | |
フィーチャ サービスが公開されるバージョン | |||
次のそれぞれについてオフライン バージョンが作成されます | ダウンロードされたマップ | ユーザー | ユーザー |
作成されるバージョンの数 | 多数 | 少数 | 少数 |
オフラインでの編集からデフォルト バージョンに対する更新までの待ち時間 | 短い | 長い (1 週間) | 長い (毎日) |
品質保証にかかわるマップ | 1 つのマップ | すべてのマップ | すべてのマップ |
オフライン バージョンが削除される頻度 | 毎日 | プロジェクトの完了時 | なし |
ワークフロー 1: データを保守するためのマップのダウンロード
このワークフローには、ArcGIS Collector を現場で使用して、描画されたマップから提供された編集内容を確認する組織のメンバーが関わります。この場合、データは従来のバージョン登録で参加するよう登録され、スタッフは、ジオデータベースのデフォルト バージョンから最新データを取得するためにダウンロードするマップを必要とします。スタッフは、事務所に戻った後に、現場で行った編集内容を同期し、マップを削除し、マップのバージョンをデフォルト ジオデータベース バージョンに対してリコンサイルおよびポストします。このプロセスを 1 日に複数回繰り返すことができます。各プロセスが完了すると、スタッフはオフライン マップのバージョンを削除します。
これを行うために、事務所のスタッフ グループのメンバーは、会社の組織アカウントで Web マップを使用できます。このグループのメンバーである作業者は、事務所で使用できるデバイスのいずれかで実行されている ArcGIS Collector を使用して Web マップにアクセスできます。作業者は、事務所を離れる前に、Collector を使用してマップをダウンロードします。その後、作業者は、現場に移動して要求された更新を検査します。現場では、Collector を使用して修正を行います。作業者は、事務所に戻ったときに、修正内容をフィーチャ サービスと同期してから、デフォルト バージョンに対してリコンサイルとポストを行います。
以下のセクションでは、次のワークフローについて説明します。
フィーチャ サービスの公開
Web マップを作成するには、はじめにフィーチャ サービスを公開する必要があります。
公開者は、ArcMap を起動し、デフォルト バージョンからマップにデータを追加します。この例では、データには、会社のエンタープライズ ジオデータベース内のフィーチャクラスから取得した新しいセンサーが含まれています。このフィーチャクラスは、バージョン対応登録されています。
公開者は、ArcMap から NetFS という名前のフィーチャ サービスを公開します。
公開者は、公開時に、[サービス エディター] で [同期] 機能を確認します。これは、このサービスがオフライン マップでの使用を目的にしているためです。公開者は、データが編集される予定であるため、[検索]、[更新]、[作成]、および [削除] の各機能についても確認します。また、公開者は、[高度な設定] をクリックして [フィーチャ サービスの高度な設定] を表示します。
[高度な設定] ダイアログ ボックスでは、[以下のそれぞれでバージョンを作成] オプションが有効化されています。この例では、公開者は [ダウンロードされたマップ] をオンにします。このオプションが設定されていると、モバイル作業者がマップをダウンロードするときに、一意の名前が付けられたバージョンがオフライン マップ用に作成されます。その後、このバージョンは作業者が同期を行うときに使用されます。
また、公開者は、自分の組織内の他のユーザーがデータにアクセスできるように、サービスを事務所の作業者グループで共有します。
Web マップの作成
フィーチャ サービスの作成後の次のステップは、Web マップを作成することです。公開者がこれを行うには、組織サイト (ArcGIS Enterprise または ArcGIS Online) にサイン インし、Web マップを作成し、フィーチャ レイヤーをマップに追加し、そのマップを事務所の作業者グループで共有します。Web マップのオフライン モード プロパティを有効に設定し、Web マップを ArcGIS Collector でオフラインで使用できるようにします。これで、事務所の作業者グループのメンバーは、このマップをダウンロードできます。
Web マップのダウンロード
Web マップが使用可能になると、作業者は、そのマップを ArcGIS Collector にダウンロードし、現場に移動して要求された更新を検査することができます。これを行うために、Bob という名前の作業者が Collector を起動し、組織サイトにサイン インします。新たに共有された Web マップが表示されます。
この Web マップは、オフライン モードが有効化されているため、ダウンロード ボタン付きで Collector に表示されます。Bob は、ダウンロード ボタンをクリックしてダウンロード プロセスを開始します。
次に Bob は、ダウンロードしたマップの範囲とベースマップの解像度を選択します。
ダウンロード プロセスの開始時に、バックエンド ジオデータベース内の公開済みバージョン (デフォルト) から、Bob_NetFS_1404578882000 という名前のバージョンが作成されます。ダウンロードされたマップごとにバージョンを作成するようにサービスが設定されているため、一意のバージョン名が生成されます。この名前は、モバイル作業者のログイン (Bob)、フィーチャ サービス名 (NetFS)、および一意の ID で構成されています。このバージョンは、ダウンロードされたマップを同期する際に使用されます。
次に、データをデバイスにダウンロードします。ダウンロードが完了すると、Collector はローカル データを参照するようにマップを切り替えます。この時点で、ネットワークに接続しなくてもマップを編集できます。Collector のマップ上に同期ボタンが表示され、マップがローカル データを参照していることを示します。
編集内容の同期
Bob は、現場にいる間、センサーのうちの 1 つが道路の誤った側に配置されていることに気付きます。Bob は、現場で Collector を使用してこれを修正します。
Bob は、その日のうちに他の場所に移動して、その他の修正を行うことができます。ネットワーク接続を使用できる場合、Bob は現場から編集内容を同期することもできます。Bob は、事務所に戻ると、自分のデバイスで社内ネットワークに接続し、最終的な同期を行います。これによって、現場で行ったすべての修正が、Bob_NetFS_1404578882000 バージョンに確実に適用されます。
これで Bob は、事務所に戻って編集内容を同期したため、Collector からローカル マップを削除し、デバイスを返却します。ローカル マップを削除するプロセスによって、Bob_NetFS_1404578882000 バージョンは、オフライン マップと関連付けられなくなります。次に、Bob は ArcMap の Bob_NetFS_1404578882000 バージョンに接続し、それをデフォルト バージョンに対してリコンサイルおよびポストします。Bob は、属性に基づく競合検出を行い、競合が検出された場合は、それらを手動で解決します。
Bob は、編集内容を保存してデフォルト バージョンに切り替えた後に、Bob_NetFS_1404578882000 バージョンを削除する必要があります。
Bob は、事務所でマップに加えた編集内容を詳細に確認した際に、もう一度現場に戻ることが必要になる場合があります。現場に戻るたびに、新たにダウンロードされたマップと新しい Bob_NetFS_<ID> バージョンが必要になります。新しい各バージョンには、デフォルト バージョンからの最新の編集内容が含まれることになります。それらのバージョンは、オフライン マップとの関連付けが解除され、リコンサイルおよびポストされるまで、ジオデータベース内に残ります。
Bob に加えて、事務所のその他の作業者も、Bob と同時に同様の作業を実施できます。
Bob は、自分の変更内容をデフォルト バージョンに対してリコンサイルおよびポストした後に、Bob_NetFS_<ID> バージョンを削除する必要があります。
ワークフロー 2: 短期間のプロジェクトのためのマップのダウンロード
この例では、モバイル作業者は、バージョン対応登録されたデータをオフラインで編集するために取得します。モバイル作業者は、その日の朝および最後に編集内容を同期します。モバイル作業者のバージョンを、他のモバイル作業者が行った編集内容を含めて最新の状態に保つために、リコンサイル プロセスとポスト プロセスが毎晩実行されます。各モバイル作業者が次の日の朝に同期を行うと、他のモバイル作業者が行った編集内容が表示されます。プロジェクトが完了した時点で、現場で行ったすべての編集内容は同期されており、プロジェクト バージョンに適用されています。その後、プロジェクト バージョンは確認され、デフォルト ジオデータベース バージョンに対してリコンサイルおよびポストされます。プロジェクトの完了時、モバイル作業者は、フィーチャ サービスとモバイル作業者のバージョンを削除します。このワークフローでは、モバイル作業者のデータの待ち時間は 1 週間以内です。
以下では、このワークフローを完了するために必要な手順について説明します。
- フィーチャ サービスの公開
- Web マップの作成
- Web マップのダウンロード
- 編集内容の同期
- ジオデータベース処理の毎晩の実行
- オフライン マップの削除および最終的なリコンサイル プロセスとポスト プロセスの実行
フィーチャ サービスの公開
この例では、プロジェクト マネージャーは、センサーの検査を行うために作業者を現場に配置する必要があります。センサーの検査は、1 年を通じて定期的に実施されます。モバイル作業者は、検査時に、センサーの損傷やアクセス性などについて確認および記録を行います。この情報は、修理計画や、簡単にアクセスできるセンサーの把握に使用されます。プロジェクトは、1 週間にわたって行われるようにスケジュールされます。データを収集するために、各モバイル作業者には、ArcGIS Collector が実行されているスマート フォンが提供されています。
このプロジェクト場合、プロジェクト マネージャーは、会社の組織アカウントでセンサーを検査するために、Web マップを作成して共有することになっています。この Web マップは、社内の ArcGIS Server で稼働しているフィーチャ サービスを参照します。
フィーチャ サービスを作成するために、プロジェクト マネージャーは ArcMap を起動し、ソース エンタープライズ ジオデータベースのデフォルト バージョンからセンサー フィーチャクラスを追加します。このフィーチャクラスは、バージョン対応登録されています。検査対象としてフラグが付けられたセンサーは、黄色で表示されます。
プロジェクト マネージャーは、作業を整理するために Inspection という名前のバージョンを作成し、このバージョンを参照するようにマップを変更します。
次に、プロジェクト マネージャーは ArcMap から InspectionFS フィーチャ サービスを公開します。
プロジェクト マネージャーは、[サービス エディター] で [同期] 機能を確認します。これは、このサービスがオフライン マップで使用されるためです。また、プロジェクト マネージャーは、[高度な設定] をクリックして [フィーチャ サービスの高度な設定] を表示します。
プロジェクト マネージャーは、[フィーチャ サービスの高度な設定] で [ユーザーごとのバージョンの作成] オプションを選択します。このオプションを指定すると、モバイル作業者がマップを最初にダウンロードしたときに、ArcGIS がそのモバイル作業者用のバージョンを作成します。このバージョンは作業者が編集内容を同期するときに使用されます。
Web マップの作成
フィーチャ サービスの公開が完了すると、プロジェクト マネージャーは ArcGIS Enterprise ポータルで Web マップを作成し、そのマップをすべてのモバイル作業者がメンバーになっているグループで共有します。
プロジェクト マネージャーは以下の手順を実行します。
- 組織サイトにサイン インします。
- Web マップを作成します。
- 先ほど公開した ArcGIS Server のフィーチャ サービスを追加します。
- Web マップを保存します。
- Web マップとフィーチャ サービスを、モバイル作業者が含まれるグループで共有します。
- Web マップでオフライン モード プロパティを有効化し、Web マップを ArcGIS Collector でオフラインで使用できるようにします。
Web マップのダウンロード
各モバイル作業者は、ArcGIS Collector を使用して自分のアカウントにログインし、Web マップにアクセスします。
Web マップが使用できる状態で、各モバイル作業者は Collector を起動し、組織サイトにサイン インします。新たに共有された Web マップが表示されます。
この Web マップは、オフライン モードが有効化されているため、ダウンロード ボタン (矢印付きの雲) 付きで Collector に表示されます。モバイル作業者のうちの 1 人 (Joe) がダウンロード ボタンをクリックして、ダウンロード プロセスを開始します。
Joe は、自分のマップの範囲およびベースマップの解像度を選択します。
ダウンロード プロセスの開始時に、ソース ジオデータベース内の公開済みバージョンから、Joe_InspectionFS という名前のバージョンが作成されます。ユーザーごとにバージョンを作成するようにフィーチャ サービスが設定されているため、このバージョン名は、モバイル作業者のログイン (Joe) およびバージョンが作成されたサービスの名前 (InspectionFS) に基づきます。このバージョンは、ダウンロードされたマップを同期する際に使用されます。
メモ:
Joe が InspectionFS サービスからマップをダウンローする際に、必ず Joe_InspectionFS バージョンが参照されます。たとえば、ある時点でローカル マップを削除し、範囲を広げてローカル マップを再作成することが必要になる場合があります。その後、Joe がマップを再びダウンロードすると、以前に Joe_InspectionFS バージョンから同期したすべての編集内容が表示されます。
マップとデータがダウンロードされると、Collector は、ローカル データを参照するようにマップを切り替えます。この時点で、Joe はネットワークに接続しなくてもマップを編集できます。Collector のマップ上に [同期] ボタンが表示され、マップがローカル データを参照していることを示します。
2 番目のモバイル作業者 (Mary) は、Joe と同じ手順を実行します。その結果、Mary_InspectionFS バージョンがソース ジオデータベースに作成されます。
編集内容の同期
Joe は、現場にいる間、マップの東側での作業を割り当てられています。Joe は、センサーの検査が完了すると、センサー フィーチャのステータスを適切に設定します。センサーが検査に合格した場合、そのセンサーは緑で表示されます。センサーが損傷していて修理が必要な場合、そのセンサーは赤で表示されます。
Joe は、その日の終了時にネットワークに接続できたときに、Collector で [同期] ボタンをクリックします。これによって、編集内容がソース ジオデータベース内の Joe_InspectionFS バージョンに適用されます。
Mary も、その日の終了時に、マップの西側での自分センサーの検査結果を同期します。
ジオデータベース処理の毎晩の実行
夜間に自動プロセスが実行されて、モバイル作業者が行った編集内容がリコンサイルおよびポストされます。このプロセスでは、Inspection バージョンに対して、はじめに各バージョンがリコンサイルされ、次にポストされます。このプロセスは、競合ポリシーを適用します。このポリシーでは、最後の編集内容が維持され、競合の検出は属性に基づきます。
現場で行ったすべての編集内容が Inspection バージョンに適用されると、そのデータに対して整合チェック スクリプトが実行されます。これらのスクリプトは、無効な値や境界外のフィーチャを含む編集内容を検索し、修正します。たとえば、ステータス フィールドには、有効なステータス値が格納されている必要があります。値が無効な場合、その値は検査が必要な状態に戻され、黄色い点でシンボル表示されます。整合チェックが完了すると、モバイル作業者のバージョンは Inspection バージョンに対してリコンサイルされ、各バージョンが最新の変更内容を保持していることが確認されます。
翌朝、Joe と Mary が同期すると、お互いの更新内容が表示されます。
メモ:
毎晩のプロセスによって、デフォルト バージョンとのリコンサイルを行い、プロジェクトの開始以降、デフォルト バージョンに対して行われた編集内容を取り込むこともできます。あるいは、プロジェクト マネージャーは、プロジェクトの終了時にのみデフォルト バージョンとのリコンサイルを行うようにすることもできます。その場合、デフォルト バージョンにポストする前に競合を検出し、手動で確認することができます。プロジェクトが終了する前にこのプロセスを実行した場合、作業者は、それらのフィーチャに対してさらに編集を行うことができます。それらの編集内容は、最終的なリコンサイル プロセスで競合として表示されません。
また、この例では、モバイル作業者が行った編集内容をリコンサイルおよびポストする自動プロセスは、毎晩実行されます。つまり、モバイル作業者が行った最新の編集内容は、翌日になるまで他のモバイル作業者には表示されません。この待ち時間を減らすために、プロセスをさらに頻繁に実行することができます。たとえば、プロセスを 1 時間ごとに実行した場合、モバイル作業者は、正時に同期を行って、他のモバイル作業者が行った最新の編集内容を取得することができます。
ダウンロードしたマップの削除および最終的なリコンサイル プロセスとポスト プロセスの実行
前述のプロセスは、プロジェクトの 1 週間の期間を通じて、継続されます。すべてのセンサーの検査が終了すると、プロジェクトは完了します。モバイル作業者は、プロジェクトの終了時に、最後の編集内容を同期し、ArcGIS Collector からローカル マップを削除するように求められます。ローカル マップが Collector から削除されると、モバイル作業者のバージョンはダウンロードされたマップに関連付けられなくなります。次に、プロジェクト マネージャーが、フィーチャ サービスを停止し、削除します。
プロジェクト マネージャーは、すべてのモバイル作業者のバージョンに対して、最終的なリコンサイルとポスト プロセスを実行し、それぞれのバージョンを削除します。その後、プロジェクト マネージャーは、Inspection バージョンをデフォルト バージョンに対してリコンサイルおよびポストします。プロジェクト マネージャーは、このプロセスで、競合の確認と解決を手動で行います。これが完了すると、すべての作業者は、センサーの最新の検査情報をデフォルト バージョンで利用できるようになります。最後のステップは、プロジェクト マネージャーが Inspection バージョンを削除することです。
ワークフロー 3: 進行中のプロジェクトのためのマップのダウンロード
このワークフロー例は、モバイル作業者がオフラインで行った編集内容を同期するという点で、前述のワークフロー (「短期間のプロジェクトのためのマップのダウンロード」) に似ています。モバイル作業者は、その日の朝および最後にネットワークに接続して同期を行います。ただし、このワークフローではプロジェクトが進行中であるため、フィーチャ サービスは、デフォルト バージョンから直接公開されるのではなく、品質保証バージョンから公開されます。つまり、追加の確認、リコンサイル プロセス、およびポスト プロセスが必要になります。
以下では、このワークフローを完了するために必要な手順について説明します。
フィーチャ サービスの公開
このプロジェクト場合、プロジェクト マネージャーは、会社の組織アカウントでセンサーを検査するために、Web マップを作成して共有することになっています。この Web マップは、社内の ArcGIS Server で稼働しているフィーチャ サービスを参照します。
フィーチャ サービスを作成するために、プロジェクト マネージャーは ArcMap を起動し、ソース エンタープライズ ジオデータベースのデフォルト バージョンからセンサー フィーチャクラスを追加します。このフィーチャクラスは、バージョン対応登録されています。検査対象としてフラグが付けられたセンサーは、黄色で表示されます。
プロジェクト マネージャーは、作業を整理するために Inspection という名前のバージョンを作成し、このバージョンを参照するようにマップを変更します。
次に、プロジェクト マネージャーは ArcMap から InspectionFS フィーチャ サービスを公開します。
プロジェクト マネージャーは、[サービス エディター] で [同期] 機能を確認します。これは、このサービスがオフライン マップでの使用を目的にしているためです。また、プロジェクト マネージャーは、[高度な設定] をクリックして [フィーチャ サービスの高度な設定] を表示します。
プロジェクト マネージャーは、[フィーチャ サービスの高度な設定] で [ユーザーごとのバージョンの作成] オプションを選択します。このオプションを指定すると、モバイル作業者がマップを最初にダウンロードしたときに、そのモバイル作業者用のバージョンが作成されます。その後、このバージョンは作業者が編集内容を同期するときに使用されます。
Web マップの作成
フィーチャ サービスの公開が完了すると、プロジェクト マネージャーは ArcGIS Enterprise ポータルで Web マップを作成し、そのマップをすべてのモバイル作業者がメンバーになっているグループで共有します。
プロジェクト マネージャーは以下の手順を実行します。
- 組織サイトにサイン インします。
- Web マップを作成します。
- 先ほど公開した ArcGIS Server のフィーチャ サービスを追加します。
- Web マップを保存します。
- Web マップとフィーチャ サービスを、モバイル作業者が含まれるグループで共有します。
- Web マップでオフライン モード プロパティを有効化し、Web マップを ArcGIS Collector でオフラインで使用できるようにします。
Web マップのダウンロード
各モバイル作業者は、ArcGIS Collector を使用して自分のアカウントにログインし、Web マップにアクセスします。
Web マップが使用できる状態で、各モバイル作業者は Collector を起動し、組織サイトにサイン インします。新たに共有された Web マップが表示されます。
この Web マップは、オフライン モードが有効化されているため、ダウンロード ボタン (矢印付きの雲) 付きで Collector に表示されます。モバイル作業者のうちの 1 人 (Joe) がダウンロード ボタンをクリックして、ダウンロード プロセスを開始します。
Joe は、自分のマップの範囲およびベースマップの解像度を選択します。
ダウンロード プロセスの開始時に、ArcGIS がソース ジオデータベース内の公開済みバージョンから、Joe_InspectionFS というバージョンを作成します。ユーザーごとにバージョンを作成するようにフィーチャ サービスが設定されているため、このバージョン名は、モバイル作業者のログイン (Joe) およびバージョンが作成されたサービスの名前 (InspectionFS) に基づきます。このバージョンは、マップを同期する際に使用されます。
メモ:
Joe が InspectionFS サービスからマップをダウンローする際に、必ず Joe_InspectionFS バージョンが参照されます。たとえば、ある時点でローカル マップを削除し、範囲を広げてローカル マップを再作成することが必要になる場合があります。その後、Joe がマップを再びダウンロードすると、以前に Joe_InspectionFS バージョンから同期したすべての編集内容が表示されます。
データとマップがダウンロードされると、Collector は、ローカル データを参照するようにマップを切り替えます。この時点で、Joe はネットワークに接続しなくてもマップを編集できます。Collector のマップ上に [同期] ボタンが表示され、マップがローカル データを参照していることを示します。
2 番目のモバイル作業者 (Mary) は、Joe と同じ手順を実行します。その結果、Mary_InspectionFS バージョンがソース ジオデータベースに作成されます。
Mary と Joe が現場で編集を行う間に、事務所の作業者によって新しいセンサーがデフォルト ジオデータベース バージョンに追加されます。この新しいセンサーは、エリア内で発生した新しいプロジェクトの結果です。新しいセンサーが設置された場合、検査が必要であるため、そのセンサーは黄色で表示されます。
編集内容の同期
Joe は、現場にいる間、マップの東側での作業を割り当てられています。Joe は、センサーの検査が完了すると、センサー フィーチャのステータスを適切に設定します。センサーが検査に合格した場合、そのセンサーは緑で表示されます。センサーが損傷していて修理が必要な場合、そのセンサーは赤で表示されます。
Joe は、その日の終了時に接続できたときに、Collector で [同期] ボタンをクリックします。これによって、編集内容がソース ジオデータベース内の Joe_InspectionFS バージョンに適用されます。
Mary も、その日の終了時に、マップの西側での自分センサーの検査結果を同期します。
ジオデータベース処理の毎晩の実行
夜間に自動プロセスが実行されて、モバイル作業者が行った編集内容がリコンサイルおよびポストされます。これらのプロセスでは、Inspection バージョンに対して、はじめに各モバイル作業者のバージョンがリコンサイルされ、次にポストされます。このプロセスは、競合ポリシーを適用します。このポリシーでは、最後の編集内容が維持され、競合の検出は属性に基づきます。
現場で行ったすべての編集内容が Inspection バージョンに適用されると、Inspection バージョンのデータに対して整合チェック スクリプトが実行されます。これらのスクリプトは、無効な値や境界外のフィーチャを含む編集内容を検索し、修正します。
メモ:
プロセスのこの時点で、Mary_InspectionFS バージョンには Joe の編集内容が含まれていますが、Joe_InspectionFS バージョンには Mary の編集内容が含まれていません。これは、Joe_InspectionFS バージョンがリコンサイルおよびポストされてから、Mary_InspectionFS バージョンがリコンサイルおよびポストされるためです。
自動プロセスの次のステップは、デフォルト バージョンに対して Inspection バージョンをリコンサイルおよびポストすることです。プロセスでは、属性に基づく競合検出が使用され、自動的に競合が解決されます。リコンサイル プロセスによってデフォルト バージョンの編集内容 (新しいセンサー) が Inspection バージョンに適用され、ポスト プロセスによって Inspection バージョンの編集内容 (Joe と Mary の編集内容) がデフォルト バージョンに適用されます。
各モバイル作業者のバージョンがもう一度 Inspection バージョンとリコンサイルされて、自動プロセスが終了します。これで、各モバイル作業者のバージョンは最新に更新されました。
ヒント:
最新の変更内容をモバイル作業者のバージョンに適用するには、リコンサイル プロセスが必要ですが、ポスト プロセスは必要ありません。組織によっては、プロジェクトの外部のユーザーに編集内容を利用できるようにするために、別のプロセスを実行して編集内容をデフォルト バージョンにポストする場合があります。
Joe と Mary が翌日の朝に同期すると、他のモバイル作業者によって更新されたセンサーと、デフォルト バージョンから取得した新しいセンサーが表示されます。新しいセンサーがマップの東側にあるため、Joe がその新しいセンサーを検査し、検査結果を同期することになります。翌日、夜間プロセスが実行された後に、新しいセンサーに関する Joe の検査情報がデフォルト バージョンに登録されます。
このプロセスは、毎日継続的に繰り返されます。Joe_InspectionFS バージョンと Mary_InspectionFS バージョンは、Joe と Mary がセンサーの検査を続行している間、残ります。Joe と Mary がある時点でプロジェクトの作業を終了した場合、最終的な同期が完了し、ローカル マップの登録が解除され、Joe_InspectionFS バージョンと Mary_InspectionFS バージョンに対する最終的なリコンサイル プロセスおよびポスト プロセスが完了すれば、それらのバージョンを削除することができます。