<\/HEAD>「計画を立てなければ、失敗を計画しているのと同じだ。」この古い格言は幅広く適用できます——10ポンド減量したいとき、リーダーシップのポジションに選ばれたいとき、完璧な仕事を得たいときなど、あらゆる場面でそうです。だから、人生の他のすべてのことと同様に、GIS分析に関しても計画が成果をもたらします。信頼できる結果を確実にするために、私たちがお勧めする確かなプロセスは次の通りです:
- 質問を定義する。<\/LI>
- データを探索し準備する。<\/LI>
- 分析方法とツールを選択する。<\/LI>
- 分析を実行する。<\/LI>
- 結果を検証し洗練する。<\/LI><\/OL>
ステップ2はおそらく最も重要です。なぜなら最終結果は、開始時のデータの信頼性に依存するからです。分析プロジェクトのためのデータ探索と準備について詳しく見ていきましょう。データの探索<\/SPAN><\/STRONG>
ステップ2の最初の部分は分析質問から直接導かれます。質問に答えるために必要なすべてのデータ（属性も含む）を事前に特定する時間をかけてください。プロジェクトの途中で重要なデータセットが欠けていることに気づくことがないようにしましょう。
データ探索の目的は、そのデータで何が有効にできるかを理解することです。以下を行うべきです:メタデータを調べる。空間解像度と精度、座標系、データ収集日時および収集者、データ使用制約など重要な情報を確認してください。<\/LI>ArcMapで使用予定のすべての空間データセットを探索する。レイヤーは正しく整列していますか？一部のレイヤーは他より一般化されていますか？必要以上に大きい（または小さい）範囲のレイヤーはありますか？<\/LI>各レイヤーの属性テーブルを調べ、レコード数と属性を確認する。フィールドを並べ替え、フィールド統計を見て値を理解する。明らかなデータ入力ミスや不整合にも注意してください。<\/LI><\/UL>データの準備<\/SPAN><\/STRONG>
データ準備とは、複数のデータセットが有効に一緒に分析できるようにし、処理時間を可能な限り短縮することです。データ準備作業には、多くの場合、投影変換、関心領域への空間範囲縮小、不必要な属性削除、新しい属性作成、属性値のクリーンアップなどが含まれます。
ArcGISジオプロセシングツールを最大限活用しましょう。多くはバッチモードで実行可能で、一部には複数のデータ準備作業を組み合わせるオプションがあります。例えばFeature Class to Feature Class tool<\/A>では、関心領域内にある特徴のみインポートするSQL式を作成でき、不必要なソース属性を除外し、必要な新しい属性フィールドも定義できます。一つのツールで三つの準備ステップが達成されます。
またモデルを作成してデータ準備作業を自動化できます——必要なジオプロセシングツールをモデルウィンドウにドラッグしパラメーターを設定します。モデル作成は作業内容と順序を視覚化しながら進める優れた方法です。
同じデータが複数分析で使われることがあります。特定プロジェクト用に変更する前に元データのコピーを作成しておくことが良い習慣です。このようにして元データは後続分析用に保存され、不測の場合にも戻れるものがあります。例：海賊事件の分析<\/SPAN><\/STRONG>
簡単な例でデータ探索と準備の重要性を示しましょう。分析質問は次のように定義されています:2009年から2011年までの間に、アデン湾およびアラビア海周辺で最も頻繁に海賊被害に遭った船舶タイプは何か？<\/LI><\/UL>
米国国家地理空間情報局（NGA）はAnti-Shipping Activity Messages<\/A>(ASAM)報告書を配布しており、これは世界中で船舶や船員への敵対行為の位置と説明が含まれています。NGAウェブサイトからASAMデータ（シェープファイル形式）をダウンロードできます。データ探索<\/SPAN><\/STRONG>
ASAMシェープファイルをダウンロード後ArcMapへ追加します。地理的文脈としてベースマップも追加すると便利です。この場合ArcGIS Online の World Topographic Map <\/A>が適しています。
右側地図グラフィックはASAMデータ全体範囲（赤点で表現）を示しています。属性テーブル簡単探索では6,158件記録があり、世界サブリージョンコード格納属性と各事件発生日付格納属性があり、その日付範囲は1978年5月1日から2012年1月9日までです。 
分析質問に効率的に答えるには2009年1月1日から2011年12月31日までサブリージョン62内で発生した事件だけに絞り込む必要があります（NGAサイトにはサブリージョンコード一覧があります）。またこのデータには他にも解決すべき問題があります。問題1：空間参照情報がない。 <\/STRONG>
ASAMシェープファイル追加時、「空間参照情報がありません」というメッセージが表示されました。シェープファイルでは空間参照情報は投影(.PRJ)ファイルに保存されますが、この場合PRJファイルが欠落していることは珍しくありません。それではどの座標系を使うべきでしょうか？
まずLayer Propertiesダイアログボックスを見ると良いでしょう。[Source]タブで範囲座標を見ると、小数点左側桁数から地理座標系だとわかります。 
地理座標系の場合、LeftおよびRight範囲値は小数点左側1〜3桁、TopおよびBottom範囲値は小数点左側1〜2桁になります。ヒント:<\/EM> 不明座標系特定方法についてはArcGISで座標系操作 ウェブコースをご覧ください。 このデータは全世界範囲なのでWGS 1984地理座標系割当てが妥当です。ただし精密測定が必要なら関心領域用適切な投影座標系も割り当てます。問題2：必要以上に広範囲。ASAMデータは空間的にも時間的にも必要以上に広範囲です。この問題はSQLクエリで解決します。この分析で初期準備作業は:1. プロジェクト用ファイルジオデータベース作成.2. ASAMシェープファイルファイルジオデータベースへインポート.
- サブリージョン62内かつ2009年1月1日〜2011年12月31日の特徴のみインポート.<\/LI>
3. ジオデータベースフィーチャクラスへWGS 1984座標系割当. 右側モデル図はジオプロセシングワークフロー示しています。Feature Class to Feature Classツールダイアログ内でSQL式定義済みなので条件満たす事件のみインポートされます.
モデル実行後、新しいフィーチャクラスには643件特徴があります。このサイズなら管理しやすいため次ステップ3へ進む前に全643件が分析期間内海賊事件か検証してください.ASAMでは2つの日付情報フィールド(Reference と DateOfOcc)があります。DateOfOcc はmm/dd/yyyy形式ですがReference は年＋ユニークID番号です。このReference フィールドはFeature Class to Feature ClassダイアログSQL式で便宜上使われましたが今後クリーンアップが必要です。DateOfOcc フィールド並べ替えでは4件記録がReference に2009年（報告提出年）ありますがDateOfOcc 値では実際には2008年最終週発生となっています。この4件は削除可能です。その後解析対象レコード数は639件となります.問題3：属性値不整合.次にあなたは すべてのレコードが海賊行為の事例であるとは限りません。Aggressorフィールドにはこの情報が格納されています。Aggressorフィールドをソートすると、複数の値が表示され、その大部分は「pirate」の何らかのバリエーションを含んでいます。
- ヒント: Aggressorの値の変化を素早く視覚的に理解する方法は、レイヤープロパティダイアログボックスを開き、Aggressorフィールドに基づいてUnique Valuesでレイヤーをシンボル化することです。各ユニークなaggressor値が表示され、Countフィールドはそれぞれの数を教えてくれます。
Aggressorの値を調査した後、「pirate」のバリエーションのいずれかをAggressorフィールドに持つすべてのレコードを選択する属性クエリを作成し、その後選択を切り替えて、海賊攻撃者を直接参照していないレコードがいくつあるかを確認できます。この場合、Aggressor値が海賊を参照していない事件は16件だけです。これら16件のうちどれが海賊による攻撃である可能性があるかを判断するために、事件の説明を調査する必要があります。明らかに海賊攻撃者が関与していない場合はレコードを削除します。この場合、事件の説明では海賊攻撃者を明確に否定していないため、曖昧さを考慮してレコードを保持し分類することにします。Field Calculatorを使用してこれら16件のAggressor値をPossible Piratesに変更し、残りのレコードはすべてAggressor値をPiratesに統一します。問題4: テーブルに重複レコードがあります。DateOfOccフィールドでソートすると、Referenceフィールドを見ると驚くべきことがわかります。同じReference値で他の属性フィールドも同一の重複レコードが多数存在するようです。これはどういうことでしょう？シェープファイルからジオデータベースフィーチャクラスに変換した際に何か問題があったのでしょうか？ この時点で元データに戻り、重複が元々存在していたかどうか確認する必要があります。シェープファイル内の特徴数が多いため、Referenceフィールドを集計してユニークなReference値ごとのカウントテーブルを出力する方法が効率的です。集計テーブル作成後、Count_Referenceフィールドでソートすると、多くのReference番号に重複があることがわかります。正確な数を知るためにCount_Reference値が2のレコードを選択します。元データには493件のReference番号に重複があります。これら493件のうちジオデータベースフィーチャクラス内にいくつあるかはさらに調査が必要です。シェープファイルと同様に、「Incidents to Analyze」レイヤーでReferenceフィールドを集計し、Count_Reference値が2のレコードを選択します。結果として170件のレコードに重複があります。170件もの重複レコードを簡単に削除する方法はありますか？はい、比較的簡単です。手順は以下の通りです:
- Reference値の集計テーブルを「Incidents to Analyze」テーブルに結合します。
- Count_Reference値が2のレコードを選択します—予想通り340件選択されます。
- 編集セッションを開始し、Delete Identicalツール を使用して、同じReference値を持つ重複レコード（もう一方と同じもの）を削除します（Delete Identicalツール実行前にテーブル結合は解除してください—結合解除後も選択状態は維持されます）。
最終結果：GIS分析プロセスのステップ3への入力として使用可能な469件の事件データとなりました。このようなデータ探索と準備には実際には数時間程度しか集中作業は必要ありませんでした。当然ながら事件被害者値もクリーンアップが必要な可能性があります—しかしGIS分析プロセスのステップ2と3間には明確な境界線はなく、この例ではここで終了します。まとめ: 分析用データ準備では意思決定とある程度の不確実性と共存しなければなりません。具体的な分析基準やトピックへの理解度によってどこまでデータクリーンアップするか決まります。誤り作成や拡散防止には慎重なデータ探索と準備内容および理由の文書化が重要です。またモデルはワークフロー記録や他者への分析結果理解支援に有用なツールです。GIS分析プロジェクトで使用するデータは完璧ではなく、ニーズに完全には合致しない場合もあります。しかし計画と準備によって信頼できる結果生成につながり、自信を持って他者と共有できます。GIS分析ベストプラクティスについてもっと学びたいですか？以下のコースがお役に立ちます。
