ちょっと実用に使ったのでメモ。
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-12
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方面に引火
して収拾がつかなくなるのでいわないのだろうと思った。
・投影面上の格子を表現するための記法は、ＣＦ１．４あたりからの伝統的な形式によっている。測地系を特定せず、地図投影法だけを指定する、気象界独自の伝統（？）である。
ＧＩＳユーザからこれでは困るという声はあるのだが、ＣＦ形式との差分が何であるかを説明できる者がおらず、ＷＫＴをそのまま入れればいいじゃないかというコメントになって、失速してしまった。極端には、ＷＫＴだけをメタデータとして入れればよく、ＣＦ形式の投影法記述を廃すればよいという声もあったように思うが、今回のＯＧＣ標準の成立によって、そこまで破壊的にはならないという一定の歯止めがかかったといえよう。
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
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.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
というのができていて、第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 ローカルルールというより、公衆電報を含めた広い電信の規則だったのね。
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 ローカルルールというより、公衆電報を含めた広い電信の規則だったのね。
登録:
投稿 (Atom)