フィールド データ収集のための効果的なデータ モデルの設計

地理情報システム（GIS）マップは、操作レイヤとベースマップ レイヤで構成されます。操作レイヤは、フィーチャの編集と識別に使用されます。ベースマップ レイヤは、視覚的な背景の参照情報を提供します。たとえば、ある区画に新しく配置された送水バルブの XY 位置と属性の収集に関係するフィールド プロジェクトには、送水バルブ操作レイヤが含まれます。このレイヤは、現場で編集されます。フィールド作業員を支援するために、個々の送水管の識別に使用される送水管操作レイヤを含めることもできます。これらの操作レイヤの下に、この操作領域上の航空画像を含むベースマップ レイヤを含めて、対象となる道路、公園などの背景地点を示すことをお勧めします。

フィールド プロジェクトの場合、マップをできるだけ単純に保つようにしてください。不要なレイヤや、ArcGIS for Desktop による高度な動作は避けてください。モバイル デバイスの制約と、モバイル マップが使用される現場の条件を考慮してください。

ジオデータベースのサポート

ArcGIS for Windows Mobile は、ファイルベースのジオデータベース内とマルチユーザ ArcSDE ジオデータベース内でのデータ編集をサポートしています。モバイル マップにはデータ ソースを参照するレイヤを追加できますが、新しいフィーチャを取得したり、既存のフィーチャを更新したりする場合は、レイヤのデータ ソースはジオデータベースに格納されたフィーチャクラスでなければなりません。ファイルベースのジオデータベースのワークフローは、デスクトップ操作が中心となります。このワークフローでは、モバイル ジオプロセシング ツールと Mobile Project Center を活用して、プロジェクトを作成し、現場での編集データを親ジオデータベースと同期させます。マルチユーザ ジオデータベースでは、同様にジオプロセシング ツールを使用できますが、ArcGIS Server を使用して、モバイル サービスを作成することもできます。このモバイルサービスは、Mobile Project Center 内でプロジェクトの作成に使用できます。これによって現場のユーザは、接続された環境にいるときに、データセットの変更をサーバからダウンロードしたり、サーバにアップロードしたりできます。

操作レイヤでの、ArcGIS for Windows Mobile のフィーチャクラスの要件を次に示します。

• ファイルベースのデータベース内またはマルチユーザ データベース（ArcSDE）内への格納。
• フィーチャクラスには、SQL の予約語をフィールド名として使用することはできません。

操作マップ レイヤのデータ スキーマと目的

操作マップ レイヤのスキーマを設計する場合、マップ レイヤごとに目的を検討し、レイヤのスキーマ要件を考慮します。マップ レイヤ フィールドのプロパティを考慮する必要もあります。

操作マップ レイヤのためのデータ スキーマ要件

操作レイヤに対して指定できる目的を、次のリストで説明します。マップ レイヤは、次のいずれかの目的でのみ使用できます。

• データの収集 - データ収集レイヤには、GlobalID フィールドを含める必要があります。さらに、ファイル ジオデータベース内に存在する操作レイヤを編集可能にするには、[モバイル キャッシュの作成（Create Mobile Cache）] ツールを使用して、レイヤを含むマップからモバイル キャッシュを作成する必要があります。レイヤが ArcSDE ジオデータベースに存在する場合も、[モバイル キャッシュの作成（Create Mobile Cache）] ツールを使用してモバイル キャッシュを作成するか、マップをモバイル サービスとして ArcGIS for Server 10.1 で公開することができます（この場合、サーバにデータベースを登録する必要があります）。
• 読み取り専用参照情報の提供 - 読み取り専用レイヤのスキーマについては、制約はありません。
• 現在のユーザの識別 - ID レイヤは、次の 2 つのテキスト フィールドを含むポイント レイヤである必要があります。1 つは、ユーザ ID を格納するテキスト フィールド、もう 1 つはユーザ表示名を格納するテキスト フィールドです。フィールド作業員がこのレイヤを編集しない場合、GlobalID は不要です。このレイヤを、ArcGIS for Server でホストするか、[モバイル キャッシュの作成（Create Mobile Cache）] ツールを使用してキャッシュを作成できます。
• ログ レイヤ - ログ レイヤは、GlobalID フィールド、日付/時刻フィールド、およびコンピュータ名のテキスト フィールド（あるいは、ID レイヤが存在する場合は ID 情報）を含むポイント レイヤである必要があります。このレイヤを、ArcGIS for Server でホストするか、[モバイル キャッシュの作成（Create Mobile Cache）] ツールを使用してキャッシュを作成できます。
• フィールド作業員レイヤ - ログ レイヤと同様に、フィールド作業員レイヤは、GlobalID フィールド、日付/時刻フィールド、およびコンピュータ名（または ID 情報）のテキスト フィールドを含むポイント レイヤである必要があります。このレイヤは、フィールド作業員全員の最新の既知の位置を同期して定期的に更新されます。そのため、このレイヤのデータは、ローカル モバイル キャッシュからではなく、モバイル サービスから取得する必要があります。
• ユーザに表示しない - 非表示レイヤのスキーマについては、制限はありません。

レイヤの目的の詳細については、「操作レイヤのプロパティ」をご参照ください。

マップ レイヤ フィールドとフィールド プロパティ

ArcGIS for Windows Mobile アプリケーションでサポートされるジオデータベースの動作を、次に示します。

• サブタイプ - 1 つのフィーチャクラスに格納されたフィーチャを分類するために使用されます。たとえば、樹木フィーチャを樹木の種類別に分類できます。フィールド作業員は、現場で新しい樹木フィーチャを作成するときに、樹木の種類を選択して作成できます。これによって、個別の属性として種類を入力する必要がなくなります。
• ドメイン - コード値ドメインと範囲ドメインの両方がサポートされます。コード値ドメインは、属性値を収集または更新するときに、選択リストとして表示されます。デフォルト値は、アスタリスク（*）で示されます。デフォルト値が指定されていない場合、有効な値を入力するよう求められます。範囲ドメインは、数値属性として入力できる有効な値の範囲を示します。
• デフォルト値 - 属性フィールドにデフォルト値が割り当てられている場合、その属性フィールドには、値を入力する必要がありません。たとえば、樹高の属性フィールドのデフォルト値として 10 を設定できます。新しい樹木フィーチャの高さの値には、自動的に 10 が割り当てられます。樹木の高さが 10 よりも低いか高い場合は、該当する高さを入力できます。フィーチャクラスの任意の属性フィールドに、デフォルト値を割り当てることができます。
• 添付ファイル - フィーチャクラスに添付ファイルを格納できるようにすると、フィーチャに関連する情報を管理することができます。現場で添付ファイルを使用するには、ジオデータベースのフィーチャクラスに添付ファイルを追加しておく必要があります。添付ファイルの一般的な用途は、フィーチャのデジタル写真の格納です。1 つのフィーチャに対して複数の添付ファイルを収集し、表示できます。
• ラスタ/BLOB - ラスタ/BLOB タイプのフィールドは、写真の格納に使用できる特殊なフィールド タイプとして認識されます。写真を選択してラスタ フィールドに追加するか、モバイル デバイスに組み込まれたカメラを直接使用することができます。ただし、それぞれのフィーチャには、ラスタ/BLOB フィールドごとに 1 つの画像のみを設定できます。
  注意:

  BLOB フィールドを使用して画像を格納するには、フィールド名に esri_picture を使用するか、picture_ という接頭辞を付加する必要があります。たとえば、esri_picture、picture_WaterValve などを使用できます。

• 日付 - 属性フィールドのデータ タイプを日付に設定することによって、属性フィールドに日付を格納できます。このフィールドには、属性フィールドを編集するときにポップアップ表示されるカレンダーから選択して編集する際に、現在の日付と時刻を設定できます。
• 電話番号 - テキスト フィールドを使用して電話番号を格納し、セルラー チップを内蔵した Windows Mobile デバイスで認識されるように電話番号のフォーマットを適切に設定した場合は、ArcGIS アプリケーション内から直接電話を起動して番号を発信することができます。

注意:

Z 値や M 値に対応したフィーチャクラスは編集可能ですが、Z 値と M 値は保存されません。新しく収集したフィーチャでは、Z 値と M 値は設定されません。

ArcGIS for Windows Mobile では、新しいマップ レイヤを作成したり、モバイル デバイス上で属性フィールドのスキーマを変更したりすることはできません。現在のデータ モデル内に存在しないフィーチャを取得する必要があると見込まれる場合、または構造化されていない情報（フィールド メモなど）を取り込む必要がある場合は、ジオデータベース スキーマ内にこの情報の格納を処理するための追加のフィーチャクラスを作成することをお勧めします。

ジオデータベース設計の考慮事項

ArcGIS for Windows Mobile フィールド アプリケーションと SDK では、ジオデータベースに構築した情報と、ArcMap でのコンテンツの表示方法の両方を、最大限に活用します。

フィールド プロジェクトで使用する既存のマルチユーザ ジオデータベースが存在する場合、次のいずれかを実行できます。

• ジオデータベース レプリケーションを使用して、既存の構造を利用します。
• 抽出、変換、および読み込み（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）など）によっては、安定した高速接続を確保するために、アプリケーションとデバイスがオフィスに戻った時点でのみフィーチャをポストできるようにする必要があります。