e_toyoda のメモ帳: 2012

2012-12-30

[気象庁防災XML] ちゃんと更新管理するためにデコード・DB化すべき情報

25日に考えたことの続き。
http://twilog.org/e_toyoda/date-121225

結局こういうテーブルを作ればいいのかな

・実体へのリンク
　uri -- 実際にはUUID URNが入る --
・データストリームの識別子
Title
EditorialOffice
Status
EventID
・更新管理
DateTime
ValidDateTime -- expire というべきかな --
・表示用
PublishingOffice
ReportDateTime -- nominal datestamp というべきか --
InfoKind -- subclass なんだよこれは --
Headline

2012-12-28

メモ：4次ルンゲクッタ法の局所打切誤差はステップ変えて計算して差をとって16/15倍

B.Carnahan, H.A.Luther, J.O.Wilkes, 1996: Applied Numerical Methods (Wiley,
藤田宏他訳, 1982) いわく、
4次ルンゲクッタ法の局所打切誤差はステップ変えて計算して差をとって16/15倍であると。
[§6.6 p.613 eq.(6.74)]

誤差が一方向に累積するという前提でいえば、ステップ変えて積分やっちゃって、差をとって小さければオッケーということになる。
なめらかで特性が変わらない関数ならそれでもいいんじゃないか。
おもしろいのは、そのあとで Collatz, L., 1960: The Numerical Treatment of
Differential Equations, Third Ed., Springer, Berlin. を引用して、動的ステップ幅制御は |(k3 - k2)/(k2 - k1)| が一定値以下になるように制御するとよいのだとい
う（記号は http://goo.gl/W6gxz とか参照)。これを組み合わせれば、なんちゃって誤差評価付きの積分ができそうな気がする。

なお、もちろん読者諸兄の被積分関数でそれが成り立つかどうかは請け合わない。ランダムにとてもでかい局所打ち切り誤差が積分区間のいろんなところで正負に発生してキャンセルしているならば、それが小さいからと言って何の保証にもならない。

2012-12-16

PubSubHubbub受信系作ってみて気がついたこと

少なくともグーグルのハブ実装では、ベリファイをしてくれたハブと違うIPアドレスから更新通知がやってくる。
更新通知は単にAtom FeedフォーマットがPOSTされるだけである。もうまったく何にも認証情報がない。つまり、中を開いてフィードのセルフリンクのＵＲＬが期待したものか確認するくらいしかない。
ＲＳＳフィードの中には、単一実体が多数のＵＲＬ別名を持っているものがあって、取得時に使ったＵＲＬじゃないものが中のセルフリンクになっているということになる。こうなるとかなりお手上げである。
そんな駄目フィードは購読できないよ、で、ま、いいか。

PubSubHubbub 受信プログラム作成中

このブログのＡｔｏｍフィードをテスト用に使っているので、記事が次々と現れて消えているがご容赦願いたい。

2012-11-30

FortranからCを呼ぶときの諸問題 @uwabami さんへ

https://twitter.com/uwabami/statuses/274207773250691072 というｔｗを受信したので、Fortran から C を呼ぼうとした場合の諸問題について知るところをまとめておく。

１．問題の解剖

・データ型の対応
・名前の対応
・引数順序の対応
・ランタイムがらみの話

２．データ型の対応

ちょっと考えでは無保証の荒野に放り出されるようであるが、意外とパズルの解は少ない。

Fortran には「INTEGER型とREAL型の幅が同じでなければならず、DOUBLE PRECISIONはその二倍でなければならない」という制約がある。そして、Fortranが実装されるような機械ではCコンパイラであってもIEEE 754のbinary32および
binary64型はどうせ実装されざるを得ないので、結局次の関係ができる。

REAL = binary32 = float
DOUBLE PRECISION = binary64 = double
符号付き32ビット整数 = INTEGER = int32_t ≒ int

反例は知らない。

int32_t は C99 でしか使えないので、実際には int を使うことになる。一見おっかないようだが、昔懐かし 16 ビットコンピュータか、ILP64 モデルでない限り int が 32 ビッ
トとみなして外れることはない。怖かったら typedef でもしよう。

３．名前の対応

実はこれが一番いやらしい。Fortranの名前が Cでどう見えるかには次の4通りが知られている。

: gfortran
全て小文字にして "_" を後置する。ただし、元の名前に "_" が含まれる場合は
"__" を後置する。
: Intel Fortran
全て小文字にして "_" を後置する。
: IBM XL Fortran
全て小文字にする。
: 旧Visual Fortran
全て大文字にする。

これを configure で判定するのがわりと常道だが、判定が外れるとリンクできないというリスクがあり、しかもどういうわけだかうまくいかないことが多い。個人的な趣味は、4種類のラッパーを作って .lib を作ってしまうこ
とである。

ところで、上記知見の重要な系：

Cで書かれたライブラリで、API関数名が全て小文字であるばあい、まったく同じ名前をFortranバインディングのAPIとすることは禁忌である。あなたはAIXの前で泣くか、かわいそうな犠牲者に石を投げられることになる。NetCDF がバージョン３で関
数名を変えたのも、NuSDaS の C API がすべて NuSDaS_ で始まるのもこのせいである。

４．引数順序の対応

Fortran の文字型引数は、データとともに長さも渡される。さてどうやって？
これは今日的には問題ではないかもしれないが、cfortran.h などのツールが第一に取り組もうとした課題である。

現在知られている Fortran 処理系では、文字型の引数を渡すにあたって、文字列の先頭へのポインタの次に文字列長を与える int の2つの引数を渡す。

SUBROUTINE SUB(I1, C, I2)
INTEGER:: I1, I2
CHARACTER(*):: C

というのがあったら

void sub_(int *i1, char *c, int c_len, int *i2);

になるというわけだ。しかし、文字列長引数を全ての引数の最後にまとめて置くという流儀があり、MS Fortran PowerStation ではこれがデフォルトだった。

void SUB(int *i1, char *c, int *i2, int c_len);

になるというわけだ。

５．ランタイムまわり

Fortran コードを書くならば、どうせメインは Fortran にする羽目になるものだ。

つまり、Fortran ライブラリ（文字列コピーや数学関数などの実体）だけでなく
Fortran ランタイム、すなわち main() としてコマンドラインや環境変数を受け取り、ファイル番号 5, 6 を開き、主プログラム（PROGRAM ... END）を呼び出すルーチンに依
存している機能が多いので、ランタイムをリンクしたくなるものである。

それはそれでいいが、メインを取られているということは、コマンドラインへのアクセスは Fortran の方法によらざるを得ないということだ。C から Fortran を呼ばねばならなくなるとリンケージ問題（上記３．）を必ず解決せねばならないし、文字列長が不明になるのは誠に腹立たしい。が、ま、しかたがない。

環境変数については getenv(3) が使えなくなる Fortran 処理系があるかどうか知見がない。たぶんないと思う。

もうちょっと嫌らしいのは、たいていの Fortran ランタイムはシグナルハンドラをフックするとか、OpenMPするとSIGFPEがマスクされる処理系があるとか、浮動小数点の丸めモードがある設定でないと動作保証しないFortranライブラリがあるとか、等々といった怪しいリソースだ。まあ、これらも知っていさえすればいいのだが。

2012-11-14

色覚についてのメモその4:NWSの配色

前項の続き。まずは準備、第三異常の混同色軌跡を描いてみる。

第三異常の混同色軌跡（カラーサークル視点）

（放射状というよりは平行な線に近いのに驚く。これは、RGB空間が人間の視覚の限界の実に狭い一部しか表現していないことを意味している）
つぎにこれがなるべく点に近くみえるようにRGB立方体を回転してみる。

2012-11-13

色覚についてのメモその３：資料追加、ＮＷＳサイトでみかけた配色

１．資料補遺。

混同色軌跡についてもうすこし資料的なページを見つけた。
http://www.med.teikyo-u.ac.jp/~ortho/med/pat/color.htm

第二異常の混同色軌跡の集積点はもうすこし正確に言うと x, y = 1.1, -0.07 付近のようだ。
（前稿の大勢に影響はないとおもうが）

また、第三異常の混同色軌跡の集積点は 400 nm 単色光付近にあるらしい。
(400 nm なら x, y = 0.1733, 0.0048)

２．気がついたこと

先日、元ハリケーン・サンディの関係で降水量の図を紹介した。
http://www.hpc.ncep.noaa.gov/qpf/zoom/Rainfall_Day_1.gif
かなり日本では見ない配色になっていて、いったいどういうセンスなんだろうと思っていた。

が、しかしこれはものすごく考えられているのではないかという気がしてきた。

いちど検算しないうちに図を示すのはためらわれるが、どうやらこの配色、三色視・第１異常〜第3異常のすべてにとって、それなりに弁別性がよいようなのだ。

誰も切り捨てまいとする態度に感服するとともに、おのが感覚を恥じる。

色覚についてのメモ２：色立体図

RGB 色空間は R, G, B それぞれに 0 から 255 までの数値の3つ組で、立方体型で描くことができる。どういう向きに描いてもいいのだが、三色視の人向けのデザインに有用なのは黒（0, 0, 0）と白（255, 255, 255）を重ねて置いて、周縁に飽和度の最も高い色、いわゆるカラーサークルが来るように置くことだ。

RGB色空間（カラーサークル視点）

前回の理屈で、混同色軌跡を描いてみるとこうなる（ただしY=1は大きすぎるのでY=0.33にした）。

2012-11-12

色覚についてのメモ：混同色軌跡

CIE xy 色度図上の混同色軌跡の図がある。（図4-4）
http://www.shikikaku.jp/explan/b-2.html

第一異常の場合は約 700nm単色光の位置から放射状に、
第二異常の場合はほぼ (x=1, y=0) の位置から放射状に線が延びている。
後者は X 等色関数が赤錐体の感度曲線に近いという散文的記述に対応する（資料は知らないが整合的である）。
前者はちょっとよくわからない。

参考：理科年表によると 700nm 単色光の色度は (0.7347, 0.2653, 0.0000)

いずれにしてもこれら集積点を通る直線を何本か引いて、x+y+z=1の関係とY=1で規格化して XYZ が得られたら、次のように線形変換をすることでこれをリニアＲＧＢに、
ついで Adobe RGB のような実用RGB値に変換することができるはずである。
http://w3.kcua.ac.jp/~fujiwara/infosci/colorspace/colorspace1.html

そうしたら、併用してはならない色の対が RGB で得られる。

とりあえず理屈だけ。

2012-10-12

(GMT) 地図上にポリゴンを描いて番号を振る

ちょっと実用に使ったのでメモ。

gmtset FRAME_WIDTH = 1p \
GRID_PEN_PRIMARY = thinnest,150 \
ANNOT_FONT_PRIMARY = 4

pscoast -P -R-180/180/-30/90 -JS140/90/5i \
-Bsg30 -Ggray -Dc -A10000 -K > plot.ps
psxy -R -J -A -L -W1p,blue \
-Sqn1:+a0+kblue+N0/-10p+l"1" <<EOF -O >> plot.ps
座標値列
...
EOF

こんなかんじでできる。

・上の例の -JS は中央経度140度の正軸平射図法。

・psxy に -A をつけないと、ポリゴンの辺は大圏になる。（気象のラージスケールだから、ええと地理では逆で…）小縮尺の地図では曲がって見えたりするので、本当に多角形を描きたい場合は -A をつける。

・逆にメルカトル投影面上のポリゴンを平射図法の地図上で表現したい場合など、辺が大圏になっていると近似がよくなる（ポリゴンの頂点数を減らせる）こともある。

・ポリゴンに文字を付すには psxy に -Sq をつける。

・-Sq の後の n1: は文字を打つ数。１なら両端の中間あたりに描く。

・+a0 は文字をアップライトにしてくれる。デフォルトでは両端を結ぶ線に平行に置かれる。

・+l の後の文字列が印字される。文字の色は +k で指定する。
　文字の位置をずらすのは +N のあとにオフセットをつける。

・枠を消したいのだが、 FRAME_WIDTH = 1p が限度だった。

2012-10-09

CF-netCDFデータモデルのOGC投票実施中

情報元：
https://groups.google.com/d/topic/wmo-ipetmdi/y676sQkiWXY/discussion

採択されるべき文書
https://portal.opengeospatial.org/files/?artifact_id=50139

文書が公表されているとは知らなかった。背景概観：

・OGC 標準リスト http://www.opengeospatial.org/standards/is をみると、netCDF関係では既にファイルフォーマットが2件（クラシック形式とNC4）成立していて、これに CF が加わって初めて完成ということに
なる。上記いずれもISO化はいまのところ具体化していないはず。

・WMOでの作業について、スティーブは婉曲に relevance といっているが、もちろん関係ないわけがない。理想的には、ＣＦ（気象学界）と通報式（現業気象界）の対比総合を、さらに地理情報の言葉で表現するという二段階の離れ業が求められる。実際には一段階もできればいいところなのではあるが。

内容面、ＣＦと地理情報の世界のつきあわせというのも、見ていておもしろい：

・まず、規定と抽象テストスイートの対からなる構成は、まあよくがんばったんだろうと思う。
　そもそも、ファイル形式の標準と異なり、ＣＦは意味と表現形式を対応付けるものだから、本質的に困難がある。形式はテストできるが、「座標Xに値を与えた俺の意図」なんてものはコンピュータにかけられないので、意味をテストすることはできないからだ。
　さはさりながら、無限定の netCDF に比べて、CF準拠のデータセットには相当の形式上の限定がある（あたかも、無限定の XML に比べて XHTML 文書には相当の形式上の限定があるよう
に）のだから、そこを確認することはできるし、テストスイートの仕事はそれでいいのだ。
　規定本文では全力で意味的規制をしておいて、テストでは形式上テストできることに抑制する書き分けは、いままでのＣＦ文書にはなかったのだから、いくらＣＦチェッカという先行知見があるにしていも大変だったろうと思う。
　ちなみに、ＷＭＯコアメタデータプロファイルでは、そういった書き換えが容易でないので、いちど規定本文を御破算にして形式的テストだけから組み直している。決してほめられた話ではないが。

・まあ、たまには不思議なところがあって、鉛直座標変数の単位は、圧力・長さに加え「ある条件のもとでは」密度や温度「など」も使える「かもしれない」（may）という輪郭のふやけた要件が「ねばならない」（shall）で強制されるというのは、いったいどう実装したらいいのか私にはわからない。

・水平軸 X や Y が複数あってはいけないという規定がないようだが、それを言い出すと時間軸 T が複数という例がでてきて時間軸の使い分けに話が発展し、WCS方面に引火
して収拾がつかなくなるのでいわないのだろうと思った。

・投影面上の格子を表現するための記法は、ＣＦ１．４あたりからの伝統的な形式によっている。測地系を特定せず、地図投影法だけを指定する、気象界独自の伝統（？）である。
　ＧＩＳユーザからこれでは困るという声はあるのだが、ＣＦ形式との差分が何であるかを説明できる者がおらず、ＷＫＴをそのまま入れればいいじゃないかというコメントになって、失速してしまった。極端には、ＷＫＴだけをメタデータとして入れればよく、ＣＦ形式の投影法記述を廃すればよいという声もあったように思うが、今回のＯＧＣ標準の成立によって、そこまで破壊的にはならないという一定の歯止めがかかったといえよう。

2012-10-02

GMTのチュートリアルを（一部）やってみて

GMT のチュートリアルをやっている。

http://gmt.soest.hawaii.edu/gmt/html/GMT_Tutorial.html

これがまたずいぶん不親切で、たぶんひとえに私が斜めに読んでいるからではあろうが、なるほど、ボットのお兄ちゃんが挫折するわけだとも思う。リファレンスを探しまくるはめになって教育的なので、これはこれでいいのかもしれないが。

で、はまったところは速やかに忘れるのでメモすべきである。

・長さを指定しろと言われるのだが、単位の指定仕方が i 以外わからないので気味が悪い。

→ リファレンス 4.1 "GMT Units" を見よ。
http://gmt.soest.hawaii.edu/gmt/html/GMT_Docs.html#x1-370004.1

・チュートリアルは各コマンドのマニュアルページにリンクしているが、そこではオプションの詳細が略されているところが多く、行き詰る。

→ 地図投影法はリファレンス 6.
http://gmt.soest.hawaii.edu/gmt/html/GMT_Docs.html#x1-900006

　→ ただし正距円筒図法はリファレンス 5.1.1.
http://gmt.soest.hawaii.edu/gmt/html/GMT_Docs.html#x1-830005.1.1

　→ その他のオプションはリファレンス 4.4.
http://gmt.soest.hawaii.edu/gmt/html/GMT_Docs.html#x1-420004.4

　地図を描くために（＝pscoastコマンドでは）正距円筒図法の経度のどこかに g または d のサフィックスをつける必要があるのだが、何故そんな意地悪を、とおもって
みたら、システム的必然性（360周期性を指示してやる必要）があると知って納得。

・おそらく文化ギャップで英語が読めないだけだけど、正距円筒図法には2種類のオプションがある。

　-Jx3c ... 軸の単位長さを 3cm にする。この単位長さを scale と呼ぶ（多分地理業界でもそうなんだろう）
-JX3c ... 軸の全長を 3cm にする。

　がんらい -JX だけあれば用は足りるはずだが、サイズいじょうに縦横比に興味がある場合は -Jx のほうが便利だろう。

・オーバーレイアプローチ、GMT の操作体系の根幹であろうに、ずいぶんざっくり説明している。
まず示されるコマンド例らしきもの

psxy data -R -J -B -P -K -Wthinner > plot.ps
psxy data -R -J -O -W -Si0.2i >> plot.ps

はこのままでは動作しない。少なくとも -R -J のあとにパラメタを指定しないといけないことは、ここまでチュートリアルをやってくればわかるのだが、さてこの例が伝えたいメッセージがよくわからないので行き詰るか、これは何かスキマティックな例だろうとおもって読み飛ばして、結局あとでもわからない。

　→まず、複数コマンドでオーバーレイするときは -K および -O オプションを使う必要がある。
　http://gmt.soest.hawaii.edu/gmt/html/GMT_Docs.html#x1-530004.4.6
　後続コマンドがあるときは -K を、先行コマンドがあるときは -O を指定する。

　→先頭コマンドでは -R や -J にパラメタをつけないとエラーになるが、後続コマンドではなぜか先行コマンドと同じ値に補完される。
　もちろんそれはテレパシーにより時とプロセスを超えて情報が伝わ…るわけがなく、リファレンスにもはっきり書いていないが、設定ファイル .gmtdefaults4 は各回起動のたびに引き継ぐべきオ
プションの履歴が書き込まれるのである。
　http://gmt.soest.hawaii.edu/gmt/html/GMT_Docs.html#x1-390004.2.1

そして -B -P は何度も指定しなくてよい。 -B はともかく -P は情報を伝える場所がない。
単純に ps ファイルの先頭に何か書いたら、あとでも有効ということだろう。
そんなわけでこんなふうに呼ぶべきなのである。

psxy data -R略 -J略 -B略 -P -K -Wthinner > plot.ps
psxy data -R -J -O -W -Si0.2i >> plot.ps

2012-10-01

日立評論9月号特集「想定外」に備える社会インフラ安全保障技術

日立評論9月号は『特集「想定外」に備える社会インフラ安全保障技術』と題している。
http://www.hitachihyoron.com/2012/09/index.html

その中、「社会安全保障のための防災管理ソリューション」 http://www.hitachihyoron.com/2012/09/pdf/09a02.pdf
(CAPじゃなくて) EDXL-DE と公共情報コモンズ形式（これも大枠EDXL）で何かしたらしい。

もうひとつ、「不測事態への柔軟な対応を可能にする広域連絡システム」
http://www.hitachihyoron.com/2012/09/pdf/09a04.pdf
これ自体は災害時に自衛隊内・自治体等の電話をマイクロ回線上のIP電話で補完するという話なんだけど、
序文にいう相互接続性の向上や動的構成変更による災害時補完というのは、上のペーパーでもふれているように、きょうび整備されるべきインフラは音声通信に留まるべきでないと日立も見通して書いているわけだろう。

オープンデータ関係めも

オープンデータ流通推進コンソーシアム http://www.opendata.gr.jp/index.html
というのができていて、第1回利活用・普及委員会がさる28日にあって諸省庁がオブザーバとして参加したらしい。

togetter ができているのは大変ありがたい http://togetter.com/li/381006
が、正直どんな話をしたのかはよくわからない（小生が文脈をつかめていないということもあるだろう）。いや、まあ、 ust
聞けといわれればそのとおりなんだけど、平日真昼間に ust 何時間もってのはちょっと簡単ではないのですよ。そのうち何らかの資料がでてきたら
togetter と見比べて理解しやすくなるだろうか。

togetter のありがたいところは、関連して3月にGLOCOMがやった「オープンデータに関する欧州最新動向と日本における可能性」も紹介してくれたことだ。
こちらは、話の要点がうまくツイートされている togetter.com/li/277035

KDDI の電報も ZCZC...NNNN だった

KDDI の電報サービスの案内をはじめてみた。
http://www.kddi.com/personal/kokusai/service/denpo/index.html

使える文字は、CCITT ITA2 文字セットを強くうかがわせる。
http://en.wikipedia.org/wiki/Baudot_code#ITA2
http://www.itu.int/rec/T-REC-S.1-198811-S

で、フォーマットの例をみて驚いた。
http://www.kddi.com/personal/kokusai/service/denpo/pdf/denpo_sample.pdf
ZCZC で始まって NNNN で終わる、少なくともこの部分は CCITT ITA2 の場合の気象電文と同じ。
これは WMO ローカルルールというより、公衆電報を含めた広い電信の規則だったのね。

2012-09-28

NCEP意見公募：GDAS2（T62σ28層互換プロダクト）終了

NCEPさんも随分また古いプロダクトを維持してきたもので。

http://www.nws.noaa.gov/os/notification/pns12gdas2_removal.txt
Subject: Soliciting Public Comments through November 2, 2012,
on the Removal of NCEP's Legacy Global Data
Assimilation System

なんでもR40からT80に移行するときに（おそらくデータが大きすぎて）ついてこれないユーザに対応するために、T62データを作りだしたんだそうで、まあしかし現業はT80からどんどこ高解像度になって、今はT574L64で解析したのを変換していたのだそうです。

2012-09-26

NWS運用お知らせ - タイムゾーンが違っていたよ

NOUS41 KWBC DDHHMM
http://www.nws.noaa.gov/os/notification/scn12-32shef-crex.txt

まずもってヘッダの日時欄が「DDHHMM」となっていて、よくこれで届くなと思うのですが、まあおいといて、
五大湖地方の潮位（水位？）データがＣＲＥX通報式で出ていたのだけど、時刻がローカルタイムで出ていたので通報式と相違するからＵＴＣに変えるよ、というお知らせ。

余談になるが潮位のページがグーグルマップ連動で地点時系列を表示するようになっていて大変かっこいい。
http://www.tidesandcurrents.noaa.gov/index.shtml

天文単位の記号が au に

８月に北京で開かれていたIAU総会で、
天文単位の単位記号を "au" にすべしという IAU 勧告がでたらしいです。

http://www.iau.org/static/resolutions/IAU2012_English.pdf

すると気になる整合性ですが、

JIS X 0124 付表１ 1-3 第一形式（小文字許容）は "AU" であるようです。
いまさら改正できるかどうか。まあ、廃止しないでくれれば御の字です。

http://kikakurui.com/x0/X0124-1993-01.html

一方 netCDF 方面で使われる UCAR udunits.txt ですが、もとから "au" であるようです。

http://www.unidata.ucar.edu/software/udunits/udunits-1/udunits.txt

というわけで、実用上の問題はないようです。

ところで、IAU 勧告の下のほうで、近地球物体の国際早期警戒体制を IAU, UNCOPUOS
と ICSU で作るというようなことが書いてありますね。アーカイブ指向の ICSU WDS
と違ってリアルタイム指向の業務であるだけに、関係はどうなるのでしょうか。

ECMWFの描画ツール Metview が OSS 化（Apache ライセンス） & Unidata IDV 3.1 リリース

MetView
https://software.ecmwf.int/wiki/display/METV/Home

GRIB, BUFR, NetCDF が読めて、みなさんおなじみの絵が描けるようです。
Linux または AIX でコンパイルできます（要 Fortran, Qt & Motif）。

New Features of IDV 3.1
http://www.unidata.ucar.edu/blogs/news/entry/idv_3_1_new_features
新機能はいろいろあるようですが、まあブログみてください。

どっちも試していませんがとりあえず。

2012-09-18

NuSDaS 1.3 ドキュメントでのランベルト正角円錐図法の表式（訂正）

NuSDaS 1.3 ドキュメント付録C「2次元座標系と地図投影法パラメタ」のランベルト正角円錐図法の表式（p.153）に誤りがあることがわかりました。
http://www.mri-jma.go.jp/Project/cons/nusdas13.pdf#page=153

式 C.18, C.19, C.20 で tan の冪乗の符号（それぞれ -n, -n, n）が逆になっています。プログラムに間違いはありません（もしあったら天気図に深刻な乱れが起こるので、気がつかないわけがないですが）。

ご迷惑おかけいたします。申し訳ありません。

別に使うわけでもないけど調査：Android 4.0 のシステムフォントは roboto という

Android 4.0 以降のシステムフォントは roboto というらしい。

http://www.itmedia.co.jp/news/articles/1111/11/news029.html

TTF は apache ライセンスで入手できるので、開発環境を持っていなくても、どんな文字が含まれているかみることができる。

http://www.fontsquirrel.com/fonts/roboto

2012-09-06

Windows の DEBUG.EXE で小さなコマンドを作る方法

いままで w の使い方がよくわからなかったが次をみつけた。

http://illegalargumentexception.blogspot.com/2008/05/assembler-using-debugexe-to-write-dos.html

C:\DOCUME~1\USER>debug
-a
2D0B:0100 mov ah,07
2D0B:0102 int 21
2D0B:0104 mov ah,4c
2D0B:0106 int 21
2D0B:0108
-n batkey.com
-rcx
CX 0000
:0008
-w
00008 バイト書き込み中.
-q

C:\DOCUME~1\USER>batkey
← @ を打ってみる
C:\DOCUME~1\USER>echo %errorlevel%
64

OGC Met-Ocean DWG で Carl Reed が珍しくウェルカムメッセージを書いていた。→ NOAA Web GIS

ブログや用語集くらいはわりと一見さんでも役に立つのではないかと思う。
http://lists.opengeospatial.org/pipermail/meteo.dwg/2012-September/001024.html

で、OGCブログというのを眺めていたら、
「2011/2012 HPCC Incubator Project: An Enterprise GIS Web Services Hosting
Environment For NOAA 」 http://www.opengeospatial.org/blog/1665
というエントリが眼をひいた。Web GIS で NOAA の各種情報を提供しますというのである。

台風トラックなんかがあるから、一瞬 NWS が本気出したか、と焦ったが、まあ気象データの範囲を見る限り、大容量・高次元データは避けられていて、NWS の知らないところで、GeoServer で無理なくでき
る範囲（がどんなもんだか知らないが）ということであるらしい。

2012-08-10

IUGONET 中間報告会のノート（とりあえず書けるだけ）

体調悪いといいながら、結局いってきてしまった。
http://www.iugonet.org/meetings/2012-08-09.html
迷惑でなければいいのだが。

主にアーキテクチャについてメモ。

【メタデータといっているものには、データセット、グラニュル（granule：伝送最小単位）、連絡先、測器などの型があり、おなじデータベースがそれらを一手に扱う】

歴史的に別のデータベース＝別の管理組織があったりすると、こうすっきり構成できないから、うらやましい。

グラニュルのメタデータDBは、WISでいうとGISCキャッシュの内部にあるデータベースに相当する。そんなものを交換するDBがスケールするのか疑問である。もっというとDB更新時間がリニアに増えているそうだから、いつかデータ増によって更新が追いつかなくなる。
WISではリアルタイム共有データの保存期間を２４時間しか保証していなくて、長期的参照は別途コンパイルした結果であって膨大なファイル数からは解放される前提。

【これらメタデータの相互リンクは spase://IUGONET/ で始まるURLで行う】

公式のスキームじゃないことが連合大会で突っ込まれていたけど、ま、ぼくはどうでもいい。

【ＤｓｐａｃｅはＸＭＬを直接扱えないので変換している】

しらんかった。逆に一安心でもある。

【連想検索検討中】

成果のほどについて期待している

【メタデータの履歴をＧｉｔで管理、置き場はｇｉｔｈｕｂ】

履歴は必要、検索で引っかかる必要はない、という要件がよく分析されている。
置き場は、プロジェクト終了後も維持できるように考えたたものだという。
自然にクラウド化していてうらやましい。

…ねむくなったのでとりあえずだす

2012-08-06

(GRIB1) wgribにローカル定義パラメタを認識させる方法

wgrib のローカル定義は次で説明されている。

ftp://ftp.cpc.ncep.noaa.gov/wd51we/wgrib/usertables.txt

要は、適当なファイルに

-1:74:2:158
201:U:eastward wind
202:V:northward wind
-1:74:2:160
222:PSEA:sea-level reduced pressure

などと書いて環境変数 GRIBTAB で指すか、ローカルの gribtab という名前にすればよいらしい。

2012-07-31

ファイルを年月を含んだ名前に変えるバッチファイル

本当は Windows PowerShell 使えるようになりたいんだけど…

CD /D %~dp0
set y=%DATE:~0,4%
set m=%DATE:~5,2%
for %%f in (inbox sent) do if exist arch\%%f%y%%m%.pdf (
echo %%f skipped
) else (
echo ren %%f.pdf arch\%%f%y%%m%.pdf
)

[Fortran] 実在しない省略可能な仮引数を自動割付け配列の上下限にすることについて

なんかつじのさんがはまっているのでメモ

- https://twitter.com/TSUJINO_SATOKI/statuses/230263952209231872
- https://twitter.com/TSUJINO_SATOKI/statuses/230264236356558848

さて、これはダメなのはわかりますが Fortran 規格は何もいっていないのでしょうか。

JIS X 3001-1:2009 （いわゆる Fortran 2003）のいうには：

5.2.1.5.1 形状明示配列
C542 (R511) 上下限が初期値式でない形状明示配列は、副プログラム又は引用仕様本体の中でだけ宣言できる。

おや、制約ではありませんね。で、読み進めると、

形状明示配列が初期値式でない上下限をもつとき、その上下限及び配列の形状は、手続に入る時に、その上下限の式を評価して決まる。

といっています。べつにOPTIONAL属性があってはいかん、とはいっていません。
配列がダメなら手続だ、ということで12章にいくと、

12.4.1.6 実在しない仮引数に関する制限
(中略)
実在しない省略可能な仮引数は、次の制限を受ける。
(中略)
(1) 実在しない省略可能な仮引数がデータ実体である場合には、その実体は引用も確定もしてはならない。(後略)

というんですね。データ実体てのは変数とか引数とかです。引用の定義が気になりますね。

2.5.6 引用
データ実体引用 (data object reference) とは、実行中のその時点での値を要求する形でデータ実体特定子を書くこととする。

というわけで、回りくどいですが、実在しないときだけダメなことがわかりました。

しかし不親切ですね。実際問題、自動割付け配列の上下限に使ってしまったら最後、その引数は省略できないのですからオプショナルにする意味はないので、こんな無茶な用例には警告を出すよう、コンパイラベンダーに文句をいうことはできないのでしょうか。

実はお願いはできても文句は言えません。

1.5 規格合致性
(中略)
(3) 識別番号の付いた構文規則及び制約によって認められていない拡張された形
又は関係 [付属書Bで規定する廃止事項(1.8.1)を含む。] を使用しているプログラム単位について、その使用を検出し報告する能力を持つ。
(後略)

つまり、構文規則でも制約でもない「してはならない」は、プログラマに対して禁止しているだけで、コンパイラベンダーに対しては、報告しなくてもいい、結果プログラムがセグフォしようがOSクラッシュしようが好きにしてよいといっているわけですね。

残念ですが、そういうものです。

2012-07-27

JRA25のGRIBエンコーディング

JRA25のデータはGRIB第1版で提供されているのだけれど、ちょっといろいろあります。

http://www.sci.u-toyama.ac.jp/earth/j-kawamura/hayasaki/data_list/JRA25_memo.html 要素が重複？
http://ruby.gfd-dennou.org/ml/2009/msg00071.html 経度ずれ
http://rda.ucar.edu/datasets/ds625.0/docs/index.html いろいろ問題

通報式関係者としては誠に申し訳ない次第です。

もし、ほかに何かご存じの方がありましたら、教えていただければありがたいです。JRA25そのものは今からどうにもなりませんが。

2012-07-18

CCSDS szip compression

GRIB2 には伝統的なビットパックだけではなく、ロスレス・ロッシーともに多様な圧縮が選べるようになっている。たとえば JPEG2000, PNG, JMA-RLE など。当然、圧縮方式（コーデッ
ク）に対応していなければ、GRIBの概形が読めても実際には使えないわけで、MPEGやＴＩＦＦのようなコンテナフォーマットに近い性格に進化しているということもできるだろう。

それに CCSDS szip というのを追加しようというドイツ提案が、２００８年からたなざらしになっている。
http://goo.gl/iRFfh (Word .doc)

正直、これ以上複雑度が増すのは望ましくないので、あまりプッシュしたくないのだが、このアルゴリズム自体についてちょっとググってみたのでメモしておく。

学会予稿らしきもの：性能を訴えている
http://esto.nasa.gov/conferences/estc-2002/Papers/A3P2%28Yeh%29.pdf

HDF のホームページ：そう、HDFで使っているのだ。
http://www.hdfgroup.org/doc_resource/SZIP/index.html

つまり、netCDF4でも内部で使っているんだっけ？
http://www.unidata.ucar.edu/software/netcdf/docs/netcdf/NetCDF_002d4-Format.html
いや、使ってない。ライセンス問題があるので切ったらしい。

一応：

GPLv2実装がある模様。
http://en.sourceforge.jp/projects/sfnet_ter/
HDF5ライセンス自体は、４条項ＢＳＤに１つ追加した、よくわからないライセンス。これに含まれるのかな？？？
http://www.hdfgroup.org/products/licenses.html

2012-07-17

Microsoft Terraserver 閉鎖

Microsoft Terraserver が５月に閉鎖されていたんだそうだ。
https://list.terc.edu/pipermail/edgis/2012-July/002324.html

本家のアナウンス：
http://msrmaps.com/About.aspx?n=AboutShutdown
（Tuesday, May 1, 2010 と書いてあるが、曜日からして 2012 の間違い）

米国の地形図とオルソ写真が見られるサイトだった、はず。日本に来てからはすっかり忘れていた。

まあ、Bing Maps に役割をゆずったということだし、元来は SQL Server のデモだったらしいから、名誉ある引退と呼んであげていいのだと思う。

Space weather metadata in CF-netCDF

GOES の宇宙天気の image データについて CF でどうやって表現したらいいかという議論がおこっている。

http://mailman.unidata.ucar.edu/mailing_lists/archives/cf-satellite/2012/msg00041.html

CF では枠組が定かでない多種のメタデータを表現したいようなのだが、データの位置とは言い難い座標値っぽいものが多数ある。

ECI & ECEF 座標というのは、それぞれ SPASE http://www.spase-group.org/docs/dictionary/spase-2_2_2.pdf で Geocentric Equatorial Inertial ＆ Geocentric Corotating といっているものと同じだろう。別の業界で違う名前なのは結構だけれど、共通語を決めてもらわないことにはどうにも話が動かない。

あと、物体の回転を指示するのに quaternions というものを使うらしいのだが、ぐぐってみると http://adsabs.harvard.edu/abs/2006cosp...36.3034S　とかひっかかって、本当にハミルトンの４元数で回転角を表現するものであるらしい。難しそう…

ところで、 CF-metadata のログ http://mailman.cgd.ucar.edu/pipermail が落ちているので悩ましい。あんまりしょっちゅうブライアンにメールするのもためらわれるし。

2012-07-06

WDC for Meteorology

WDC for Meteorology http://www.ncdc.noaa.gov/oa/wdc/index.php は NCDC がやっている。なぜか NCDC は NESDIS の機関なのね。

単なる WMO WDC だと思っていたのだが、2011年９月に ICSU WDS に参加したのだそうだ。

つまり、WMO と ICSU 共管のような状態になっている。Considering that meteorology is best coordinated at the international level by one responsible international organization,　（WMO条約前文）とはいうけれど、どうしたって境界はある。ここらへんが境界だということだろう。

2012-07-04

エクセター OGC TC での cf-netcdf

Galeon にメールが来た。
http://www.unidata.ucar.edu/mailing_lists/archives/galeon/2012/msg00007.html

パブリックコメント期間が無事終了した。まあ、コメントがないことを喜んでいいのかどうかはわからない。

誰かはわからないが、ISOメタデータとの関係を問うたのだという。
まあ、ncISO
http://www.ngdc.noaa.gov/eds/tds/
で出力できるからいいよね、という話ではあるんだけど、WMO Core Metadata
Profile との harmonization はいらないんだろうか。

登録: 投稿 (Atom)