増田 耕一
次の形で出版されたものです。 参考文献として使う場合は、次の出版物のほうをあげてください。
高阪宏行・村山祐司編 (2001): 「GIS--地理学への貢献」, 古今書院, p. 39 -- 57.
思想としての地理情報システムとは、データを地図上に可視化することと、 データを体系的に保管し再利用可能にしておくこととを 有機的に結合することであろう。 気候学にとってもこのような技術が重要であることは明らかであり、 むしろ、それぞれの機能に関して、先進的な立場に立ってきたのである。
しかし、現在GISソフトウェアと呼ばれるものは、 気候学の需要には断片的にしかこたえていないと思う。 当面、気候の解析では、GISソフトウェアよりも、 数量データの可視化に特化したソフトウェアを使うことが主流となりつづけるだろう。 将来、気候情報を本格的に他の地理情報と統合するために、 時空間4次元の大量データを自在に扱えるGISソフトウェアが 開発されることを期待したい。
人類の居住や産業の立地は、いくらかは直接的に、むしろおもに植物・動物の 生育条件をとおして、気候の制約をうけている。 気候を定義することはむずかしいが、 気候を考えるうえで、 気温、気圧、風速などの大気の物理量(気象変数)を 1か月程度以上の時間スケールで統計して 得られた数値が重要であることはまちがいない。 (人間個人を、身長、体重、年令などの数値で記述しきれるものではないが、 人を同定するのにこれらの数値が有意義であることと似ている。) ここで使われる統計値は、単純な平均ばかりでなく、最高・最低のような極値が 問題になることもあるし、 複数の変数の(それぞれ1日以下の時間間隔での値の)積の 時間平均が必要になることもある。 現代の気候学は、このように毎日の気象データを扱うものなので、 気象学との間には、重点のおきかたの違いはあるものの、明確な境目はない。 ここで筆者が論じる「気候学」には、筆者から見れば気候学に含まれるが、 当事者は「気象学」あるいは「大気科学」に属すると考えていた要素も 含んでいることをおことわりしておく。
近代科学は、 法則の候補となる仮説をたてて因果関係を説明しようとする演繹的アプローチと、 事実を集めてその中から法則の候補となる規則性を見つけようとする帰納的 アプローチの両方で成り立っている。 ただし、その重みづけは学問分科ごとにちがっている。 演繹を重視する分科を物理科学、帰納を重視する分科を博物学と 呼ぶこともできるだろう。 地理学は博物学的傾向の強い分科であるが、 その中で気候学は、初期から、物理科学で使われるのと同じ、 温度、圧力、速度などの変数を使ってきた (Fleming 1998; Nebeker 1995)。
ただし、物理量による気象観測が系統的に行われるようになったのは、 最近百数十年にすぎない。 46億年の地球の歴史はもちろん、人類の歴史に比べても非常に短い期間である。 気象観測のない時代の気候についての議論(古気候学)は、 化石などの定性的な情報に頼らなければならず、 現代の気候を扱う場合(狭い意味の気候学)と方法論が違ってくる (坂元・増田 1999)。 ここでは、おもに気象観測データにもとづく気候学について述べ、 古気候学の特徴はVII節で簡単にふれることにする。
地理情報システムという用語は、 本来、地理的情報を要素として構築したシステム、 あるいは、地理的情報とそれを操作する技術を組み合わせたシステムを さすものだろう。 地理情報システムを構築するとは、地理的情報を、 ある体系のもとに編纂することである。 ただし、編纂されたものが固定した形であるだけでなく、 それを使って人間がものを考え、判断をすることを助けるような形にしておきたい。 そのなかで、まず、別々の源から得られた情報を組み合わせて操作できるような 形にデータを整理する、いわゆるデータベース技術が重要になってくる。 また、当然ながら、情報をたくわえている機械とそれを使う人間との間で、 情報をやりとりすることが必要である。 特に、空間パターンを認識する人間の能力は、まだなかなか機械でおきかえることが できないものである。 したがって、人間がパターン認識をしやすい形まで機械で情報を処理して表示する 可視化技術も重要である。 地理的情報の場合には、人間は地図を読むというパターン認識の経験をもっている ので、可視化技術の中では情報を地図の形に表現することが大きな位置を 占めている。 しかし、可視化は必ずしも地図の形に限られるものではない。
GISは地理情報システムの略だから、同じ意味に使われていいはずだが、 GISというときはむしろ、地理情報システムを構築する技術、あるいはそれを 実現する具体的ソフトウェア製品をさすことが多い。 それは、データベース技術と可視化(地図化)技術を結びつけたものだと 言ってもよいだろう。
気候学は、なかみとしての地理情報システムにはいちはやく取り組んだ分野 である。 しかし、いれものとしてのGISには縁が薄い。 この事情を、次にもう少し詳しく述べていきたい。
気候学で使われる観測データは、 研究者による観測で得られたものもあるとはいえ、 基本となる部分は、日本でいえば気象庁などの気象現業機関の 天気予報や防災を目的とする観測で得られたものである。
各国の気象現業機関は、相互に、観測後なるべく早く(リアルタイムに)、 データを通報している。 1880年ごろから国際気象機関(IMO)、今では世界気象機関(WMO)が、 この通報のしくみの調整や標準化を行なっている。 その結果、たとえば、 日本の気象庁には、直接に国交のない北朝鮮の観測値も 中国経由で届いている。
各国の観測データをいっしょにして予報のための天気図を作るためには、 次のような標準化が重要な役割を果たした。 気候学が気象現業機関の観測データをそのまま使うことができるのも、 こういった標準化のメリットだということができるだろう。
気象観測のデータが、気候の研究に使われるようになるのには、 データを提供することを職務とするデータセンターが大きな役割を果たした。
そのなかに、世界データセンター(WDC)というしくみがある。 これは、1957--58年に行なわれた国際地球観測年(IGY)のために 国際学術会議連合(ICSU)の公認で作られたものだが、その後も常設の形で 続けられている。 1970年代に行なわれた全球大気研究計画(GARP)の強化観測の データも、基本的にこのしくみを通じて世界の研究者に提供された。 WDCは独立の国際組織ではなく、いくつかの国の機関が自発的にWDCの業務を 兼ねることによって実現されている。 WDC-Aはアメリカ合衆国の機関が担当しており、そのうち気象関係は 海洋大気庁(NOAA)のNational Climatic Data Center (NCDC)が担当している。 WDC-Bはソ連(現在はロシア)、-C1はヨーロッパ諸国、-C2は日本が 担当している(ただしWDC-C2の気象データ部門はない)。
アメリカの連邦政府データセンター群は、 WDCの機能のほか、本来の業務としても、多くの研究者への データ提供を行なっている。 その背景には、連邦政府が得た情報は国民のものであり、 (軍事機密やプライバシーなどの例外はあるが) 政府は国民にそれを提供する義務があるという アメリカの政府観があるように思われる。 なお、アメリカのデータセンターのデータ提供は (最近のインターネット経由での提供を除いて)有料の場合が多いが、 それは手数料であり、テープなどの記録媒体のコストや、 直接データを複製するのに必要な計算機利用のコストに相当するものである。 データセンターがデータを得るまでの観測や編集のコストはもちろん、 データセンター職員の人件費も、 利用者の負担になっていないのがふつうである。 日本の多くの政府機関との違いは、 研究者へのデータ提供が業務として位置づけられていることと、 少額の現金を現場で受け取る体制ができていることである。
WDC-Aではないが、アメリカの気象関係のデータセンターとしてもうひとつ 重要なものとして、National Center for Atmospheric Research (NCAR)のData Support Sectionがある。 NCARはアメリカの大学(私立や州立)が連合で設立した法人UCARが、 政府から国立科学基金(NSF)経由で予算をもらって運営している 共同利用研究所である。 NCAR Data Support Sectionは、 海軍気象部と共同で南半球の気候格子点データを作成した (Jenne et al. 1973)のをはじめとして、 多くの研究者の需要にこたえて積極的にデータを集め、提供した (Jenne 1975)。 その中で、計算機間のデータ交換の互換性の問題点と対策も整理した (Jenne and Joseph 1974)。
1985年ごろから、地球規模環境変化(アメリカではglobal changeといわれることが 多い)が社会的問題として認識されるようになった。 このためのデータ整備をどうするかについて、アメリカでは省庁横断的な 討論が行われた(Unninayar and Ruttenberg 1990)。 そこでは、データセンター間で目録情報を共通化すること、 従来の専門分科外の人にも理解できるようにドキュメントを充実させること、 データを長期保存すること、 データ利用者からデータ作成者へのフィードバックを促進すること、などの 提言が行われた。 その後の発展は、このときの議論の線に沿っているように思われる。
第二次大戦直後、最初の電子計算機と言われるENIACを使った研究の中に、 数値天気予報の基礎研究があった(Nebeker 1995など参照)。 アメリカでは1955年から(実験的ではあったが)毎日の数値予報が始められた。 今では、数値予報は、約1週間先までの天気予報では最大の情報源であり、 季節予報にも重要な参考情報として使われるようになってきている。
数値予報では、地球をなんらかの座標で等間隔の格子に区切って、 その格子点での変数を扱うのがふつうである (他の表現もあるが、その場合も格子点表現が併用される)。 予報モデルの結果は格子点値として得られるし、 予報計算に必要な初期値や境界条件は、あらかじめ格子点値として作って おかなければならない。 初期値は観測値を空間内挿することによって作られるが、観測のないところは それ以前からの予報結果で補う。予報値の精度が高まってくると、観測が ある場合でも、予報値にも一定の重みづけをして併用するようになった。 予報モデルを時間方向の外挿の手段として使うと考えてもよい。
予報の初期値のために作られた格子点データは、 予報モデルに依存する要素を含んでいることが欠点ではあるが、 領域全体を均一に覆う気象変数の場の量が得られるため、 特にエネルギー収支や水収支に注目した気候の研究には たいへん有効だった(増田 1989参照)。
予報用の格子点データの欠点として、 リアルタイムで届かなかったデータは使われないことと、 予報モデルの改訂の影響を受けるため経年変化があまり論じられないことが あるが、 これらを克服するために、 過去にさかのぼって一定の予報モデルを使った「再解析」も行われている。
温帯の天気の変化が低気圧という構造によって起こることは、 天気図、つまり気圧の等値線を主として風や天気の情報を重ねた主題図を 作ることによってわかってきた。 さらに、定性的ではあったが雲の高さが報告されていたので、 断面図を作ることによって、寒冷前線や温暖前線の鉛直構造が わかってきた。 ラジオゾンデなどの高層観測が行われるようになると、 気圧あるいは温位を鉛直座標にとった定量的な断面図が作られ、 低気圧に伴う空気の動きが詳しく表現されるようになってきた(斎藤 1982)。
数値予報の結果は、空間分布をもつ格子点データとして得られるので、 これを天気図と比較できるような形で見ることが必要になる。 1970年代まで計算機のおもな出力装置であったラインプリンタで、 数値の分布に従って印字する文字を変えたり、空白で残したりすることに よって、疑似的に等値線のように見える表示をすることがさかんに行われた。 新田ほか(1972, 付録10.1)のプログラム例に名前が出てくる FortranサブルーチンCONTMAはその一例である。 1970年代にはペンを動かす方式のXYプロッタはあり、 それ用のFortranサブルーチンライブラリも整備されていたが、 速度や信頼度の点で、現業的に大量の図を出すのには適さなかった。 1980年ごろから、ラスター型のプリンタが導入され、 XYプロッタ用と同じ形式のFortranサブルーチンを呼べば、 線画がラスターに変換されて出力されるようなソフトウェアも導入された。 これで、天気図などの分布図の作図の機械化は急激に進んだ。
アメリカのNCARは、1970年代に、 データの可視化技術についても先駆的役割を果たした。 NCAR Graphicsとして知られるFortranサブルーチンライブラリ (McArthur 1981)の整備である。 これは線画の基本ルーチンと、それを呼び出す応用ルーチンからなっている。
System Plot Package (S.P.P.)と呼ばれていた基本ルーチンは、 長さを画面の大きさに対する相対的な比率として指定するようになっていた。 当時、プロッタルーチンは紙の上の長さ(アメリカではインチ、 日本ではcm)を、画面向け出力ルーチンは画面上の画素数を直接指定するように なっていたのに対して、S.P.P.では装置が違っても同じプログラムで作図 できるように考えられていた。 さらに、のち広くwindow-viewport変換と呼ばれるようになった、 「ユーザーは長さを表現対象に適したスケールで指定し、 作図時に画面上の大きさに換算する」という機能を早く取り入れていた。 また、S.P.P.自体は、図形情報を出力装置に依存しないmetacodeという形式で ファイルに書き出し、 別のプログラムでmetacodeを読んで出力装置に作図するように作られていた。 このような構成がとられたのには、次のような理由がある。 NCARは気象・気候関係の全国共同利用計算機センターの役割をしていたので、 遠隔地からの利用が多かった。 当時、遠隔端末との間でやりとりできるのは文字だけであり、 作図結果はマイクロフィッシュで郵送するのがふつうだった。 Metacodeはもともとマイクロフィッシュ出力装置用のファイル形式であり、 そこでは紙や画面の上での大きさは意味をもたなかったのである。
応用ルーチンのおもな機能は、 等値線やベクトル場の矢印表示など、数量の分布の作図である。 等値線などを地図に重ねることができるが、その場合、 ユーザーがソースプログラムを部分的に変更する必要があった。
1985年までのNCAR Graphicsはpublic domainソフトウェアであり、 ソースプログラムが無料あるいは手数料だけで広く配布されていた。 東京大学では、中村 一氏(現在、気象庁気象研究所)が1981年に NCARからプログラムを持ち帰り、 萬納寺信崇氏(現在、気象庁)と増田が加わって、 東大大型計算機センターの大型計算機に移植した。 これは計算機センターのプログラムライブラリ「NCARG」として公開されている (増田・中村・万納寺 1990)。 この版では、metacodeを作成する代わりに、 プロッタルーチンを呼び出すことにより作図を実現した。 また、等値線を地図に重ねる機能を東大での需要に応じて実装した。
1986年以後のNCAR Graphicsについてはあとの項目(VI-3)で述べる。
気候学で使われるデータの大部分は、実数値をとり、 しかも、空間と時間の座標の連続関数であると想定できるものである。 また、その水平方向の空間構造は、 不規則に分布する地点に値があるもの(以下、観測点データと呼ぶ)か、 なんらかの地理座標系で等間隔の2次元格子点またはマス目に値があるもの (格子点データと呼ぶ)がほとんどである。 地図上の折れ線あるいは多角形内部に対応して値があるようなデータは少ない。 したがって、いわゆるベクター型GISを使うメリットはない。 (ただし、気候学の課題でも、流域や植生を扱うことはあるので、その部分では 有効なこともある)。
格子点データの構造はラスター型GISには適しているはずだが、 気候学では、たくさんの時点のデータを同時に扱う必要がある。 特に、気候をメカニズムに立ち入って考えるために 気象現象の構造を観察しようとすれば、 風速が10 m / s程度であることから、 空間スケール1000 kmのスケールに対しては毎日、 100 kmのスケールに対しては毎時のデータを見る必要が生じる。 しかも、単独の事例研究でなく、帰納的議論をしようとすれば、 1000個のオーダーの時間断面を同じ統計処理にかけられる状態に準備しておきたい。
具体例をあげると、気象庁で作られ気象業務支援センターから有料配布されている レーダーアメダス解析雨量というラスターデータは、約5 km間隔の緯度経度格子の 毎時の降水量を含んでいる。4年分が圧縮して1枚のCD-ROMにおさめられているが、 画素数が東西352、南北444であるのに対して、時刻の個数は35064である。
気候学では、このように大量のデータを短時間で見たい、また統計処理もしたい という需要があるために、 多機能で複雑なGISの入出力機能よりも、 あとで述べるGrADSに代表されるように、 ディスクのファイル上の位置がデータの時空間座標から 簡単に計算できるようにしておき、直接読み出す方式が好まれる。 現在の多くのGISでは(あとで述べるGMTでも同様だが)、 データを2次元空間に分布する変数のレイヤーとして持っており、 それを組み合わせて演算するが、 これでは気候データの解析で必要になる時間軸上の統計処理を 効率よく行うことはむずかしいだろう。
もちろん、たとえば月平均平年値が有効な課題であれば、 各変数について12枚のレイヤーがあればよいので、 現行のラスター型GISが活躍できる局面である。 実際、アメリカのNOAAのNational Geophysical Data Centerで編集された Global Ecosystems DatabaseというCD-ROMは、 植生などとともに気候データもラスター型で収録しているが、その形式は GRASS (アメリカ陸軍研究所で開発されたpublic domainのGIS)や、 Idrisi (アメリカのClark大学で開発された、商品だが安いGIS) を使うことを 想定したものである。
大気のもつ数量は、緯度、経度、高さ(気圧)、時間の4次元の時空間に分布するが、 多く使われる表現はそのうち二つの次元を両軸にとった2次元分布図である。 ただし、図の軸にとらない座標軸については、平均などの統計操作をする ことが多い。具体的な事例は廣田(1999)を参照されたい。
気候学にまず必要となるソフトウェアは、 このような2次元分布の作図を少ない労力で多数行うことができるものである。 たくさんの断面を同じ形式で作図する作業が多いため、 バッチ処理(会話型でなく無人で計算機を動かす処理)ができることが必須と言える。 なお、作図では欠測(データ欠損)を考慮することも必要であり、 理論や数値モデルのために作られた可視化ソフトウェアそのままでは 不充分なことが多い。
気候学では、 3次元グラフィックスとして知られる、見取図、透視図、実体視用の図など の技術の優先順位は低い。それは、大気が連続体であり、視線方向のどの距離の 対象に注目したらよいのかが明らかでないからである。 変数の空間微分が大きく、 近似として不連続とみなせる場合、たとえば前線面や積雲の外形を見る場合には、 3次元グラフィックス技術が有効になることもある。
なお、可視化は、平均値やそれからの偏差の計算などの 統計操作に続けて行うことが多い。 あとで述べるGrADSは、可視化と統計操作の両方を おもな機能とするソフトウェアである。 可視化にFortranサブルーチンを使う場合は、 統計操作は、同じメインプログラムの中から グラフィックスとは別の(多くの場合自作)サブルーチンを 呼び出して行うことが多い。
統計操作としては、異常値(注目すべき現象またはデータの誤り)の検出の ためにデータを全数検査することも必要だが、 これを助ける汎用的ソフトウェアは見当たらない。 今のところ、以下にあげるようなプログラムによる可視化と、 自作プログラムによる加工を往復して作業する必要がある。
表1に、 筆者が使ったことがあるソフトウェアの特徴をまとめた。 このうちgnuplotは地理情報向けのものではないが、 グラフの作図に広く使われているフリーソフトウェアである。
NCAR Graphicsは、1986年に大きく変更された。 グラフィックスの基本ルーチンの仕様として、 ISO (国際標準化機構)の標準となったGKS (Graphical Kernel System, ISO 7942: 1985年; プログラム言語からの呼び出しかたは ISO 8651: 1988年)を、 また図形情報ファイルの仕様として、同じく CGM (Computer Graphics Metafile, ISO 8632: 1987年)を採用した。 機能面での重要な変化は、線画に加えて多角形の色による塗りつぶしができる ようになったこと、Fortranに加えてC言語からも使えるようになったことである。
これ以後の版は、著作権がUCARにあることが明記され、ライセンスが有料となった。 レーガン政権の「小さい政府」政策でUCARへの政府支出が減ったことが背景の ようである。 これは不幸なことだったと思う。 確かに当初は、NCAR Graphicsはライセンスを購入する価値のあるものだった。 しかし、一方で、営利企業により、AVSなどのソフトウェア商品が開発され、 積極的営業活動によって普及した。 他方で、GNUに代表されるフリーソフトウェアが地位を確立し、 その中にあとで述べるような可視化の道具もあった。 中途半端に商品化されたNCAR Graphicsは、両側からユーザー層を削られて、 進化を止めてしまったように思われる。 GKSやCGMがISO標準になったにもかかわらずあまり広く使われなかったことも 不幸だったが、この点は、仮にNCAR Graphics自体がもっと普及すれば 事情は変わっていたと思う。
最近、NCAR Graphics (バージョン4.2)の主要部分は、フリーとなった。
それに付加価値をつけた商品もある。
ホームページhttp://ngwww.ucar.edu/参照。
地球流体電脳倶楽部は日本の気象学・海洋物理学などの研究者の集団である。
当初から1995年までの経緯は林(1995)がまとめている。
最新の情報はホームページhttp://www.gfd-dennou.org/から得られる。
地球流体電脳ライブラリはこの集団が作ったソフトウェアをさすが、
表1には、そのうちグラフィックス用のFortranサブルーチンライブラリに
限って特徴をあげた。
作者たちがもとNCAR Graphicsのユーザーだったこともあって、 このライブラリの機能はNCAR Graphicsと共通するところが多い。 NCAR Graphicsのプログラムが、デザインの古いもの・新しいものが混在して 見通しが悪くなっていたのに対して、 内容をよく理解できる道具を自前で整備しようということで開発された。
なお、表1にはあげなかったが、格子点データを一定の体系で保管し、 平均操作などの演算と可視化を行うソフトウェア「gtool」も開発されている。 その機能はGrADSに近いと言えるだろう。 さらに、地球科学向けのデータの論理的構造と演算・可視化の道具を 整備する「Davis」プロジェクトも進行中である(上記URL参照)。
気象データの図化と簡単な統計処理に特化したソフトウェア。
アメリカのメリーランド州にあるCOLA (Center for Ocean-Land-Atmosphere
Interactions)という研究所の技術者である
Brian Doty氏が作ったフリーソフトウェアである。
情報はCOLAホームページhttp://grads.iges.org/
[2019年6月現在、http://cola.gmu.edu/grads/]
にある。
ソフトウェア自体もここからたどれるアドレスからftpで得ることができるが、
日本では、北海道大学にあるミラーサイト
ftp://ftp.eos.hokudai.ac.jp/pub/Geo/grads/のほうが便利である
[2006年11月現在、このサイトはなくなったようだ]。
主としてUnix上のX Windowで動くものだが、
MS Windows上のX Windowで動く版やPC DOS版もある。
主な操作対象は4次元格子点データであり、しかも時空間座標が、 x=経度、y=緯度、z=気圧、t=日時(年・月・日・時・分)と決められている。 この座標の選択からも、気象データに特化していることがわかる。 ファイル形式はおもに数値を順にならべた単純な形式のバイナリファイル (他にWMOで決められたGRIBという気象格子点データ専用の形式など)であり、 その変数名や格子点数・座標値などは補助用のテキストファイルに書いておく。
観測点データを扱うこともできるが、 表示機能も格子点データとの相互変換機能も最低限程度でしかない。 観測点の位置は毎時刻違っていてもよいが、 地点網が同じであっても毎時刻緯度経度の情報を与えなければならない。 (講演要旨(増田 2000)を書いた時点ではこの機能について誤解していた。 この機会に訂正しておく。)
独自のコマンド言語を持っていて、 あらかじめ手順を組んでバッチ処理することもできる。
グラフィックスは画面表示が主で、 高速なアニメーションができることが特徴である。 紙への出力は、中間ファイルに書き出し、 付属するプログラムでPostScript形式に変換することで可能である。 ただし、塗り分けはカラーまたは濃淡表示だけで模様がないので、 白黒の印刷原図にはあまり適さない。
格子点データを組み合わせた演算もできる。 ただし、格子の座標値が同じもの同士に限られている。 違う格子への内挿については、ユーザー定義関数という機能を使った例文はあるが、 汎用にはなっていない。
地球上に分布する数量データの作図を主な機能とするプログラムパッケージ。
地理座標に限らない一般のデータのグラフを作る機能もある。
Paul Wessel (ハワイ大学), W.H.F. Smith (NOAA衛星測地部門)
の両氏(いずれも固体地球物理の研究者)が作ったフリーソフトウェアである
(Wessel and Smith 1991, 1998)。
情報はホームページhttp://www.soest.hawaii.edu/gmt/
[2006年11月現在、http://gmt.soest.hawaii.edu/]にある。
ソフトウェア自体もここからたどれるアドレスからftpで得ることができるが、
日本では、
北海道大学にあるミラーサイト
ftp://ftp.eos.hokudai.ac.jp/pub/Geo/GMT/
[2006年11月現在、
東海大学にあるミラーサイト
ftp://ftp.scc.u-tokai.ac.jp/pub/gmt]
が便利である。
Unix用であるが、MS Windowsでも「CygWin」 (GNUソフトウェアをCygnus社がWindows用にフリーで提供しているもの) 上でコンパイルすれば動く。 比較的単純な機能のコマンドの群として構成されており、 ユーザーはそれらを呼び出すUnixの シェルスクリプトを書くことで、複雑な図を作ることができる。
扱える地理データは、2次元格子点データとベクターデータである。 格子点データの座標は、x=経度、y=緯度の等間隔に限られている。 データを空間座標の連続関数と仮定している部分があるが、 改訂を重ねるとともに、 名義型変数(分類コードなど)も扱える部分がふえてきた。 格子点データのファイル形式として、 UCARのUnidataプロジェクト(NCARとは別)で開発された「netCDF」という 形式を採用している。 ベクターデータは、点、線、面(多角形)を扱うことができるが、 arc-node構造ではなく、単なる点の列として扱う。 そのファイル形式はテキストファイルである。 なお、GMTシステム内で用意された海岸線などのデータに限り arc-node構造をもたせており(ファイル形式はnetCDF)、 海あるいは陸を塗ることなどができる。
作図は、PostScript形式のファイルを書き出すだけで、 グラフィックス装置を操作しない。 これは機種依存性が低いという長所でもあるが、 画面表示はGMTの外のghostscriptなどのソフトウェアに頼ることになる。 アニメーションをしたければ、PostScriptファイルを作っておいて、 それを別のソフトウェアで動画ファイルに変換するという 手順をふまなければならない。 紙への出力を想定する限りでは、 地図ばかりでなく、一般のグラフの清書用にも適している。 色のほか模様による塗り分けもでき、 文字の位置や大きさの調節も細かくできるので、 白黒、カラーのどちらの印刷原図も作ることができる。
GMTは、作図機能のほかに、別のプログラムとして、 格子点データを組み合わせた演算や、 観測点から格子点への内挿の機能ももっている。 ただし、緯度経度の2次元を扱えるだけなので、 空間分布と時間座標をもつデータの処理については、 Fortran, C, awkなどによるプログラミングを併用する必要がある。
現在あるGISソフトウェアは、 GrADSに代わって 大量の気象データを高速に見る需要にこたえることはできないだろう。 しかし、コマンド言語をもちバッチ処理が可能なGISであれば、 GMTが果たしている用途の大部分は満たすことができるはずである。
ただし、教育現場で、 遠からず卒業していく学生に技術を修得してもらうための選択としては、 同じ程度の効率であれば、GISソフトウェアの専用コマンド言語よりも 汎用のシェルスクリプトやプログラム言語のほうが有意義と思われる。 GISソフトウェアを導入するのであれば、 フリーまたは個人で気軽に買える値段であり 卒業しても使い続けられることと、 ユーザー層が厚く外部の組織とノウハウが交換できることが前提となる。 研究機関でも、人の異動が頻繁な場合は、同様なことが言えるだろう。
坂元ほか(1998)は、古気候学のための地理情報システムのプロトタイプ構築を 試みた。この経験をもとに、古気候学向けシステムの要件を簡単に述べる。
古気候の観測データは主として、化石の有無や種類に代表されるように、 定性的変数である。 しかし理論や数値モデルから得られる情報は、現代を対象とする気候学と 同様に、定量的物理変数である。この両方が扱える必要がある。
古気候学では、同一とみなす時刻の間の間隔が不均一であり、 しかも研究の進展とともにそれが変更される可能性がある。 また、地図でいえば基図にあたる海陸分布の変化を考慮する必要がある。 特に数千万年以上の時間スケールを扱う場合、大陸移動に伴う緯度経度の 変化を計算に入れる必要がある。この変換も、研究の進展とともに 改訂される可能性があるので、データには現在の位置を対応させたうえで、 変換して過去の位置を表示できるようにしておく必要がある。
GISが気候をも本格的に統合した地理解析の道具となるためには、 GrADSのもつ機能を兼ね備える必要がある。 さらに、格子点データばかりでなく、4次元時空間中に不規則に分布する 観測点データを扱い、それと格子点データとの比較・演算ができるように なることを望む。
Cleveland (1985)は、多変量データの可視化の基本は、二つずつ総当たりで 散布図を作る「散布図方陣」(scatterplot matrix)だと述べている。 さらに、方陣を構成するある散布図中で点の集合を指定すると、他の散布図上 でも対応する点がマークされて表示される「brushing」機能が有効だと述べている。
気候データも、多くの場合、多変量データである。 たとえば気象衛星NOAAのAVHRRセンサーからは、同じ場所について五つの波長帯の 放射輝度の値が得られる。地表面状態の分類をする場合は これを5次元空間に分布する点として扱い、近さを評価したりする。 さらに、緯度経度を加えた7次元空間の点と考えることもできるだろう。 七つの軸の任意の二つ(たとえば可視と近赤外の輝度)についての散布図上で 点を指定し、他の軸の組み合わせ(たとえば緯度と経度)で どんなところに来るかを見ることが簡単にできれば、 人がデータから有効な情報を抽出するのを大いに助けると思う。 データの軸の組み合わせ演算を行なって新たな軸を設定することもできる ことが望ましい。
定性的変数、たとえば「ある種の生物が生存可能であること」は、 定量的変数の区間と関係づけることができる(坂元・増田 1999)。 ここでいう区間は多次元のもの、つまり複数の定量的変数を軸とする空間中の 多面体のようなものかもしれない。 すでに、多くのGISソフトウェアには、定性的変数のレイヤー間の論理演算機能が あるが、これと組み合わせて、数量データの不等式を処理する機能が発達する ことを期待したい。 場合によっては、区間の限界を厳密にせず幅をもたせる、 いわゆるファジー論理を導入したほうがよいこともあるだろう。
現在、データベースの形式の標準といえるのは、 データを正規化された形式の表の集まりとして持つ リレーショナルデータベース管理システム(RDBMS)であろう。 気候データをRDBMSで管理している例としては、 スイス国立工科大学気候学教室の Global Energy Balance Archive (GEBA, Gilgen and Ohmura 1999)がある (地図による表示や地点選択の機能はあるが、いわゆるGISは使われていない)。
筆者の経験は乏しいが、あえて主観的な感想を述べれば、 いま世に出ているRDBMSは、 気候データの散逸や見落としを防ぐ効用はあるが、 それ以外の面では必ずしも解析の効率には寄与しないように思われる。 具体的に感じている問題点については、 RDBMSの概念の限界なのか、実装上の問題なのか よく理解していないので、ここでふれるのは避ける。 いずれにせよ、今後のデータベース技術の発達に期待したいと思う。
本稿は、日本地理学会のシンポジウムで述べたこと(増田 2000)に、 東京都立大学理学部地理学科在職中に「地理情報学」その他の授業で 講義したことの一部を含めて再構成したものである。
[追記]
ウィスコンシン大学のBill Hubbard氏が開発しているフリーソフトウェア
「Vis5D」と「VisAD」は、GrADSよりも進んだ4次元時空間データの
演算・可視化の能力を持っているようである。
http://www.ssec.wisc.edu/~billh/vis.html 参照。
ただし筆者は話を聞いただけで、使った経験はない。