prasinos' work memo

GCM = Global Cloud Model

TRMM ウェブサイトというのは、当然 JAXA と NASA にあるわけだけれど、NASA のほうは「Why Do We Need TRMM」というのが「小学生用」から「大学院生用」まで5段階用意されていて面白い。もちろんどれも読み応えがある内容だ。

ただ、大学院生用の最後で「GCM」の説明が Global Cloud Model となっていてずっこけた。雲だけモデルしているわけではないよ。Circulation だからね。でも、逆にそのことから、GSFC の担当者が畑違いのことまで幅広く勉強して書いているのだなあということが伝わってくるので、じーんとくるのである。いやほんと、そういうのって大変だよ。
スポンサーサイト

格子とRDBの境目

ある業界の用語では私はデータベースをやっていることになっているのだが、RDB(関係データベース)ではなくて格子データベースなので誤解をうけることが多い。

データベースという言葉はとてもあいまいで、いい定義を見たことがなかったが、ウィキペディアの定義がけっこう良い。
特定のテーマに沿ったデータを集めて管理し、容易に検索・抽出などの再利用をできるようにしたもの。 狭義には、コンピュータによって実現されたものを言う。


私のもっていた考えでは、(1) データ全体になんらかの分割がなされ、(2) それらが検索・抽出されるものである。検索するために与える情報がキーであって、格子データではインデックスという整数群がキーにあたる。すると結局何でも理論上はRDBで書けるのだが、どういうときに格子DBで表現したいかというところが気になる。

最初は素朴にキーが整数であること、と考えたが、べつに番号を割り当てればいいから違う。

次に考えたのは、キーが順序尺度であること、であるが、べつに名義尺度に先着順なり辞書順で番号を与えたところで格子データベースが使えなくなるわけではないからちょっと違う。

次に考えたのは、キーの2値の間というレンジをとったときに、その間の要素数が予知できて増えないものが格子という、というものである。

今のところこの定義はアタリである。

黙ってスパム消すかねえ

前世紀に私はメールアドレスを Web で公開し、学会の論文誌に載せて公表しまくった。当時はそれがあたりまえのことだったのだ。ところが時は移って末法となり、スパムが雲霞のようにやってくるようになった。普通の人には「Webのメールアドレスを消しましょう」なんてアドバイスがなされるようだが、私の場合オンライン論文誌やらフリーソフトのソースコードなどあって、流布してしまった情報を消すことは無理である。んで、最初はいちいち消していたのだが、2003年末ごろについに根をあげて、自作フィルタで怪しいメールをマーキングすることにした。

アルゴリズムは至極単純なもので、知ってるメールアドレス一覧に載っていないものは全部怪しいとマークする。私はエグゼクティブではないから、知らないメールアドレスからメールが来ることなんかまずない。

さて、まちがってウィルス入りの地雷を踏んでしまわないために、普段は秘密の POP サーバを経由して Web メールに流し込んだメールを読むことにしている。で、この POP サーバが遅かったので別のプロバイダに変えたのだが、とたんにスパムが激減してしまったのである。

関連するすべてのSMTP通信を傍受したわけではないから断言はできないが、状況証拠からいって、プロバイダがスパムを黙って握りつぶしているとしか思えない。なんていうすばらしいアルゴリズムだろう、と思うのと同時に、なんだかスパムでないものも消えているような気もする。

私は世の中から孤立していないだろうか。


WI 地図サーバガイド

ウィスコンシンの地図サーバガイド(州政府行政管理局)著者の講演をきいたのでURLメモ。なかなか網羅的なメモで、まじめにレビューすると相当時間がかかるだろう。

ひとつだけ特色があるとすると、ArcIMS サーバがとても多いということだ。日本でもそうだろうか?


imap ありがたや

引っ越してからメール環境は失敗だらけだったのが、ようやく再建のめどが立った。

というのは、SSL つき IMAP のメールサーバがあって、長年つきあってきた Becky! では対応していないのでとりあえずしょうがないから Outlook で読んだのだけど、よせばいいのに別アカウントの POP のメールをダウンロードしてしまった。すると、その Windows PC にしか大事なメールが無いから、「箱に縛られる」という現象が発生する。しかもこの Outlook 検索が貧弱なんだよね。

それでもこれでしばらくは我慢していたのだが、フリー Web メールに乗り換えた(悪いがニフティさんではない)。すると imap じゃないけどサーバにメールがあるので別にどこに行ったって仕事ができるわけで、別にプロトコルなんて何でもよかったわけだ。

そうすると残った問題は Outlook が抱えて離さない過去メールである。エクスポートも試みたが、Outlook 専用フォーマットか添付ファイルが欠落するテキスト書き出ししかないようなので、ぜんぜんダメである。こういう囲い込みはワタシ大嫌い。でも、ログインできるもうひとつの imap サーバにドラッグしてしまえば、mbox フォーマットとして簡単に取得できるのであった。

だから UNIX はやめられない。

やっぱり履歴は全部保存するものかね

「圏外からのひとこと」で拾ってきた「楽観的ロックでいいじゃん!」には教えられた。

私のようなデータベース素人が無理やりモデル作ると、ついつい更新のことを忘れてしまって静的関係だけ作ってみて、後でワークフローに気がついたところでやりなおしになるのだが、対照表(たぶん僕ら語では更新履歴というのだろう)を作ると全部追加なので扱いやすい。ああこれは便利だ。

でも、申請が承認されたか却下されたかはどう表現するのかなあ。承認・却下操作を申請と別の表にすれば追加ばっかりになるんだろうなあ。それってつまり「申請書差し替え」みたいな寝技ができなくなるってことだよね。いやそれが申請の電子処理ってことか。紙の世界ではあたりまえにやっていることができないことに気をつけて宣伝しておかないと、後で怒られることになるから用心。当然、履歴がきちんと管理されて障害原因追及がより明確にできるようになるとかいうメリット(犯人探しばかりやっても仕方がないか)もあるかもしれないけど。

URL メモ

30メガバイトの大きさ

ココログは一番安いベーシックコースで30メガバイトのファイルが使える。最初、小さいなあと思ったのだが、使ってみるとなかなかいっぱいにならない。10日で1.7%弱しか使わなかったから、このペースでいくと2006年5月末まで使える計算になる。それまでにはハードディスクも安くなることだし容量リミットも大きくなってくれるといいなあ、と安易に期待するのである。技術は進歩するが、人間に書けるテキストの量は進歩する見込みはないので、何十年か後に1ギガバイトくらい貰えるように線形に拡張してくれれば、たぶんココログからどこかに乗り換える必要がなくて一生使えるだろう。人生は短い。

古いWindows はなぜ起動が遅い?

昨日に続いて環境整備で時間をとられている。というか、渡米してからこれまでずっとその場しのぎでやってきたので、どうしたって時間がかかる。ここ1週間程度でやった作業の要約。

古いほうのラップトップだけど、どういうわけだか起動時間がこのところむやみに延びてきた。まず思いつくのはハードディスク故障なので、さっそく scandisk をかけてみたら何やらぼろぼろ引っかかる。内容には関心がないので破損ファイルはバサっと消す。何が悪いのかわからないけどアプリケーションエラーでログオンできなくなってしまったユーザは思いきって消す。とりあえず常駐プログラムを減らす。レジストリのどこをいじるのか忘れたので google すると MSCONFIG というもので編集できるらしい(http://kanon.ciao.jp/pcfaq.html#03にいろいろ便利なことが書いてある)。

これで一応起動は大分速くなったから、まあいいか。

CDライターを買った

手元のラップトップのCD-RWドライブが6月ぐらいからあまり動かなくなった。忙しいこともあって放置していたのだが、デジカメの写真でディスクが一杯になりはじめたし、CD-ROM が読めないのはどうにも仕事にならないので、そろそろ買い替えることにした。アメリカで内蔵ディスクを探すのはいろいろな意味で高くつきそうなので、USB 外付け iomega の CD-RW 52x DVD-ROM (この長ったらしいのが型番)を買うことにした。これなら他のラップトップ(これまた瀕死だけど)にもつなげるからね。Wal-mart で 89 ドルいくらかだから、 kakaku.com で一番安いのを買ったのと同じくらいである。一体何年ぶりの買い物だろう。

さて、壊れていたら返品しなければいけない(45日以内らしいが)ので、早速動作確認をした。一番感心したのは、
きれいに再梱包できるようなパッケージである
ということである。何でも返品できてしまうアメリカならではだが、このへんは日本も見習って欲しいと思った。ただし、CD-ROMでインストールしてからハードウェアをつないでくれというのはちと困ったが、たまたま今日は内蔵ドライブのご機嫌がよかったので、事なきを得た。そうでないと、ネットワーク経由でCD-ROMの内容をコピーしてから転送しなければならなかっただろう。

で、システムテストとやらをしてみると、我がラップトップには USB 1.1 しかないので、2倍速なら書き込めるという。もとのCD-RW は4倍速だったのだから、べつにびっくりするほど遅いわけではない。が、どういうわけだか付属の書き込みソフトが勝手に4倍速にしてしまう。このせいだかどうだかよくわからないのだが、古いCD-RW を書き換えようとすると何回かI/Oエラーで失敗した。気に入らないのでソフトウェアのアップデートをしたあと、小規模な書き込み2回は成功した。

なるべく早く600メガバイト級の書き込みをやっておきたいのだが、内容が思いつかない。さてどうしたものか....

JRE バージョン地獄

そういうわけで、IDV をちょっと使って見ることにしたわけである。

推奨最低スペックはインテル 1.2GHz プロセッサ相当と 512MB メモリである。それはちょっと... と思う方も多いと思うが、Athlon 1GHz 256MB の機械でもとにかく動くことは動いたので、ちょっと試してみるくらいだったら安心(?)である。しばらく使っていると(容易に想像されるように)スラッシングの嵐になって使い物にならなくなることもあるが、これはまあ致し方ないところである。今から見ればCPUのしょぼい機械でも、メモリさえ1Gくらい積んでやればサクサク動くので、果報は寝て待てというやつで、数年後のパソコンならぼちぼち動くだろうと期待したい。

さて、問題はそんなことではない。

IDV のインストーラは JRE 1.4.2_01-b06 をインストールする。が、さるところで MS Internet Explorer の Java プラグインの更新を要求されてしまったため、別口で JRE 1.4.2_05-b04 をインストールする羽目になった。するとディスクがもったいなく感じるのが人情というもので、新しいものならいいだろうと 05 に変更したところ、案のじょう謎の例外を出しまくって絵が出ない。結局両方持つ羽目になるのである。

IDV のデモをみた

UW SSEC の Tom Whittaker に IDV のデモをみせてもらった。正直圧倒された。もう日本発ソフトウェアなんて馬鹿らしいからやめようよ、ってくらい圧倒された。このへんやらせたらアメリカさんにはかなわない。以下備忘録。

彼は主に VisAD の Python 向けインターフェイスを作っていると言っていた。「サイエンティストにはスクリプティングが必要なんだ」とのこと、まったく同感である。Python 言語を JVM 上で実現する Jython というものがあって、スクリプトから Java のオブジェクトがいじれるのだそうだ。

で、VisAD のスクリプティングといっても、単に可視化のスクリプトなんてチャチなものではなく、データ処理(加減乗除とか)ができるのである。VisAD はクラスライブラリであり、可視化やらデータ処理やらというチャラチャラの下には強力なデータモデルがあり、そいつで単位を認識してやってくれるんだと。だからこれは堀ノ内博士の GPhys みたいなものだ。はっきりとは聞かなかったが、データの見方を変えるだけでデータアクセスが発生するところから、堀ノ内博士の「遅延評価」は当然含まれている。

そんでもって、VisAD ではデータのリサンプリングがやり放題らしい。格子間引きなんてケチなものではなく、座標系変換だってへっちゃらである。

知らなかったという顔をすると「データモデルのドキュメントから読んでくれ」とのこと。
そりゃそうだ。宿題にされちゃったよ。読まなきゃ。

IDV ではデータに含まれる多数のパラメタを「あるがまま」に表示するだけでなく、たとえば気温と湿度から露点を計算するといった derived な要素が表示できるようになっている。これも、IDV に組み込みになっているわけだが、気に入らなければ Jython でスクリプトすれば追加される。

また、表示を JPEG や QuickTime でセーブできるだけでなく、IDV の状態を bundle と呼ばれる XML ファイルにセーブすることができて、これを他人に送れば(ローカルデータ参照がなければ)「解析できる絵」として扱うことができる。

ただし、データを追加(ちょっとGISっぽいUIだ)するメニューでは「データの種類」というタブがならんでおり、形式が同じならばどんなデータでも統一的に扱えるというよりは、むしろ現物主義的にやっちゃっているみたいだ。

ともかく、
私が5年目標にしてきた理想が、すべてここでは実現している。

これはもう「今からなら追いつける」なんて言っていてはいけない状況だ。GFDはいざしらず、現業気象ならば彼らと本質的に違う種類のデータを扱うなんてことはありえないわけで、彼らの成果を輸入移植することにマンパワーを割いたほうがいい。

さて、気を取り直してGISとの関連だけれども、IDVコミュニティはGISデータの表示のためにがんばっている。特に、水文学関係者は本来的に気象データとGISデータの統合表示を必要としているので、IDVの機能拡張へのプルがあるんだという。LGPL で配布しているし、これは将来性がありそうだ。

それにしてもデータアクセスはいまいちよくわからない。GPhys みたいなものを考え付くほどの知能があるなら当然DODS 改め OpenDAP で何でも吸収という方向に突っ走っているのかと思ったら、結構ローカルファイルも馬鹿にしないでやっている。扱えるファイル形式が少ないのが問題だとかいうし。さらに ADDE というプロトコルもある。このへんの方向性はどうなっているんだろう。

あとは走り書きご容赦。

  • OpenDAP では多様なデータをサービスして統合できるのに対して、ADDE は単位の変換ができたりしてちょっと smart。
  • HDF は API がころころ変わるからお勧めしない。

JavaScript Japanese Input Module

えいごばんの Windows をつかっていて、にほんごをにゅうりょくしたくなることがおおい。のだが、かんりしゃけんげんがかってにならないので ime wo install suru ki nimo naranai. Konnnatokiha http://www.karlson.ru/jstoys/index.php?module=input_ja wo tukauto ikkyo kaiketu!

(追記) と、途中でひらがなにするのさえ放棄してしまったのは、ちょっと約束があって急いでいたのと、

  • やっぱり単漢字変換ってどうよ
  • なのに、ついついスペースを押してしまって混乱
  • ラテン文字も混ぜたい

というようなところであった。ま、マイナーな話といえるので、改良されたらかなり実用になるかも。

ドーン社の決算説明会資料

日本の GIS 市場の調査(の調査)のつづき。

「GIS シェア」と安易に google したら、(株)ドーンの2003年5月期中間決算説明会資料が出てきた。GeoBase というのが主力製品ブランド名のドーン(Dawn)社自体のことは申し訳ないけど置いといて、見所は付録。


  • 「自治体の GIS 全般整備状況」について総務省自治行政局地域情報政策室
    「地方自治コンピュータ総覧」が調べている。引用は平成10~13年度のデータ。
  • 「何らかの形でのGIS」の有無について

    • 都道府県には8割がた
    • 市町村への普及率は2割程度で伸び悩み
    • ドーン社は防災が伸びの見込める新分野と考えていたらしい

  • ただし、「自治体統合型GIS」について

    • 都道府県の普及率は1割程度で、
    • 政府の後押しがあるから伸びが見込めるがそれは2005年がピーク



というわけで、とても大雑把にいうと


  • 自治体市場はそろそろ飽和
  • ただし防災や統合化はこれから


というわけだ。とりあえず、大証ヘラクレス上場企業の決算報告はそう簡単に消えないだろうから保護しないでいいかな。

UNIDATA workshop on data and tools, Sep 20-21, 2004

地球流体電脳倶楽部Davisプロジェクトの人が Unidata を訪問して話をきかせてもらったという感じのワークショップ

GIS むけ気象データサービス

Meteorologix 社が気象データを GIS 向けに販売しているらしい。彼らが(?) ArcIMS サーバーを持っていて利用者は ESRI の ArcMap バージョン 9 を使って気象データと自前の地理情報を重ねて(重ねて、がGISのキーワードだ)見ることができる。WMO Resolution 40 とのからみが出てくるだろうから、米国外へのサービスや、米国外のデータのサービスはたぶんしていないと思うが、未確認。

ともあれ、米国でビジネスになるということは、少なくともこの手のGIS向け気象データサービスに実用的意義はあるという証明ではある。

日本の GIS 資料ポインタ

雑な表題ご容赦。

「GIS site:.jp」で google したらとても充実していた。自分の不勉強を思い知らされるわけであるが、とりあえず使えそうなリンクだけ記録しておく。



で、何をこんなに漠然と引いてみたかというと、ウィスコンシン州行政管理局がやっている WLIP annual survey のようなものがないかなあ、と思ったのである。日本政府もきっとどこかでやっているに違いないのだけど、やっぱり国土地理院のサイトなんでしょうね。

もうちょっと勉強します。

物理量の名前

気象データのメタデータで一番厄介なのが、物理量の同定である。

物理量とはたとえば「気温」と「気圧」の区別のようなものである。この例だけとってみれば、すべて物理的に決まっていて、こんなに自明なもので何を悩むのだと思われそうだが、「気温」と「最高気温」や「気温の平年偏差」は区別されるべきか否か、とか「風速」と「海水の流速」は区別されるべきか否かと考えてみると任意性の闇に向かって広がっていくダークゾーンが見えてくると思う。

私の知る限り、この問題に初めて手をつけたのはWMOである。GRIB通報式では物理量と単位を一緒くたにして「パラメタ」と呼び、パラメタ番号表というものを作って標準化を行った。なるべくSI単位を使うと決めてかかれば物理量と単位を一緒くたにするのは科学の正義といえるかもしれないが、計算機資源が高価だった時代の制約からやむをえないことではあるけれど、8ビットしかパラメタ番号に割り当てなかったことは後代に禍根を残すことになる(小さな2000年問題のようなものですね)。普通のデータ交換に使うパラメタは知れたものだけれど、普通でないものも時折は追加しないでは済まず、だんだん苦しくなる道理である。それでもまあ128~254を作成機関定義(しかしその作成機関番号がまた8ビットしかないんだけど)にしていることもあって、なんとかかんとかやってきた。

でもさすがに色々なところで行き詰まりが出てきたので、2003 年に GRIB Edition 2というものに切り替えるのだ、ということになった。Edition 1 との非互換性がすごいこともあって、普及には時間がかかるかもという話はおいておいて、物理量の識別に関与するビット数は分野番号・カテゴリ番号・パラメタ番号各8ビットずつに拡張された。

で、アカデミアはこんなきつい縛りにはおさまらない研究がいっぱいあるので、逆のアプローチをとった。UCAR Unidata というところがNetCDFというものを作ってデータに名前やら属性をつけられるようにして、「任意長の文字列をつけられるのだからお好きにどうぞ」状態にしたわけである。当然、同じ物理量で単位が違っても作成者の勝手で「units 属性に何か書いておけばオッケー」である。で、このような属性の使い方は当初「最低限のものを除いて利用者が勝手に組織して勝手に標準化してね」という放任状態だったのだが、10年もすると世の中だんだんこなれてきて、少なくとも気象予報・気候データについてはCF conventions というものに収斂しつつある。

そんで結局どうなったかというと、やっぱり彼らも(強く推奨レベルではあるけれど)集中管理方式に回帰した。ただし、変数名は比較的その場その場の事情が効いてくるので統一はせず、standard_name 属性を表参照させるのである。米国気象局版ECMWF版それぞれのGRIBとの対照表も作られている。GRIB2 の対照表はまだないようだ。




ファイル末尾へのシーク(2)

OPEN 文による位置づけができるなんて書いたが、世の中そんなに甘くない。
どうもファイルを開くときにしかやってはいけないみたいだ。
したがって、次のようにファイルを閉じて開かないといけない。

program eof
open(10, file='test.dat', form='unformatted', access='sequential')
rewind(10)
write(10) 'INIT'
write(10) 'MID '
write(10) 'END '
rewind(10)
print *, 'rewind'
call list(10)
print *, 'seek to EOF - 1'
close(10)
open(10, file='test.dat', form='unformatted', access='sequential', position='append')
backspace(10)
call list(10)
print *, 'seek to EOF - 2'
backspace(10)
close(10)
open(10, file='test.dat', form='unformatted', access='sequential', position='append')
backspace(10)
backspace(10)
call list(10)
close(10, status='DELETE')
contains
subroutine list(ifile)
integer:: iostat
character(4):: str
print *, '--- list ---'
do
read(ifile, iostat=iostat) str
if (iostat /= 0) exit
print *, '[', str, ']'
enddo
print *, 'iostat=', iostat
end subroutine
end program

GEOG377 要約§13 メタデータとSDTS

●メタデータ

FGDC メタデータ規約の構成

・同定(図題、データ取得手段など)
・品質
・空間データ構造
・空間参照情報
・実体と属性情報
・配布情報(再取得元へのポインタ)
・メタデータ参照情報(問合せ先、有効時期)

●SDTS

Spatial Data Transfer Standard

{ただし、他講義で「規定が複雑すぎて使い物にならない」との説が示されているので要注意}

ファイル末尾へのシーク

Fortran のシーケンシャルファイルでは、WRITE 文を実行するとその後のレコードが消えてしまうことになっている。規則は規則で、ばかげていると文句をいってもはじまらないので、ファイルの内容の一部がアップデートされるようなファイルを管理するときは、変更されやすいものを最後に持ってくることになる。そうすると、レコードを次々追加していくような状況を想定すると、レコードの一覧表みたいなものは当然最後の最後に書かれなければならない。

ところがファイルを読む立場からすると、レコードの一覧表なんかは真っ先に読みたいものであるわけで、ファイルを開いたら即座に末尾にシークしなければならないわけである。そこでどうやってシークするかが問題なのであるが、 FORTRAN77 では

10000 CONTINUE
00000 READ(IUNIT, IOSTAT=IOSTAT)
00000 IF (IOSTAT .NE. 0) GOTO 10001
00000 GOTO 10000
10001 CONTINUE


といった感じで全レコードをひたすら読み飛ばさないといけなかった。

さすがにこれでは速度的にどうよというわけで、Fortran 90 で何か使えそうなものがないかと探してみると、OPEN 文で位置づけができるらしい。プログラム例はこんなんである。

program eof
open(10, file='test.dat', form='unformatted', access='sequential')
write(10) 'INIT'
write(10) 'MID '
write(10) 'END '
rewind(10)
open(10, position='REWIND')
print *, 'rewind'
call list(10)
print *, 'seek to EOF - 1'
rewind(10)
open(10, position='APPEND')
backspace(10)
call list(10)
print *, 'seek to EOF - 2'
rewind(10)
open(10, position='APPEND')
backspace(10)
backspace(10)
call list(10)
close(10, status='DELETE')
contains
subroutine list(ifile)
integer:: iostat
character(4):: str
print *, '--- list ---'
do
read(ifile, iostat=iostat) str
if (iostat /= 0) exit
print *, '[', str, ']'
enddo
print *, 'iostat=', iostat
end subroutine
end program


9月23日版の g95 で動いたから多分大丈夫だろう。
[追記] やっぱり可搬性の問題あり


注意点としては、いったん end-of-file condition に陥ってしまったファイルはどうやら BACKSPACE 文か REWIND 文でないとこのエラーをクリアできないらしいということである。本当かなあ。規格本文をあたらないと。

ところで、何ギガバイトもある巨大なファイルをシークすると悪いことが起こらないだろうか。いや、どうせカーネルのなかでオフセット番号書き換えるだけだから、きっと何も悪いことは起こらないに違いない...。

SDTS

多様なGISソフトウェアの多様なファイル形式の相互変換のための中間的形式として、SDTS (Spatial Data Transfer Standard) というのが作られている。リファーするのはUSGSのサイトであるべきなんだろうけど、とりあえずリンクするならgeocomm.comのサイトが便利そうだ。ANSI規格にもなっている。
このフォーマットが使い物になれば、「GIS向けにデータサービスをしたいが特定の会社に依存するのはどうも...」というようなシチュエーションには「ラスタデータはGeoTIFFで、ベクタデータはSDTSで」というソリューションが思いつくが、さてどんなもんだろう。

コストリカバリモデル

デーン郡のGISデータは一部データ取得経費を含んだ価格 cost-recovery basis で出しているよ、という資料
日本では複製経費による価格設定 cost of reproduction basis が普通だから、それと同じかより安いのが情報公開の国アメリカだろうと思ってみたら、案外そうでない例もあるのでした。

GEOG377 要約§12 座標変換

●ラバーシート化

制御点の対応から回帰的に座標変換式を決定すること。高次多項式も用いられる。

●アフィン変換

回転・伸張・併進だけで書かれる変換。

GEOG377 要約§11 リモセン

細かい数字で記憶に値するのはランドサットだけ。

●MSS = Multi Spectral Scanner

解像度 80m, 4バンド

●TM = Thematic Mapper

解像度 30m, 7バンド

GEOG377 要約§10 データ収集

●方法

・ラスタ:リモセン、地図のスキャン
・ベクタ:測量、地図のデジタイズ

●エッジマッチング

隣接する地図・データセットに含まれる地物の位置が境界でずれているところをすりあわせること

●地図合成 conflation

同じ領域を描く異なるレイヤーに含まれる同じ地物の位置がずれているときに、これを同定・修正すること。正解を定めてそれにあわせる手法が用いられる。

FC2Ad