フィールド データ収集のための効果的なデータ モデルの設計
地理情報システム（GIS）マップは、操作レイヤとベースマップ レイヤで構成されます。操作レイヤは、フィーチャの編集と識別に使用されます。ベースマップ レイヤは、視覚的な背景の参照情報を提供します。たとえば、ある区画に新しく配置された送水バルブの XY 位置と属性の収集に関係するフィールド プロジェクトには、送水バルブ操作レイヤが含まれます。このレイヤは、現場で編集されます。フィールド スタッフを支援するために、個々の送水管の識別に使用される送水管操作レイヤを含めることもできます。これらの操作レイヤの下に、この操作領域上の航空画像を含むベースマップ レイヤを含めて、対象となる道路、公園などの背景地点を示すことをお勧めします。
フィールド プロジェクトの場合、マップをできるだけ単純に保つようにしてください。不要なレイヤやその他高度な ArcGIS for Desktop の動作は避けます。モバイル デバイスの制約と、モバイル マップが使用される現場の条件を考慮してください。
ジオデータベースのサポート
[モバイル キャッシュの作成（Create Mobile Cache）] ツールで作成されるモバイル キャッシュとモバイル サービスに対して、ArcGIS for Windows Mobile は、ファイルベースのジオデータベース内とマルチユーザ ArcSDE ジオデータベース内でのデータ編集をサポートしています。モバイル マップには、他のデータ ソースを参照するレイヤを含めることができますが、レイヤを編集可能にするには、そのデータ ソースが少なくともジオデータベース内に格納されたフィーチャクラスである必要があります。編集可能なレイヤの要件については、後述の「操作マップ レイヤのためのデータ スキーマ要件」をご参照ください。
注意:また、フィーチャクラスには、SQL の予約語をフィールド名として使用することはできないので注意してください。
ホストされたフィーチャ サービスは、データ ソースに対する要件という点で、モバイル サービスほど制約はありません。データは、ファイルベースのジオデータベース、ArcSDE ジオデータベース、CSV、またはシェープ ファイルから取得できます。これらのソースから取得したデータは、ホストされたフィーチャ サービスとして公開した場合、フィールド アプリケーションで編集することができます。ただし、ホストされたフィーチャ サービスとしてデータが公開された場合、そのデータは ArcGIS Online for Organizations または Portal for ArcGIS のオンライン ストレージにコピーされるため、フィールド作業員が行った編集はソース データベースではなく、オンライン ストレージに反映されます。
操作マップ レイヤのデータ スキーマと目的
操作マップ レイヤのスキーマを設計する場合、マップ レイヤごとに目的を検討し、レイヤのスキーマ要件を考慮します。マップ レイヤ フィールドのプロパティを考慮する必要もあります。
操作マップ レイヤのためのデータ スキーマ要件
操作レイヤに対して指定できる目的を、次のリストで説明します。マップ レイヤは、次のいずれかの目的でのみ使用できます。
- データの収集 - モバイル サービスの場合、使用されるデータ リポジトリのタイプは、フィールド作業員のデータの収集方法に影響を与える場合があります。ファイル ジオデータベースからのデータを ArcGIS Server でホストすると、そのデータは GlobalID を追加していても読み取り専用になります。この場合でも、[モバイル キャッシュの作成（Create Mobile Cache）] ツールを使用してモバイル キャッシュを作成し、そのキャッシュをデータ収集用のプロジェクトに追加することができます。ただし、ArcSDE データベースからのデータも、公開前にサーバで登録していない場合は、読み取り専用になります。ただし、これらの制限は、フィーチャ サービスには適用されません。つまり、データは GlobalID がなかったり、ファイル ジオデータベースに格納されていたりしても、編集可能です。
- 読み取り専用参照情報の提供 - 読み取り専用レイヤのスキーマについては、制約はありません。
- 現在のユーザの識別 - ID レイヤは、次の 2 つのテキスト フィールドを含むポイント レイヤである必要があります。1 つは、ユーザ ID を格納するテキスト フィールド、もう 1 つはユーザ表示名を格納するテキスト フィールドです。フィールド スタッフがこのレイヤを編集しない場合、GlobalID は不要です。レイヤを編集する場合、それをモバイル サービスとして ArcGIS Server でホストしたり、フィーチャ サービスとして ArcGIS Online for Organizations または Portal for ArcGIS でホストしたり、あるいは [モバイル キャッシュの作成（Create Mobile Cache）] ツールを使用してキャッシュを構築したりできます。
- ログ レイヤ - ログ レイヤは、編集可能なポイント レイヤである必要があります。これは、日付/時刻フィールド、コンピュータ名のテキスト フィールド（あるいは、ID レイヤが存在する場合は ID 情報）を持つ必要があります。このレイヤは、モバイル サービスとして ArcGIS Server でホストしたり、フィーチャ サービスとして ArcGIS Online for Organizations または Portal for ArcGIS でホストしたり、あるいは [モバイル キャッシュの作成（Create Mobile Cache）] ツールを使用してキャッシュを構築したりできます。
- フィールド作業員レイヤ - ログ レイヤと同様に、フィールド作業員レイヤは、編集可能なポイント レイヤである必要があります。これは、日付/時刻フィールド、コンピュータ名（または ID 情報）のテキスト フィールドを持つ必要があります。このレイヤは、フィールド スタッフ全員の最新の既知の位置を同期して定期的に更新されます。そのため、このレイヤのデータは、ローカル モバイル キャッシュからではなく、モバイル サービス/フィーチャ サービスから取得する必要があります。
- ユーザに表示しない - 非表示レイヤのスキーマについては、制限はありません。
マップ レイヤ フィールドとフィールド プロパティ
ArcGIS for Windows Mobile アプリケーションでサポートされるジオデータベースの動作を次に示します。
- サブタイプ - 1 つのフィーチャクラスに格納されたフィーチャを分類するために使用されます。たとえば、樹木フィーチャを樹木の種類別に分類できます。フィールド スタッフは、現場で新しい樹木フィーチャを作成するときに、樹木の種類を選択して作成できます。これによって、個別の属性として種類を入力する必要がなくなります。
- ドメイン - コード値ドメインと範囲ドメインの両方がサポートされます。コード値ドメインは、属性値を収集または更新するときに、選択リストとして表示されます。範囲ドメインは、数値属性や日付属性として入力できる有効な値の範囲を示します。
- デフォルト値 - 属性フィールドにデフォルト値が割り当てられている場合、フィールド アプリケーションによって、そのフィールドにデフォルト値が自動的に入力されます。たとえば、樹木の高さ属性フィールドのデフォルト値として 10 を設定できます。新しい樹木フィーチャの高さの値には、自動的に 10 が割り当てられます。樹木の高さが 10 よりも低いか高い場合は、フィールド作業員が高さフィールドを更新できます。フィーチャクラスの任意の属性フィールドに、デフォルト値を割り当てることができます。
- 添付ファイル - フィーチャクラスに添付ファイルを格納できるようにすると、フィーチャに関連する情報を管理することができます。現場で添付ファイルを使用するには、ジオデータベースのフィーチャクラスに添付ファイルを追加しておく必要があります。添付ファイルの一般的な用途は、フィーチャのデジタル写真の格納です。1 つのフィーチャに対して複数の添付ファイルを収集し、表示できます。
- ラスタ/BLOB（ホストされたフィーチャ サービスではサポートされません） - ラスタ/BLOB タイプのフィールドは、写真の格納に使用できる特殊なフィールド タイプとして認識されます。写真を選択してラスタ フィールドに追加するか、モバイル デバイスに組み込まれたカメラを直接使用することができます。ただし、それぞれのフィーチャには、ラスタ/BLOB フィールドごとに 1 つの画像のみを設定できます。
注意:BLOB フィールドを使用して画像を格納するには、フィールド名に esri_picture を使用するか、picture_ という接頭辞を付加する必要があります。たとえば、esri_picture、picture_WaterValve などを使用できます。
- 日付 - 属性フィールドは日付値を格納できます。フィールド作業員は現場で、ポップアップ表示されるカレンダーから選択して、日付/時刻を編集できます。
- 電話番号 - テキスト フィールドを使用して電話番号を格納し、セルラー チップを内蔵した Windows Mobile デバイスで認識されるように電話番号のフォーマットを（XXX）XXX-XXXX に設定した場合は、ArcGIS アプリケーション内から直接電話を起動して番号を発信することができます。
注意:Z 値や M 値に対応したフィーチャクラスは編集可能ですが、Z 値と M 値は保存されません。新しく収集したフィーチャでは、Z 値と M 値は設定されません。
ArcGIS for Windows Mobile では、新しいマップ レイヤを作成したり、モバイル デバイス上で属性フィールドのスキーマを変更したりすることはできません。現在のデータ モデル内に存在しないフィーチャを取得する必要があると見込まれる場合、または構造化されていない情報（フィールド メモなど）を取り込む必要がある場合は、ジオデータベース スキーマ内にこの情報の格納を処理するための追加のフィーチャクラスを作成することをお勧めします。
ジオデータベース設計の考慮事項
注意:マップをフィーチャ サービスとして公開する予定の場合は、このセクションの残りはスキップできます。
フィールド プロジェクトで使用する既存のマルチユーザ ジオデータベースが存在する場合、次のいずれかを実行します。
- ジオデータベース レプリケーションを使用して、既存の構造を利用します。
- 抽出、変換、および読み込み（ETL）プロセスを使用して、ジオデータベースを変換します。
次のセクションでは、既存のジオデータベースを使用してフィールド編集アプリケーションを管理するための、ジオデータベース レプリケーション モデルと ETL モデルについて説明します。
ジオデータベース レプリケーション モデル
現場で使用するマルチユーザ ジオデータベースのコンテンツを公開し、バージョニングを使用して、現場からの編集データと、オフィスで作成された他の編集データを区別することができます。ただし、この方法には多数の課題が伴います。たとえば、現場からの更新を同期する必要がある場合は、ジオデータベースに会社のファイアウォールの外からアクセス可能にする必要があります。大部分の組織では、これは不可能です。より適切なアプローチとして、ジオデータベース レプリケーションを使用して、現場で収集された情報とオフィスで継続的に更新される情報を区別する方法があります。
ジオデータベース レプリケーションを使用して、現場で作成された編集データを格納し、更新を親ジオデータベースと定期的に同期するための、別のエンタープライズ ジオデータベースを作成することができます。この方法では、（ジオデータベース全体の情報ではなく）現場に携帯する必要のある情報を複製するだけでよく、モバイル Web サービスとマスタ ジオデータベースを分離することができます。レプリケーションが役立つ状況の例としては、フィールド スタッフがリモート オフィスにいて、メイン オフィスに接続しない分散システムや、車載ラップトップに複製されたジオデータベースが格納されていて、デバイスが車に装着されたときに現場での編集データが同期される状況が挙げられます。どちらの場合も、エンタープライズ ジオデータベースに属さないフィールド編集タスクごとに、メタデータを格納できます（たとえば、収集データの補正に必要となる GPS（全地球測位システム）の計測データ）。
ETL モデル
ほとんどの場合、エンタープライズ ジオデータベースで空間情報を表す方法は、それを現場で作成して更新する方法とは異なります。湖ポリゴンを湖岸ライン フィーチャとしてモデリングして個別に捕捉できるようにする方法は、その一例です。他には、エンタープライズ ジオデータベースに格納されている正規化されたデータ テーブルまたは属性フィールドを結合し、現場のジオデータベース内の 1 つのテーブルまたは属性にする方法があります。別の良い例としては、道路属性情報があります。多くの場合、正式な道路名は複数の属性に格納されます（番号、接頭辞、名前、接尾辞など）。ArcMap では、条件式を使用して完全な道路名をラベリングします。道路名をモバイル デバイスに表示するには、それらの属性を 1 つのフィールドにまとめ、ラベリングできるようにします。
ジオプロセシング モデルを、モバイル ジオデータベースとエンタープライズ ジオデータベースの間での ETL プロセスの管理に使用できます。また、ArcGIS Data Interoperability エクステンションを使用して、これらの変換プロセスを視覚的に設計することもできます。ここで定義するプロセスが双方向ではない場合があることに注意してください。データ モデルをモバイル デバイスに変換するための 1 セットのジオプロセシング モデルまたはカスタム空間 ETL ツールを定義し、エンタープライズ スキーマに合わせて現場のデータを再構築するための 2 セット目のモデルを定義します。
モバイル トランザクション モデル
フィールド更新の管理およびジオデータベースとの更新の統合をどのように計画するかは、トランザクション モデルによって具体化されます。その一部は、ジオデータベース設計の決定によって定義されますが、サポートする必要があるフィールド作業員の数とそれらの編集データを区別する方法によっても定義されます。
トランザクション モデルの考慮事項の一部を次に示します。
- 現場での編集データによって、ジオデータベースのデフォルト バージョンを更新する必要があるか。その必要がない場合、現場でのすべての編集データを 1 つのバージョンにまとめるか、それともフィールド作業員ごとにバージョンを定義するか。
- バージョニングを使用せずにジオデータベースを更新することは可能か。
- 現場で作成された編集データの履歴を管理する必要はあるか。
- 現場での更新データの間で生じる競合をどのように管理するか。
次のセクションでは、現場で使用するジオデータベースを設計するときに検討する必要のある、重要な機能の一部を示します。
バージョン非対応のジオデータベースの編集
簡単な編集タスク（属性の更新など）を実行するフィールド作業員が数名いるだけで、現場で同じフィーチャが更新される可能性がほとんどない場合には、バージョン非対応のトランザクション モデルで要件を適切に満たすことができます。この方法には、フィールド作業員に対する選択肢が直接更新だけである、という欠点があります。何らかの理由で更新データを同期する必要があるが、それらが不完全である、という場合、同期は問題になりかねません。バージョニングを使用する場合は、フィールド スタッフが更新データを同期する方法をより柔軟に制御できます。
バージョン対応のトランザクション モデルを使用して、現場の編集データを区別し、更新をリコンサイルする前に、追加の後処理と品質管理を提供することができます。現場の編集データをどのように区別するかによって、すべての編集データを格納するバージョンを 1 つ作成するか、フィールド作業員ごとにバージョンを作成することができます。フィールド作業員ごとにバージョンを作成する場合は、フィールド作業員ごとにサービスを公開する必要があります。フィールド スタッフがデータの取得や保存を完了し、更新データをジオデータベースに同期させた後、オフィスでバージョンへの編集データを親バージョンとリコンサイルするためには、ArcGIS for Desktop が必要です。
ArcGIS for Windows Mobile クライアントの編集フレームワーク
ArcGIS for Windows Mobile アプリケーションには、他の ArcGIS アプリケーションのように編集を開始および停止し、編集データを保存する概念はありません。作成された各編集データは、更新データをサーバと同期する時間になるまで、デバイスのモバイル キャッシュ内に格納されます。アプリケーション内で実行した編集をキャンセルすることができます。これにより、現場で更新したすべてのデータがロールバックされ、編集前の元のフィーチャの状態が復元されますが、フィーチャに行った編集内容を 1 つずつ元に戻すことはできません。
フィーチャ レイヤを更新しても、変更データはジオデータベースに直接同期されません。
変更のポスト
現場で更新したデータは、モバイル デバイスのモバイル サービス キャッシュのローカルに格納されます。フィールド スタッフが非接続環境で常時作業する場合や、デバイスをシャットダウンして充電する必要がある場合があるため、この処理は重要です。また、更新データが失われないことも重要です。サーバへの接続が確立されたときに、キャッシュに格納された更新データをバックエンド データベースに同期させることができます。
モバイル デバイスから変更をポストすると、変更（「差分」とも呼ばれます）のみがサーバに送信されます。たとえば、フィーチャの属性を変更する場合は、行全体が編集済みとしてマークされるのではなく、特定のフィールドへの変更だけが記録されます。これにより、変更データを同期する際には、実際に変更された情報だけがサーバに送信されます。
予想される編集データの数と、使用するデータ接続の種類（GPRS（General Packet Radio Service）など）によっては、安定した高速接続を確保するために、アプリケーションとデバイスがオフィスに戻った時点でのみフィーチャをポストできるようにする必要があります。