データ解析にはいる前の仕事

気象データの場合を例に

1998年、東京都立大学 理学部 地理学科の卒論生・大学院生向けのゼミの教材 として作ったメモです。 話すための補助のメモなのでことばの説明はじゅうぶんではありません。 また、それ以後、内容の改訂はしていません。

地理情報学からみたデータの構造(2次元の範囲で)

• ラスター(グリッド)データ (空間を座標値で等間隔にくぎり、それぞれの格子に数値がおかれる)
• 広い意味のベクターデータ
  • 点データ
  • 線データ(線分、折れ線) [気象関係では少ない]
  • 多角形(polygon)領域データ [気象関係では少ない]

対象とデータの型との関係の傾向

• 空間に連続分布する数量の近似表現...ラスターデータ
• 空間に分布するが、番号(名義尺度)でしか表現できないような定性的な対象 ...多角形データ

気象の場合の利用側からみたデータの編集段階

Global Atmospheric Research Programでの用語

• Level 1: 生データ (機器からの信号)
• Level 2: 変数と形式が標準化された観測点データ (気象電報など)
• Level 3: 数値予報の初期値として使えるような格子点データ

気象データの場合のデータの型の傾向

• 多くの観測は国際的約束で時刻をそろえて観測されている。 データのまとめかたは、
  • 地点別の時系列
  • 時刻をそろえた広域分布
  の両方の形がある。
• 数値モデルが発達しており、そのために作られた (多くの場合、数値モデルによる予報値を混ぜた)格子点データが作られている。 (水平2次元 × 鉛直 × 時間の2,3,4次元配列型データ)
• 衛星観測値(sounding: 温度などの数値)は位置・時刻がまちまちである。
• 衛星画像は緯度経度座標に幾何変換した格子点データとして使うことが多い。

データのerror

• 誤差
  機器の精度、観測者の個人差、地点の代表性
• まちがい
  機器の故障、記録の失敗、伝達経路での雑音、編集のプログラムや操作の失敗

データをみるうえで重要なこと

• まちがいを検出するための全数検査
  • [ ヒントはTukeyの探索型データ解析(exploratory data analysis) ]
  • グラフ化: 人間の目と計算機の処理速度の組み合わせ
  • 度数分布とrobust(じょうぶ)な統計量: 中央値、四分位幅など
• 大量処理もできるような、データの流れを重視した処理の流れの組み立て
  • データの量(バイト数、レコード数)を見て、 データ処理にかかる時間を見積もる。 ためしに読んでみながら見積もりを修正する。
  • Unixの標準入出力を活用。 ためしの段階では目でみて、大量処理ではバックグラウンドにまわせる ようにする。

コンピュータ側(OSレベル)からみたデータの形式

• テキストデータ
  • 印刷できる文字、空白文字、改行コードだけからなるファイル。 適当な字数で改行があるのがふつう。
  • テキストファイルの形式はOSの系列ごとに違う。 Unix, DOS, MacOS では改行コードが違う。 大型計算機では文字コードがASCIIでなくEBCDICのことが多い。 よその機種でのテキストファイルはバイナリファイルとして扱わなければ ならないことがある。(ftpでテキストファイル用の指定をすれば転送に伴って 自動変換されるのが原則だが、うまくいかないこともある。)
  • 文字コード別にみると(大型計算機関係は省略)
    • 7ビットASCIIのみ
    • 8ビットLatin1
    • 2バイト漢字かな と ASCII(またはJISローマ字) [JIS, SJIS, EUC]
    • 1バイトカタカナ と ASCII(またはJISローマ字)
    • その他、外国語
    ASCIIだけならばほとんどのソフトウェアで処理できるが、日本語文字がまじった 場合は日本語対応のプログラムが必要なことがある。また、Latin1が含まれている 場合、日本語対応のプログラムでは正しくない動作をすることがある。
• バイナリデータ
  • [原則としては、テキストデータ以外すべて]
  • Fortran順アクセス書式なし
    機種やコンパイラに依存する形式。 ただし、Unix上のFortranのほとんどでは、 バイト順(big-endian, little-endian)の違いを除いて共通。 1回のwriteで書かれた記録の長さが最初(および最後)にはいっていて、 それに続いて中身がある。
  • 裸の固定長バイナリデータ (行末に改行コードなし)
    Unix上のFortranのほとんどでは、 「直接アクセス書式なし」で読み書きすればよい。 (IBM系の旧大型機のFortranでは順アクセスA書式)
  • 固定長でないもの
    Fortranで読むことはむずかしい。 Unix上の場合、レコード長1バイトの固定長データとして読むことは 可能(能率は非常に悪いが)。

表(テーブル)形式

• 形式
  • 各行がひとつのレコード
  • 各列がひとつの項目
  • レコードの順序には本質的に意味がない
  • 列の順序には意味がある
• コンピュータ上での実現形式
  • 空白区切り: awk, sort, gnuplot, GMTなどでの処理に便利
  • コンマ区切り: 表計算やデータベースソフトウェアでの読み書きに便利
  • 固定長テキスト(改行コードあり): Fortranでの読み書きに便利
  • relational型データベースソフトウェアのデータ構造 (内部表現は非公開であったり、複雑なことが多い。 入出力は上のどれかで行なうことが多い。)

データのチェックに適したデータ形式

• 観測点データの場合: 表形式のテキストファイルに変換し [わたしの場合たいていはFortranプログラムを書く]、 必要に応じてawkなどで処理して、 gnuplot, GMTなどで作図する。
  (手入力に表計算ソフトウェアを使った場合は、 そのグラフ機能を使うこともある。)
• 格子点データの場合: 単純なバイナリデータだけのファイルを作り、 GrADS (気象データに特化), IDRISI, GRASSなどのソフトウェアで見る。 (識別情報はバイナリデータファイル自体ではなく別ファイルにもつことに なるので、散逸に注意!)

欠損値 (欠測)の扱い

• データファイル上で見られる状況
  • 記録そのものが欠けている
  • 特定の数値がはいっている (ドキュメントしてあるはずだが、ときにそれが まちがっていることもある。また浮動小数点数での換算誤差に注意。)
  • バイナリデータの場合、「数値でない」ビットパタン(NaN)がはいっている。
  • テキストデータの場合、数字でないものがはいっている。 (たとえば、Fortranのけたあふれの結果、"*"ばかりになっていることがある。)
• 処理上の注意
  • 特定の数値で表現されている場合、グラフのスケーリングを決める際に その数値を無視するように指定する。
  • gnuplot, GMTは欠損を特定の数値で表現する方法を知らないので (GMTはNaNならば認識するが), あらかじめawkなどで除いておく必要がある。
  • 時系列をグラフで表示したとき、欠損がどこにあるか見えにくい、 または欠損の前後で有効な数値まで見えなくなることがあるので 注意する (必要なら別に欠損の印を表示する)

以下は、データを正しく解釈するために注意したほうがいい点

• 大きなまちがいは、地理的分布の想像のつく変数を表示してみればすぐわかる。
• 格子点間隔や時間ステップの1つぶんあるいは半分だけずれている場合は、 慎重に調べないとわからない。

時刻の扱い

• どこの時刻なのか
  • 世界時(UTC), グリニッジ時(GMT), 「Z」(予報現業の符丁)
  • 地方標準時(LST), 日本では日本標準時(JST)
  • 夏時間
  • 地方時(local time)
• 日集計している場合、どの時刻までか、前日としているか当日としているか

緯度経度の扱い

• 単位
  • 度(,度の小数)
  • 度、分(,分の小数)
  • 度、分、秒
  • ラジアン
• 符号
  • 北緯、東経を正 (日本の場合ほとんどこれだが、外国では必ずしもそうでない)
• 経度の範囲
  • 0 -- 360
  • -180 -- 180
• 緯度と経度とどちらを先にするか
• 格子点をならべる順序。とくに南北は北からと南からと両方ある
• 格子点データの場合、「のりしろ」として両側に同じ値を入れておくかどうか

数量の次元と単位

• 総量なのか、時間あたり/面積あたり/体積あたりの量なのか、 もともと強さの変数(intensive variable: たとえば温度)なのか
• 水の密度 1 g / cm³ が隠れていないか
• 重力加速度, 水の蒸発熱, 空気の比熱などは定数とみなしているか (自分で換算したときはどうしたか忘れないように記録を残すこと)
• 1か月の日数はまじめに計算しているか、一定としているか (2月はどうか)

[地理情報学教材の目次へ]