prasinos' work memo

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

風速の矢羽根

びっくりしたなあもう。風速の矢羽根の単位が日米で違うとは思わなかった。

天気図にはこんなの

wind-int

が描かれていて、風速をあらわしている。▲が50ノット、長い線が10ノット、短い線が5ノットである。1ノットは 0.5144 m/s なので、それぞれ 25 m/s, 5 m/s, 2.5 m/s と考えても誤差の範囲である。というか、昔人間が電報を聞きながら天気図をプロットしていたころは、風速がノット単位とm/s単位のゴタマゼで通報されるのでこの読み替えをしてプロットせざるを得なかった、らしい。2.5 の倍数の計算はまあ面倒だが、どうせすぐ慣れる。

上の絵は 50 + 10 + 5 = 65 ノット = 33.4 m/s である。地上でこんな風は台風の時くらいだが、上空のジェット気流の中では「▲▲\_」なんてなることもざらにある。

なのであるが、なんと、アメリカでは▲が50m/s, 長い線が 10m/s, 短い線が 5m/s でプロットされることが多いらしいのである。特に注意しないでみていると、「25m/s ですか。たいしたことないジェットだなあ。」と思うのだが、よくよく調べて見ると全然違った。

なお、昔中学校で教えていた

wind-ja

の型の矢羽根は日本式といって、線の数を数えれば風力階級の番号(つまり上図は風力7)がわかるのだけど、これは日本でしか使いません。
スポンサーサイト

雑感

だいぶん更新しないでしまった。ひとつには忙しかったからだが、もうひとつは日本語が書けない(時間が一日の大半を占める)状況が続いていたからだ。技術メモと違って、ここはなるべく英語記事を書かないようにしようと思っている。

さて、最近いろいろの(自分にとって)新しい技術に触れたが、紹介し損なっているものが多い。本来はそれぞれ何エントリも費やさなければならないのだが、本当に忘れそうなので、ちょっと箇条書きにしておこう。

  • GEMPAK が GTOOL3 に似ていること。また、より豊富な機能を備えていること。
  • GEMPAK のデータ identifier が NuSDaS に似ている、というか、GRIB そのものであること。
    時間やレベルが Range であることを無視してはいけないが、さりとて頻繁に使われるわけでもないこと。
  • ArcGIS の ArcCatalog は gtool4 の VB ブラウザにそっくりであること。
    いや、むしろ、NuSDaS と類似して、複数ファイルを一体に見せかけなければならないシステムにおいては、
    ほとんど Windows エクスプローラを再発明したようなビジュアルシェルを作る必要があること。
  • それで、ArcGIS の利用者界面は ArcCatalog と ArcMap という組み合わせに収斂しつつあるわけであるが、
    さて我々はと振り返ってみると ArcMap みたいなものばかりしかないのではないかということ。
  • GeoTIFF は使い物になるらしいこと。しかし、ERDAS LAN ファイルのほうが使いやすいこと。
  • Erdas Imagine の評価はよくわからん。まだ知らない機能がたくさんある。


やっぱりあとは思い出せないぞ。思いついた時に描かないとだめだ。

とりあえず、GEMPAK を帰国後も使いこなせる水準に達するために、実時間データポータルを作って見ようと思う。同じようなものは UW-AOS であるとか、IGES のようにいくらでもあるのではあるが、自分でやってみないと道具の作りというのは調べられないものだ。ここがその、サイエンスたりえないところで、私をサイエンティストだと思って見ている人から見ると「何をこいつは退行しているのか」状態でつらいのであるが仕方がない。

How to read JPEG in short

Similar to the last entry, but for JPEG. This is more difficult.

  • #include ≤jpeglib.h≥
  • jpeg_create_decompress(&cinfo) initializes decompressor whose information stored in struct jpeg_decompress_struct cinfo
  • jpeg_stdio_src(&cinfo, file_pointer) sets a stdio file handle to the decompressor
  • jpeg_read_header(&cinfo); jpeg_start_decompress(&cinfo);
    to start decompression
  • at that time, cinfo.output_width, cinfo.output_height, and cinfo.output_components give width, height, and number of components respectively.
  • to allocate buffer for a line, issue
    JSAMPARRAY buffer = (cinfo.mem->alloc_sarray)((j_common_ptr) &h->cinfo, JPOOL_IMAGE, cinfo.output_width * cinfo.output_components, 1);
  • to decode a line, jpeg_read_scanlines(&cinfo, buffer, 1);
  • pixel value at i-th pixel is given by GETJSAMPLE(buffer[0][i * cinfo.output_components + iband], where iband is number of band.
  • to finalize the decompressor, issue jpeg_finish_decompression(&cinfo), jpeg_destroy_decompress(&cinfo);

sylpheed installed

I have installed sylpheed 1.0.4, a email reader.

Another email reader Ximian Evolution comes with the OS and it looks nice. But I want to read huge number of mails by just hitting SPACE continually.

I found SRPM package for Fedora Core 3 at rpmfind.net, rebuilt and installed it.

(Note 5/1: this entry should have written on 4/27.)

GIF 解読事初め: libungif の使い方

画像ファイルを読むライブラリというものを初めて試してみたが、なかなか便利である。覚えのため、それから、英語が障壁になって試せないでいる人のため、ちょっと簡単にやったことの記録。

まずはライブラリを探して来る。RedHat や Vine だと libungif-devel という。これが最も普及しているか、あるいは、佐井高性能であるか等については一切リサーチしていない。どうやってみつけたかというと、とりあえず /usr/lib のぞきこんでライブラリを見付けて

$ rpm -qf /usr/lib/libgif.a

RPM 系の Linux では、たいていドキュメントは /usr/share/doc/libungif-devel-4.1.0 といったあたりにインストールされる。のぞき込む。 index.html があるので読む。ライブラリリファレンスがあるのが正攻法であるが、ないのでコード例を探すと

  • giffltr - 一列毎に読み書きする例
  • gifspnge - 1画像まるごとメモリに読む例
がある。いまどき一列毎に読まなければならないようなメモリ逼迫情勢は考えにくいので、迷わず gifspnge に行く。おっとこれは ESR 様がお書きになったのではないか、と尊敬度アップ。 腹立たしいことに gifspnge.html から gifspnge.c がリンクしていないが、気にせず読む。

とりあえず読めればいいので読む使い方。

  • #include
  • stdio の FILE * のかわりに GifFileType *g を使う。
  • fopen のかわりに DGifOpenFileName を使う。関数名の先頭 D がデコード系、E がエンコード系である。
  • 失敗したら GifPrintError() して大人しく止まる。
  • g が指している構造体には SWidth, SHeight, SBackGroundColor (パレット番号) がある。SWidth/SHeight は必ずしも次のイメージの大きさではないような気もするがたぶん気にしないでいいだろう。
  • DGifSlurp(g) するとメモリにイメージが全部読み込まれる。 全部というのはアニメーションがあるから複数かもしれないが、今は気にしない。 GIF_OK 以外を返したら当然エラー。
  • しかるのちに g->ImageCount はイメージ数。 g->SColorMap->ColorCount が色数。
  • 最初の画像は g->SavedImages[0].ImageDesc に入っている GifImageDesc 構造体。誰でも面倒なのでこれへのポインタを d とかいってセーブしたくなるだろう。
  • d->Width, d->Height が本当のイメージサイズ。違っていたらどうなるのか知らない。
  • g->SavedImages[0].RasterBits[i + d->Width * j] がピクセル i, j のパレット番号。
  • パレット番号から RGB を得るのは g->SColorMap->Colors[パレット番号].Red, (...).Green, (...).Blue のようにする。
  • 用が済んだら DGifCloseFile(g)
なお本情報をあてにして何か問題が生じても当局は一切関知しない。真面目にマニュアル読め(俺もだけど)。

NCEP/NCAR reanalysis

I am supposed to perform a case study for AOS 650 using NCEP/NCAR reanalysis. Today I spent a lot of hours to visualize provided GEMPAK file, but it was still unsuccessful. It seems to be broken, or I don't know how to visualize it.

Maybe I can download original data, but I don't think I have enough time....

JPEG to LAN converter

I wrote a JPEG to ERDAS Imagine LAN converter.

There may be something like that. But I wanted to write this to combine several monochromatic images into one .LAN file with as many band as input files.

The goal is to perform principal component analysis (PCA) for meteorological satellite images. That is not so useful for GOES series or GMS-5: SSEC has only 4 bands for their data (IR1 seems to be omitted), and reducing 4 bands into 3 has not so interesting. But METEOSAT 8 has 11 bands! It should be very useful to visualize what is the difference between so numerous infrared bands.

Using libjpeg, the programming work is not so difficult.
続きを読む

translation buttons added

I have edited the style of this blog. There are "to English" and "to Japanese" links on each entry.

I am glad to have learned how to do that.
I want to make my work accessible to everybody.
But language has been a great barrier.
Now I have no longer to maintain both english and japanese pages.

From now on, I will write most entries in English.
One reason is that I am not able to write Japanese letters on many terminals.
Another reason is that translation from English is relatively better than that from Japanese.
This is not case for computer literature including many blockquotes,
but readers are suggested to refer original text.

GTOPO30

GTOPO30 is a global DEM made by USGS and many international collaborators
( mirror in Japan).

[g95] compilation complete, but

compilation has been completed. But rpm died at the end of its work!
Finding  Provides: (using /usr/lib/rpm/find-provides)...
Finding  Requires: (using /usr/lib/rpm/find-requires)...
PreReq: rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Requires: ld.so.1 libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.1.3) libc.so.6(GLIBC_2.2)

at: script exit 1

libungif/libgif

I had to analyse a GIF file.

In the past, my favorite method is to convert into PNG first and then read that. But it takes much disk and time. So I tried to use libgif which comes with RedHat distribution.

Documentation was good enough to guess what's needed, so that I could write a program to read GIF file in one day!

I have long pursued to make my programs independent from work of others. That improved usability, portability, and even reliability. However, what I want to make has become too big to do it only by myself. Now is the time to think about using reusable software component. (Libgif has long had a patent problem. But the LZH patent of Unisys has been expired).

This inspires me. For example, it might be able to add direct GIF support to DCL. It would be best for web-based appliaction. It should be far easier to use Xvfb with problems.

g95: assembly error

Compile error in the last time was in gcc. I decided to ignore that because libgcc.a with pretty big size had been generated.

After that, g95 compilation is done successfully, but libf95 fails to compile at runtime/fpu_set.c. Hmmmm. I hope I can also ignore that....

[g95-PPC] end up with compile error

I have been trying to recompile g95 on PPC-Linux.

It is very tricky to follow recent change in the gcc directory structure.

And finally I got compile error. I have to suspend this work until I have time.

測地系用語集

GeoVRMLのサイトの表があるよ。というURLメモ。

ISO Spatial Reference Model に準拠するらしい。これも勉強しないとね。

asbest

Entrance of my office's building is under construction. They remove seiling and doing something I don't know (actually I don't care). That's fine. There must be reasons.

But I'm angry because workers there don't care asbest as insulation at all. The floor is full of fragment of asbest, and the atmosphere is quite dusty.

It is unacceptable. Is there any regulation?

何故 Fortran で書くのか

Lisp だとか ruby だとかの話を書いて、ちょっとため息。

私のキャリアは結局のところ Fortran である。Fortran ったって Fortran 90 だけれども、まあそんなに違うものではない。古典ギリシャ語がラテン語になったくらいの飛躍的な実用度アップ! (だってバチカンでは今でも使ってるよ)なんだけど、コンピュータサイエンスの清く正しい世界からみたら、何化石みたいなの相手にしてるんだよ、ってな話。

生産性だってひどく違うわけで、ruby 触ると桁違いだって実感する。

だけれども結局のところ Fortran 捨てることはできないんだな。これは、業界がそうであるからで、個人プレーの世界ではないのでしょうがないのだ。「人月の神話」のブルックス大先生様もそう仰っていたのであるから間違いない。

で、あるならば、嫌々付き合うんじゃなくて、世界をより生産的に過ごしやすいものにするための努力に意味があるんでないの、ということで、fortran-stdio なんか作ろうとしたりすることに熱中している。これ、出来れば本当に (Fortran にとっての) 世界が変わるよ。2020 年には来ることがわかっている変化を先取りするだけだけどね。

うーん。落ちがないね。ごめん。そういうことで。

エラーで落ちた(泣き)

ちょっとリンクいっぱいのエントリを書いたらエラーで落ちた。こういうときに限ってコピーしていないので原文復旧不可能。

泣き。

もう寝ます。

On Lisp

またきっかけは「圏外からのひとこと」なんだけど、東大の野田さん(ここに移転予定)という人が「On Lisp」の邦訳をしているんだと。

Lisp は嫌いだし実習につきあっている時間もないから最初のほうだけ読んだ。くやしいけど衝撃を受けたぞ。

・Lisp ではボトムアップデザインが自然なんだと。オイラのスタイルではないか。
・階層構造はボトムアップの産物である。言われて見ればそりゃそうだ。
・他の言語でもライブラリはボトムアップに作るものだ。言われて見ればそうかもしれん。

うーん。こんなことも考えて見なかったなんて。無知って恐ろしい。

(追記) リンク追加。

google map で衛星画像

Google Map で衛星画像が見られるようになった。セキュリティホールmemo経由武田ブログより。これはマップサービス界の一大事だ。

どんな衛星だか知らないが 1ft 解像度だというから Landsat の 1,000 倍、気象衛星の 30,000 倍(そんなものと比べるなって?)の解像度ということになる。あたりまえだが可視画像。

ひとつ思いつく用途として、アメリカは高速道路の地図がとてもいい加減なので、インターの位置や形状をトレースしておくと道に迷わないというのがあるな。

しかしあれですな。少し眺めていると地図と衛星画像が結構ずれている(シアトルのダウンタウンで1ブロックくらい)。これはちょっとかっこ悪いんでないの。

(追記) 衛星画像は (最高で) 1ft 解像度のところと、Landsat MSS に見える (TM かもしれないが、もっと粗い) 画像が混ざっている。高解像度のところは大都市が多いが、首をかしげたくなるような場合もあり、まあそれは出来次第ということかもしれないし、保安上の要請なのかもしれない。Orthorectification どころか Georectification もしていないので、碁盤の目の街でも菱形の街(ひしゃげ加減は場所に依存)になってしまう。

BUFKIT

BUFKIT という可視化ツールがあることを知った。GPV 予報から1時間毎の地点系の図:skew-t, 降水、ZT 図などを描く。

UPC seminars

I have found that Unidata Program Center holds almost monthly seminar, while google searching GIS-ASIS related activites

[redhat] jdk 1.5.0-02

I want to install JDK, Java Development Kit.

It is downloadable from http://java.sun.com/j2se/1.5.0/download.jsp.

Installation procedure is simple if you use RPM version: extrac t and install by rpm(1). Extraction process printed some error messages informing failing access to get RPM database, but I think it's okay.

More difficult thing is adding Java plug-in to Mozilla.
$ /usr/lib/mozilla-1.4.4/plugins
# ln -s /usr/java/jdk1.5.0_02/jre/plugin/i386/ns7/libjavaplugin_oji.so .

Source: http://java.sun.com/j2se/1.5.0/manual_install_linux.html

You can check the Java plug-in at http://www.gfd-dennou.org/arch/zz1998/ekman/Ekman.html. Whoa, it's already seven-years ago....

[redhat] update ruby to 1.8.2

Although our OS (RedHat Enterprise Server AS 3.0) has ruby, it is quite old:

$ rpm -qa | grep ruby
ruby-1.6.8-9.EL3.3
ruby-mode-1.6.8-9.EL3.3
ruby-libs-1.6.8-9.EL3.3
ruby-devel-1.6.8-9.EL3.3

Language itself is very stable, but changes in libraries (especially CGI) will cause trouble for me. So I'll try to update it.

STEPS

NET SEARCH

Firstly, I have checked whether ruby is recognised by system or not, using redhat-config-packages. I don't understand the result that it claims there is no ruby. But I won't care that.

Secondly, I have searched source RPM package at http://www.rpmfind.net. Fortunately, Fedora Core has ruby 1.8.2.

REBUILD RPM

Install downloaded package:

$ rpm -i ruby-1.8.2-6.src.rpm
$ cd ~/rpm

Check the content:

$ vi SPECS/ruby.spec

I think that's ok, so go:

$ rpmbuild -ba SPECS/ruby.spec
INSTALLATION
# rpm -ivh RPMS/i386/ruby-libs-1.8.2-6.i386.rpm
# rpm -e ruby-libs-1.6.8
# rpm -Uvh RPMS/i386/ruby-1.8.2-6.i386.rpm
# rpm -Uvh RPMS/i386/ruby-devel-1.8.2-6.i386.rpm
# rpm -Uvh RPMS/i386/{ruby-docs,rdoc,ri,irb}-1.8.2-6.i386.rpm

Option -U stands for update, not install first (-i).

[fortran-stdio] buffering logic

I got better expression of buffering logic:
  !private
  subroutine flushblock(unit, iostat)
    integer, intent(in):: unit
    integer, intent(out):: iostat
    if (info(unit)%hot) then
      call writeblock(unit, info(unit)%cached%blk, info(unit)%buf, iostat)
      info(unit)%hot = .false.
    else
      iostat = 0
    endif
  end subroutine

  !private
  subroutine fetchblock(unit, i, iostat)
    integer, intent(in):: unit, i
    integer, intent(out):: iostat
    call set_buffer(unit, iostat)
    if (iostat /= 0) return
    if (info(unit)%cur%blk == i) return
    call flushblock(unit, iostat)
    if (iostat /= 0) return
    call readblock(unit, i, info(unit)%buf, iostat)
  end subroutine

This pair of routines are written at the viewpoint of buffer management, instead of top-down approach from read/write. I believe that such a inversion of viewpoint is important in programming.

Environmental Corridor - defs

Good explanation found.

The name 'corridor' implies the importance of contiguity.

[PPC] give up GEMPAK: X required

I've been trying to compile GEMPAK on PPC Linux. But I found that it requires X. What fool I am....

TIFF specifications

Last time I got PostScript version of TIFF rev6 specification and printed it. That's fine.

Today I wanted to view on the Web Browser, so I tried PDF version, but it was unaccessible. Firstly it requests to sign in. That's fine. I trust Adobe not to leak my email address. Then password is sent by email. But the result is
Insufficient privileges (HTTP 403 error)

.img file was not TIFF!

Image files with .img suffix are not TIFF. TIFF starts with magic number "II*\0" or "MM\0*", but .img files start with "EHFA_HEA".

I have thought it is GeoTIFF, and study of its structure will be
helpful for capstone study. The life is not so easy.

Anyway I have to study on TIFF. Later (when I am able to use Windows) I will check whether WISCIMG (or maybe Erdas Imagine) can load TIFF or not.

6 バンド TIFF

普通のカラー画像は(256色パレットみたいなのは別)RGB の3バンドでできているのであるが、衛星リモセンの画像ファイルは6バンドとかいろいろである。で、こういうのを主成分分析してもっとも情報量の多い 3 バンドに落しこんで見るということをやる。

そうしたら、気象の格子点データなんかもっとマルチバンドであるわけだから、同じように主成分分析したら面白いのではないだろうか。もちろん、気象で EOF といっているのが同じことなんだけれど、時間軸である必要はないし、ファイルフォーマットさえどうにかなれば Erdas Imagin だとか WISCIMG みたいなリモセン系のソフトが使えるでしょうというわけだ。

そう思っていろいろの画像フォーマットについて調べてみた。Erdas Imagin なんかのソフトに特有のフォーマットしか使えないと困るなあと思っていたが、幸い、少なくとも WISCIMG は 6 バンド TIFF というものを読み書きできることがわかった。TIFF のタグ構造というのも理解できたので、たぶん解析・再合成できると思う。

Phil Lewis and Environmental Corridor

A page found by Google search suggests that Phil Lewis was a UW-Madison professor in 1960s who proposed an idea of Environmental Corridor.

FC2Ad

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。