気象業務支援センター http://www.jmbsc.or.jp/hp/book/g_j0080.htm によると、
配信資料に関する技術情報 381〜384 号が発売になったそうです。
数値予報関係では次のものが含まれます：
383 週間アンサンブル予報システムの高度化について
382 平成26年3月からの1か月予報及び異常天候早期警戒情報の発表日変更と配信資料変更について
2013-11-25
CVE-2013-4164 と RHEL5
ぐぐって出てきたredhatのチケットトラックらしきものをみて、viewvcをみにいくと、差分はこんな感じであることを知る。util.cのruby_strtod()に問題があるという。この書き方は、1.9.3 の最新版だけでなく、1.8.7 の最新版で同じようになっていることがわかる。
ところが、RedHatの最新版は、
ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Client/en/os/SRPMS/ruby-1.8.5-31.el5_9.src.rpm
とかいうのである。たぶん（私は保証せんよ）。
emacs必要とかいうのでビルドする気をなくしたが、 1.8.5 のリビジョン10553あたりからとられているようである。そこでは、同じループがなく、仮数部が長すぎる場合に無視するようなコードになっている。
それが何を意味するかは、みなさんの責任でご判断ください。
（追記）
RHEL チケットトラックのコメント6番にも書いてあった。
2013-11-18
「パーフェクトRuby」読書メモ - 最初の見開き
買ったから、古びないうちに無理にでも読まないともったいない。ちょっとづつメモしていきますよ。たぶんすぐめげると思うけど。
最初の見開き、最初の例がこれ。
すごいですねえ。 そうこなくっちゃいけませんね。いや、もちろん、その次に、3行目だけを取り出したものが手続き型の例だとしてつづくのですが。
あとは、String.ancestors とか何気に表示させているのも、クラス構成の重要なところを早めに出す工夫としてよろしいのではないかと。
どうでもいいですけど、String はもう Enumerable じゃないし、Kernel の下に BasicObject はあるし、古き良き 1.8.7 よさらば、なんですが。
最初の見開き、最初の例がこれ。
class Sample
def say
puts 'Hello, World!'
end
end
sample = Sample.new
sample.say
すごいですねえ。 そうこなくっちゃいけませんね。いや、もちろん、その次に、3行目だけを取り出したものが手続き型の例だとしてつづくのですが。
あとは、String.ancestors とか何気に表示させているのも、クラス構成の重要なところを早めに出す工夫としてよろしいのではないかと。
どうでもいいですけど、String はもう Enumerable じゃないし、Kernel の下に BasicObject はあるし、古き良き 1.8.7 よさらば、なんですが。
2013-11-12
示量変数と積分量は格子点データによろしくないと思うが中々皆さん理解してくれない
示量変数 extensive quantity と示強変数 intensive quantity というのは、物理量が空間の測度あるいは媒体の量に比例するようなものであるか、あるいはそうでないかという区別である。たとえばひとかたまりの物体のエネルギーや質量は、それを半分に分ければ半分になるが、温度や圧力は半分にわけても半分にはならない。
格子点データには示強変数が通常は用いられる。温度が5 km格子で与えられているとして、10 km格子が欲しければ、単に間引けばよい。格子の数は1/4になるが、格子点が同じ場所になるなら同じ値が使える。
これが示量変数、質量や、もうちょっと気象らしい例でいうと降水量を格子セル内に降った水量 kg とかで与えてしまうならば、間引きや他の投影法についての格子変換は複雑にならざるを得ない。示量変数は面積や体積で割ることで、示強変数になる。降水量でいえば kg のかわりに kg.m-2 を用いればもう間引きは心配いらない。
時間次元でも似たような問題があって、積分量（たとえば降水量 kg.m-2）のかわりに降水強度（kg.m-2.s-1）を用いたならば、いつからいつまで積分したかを明示する必要がある。
まあ、そうは言っても積分量を使いたい人は多いので、積分区間を明示するしかないのである。
ところで、河川流量の格子点データで単位 m3.s-1 を使いたいという話をきいて仰天した。きいてみると、モデルが変わっていて、本来は線（一次元）地物としてあらわしたほうがよさそうな地形を格子点の列であらわし、流れのない格子は欠損値にするんだという。
http://www.emc.ncep.noaa.gov/mmb/nldas/drought/Stream/
こんなのでいいのか、と言いたくなってはくるが、さて何が悪いか言うのは難しい。
格子点データには示強変数が通常は用いられる。温度が5 km格子で与えられているとして、10 km格子が欲しければ、単に間引けばよい。格子の数は1/4になるが、格子点が同じ場所になるなら同じ値が使える。
これが示量変数、質量や、もうちょっと気象らしい例でいうと降水量を格子セル内に降った水量 kg とかで与えてしまうならば、間引きや他の投影法についての格子変換は複雑にならざるを得ない。示量変数は面積や体積で割ることで、示強変数になる。降水量でいえば kg のかわりに kg.m-2 を用いればもう間引きは心配いらない。
時間次元でも似たような問題があって、積分量（たとえば降水量 kg.m-2）のかわりに降水強度（kg.m-2.s-1）を用いたならば、いつからいつまで積分したかを明示する必要がある。
まあ、そうは言っても積分量を使いたい人は多いので、積分区間を明示するしかないのである。
ところで、河川流量の格子点データで単位 m3.s-1 を使いたいという話をきいて仰天した。きいてみると、モデルが変わっていて、本来は線（一次元）地物としてあらわしたほうがよさそうな地形を格子点の列であらわし、流れのない格子は欠損値にするんだという。
http://www.emc.ncep.noaa.gov/mmb/nldas/drought/Stream/
こんなのでいいのか、と言いたくなってはくるが、さて何が悪いか言うのは難しい。
2013-10-15
尺度水準とデータベースのキー、あるいはハッシュ・二分木・配列の使い分け
あたりまえっていえば、あたりまえなんだけど。
量的指標の尺度水準というものがある。実数でなにかを表わそうとするときの表現の仕方を分類したもので、扱いがこれにより異なる。定義はウィキぺを見てもらうとして、これらは記号に許される2項演算子のセットに根がある。
説明するまでもなく、配列モデルの適用条件が美しくない。なにかまったく違った整理をすれば美しい数理が見えてくるのかもしれないと数日考えていたが、とりあえず今の私にゃ無理だ。
量的指標の尺度水準というものがある。実数でなにかを表わそうとするときの表現の仕方を分類したもので、扱いがこれにより異なる。定義はウィキぺを見てもらうとして、これらは記号に許される2項演算子のセットに根がある。
- 名義尺度
- ２つの値の比較が↑できない↓できる
- 順番尺度
- ２つの値の差を計算すること（減算）が↑できない↓できる
- 間隔尺度
- ２つの値の比を計算すること（除算）が↑できない↓できる
- 比率尺度
- ハッシュが使える
- ２つの値の比較が↑できない↓できる
- 二分木が使える
- 次の３つが仮定↑できない↓できる
- ２つの値の差を計算できる
- その間にいくつの他の値が入りうるか算出できる
- 値の分布を最大値から最小値まで見たときに「空き地」がもったいないと思うほどは多くない
- 配列にいれておける
説明するまでもなく、配列モデルの適用条件が美しくない。なにかまったく違った整理をすれば美しい数理が見えてくるのかもしれないと数日考えていたが、とりあえず今の私にゃ無理だ。
2013-10-03
表題・概要の指針、つづき
（ちょっとまとまりが悪くなります。）
前回みたように、内容は充実していたほうがいいが、適切な長さというものがある。また、一群の類似したデータには一貫した命名がなされることが望ましいので、つまりは分野ごとに一貫した命名法を作ってほしい。既にテーブルの上にある案はそのたたき台であり、いくらか取捨選択がなされるべきである。
案というのはこういうもの：
運用メタデータの title に現れる語を抽出し、出現回数順でトップ１５０まで手作業で分類してみた。
むろん主観的であることは免れないが、何か見落としはないかチェックするという意義はあるだろう。提案済みの４分類、それから ISO 19115 の構造とキーワード種別、さいごに Volume C1 の列との対比を考えるとこのようになる。
要は、４Ｗのそれぞれについて、もっとも典型的な類型ではない語を追加する余地があるのと、ＧＴＳヘッダのようなデータ名略号については４Ｗでなくても追加を検討しうるということがいいたい。
ただ、RTH については書かない方がいいと思うんだけど。
記入項目の再検討
前回みたように、内容は充実していたほうがいいが、適切な長さというものがある。また、一群の類似したデータには一貫した命名がなされることが望ましいので、つまりは分野ごとに一貫した命名法を作ってほしい。既にテーブルの上にある案はそのたたき台であり、いくらか取捨選択がなされるべきである。
案というのはこういうもの：
- 表題はwhat, where, who, when から構成すべし
- when は予報期間と有効期間を混同しているように思われる
- 語順は厳密でない
- 長さ制約については、内容を迅速に把握できるように、との一言がいちおうある。
- それに対して、内容充実については、重複回避について言及していないが、 多義語を避けるべきとの言葉はある。
- 概要は
- 冒頭１文１パラがwhat
- 中パラが詳細（内容、精度、作成組織など）
- 末尾１文１パラがデータフォーマット
- 安易に 5W1H といわず、why と how を省いている。強いていえば why はデータ作成の根拠となる国際計画にあたり、how は提供方法といえなくもないが、それは表題にあるべきではない、ということを暗黙にいっていることになる。計画間でデータ再活用を促進するための学際計画なんだし、提供方法自由度や流通範囲をデータに強く紐づけせず、拡大すべきだからである。
- 残る４Ｗをすべて概要で繰り返すのではなく、what に力点を置き、おそらくそこから漏れたフォーマット情報を末尾に置かせるなど、工夫の形跡がある。
運用メタデータの title に現れる語を抽出し、出現回数順でトップ１５０まで手作業で分類してみた。
むろん主観的であることは免れないが、何か見落としはないかチェックするという意義はあるだろう。提案済みの４分類、それから ISO 19115 の構造とキーワード種別、さいごに Volume C1 の列との対比を考えるとこのようになる。
要は、４Ｗのそれぞれについて、もっとも典型的な類型ではない語を追加する余地があるのと、ＧＴＳヘッダのようなデータ名略号については４Ｗでなくても追加を検討しうるということがいいたい。
ただ、RTH については書かない方がいいと思うんだけど。
指針案まとめ
まとめるとこういうことになると思う。- 表題
- 次の４項からなるとよい
- What - データのカテゴリ
- Where - 水平位置
- When - 予報時間（あれば）
- Who - データ管理者（発信センター）
- データの種類によっては次のようなものを用いてもよい
- What - データ作成プロセス、測器、物理量、水平解像度
- Where - 鉛直位置
- When - 一日の中の時間（観測時刻、初期値時刻、発信周期）、データの期間（有期の場合）
- 他 - データ名略号
- 長さ
- 複数の異なるメタデータレコードが同じ表題を持たないように、表題に多くの項目を盛り込むことが望ましい。
- しかし、通常は表示用途であることと、短時間で把握すべきことをかんがみて、概ね１６０字以下にすべき
- 個々の項目は、意味不明にならない程度にコンパクトであることが望ましい。略語説明のカッコ書きや、「詳細はアブストラクト参照」などの冗長語は避ける。
- 次のようなことは書かない方がいい
- データフォーマット（アブストでよい）
- ディストリビュータ（替わりうる）
- 概要
- 次の３段落からなるとよい（それ以上であっても差し支えない）
- 冒頭段落 - 表題の what を１行程度で説明したもの。略語を避ける。
- 中間段落 - 表題のその他の事項を１０００～２０００字程度で説明する。
- 末尾段落 - データフォーマットを１行程度で説明する。
- 説明は、次のようなことが期待される
- 盛り込めなかった項目の説明
- 略語あるいは一般的でない術語の説明
2013-09-27
メタデータ暫定構造ガイドラインと、gml:VerticalCRS の例いろいろ
（先に考えたいことがあるので予定を変更してお送りしております。表題・概要の続きは後日とさせてくださいごめんなさい）
メタデータ構造について急いで詰めなければならない。 文書を確定する必要はないのだが、なにかプレゼンで見せられる程度の自信をもった詰めが必要。
どのタグ使うか迷うものについて：結論だけのべる。
もうひとつ、書き下していて気になるのが、gml:VerticalCRS についてである。
要は、なんら確立された書法がない。
ググると自分のブログばかり出て嫌になるが、
メタデータ構造について急いで詰めなければならない。 文書を確定する必要はないのだが、なにかプレゼンで見せられる程度の自信をもった詰めが必要。
どのタグ使うか迷うものについて：結論だけのべる。
- 固有名の地名
- 地点番号表（Volume A）が参照できるものについては、place keyword (ApMD2勧告)。ここで使うべき thesaurusName が決められている。
- それ以外についても、整合性の観点から、place keyword とすべき。可能なら thesaurusName を記述することを勧告。
- つまり、geographicIdentifier は
避けて[9/30改訂]勧告されず place keyword にすべき。後で thesaurusName を追加するのが難しいからである。例外として、シソーラス抜きで固有名それぞれに identifier があるような体系ならば、これを使ってもよい。 - データ所在ＵＲＬ
- 連絡先を明示することが望ましいので、distributionInfo/*/distributor/*/distributorTransferOptions を勧告。
- いいかえれば、distributionInfo/*/transferOptions や datasetURI は非勧告であるが、データが製造直専売される場合は transferOption でもまあいいだろう。
- datasetURI は複数指定不可なので、避ける（discouraged）。
- データ形式
- distributionFormat を勧告する。
- distributorFormat は避けるべき。
- resourceFormat
も避けるべき[9/30改訂]は勧告しないが、避けるべきとまでは言わない。来てしまうことに備えるべき。 - いずれにしても、formatDistributor は避ける。特に distributorFormat内は駄目（strongly discouraged）。
- 連絡先
- identificationInfo/*/pointOfContact[*/role=originator] は勧告。データ作成者としてクレジットされる者。
- identificationInfo/*/citation/*/citedResponsibleParty は前項と異なる理由がないから、避けるべき。サイテーションに組織名を書くことが期待される場合、organizationName などのコンパクトな内容で十分。
- 上述のように distributor は勧告される。データ作成者と同一であっても勧告される。
- thesaurusName の中に citedResponsibleParty を書く場合も、組織名などコンパクトな内容で十分。
- individualName に役職名を書くのは駄目。
- いずれ、code.wmo.int レジストリを xlink するような提案をする。
もうひとつ、書き下していて気になるのが、gml:VerticalCRS についてである。
要は、なんら確立された書法がない。
ググると自分のブログばかり出て嫌になるが、
- ２０１１年の自分
- 海抜だけ考えた。
- <gml:identifier codeSpace="urn:ogc:def:crs:EPSG::">5714</gml:identifier>
- ９月９日の自分
- 海抜、気圧、海水深[9/30補]が区別されれば大概の用は足りるということを考えた。
- gml:identifier="urn:ogc:def:verticalDatumType:OGC:1.0:barometric"
- ＮＧＤＣ
- 海水深だけ考えているようである。
<gml:identifier codeSpace="OGP">urn:ogc:def:crs:EPSG::5715</gml:identifier>
2013-09-25
データカタログ書誌情報（メタデータ・レコード）における良い表題・概要の記述指針、または良いテキストという言葉をどう消化するか
データカタログの書誌情報（メタデータ・レコード）には、通例２つのフリーテキストの必須要素がある。ISO 19115 でいえば title, abstract であり、ダブリンコアでいえば title, description である。
これらは機械でなく人間が読むための文字列であり、どう書くかは現状では常識にゆだねられている。自由文について、XMLスキーマのバリデータのような簡単な仕掛けで機械的に不適切な記述を検出することはできない。
だからといってこれらを野放しにして、まちまちの書法（スタイル）が用いられたり、極端にいえば "dummy", "tbd", "data 123" でさえ許容するならば、メタデータ作製は容易になるかもしれないが、データカタログの品質は著しく劣化してしまう。個人や少人数ならば暗黙知に頼ることも許されようが、WIS のような組織的取り組みにおいては、なんらかの明示的な指針・ガイドラインが求められる。
しかし、良いテキストという言葉は実に曖昧模糊・感覚的に聞こえる。安易に指針を書くと、あまりに抽象的で用をなさないか、または具体例に頼るならば射程が狭くなりかねない。それを超えて、真に学際的な基盤として、メタデータ作者の助けになることができるのだろうか。私の考える力が問われている。
何かを設計するとき、しばしば私は２つの主義を唱える：
- オペレーショナリズム： 人工物は、まずその用途によって評価されるべきである。「意味」や、内在的構造の美しさなどを優先すべきでない。
- 中庸： 単一の指標を際限なく片方に振りさえすればよい、というような指針は、しばしば暗黙の前提を忘れており、それが破れたところで酷い結果をもたらす。なんらかの指標で相矛盾する複数の要件を見出して、それらの間の妥協点を探すといった書き方に改めると、よりましになる。
- 用途： メタデータは、第一にデータ発見のために作られると考えられている（他の用途もあるが後の議論を覆すものでない）。それは２段階で行われる。
- 検索： まずは keyword 欄が検索のために用意されているが、かならずしも全ての情報がキーワードに盛り込めない。表題や概要についてもフリーテキスト検索が求められている。
- 検索結果の評価： 検索結果は人間に呈示され、人間が適切なものを選択する。このとき（キーワードなどではなく）まず表題が、次いでスペースが許せば（あるいは個別のレコードの画面で）概要が表示されることになるであろう。
- これら２つの段階に共通することは、選択であるということ。つまり、テキストの意味を機械的に判断できなくても、異なる多数のレコードにしばしば同一または類似の表題・概要がつけられるようでは用をなさない、ということは機械的にいえる。
- 中庸： テキスト（文字列）にとって自明に重要な量的指標は、長さ（字数）である。
- 前項の議論も、情報が多いほうがよい、つまり、テキストは長いほうがよいという方向である。巷間でみられる散文的な指針も基本的には同様。
- では無限に長いほうがよいか、というとそうではあるまい。表示しきれないほど長い表題や、読み切れないほど長い概要は、逆効果となる。
まず表題の長さのヒストグラムはこうである。（横軸は対数目盛）
際立った２峰性の分布であるが、これは、メタデータレコードを生成するソフトウェアの数がまだ少数だからであろう。文字数が１１０～１１９の時だけ特別に不都合となる理由はない。
現時点では、次のような観察にとどめて置くのが安全だろう：
- ９５％のレコードが４５文字以上である
- 中央値は８８文字
- ９５％のレコードが１５３文字以下である
- 最大値は２０８文字
もうちょっと言うと、あまりに短い表題（たとえば４０文字以下）や、あまりに長い表題（たとえば１６０文字以上）を頻繁に生じるような命名法は、良いとはいえないだろう。
ついで、概要の長さのヒストグラムはこうである。
今度はまったく違って、片方に裾野を引いた分布である。極めて短い例が多数ある、というか、実をいうと <abstract/> が空要素になっているレコードが１２％も存在する。それは流石に推奨するわけにはゆかないけれど。
- 中央値は２８０文字
- ９５％のレコードが１３５１文字以下である
- ９９％のレコードが１４４３文字以下である
- 最大値は５３１２文字
長くなったのでここでいったん切る。
2013-09-09
gmd:VerticalCRS/gml:verticalCRS/gml:identifier には何を書いたものやら（OGC資料探索）
緊急とは思わないのだが、頭の体操。
ISO地理メタデータ標準19115において鉛直位置を数値的に表現しようとするなら、それは gmd:identificationInfo/*/gmd:extent たらざるを得ない。
さてそこで座標の種別をどう表現するか。上述 extent には
gmd:verticalElement/*/gmd:VerticalCRS というのがあって、要は gml:identifier
ひとつみたいなものなのであるが、それはなんでしょうと。
OGC 07-092r2 に verticalDatumType の表というものがあって、筆頭が
urn:ogc:def:verticalDatumType:OGC:1.0:geoidal
urn:ogc:def:verticalDatumType:OGC:1.0:depth
urn:ogc:def:verticalDatumType:OGC:1.0:barometric
と続く。
これはあくまで datum Type であって、それを使った datum を作らないといけない。
では、オープンなレジストリに WKT でも書いて登録すればいいのか…というと、WKT
の VERT_DATUM の２項目（普通2005）に何を書くかわからないのではたととまる。
答は OGC 01-009 に書いてあって、上述 verticalDatumType:OGC:1.0:barometric ならば 2003 である。
と、そこまで調べて spatialreference.org に行ったら新規登録を受け付けていない....
ここではたと原点に立ち返って考えると、気象界の利用者というのは実は datum が何だってどうでもいい。実用上何を区別したいのかというと気圧座標と標高と海面下水深が区別できればそれでいいのである。ならば
gml:identifier="urn:ogc:def:verticalDatumType:OGC:1.0:barometric"
としてしまっても、いいのではないか。本当は駄目だけど、混乱が減るし。
ISO地理メタデータ標準19115において鉛直位置を数値的に表現しようとするなら、それは gmd:identificationInfo/*/gmd:extent たらざるを得ない。
さてそこで座標の種別をどう表現するか。上述 extent には
gmd:verticalElement/*/gmd:VerticalCRS というのがあって、要は gml:identifier
ひとつみたいなものなのであるが、それはなんでしょうと。
OGC 07-092r2 に verticalDatumType の表というものがあって、筆頭が
urn:ogc:def:verticalDatumType:OGC:1.0:geoidal
urn:ogc:def:verticalDatumType:OGC:1.0:depth
urn:ogc:def:verticalDatumType:OGC:1.0:barometric
と続く。
これはあくまで datum Type であって、それを使った datum を作らないといけない。
では、オープンなレジストリに WKT でも書いて登録すればいいのか…というと、WKT
の VERT_DATUM の２項目（普通2005）に何を書くかわからないのではたととまる。
答は OGC 01-009 に書いてあって、上述 verticalDatumType:OGC:1.0:barometric ならば 2003 である。
と、そこまで調べて spatialreference.org に行ったら新規登録を受け付けていない....
ここではたと原点に立ち返って考えると、気象界の利用者というのは実は datum が何だってどうでもいい。実用上何を区別したいのかというと気圧座標と標高と海面下水深が区別できればそれでいいのである。ならば
gml:identifier="urn:ogc:def:verticalDatumType:OGC:1.0:barometric"
としてしまっても、いいのではないか。本当は駄目だけど、混乱が減るし。
2013-08-09
2013-08-08
まとめ ― Ubuntu 12.04 で VIA VNT6656 USB Wifi Module を使えるようにした
ついに完動するに至ったのでまとめておきます。いちおう言っときますが無保証です。
1. 準備
Cコンパイラとかカーネルヘッダとかインストールしておいてください。
2. VIA ドライバのコンパイル
(1) ソースコードを取得
http://www.viaembedded.com/en/products/boards/1890/1/VNT6656_USB_Module_/_Dongle.html
にある VT6656_Linux_src_v1.21.03_x86_11_04.zip です。
(2) 修正
そのままではコンパイルできないので直します。
[追記：KVER マクロは、将来の Linux の別バージョンでは修正が必要です。要は "2.6" という値になりさえすればいいので、カーネル 2.4 以前を使わないならば、 KVER := 2.6 で十分です。]
(3) ビルド・インストール
config.h は無いので作りました。
(4) 設定
[追記： これは、モジュールにネットワークインターフェイス名（今回は eth0 が既にあったので eth1 にしました）。を割り当て、ついで、ブート時に vntwusb が読みこまれるようにします]
あとは、Ubutuのドキュメントでもみてください。
1. 準備
Cコンパイラとかカーネルヘッダとかインストールしておいてください。
2. VIA ドライバのコンパイル
(1) ソースコードを取得
http://www.viaembedded.com/en/products/boards/1890/1/VNT6656_USB_Module_/_Dongle.html
にある VT6656_Linux_src_v1.21.03_x86_11_04.zip です。
$ unzip VT6656_Linux_src_v1.21.03_x86_11_04.zip
$ cd VT6656_Linux_src_v1.21.03_x86/
(2) 修正
そのままではコンパイルできないので直します。
--- VT6656_Linux_src_v1.21.03_x86/driver/Makefile 2009-09-07 09:53:36.0000
00000 +0900
+++ work-vt6656/driver/Makefile 2013-08-07 01:51:32.655889247 +0900
@@ -24,7 +24,7 @@
endif
# check kernel version
-KVER := $(shell uname -r | cut -c1-3 | sed 's/2\.[56]/2\.6/')
+KVER := $(shell uname -r | cut -c1-3 | sed 's/2\.[56]\|3\.2/2\.6/')
KERVER2=$(shell uname -r | cut -d. -f2)
ifeq ($(KVER), 2.6)
diff -ur VT6656_Linux_src_v1.21.03_x86/driver/main_usb.c work-vt6656/driver/main
_usb.c
--- VT6656_Linux_src_v1.21.03_x86/driver/main_usb.c 2011-08-03 11:53:08.0000
00000 +0900
+++ work-vt6656/driver/main_usb.c 2013-08-07 02:23:35.573424483 +0900
@@ -387,7 +387,9 @@
.ndo_stop = device_close,
.ndo_get_stats = device_get_stats,
.ndo_start_xmit = device_xmit,
+#ifdef HAVE_MULTICAST
.ndo_set_multicast_list = device_set_multi,
+#endif
.ndo_do_ioctl = device_ioctl,
};
#endif
[追記：KVER マクロは、将来の Linux の別バージョンでは修正が必要です。要は "2.6" という値になりさえすればいいので、カーネル 2.4 以前を使わないならば、 KVER := 2.6 で十分です。]
(3) ビルド・インストール
config.h は無いので作りました。
# touch /usr/src/linux-headers-3.2.0-51-generic-pae/include/linux/config.h[追記： いきなりインストールが心配なら、 make install のかわりに非特権ユーザでただ make してみるとよいです。]
# make cleanこのへんで一度 insmod とか試してみるんでしょう。
# make install
(4) 設定
[追記： これは、モジュールにネットワークインターフェイス名（今回は eth0 が既にあったので eth1 にしました）。を割り当て、ついで、ブート時に vntwusb が読みこまれるようにします]
# cat /etc/modules.conf <-- なければ作る[追記：これでリブートしてみるのがいいでしょう。リブートしたくなければ、特権ユーザで modprobe vntwusb とします]
alias eth1 vntwusb
# cat /etc/modules <-- これも
lp
vntwusb
あとは、Ubutuのドキュメントでもみてください。
2013-08-07
モジュールのビルド つづき
何もしないモジュールの例
http://wiki.bit-hive.com/tomizoo/pg/Loadable%20Kernel%20Module%A4%CE%BA%EE%A4%EA%CA%FD
を試してみたら、カーネル 3.2.0 でもプログラムと Makefile は動作した。
（ただし、config.h は先日のインチキなので、これからはよしたほうがいいだろう）。
つまり、モジュールのファイル名が *.ko になったとか、そういった特徴はカーネル 2.6 のころから変わっていないわけだ。
そうおもって VNT6656 ドライバの Makefile を読み直してみると、なぜ全然まともなビルドプロセスにならないかが見えてきた。
この Makefile は、uname -r を sed でホゲってカーネルバージョンをとりだして、それで gmake の ifeq を使って分岐しているんだが、そこで 2.6 決め打ちをしているのである。そんなら話は簡単、強引に 2.6 という文字列を作らせてしまえばいいのである。
これで make から make -C なんちゃらを呼ぶプロセスに入る。
次のエラーは、ずっとまっとうである。
そこらに落ちてる 2.6.32 のヘッダと3.2のヘッダを見比べてみると、ほんとうにそのメンバだけなくなっている。何が代替だか自明でなさそうなので、とりあえず消しちゃうことにする。
すると、他の警告がいっぱい表示されながらもビルドに成功して vntwusb.ko ができた。
試すのはまた明日移行にしようかな。遅いし。
http://wiki.bit-hive.com/tomizoo/pg/Loadable%20Kernel%20Module%A4%CE%BA%EE%A4%EA%CA%FD
を試してみたら、カーネル 3.2.0 でもプログラムと Makefile は動作した。
（ただし、config.h は先日のインチキなので、これからはよしたほうがいいだろう）。
つまり、モジュールのファイル名が *.ko になったとか、そういった特徴はカーネル 2.6 のころから変わっていないわけだ。
そうおもって VNT6656 ドライバの Makefile を読み直してみると、なぜ全然まともなビルドプロセスにならないかが見えてきた。
この Makefile は、uname -r を sed でホゲってカーネルバージョンをとりだして、それで gmake の ifeq を使って分岐しているんだが、そこで 2.6 決め打ちをしているのである。そんなら話は簡単、強引に 2.6 という文字列を作らせてしまえばいいのである。
ここで、 sed の正規表現での A or B は A\|B ということに注意。はまる。
27c27
< KVER := $(shell uname -r | cut -c1-3 | sed 's/2\.[56]/2\.6/')
---
> KVER := $(shell uname -r | cut -c1-3 | sed 's/2\.[56]\|3\.2/2\.6/')
これで make から make -C なんちゃらを呼ぶプロセスに入る。
次のエラーは、ずっとまっとうである。
$ make2つあるみたいだけど、先の方（３９０行目）をチェックしてみると、struct net_device_ops に ndo_set_multicast_list というメンバがないみたいなんだよね。
make -C /lib/modules/3.2.0-51-generic-pae/build SUBDIRS=/home/toyoda/work-vt6656/driver modules
make[1]: Entering directory `/usr/src/linux-headers-3.2.0-51-generic-pae'
CC [M] /home/toyoda/work-vt6656/driver/main_usb.o
/home/toyoda/work-vt6656/driver/main_usb.c:390:2: error: unknown field 'ndo_set_multicast_list' specified in initializer
/home/toyoda/work-vt6656/driver/main_usb.c:390:2: warning: initialization from incompatible pointer type [enabled by default]
/home/toyoda/work-vt6656/driver/main_usb.c:390:2: warning: (near initialization for 'vntwusb_netdev_ops.ndo_select_queue') [enabled by default]
/home/toyoda/work-vt6656/driver/main_usb.c: In function 'device_set_multi':
/home/toyoda/work-vt6656/driver/main_usb.c:2454:26: warning: unused variable 'mclist' [-Wunused-variable]
そこらに落ちてる 2.6.32 のヘッダと3.2のヘッダを見比べてみると、ほんとうにそのメンバだけなくなっている。何が代替だか自明でなさそうなので、とりあえず消しちゃうことにする。
@@ -387,7 +387,9 @@
.ndo_stop = device_close,
.ndo_get_stats = device_get_stats,
.ndo_start_xmit = device_xmit,
+#ifdef HAVE_MULTICAST
.ndo_set_multicast_list = device_set_multi,
+#endif
.ndo_do_ioctl = device_ioctl,
};
#endif
すると、他の警告がいっぱい表示されながらもビルドに成功して vntwusb.ko ができた。
試すのはまた明日移行にしようかな。遅いし。
2013-08-06
そもそもカーネルモジュールのビルドしかた
https://www.kernel.org/doc/Documentation/kbuild/ あたりを読むべきらしい。
ぐぐったら modules.txt が引っかかったが、これだけ読んでも、どうも kbuild という機構がわからないと壊れたMakefileをなおせるようにならなさそうだ。
とりあえず、何もしないモジュールを作ってみる例がある。
http://wiki.bit-hive.com/tomizoo/pg/Loadable%20Kernel%20Module%A4%CE%BA%EE%A4%EA%CA%FD
これを最新のカーネルバージョンで試してみるというのも一法だろう。
2013-08-04
VIA VNT6656 USB Wifi Module を Ubuntu からまだ使えていないメモ
まあ表題のとおりなわけでダメなんだけど、ダメなりにメモを残しておこう。
工人舎MLというネットブックを持っていて、金物は元気なんだけどWindows XPだからそろそろ延命策を考えたいところ。とりあえず、楽そうなところでUbuntu 12.04 LTS を入れたらさくっと動いたのでそこはよし。Tipsがあるとすれば、BIOSではブータブルUSBはHDD扱いされるということかな。
で、内蔵無線LANがVIA VNT6656なんだけど、これがどうも始末の悪いものであるらしい。
http://www.linuxforums.org/forum/suse-linux/147396-install-via-vnt6656-wireless-usb.html
最後を見ると、ありがたくもVIAがドライバを出してくれてはいるのだけれど、これが古い。
http://www.viaembedded.com/en/products/boards/1890/1/VNT6656_USB_Module_/_Dongle.html
Ubunto 11.04 まで対応なんだけどね。うーんちょっとサポート切れバージョンに戻すのも心配だよね。もともとXP移行なんで、なにやってるかわからない。
まず、インストラクションにのっとって unzip; make clean; make を試みると、 driver/Makefileが爆死。
...かとおもったらそうでもない。
対症療法だけど、システムの %.o: %.c ルールに然るべきコンパイラオプションを渡すには、 無視されてしまう EXTRA_CFLAGS 変数の代わりに CFLAGS に同じことを設定すればいい。で、その設定らしきものが既に Makefile にコメントで入っているという中途半端な状態。
とりあえず、こうするとヘッダが見つけられるようにはなる。
で、現状、 カーネルソースヘッダの arch/x86/include/asm/arch_hweight.h:53:7 でexpected ‘:’ or ‘)’ before ‘POPCNT64’ と言われて止まる。
このへんはアセンブリなので正直分からないのだけれど、構文エラーということは、おそらくはマクロの未定義とかなんとか、正しいヘッダの読み方をしていないからだろう。
が、しかし、それが何なのかはわからない。
工人舎MLというネットブックを持っていて、金物は元気なんだけどWindows XPだからそろそろ延命策を考えたいところ。とりあえず、楽そうなところでUbuntu 12.04 LTS を入れたらさくっと動いたのでそこはよし。Tipsがあるとすれば、BIOSではブータブルUSBはHDD扱いされるということかな。
で、内蔵無線LANがVIA VNT6656なんだけど、これがどうも始末の悪いものであるらしい。
http://www.linuxforums.org/forum/suse-linux/147396-install-via-vnt6656-wireless-usb.html
最後を見ると、ありがたくもVIAがドライバを出してくれてはいるのだけれど、これが古い。
http://www.viaembedded.com/en/products/boards/1890/1/VNT6656_USB_Module_/_Dongle.html
Ubunto 11.04 まで対応なんだけどね。うーんちょっとサポート切れバージョンに戻すのも心配だよね。もともとXP移行なんで、なにやってるかわからない。
まず、インストラクションにのっとって unzip; make clean; make を試みると、 driver/Makefileが爆死。
$ unzip VT6656_Linux_src_v1.21.03_x86_11_04.zipこれは、最近の Linux ではカーネルソースに linux/config.h がなくなったからであるらしいので、ないものは作ればよい。作り方はこれでいいかは知らんが Makefile は黙る...
$ cd VT6656_Linux_src_v1.21.03_x86/
$ make
...
Makefile:116: *** Linux kernel source not configured - missing config.h. Stop.
$ sudo touch /lib/modules/3.2.0-51-generic-pae/build/include/linux/config.h
...かとおもったらそうでもない。
$ makeあせったけれど、よくよくコマンドラインをみるとヘッダの場所を教えていないのでコンパイルできるわけがない。それはなぜかと make -p の結果を読んだりしてみると、どうやら Makefile 内の .c.o ルールが使われていないみたい。
...
gcc -c -o main_usb.o main_usb.c
In file included from main_usb.c:50:0:
device.h:40:24: fatal error: linux/init.h: No such file or directory
compilation terminated.
make[1]: *** [main_usb.o] Error 1
対症療法だけど、システムの %.o: %.c ルールに然るべきコンパイラオプションを渡すには、 無視されてしまう EXTRA_CFLAGS 変数の代わりに CFLAGS に同じことを設定すればいい。で、その設定らしきものが既に Makefile にコメントで入っているという中途半端な状態。
とりあえず、こうするとヘッダが見つけられるようにはなる。
$ diff -ru VT6656_Linux_src_v1.21.03_x86 work-vt6656/
diff -ru VT6656_Linux_src_v1.21.03_x86/driver/Makefile work-vt6656/driver/Makefile
--- VT6656_Linux_src_v1.21.03_x86/driver/Makefile 2009-09-07 09:53:36.000000000 +0900
+++ work-vt6656/driver/Makefile 2013-08-04 23:05:11.296911687 +0900
@@ -62,12 +62,13 @@
ifeq ($(HOSTAP), 1)
-# CFLAGS += -DHOSTAP
+ CFLAGS += -DHOSTAP
EXTRA_CFLAGS += -DHOSTAP
endif
-#CFLAGS += -I$(PWD) -I$(PWD)/../include -I$(PWD)/include
+CFLAGS += -I$(PWD) -I$(PWD)/../include -I$(PWD)/include -I$(KSRC)/include \
+ -I$(KSRC)/arch/x86/include
EXTRA_CFLAGS += -I$(PWD) -I$(PWD)/../include -I$(PWD)/include
# build rule
@@ -113,7 +114,7 @@
endif
ifeq (,$(wildcard $(CONFIG_FILE)))
- $(error Linux kernel source not configured - missing config.h)
+ $(error Linux kernel source not configured - missing config.h in $(KSRC))
endif
ifneq (,$(findstring egcs-2.91.66, $(shell cat /proc/version)))
@@ -126,10 +127,10 @@
CC := $(foreach cc, $(CC), $(test_cc))
CC := $(firstword $(CC))
-#CFLAGS += -Wall -DLINUX -D__KERNEL__ -DMODULE -DEXPORT_SYMTAB -D__NO_VERSION__ -O2 -pipe
-#CFLAGS += -I$(KSRC)/include -Wstrict-prototypes -fomit-frame-pointer -fno-strict-aliasing
-#CFLAGS += $(shell [ -f $(KSRC)/include/linux/modversions.h ] && \
-# echo "-DMODVERSIONS -include $(KSRC)/include/linux/modversions.h")
+CFLAGS += -Wall -DLINUX -D__KERNEL__ -DMODULE -DEXPORT_SYMTAB -D__NO_VERSION__ -O2 -pipe
+CFLAGS += -I$(KSRC)/include -Wstrict-prototypes -fomit-frame-pointer -fno-strict-aliasing
+CFLAGS += $(shell [ -f $(KSRC)/include/linux/modversions.h ] && \
+ echo "-DMODVERSIONS -include $(KSRC)/include/linux/modversions.h")
EXTRA_CFLAGS += -Wall -DLINUX -D__KERNEL__ -DMODULE -DEXPORT_SYMTAB -D__NO_VERSION__ -O2 -pipe
EXTRA_CFLAGS += -I$(KSRC)/include -Wstrict-prototypes -fomit-frame-pointer -fno-strict-aliasing
EXTRA_CFLAGS += $(shell [ -f $(KSRC)/include/linux/modversions.h ] && \
Only in work-vt6656/: make.log
Only in work-vt6656/: utility
で、現状、 カーネルソースヘッダの arch/x86/include/asm/arch_hweight.h:53:7 でexpected ‘:’ or ‘)’ before ‘POPCNT64’ と言われて止まる。
このへんはアセンブリなので正直分からないのだけれど、構文エラーということは、おそらくはマクロの未定義とかなんとか、正しいヘッダの読み方をしていないからだろう。
が、しかし、それが何なのかはわからない。
2013-07-29
天気４月号、二宮「１８８９年（明治２２年）８月１９−２０日の台風に伴う紀伊半島豪雨の気象状況」
防災上の観点から古い観測資料を使おうとするときは、現在観測点の近隣地点で気候統計上は切断とされている観測を接続とすることもあり得るのではないかという指摘がある。
http://www.metsoc.jp/tenki/pdf/2013/2013_04_0041.pdf
http://www.metsoc.jp/tenki/pdf/2013/2013_04_0041.pdf
2013-07-10
ECMAScript (ECMA-262 は意外と読みやすい、三項演算子もどき構文)
何の因果か JavaScript について調べることになった。三項演算子
val ? "ok" : "failed"
みたいなのがあるのだが、
val && "ok" || "failed"
みたいな書き方をしばしば見かける。
実装がついてきているかは必ずしも知らないが、ECMA-262をみるべきだろう。
http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf
意外とコンパクトで読みやすい。
結論から言うと、上記の２構文は同等のロジックで評価されるようである。null とか
undefined にからんだ相違はない。相違は文法だけで、本物の三項演算子の ? のあとや : のあとには代入式を書くことができる（代入演算子より優先度が低い）が、代
替記法 && || ならば中に代入式を書くことができない（代入演算子より優先度が高い）。
JavaScript はあまり書かないが、代入演算子より優先度の高い三項演算子がほしいことはよくあるだろう。Ruby の
a = if b then c else d end
なんかはスタイルとして好まれないかもしれないけれどそうだ。
val ? "ok" : "failed"
みたいなのがあるのだが、
val && "ok" || "failed"
みたいな書き方をしばしば見かける。
実装がついてきているかは必ずしも知らないが、ECMA-262をみるべきだろう。
http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf
意外とコンパクトで読みやすい。
結論から言うと、上記の２構文は同等のロジックで評価されるようである。null とか
undefined にからんだ相違はない。相違は文法だけで、本物の三項演算子の ? のあとや : のあとには代入式を書くことができる（代入演算子より優先度が低い）が、代
替記法 && || ならば中に代入式を書くことができない（代入演算子より優先度が高い）。
JavaScript はあまり書かないが、代入演算子より優先度の高い三項演算子がほしいことはよくあるだろう。Ruby の
a = if b then c else d end
なんかはスタイルとして好まれないかもしれないけれどそうだ。
2013-07-04
台風・熱低の記号の由来
台風・熱低の記号が話題になっているようだ。歴史的起源かどうかは分からないが、リファレンスとしては WMO Manual on GDPFS, Appendix II-4, 4.1.3 (b) http://goo.gl/BTlzi であろう。
2013-07-02
暖湿流入は境界層の現象であって850hPa資料の予測力は限られるという加藤さんの天気への投稿
話題になっているが学会誌で公知になっていることなのだから公に紹介しておくべきだろう。
加藤輝之, 2010: 「新用語解説 湿舌」 . 天気, 57, 12, pp.917-918.
http://www.metsoc.jp/tenki/pdf/2010/2010_12_0043.pdf
そっから引いているのがこちら。
加藤輝之, 2007: 「創立125周年記念解説 梅雨前線帯と集中豪雨—積乱雲が発達するための条件—」. 天気, 54, 5, pp. 395-398.
http://www.metsoc.jp/tenki/pdf/2007/2007_05_0009.pdf
実証的には次のを読むべきなんだろうけれど、未見。
Kato,T.,2009：Representative height of low-level
water vapor field to examine the occurrence possibility
of heavy rainfall in East Asia.Proc.Conf.on MCSs
and High-Impact Weather/Climate in East Asia,
343-350
2013-06-10
srv:SV_ServiceIdentification の利用是非
ちょっと頭パンクする前にメモしておきたい。
地理情報メタデータ標準 ISO 19115 では、メタデータレコードを表わすクラス
MD_Metadata に identification というプロパティ（属性と訳すこともあるがＸＭＬ属性のことではない、XML要素で表現する）があって、メタデータ自体のプロパティは MD_Metadata 直下に、メタデータが記述
するデータのプロパティは identification の下に記述される。
identification プロパティは抽象クラス MD_Identification を継承する任意のクラスによっていて、INSPIRE とか NOAA/NGDC とかの解説を見ているとそれは
MD_DataIdentification （データ用） と SV_ServiceIdentification である。SV_ServiceIdentification
自体の定義は ISO 19115 から参照される ISO 19119 にある。
UML の世界（ISO 19115）から具体 XML 表現の世界（ISO 19139）に行くと、それは
gmd:MD_Metadata/gmd:identification 内に許される XML 要素が
gmd:MD_DataIdentification または srv:SV_ServiceIdentification であるのだが、名前空間 gmd のスキーマは
http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/gmd/identification.xsd
など ISO サイトにあるのに対し、名前空間 srv のスキーマは
http://schemas.opengis.net/iso/19139/20060504/srv/
http://wis.wmo.int/2011/schemata/iso19139_2007/schema/srv/serviceMetadata.xsd
などサードパーティにしか見当たらない。
これは何としたことか、と思っていたのだが、ISO 19115 の Normative Reference
に ISO 19119 が含まれていないからであり、そして、それは ISO 19115 を実装するのに 19119 は必要ないということであるようだ。
実は、ISO 19115:2003 策定途上の DIS へのコメントで Normative Reference に
19119 を追加しようとして却下されたということがあり、それを読んで疑問が氷解した。
WMO も紆余曲折したが、結局 WCMP 1.3 の文書で SV_ServiceIdentification などへの言及がいっさいないのは、WMO としては、いままでのところ ISO 19115 への適合だけを求めて ISO
19119 への適合を求めていなかったからであるようだ。今となってはわたしが説明しないといけないので、気をつけよう。
地理情報メタデータ標準 ISO 19115 では、メタデータレコードを表わすクラス
MD_Metadata に identification というプロパティ（属性と訳すこともあるがＸＭＬ属性のことではない、XML要素で表現する）があって、メタデータ自体のプロパティは MD_Metadata 直下に、メタデータが記述
するデータのプロパティは identification の下に記述される。
identification プロパティは抽象クラス MD_Identification を継承する任意のクラスによっていて、INSPIRE とか NOAA/NGDC とかの解説を見ているとそれは
MD_DataIdentification （データ用） と SV_ServiceIdentification である。SV_ServiceIdentification
自体の定義は ISO 19115 から参照される ISO 19119 にある。
UML の世界（ISO 19115）から具体 XML 表現の世界（ISO 19139）に行くと、それは
gmd:MD_Metadata/gmd:identification 内に許される XML 要素が
gmd:MD_DataIdentification または srv:SV_ServiceIdentification であるのだが、名前空間 gmd のスキーマは
http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/gmd/identification.xsd
など ISO サイトにあるのに対し、名前空間 srv のスキーマは
http://schemas.opengis.net/iso/19139/20060504/srv/
http://wis.wmo.int/2011/schemata/iso19139_2007/schema/srv/serviceMetadata.xsd
などサードパーティにしか見当たらない。
これは何としたことか、と思っていたのだが、ISO 19115 の Normative Reference
に ISO 19119 が含まれていないからであり、そして、それは ISO 19115 を実装するのに 19119 は必要ないということであるようだ。
実は、ISO 19115:2003 策定途上の DIS へのコメントで Normative Reference に
19119 を追加しようとして却下されたということがあり、それを読んで疑問が氷解した。
WMO も紆余曲折したが、結局 WCMP 1.3 の文書で SV_ServiceIdentification などへの言及がいっさいないのは、WMO としては、いままでのところ ISO 19115 への適合だけを求めて ISO
19119 への適合を求めていなかったからであるようだ。今となってはわたしが説明しないといけないので、気をつけよう。
2013-06-04
OAI-PMH モニタリングのアルゴリズム（考えてみた）
こんなことしてる場合じゃないんだけど考えを吐きだしておかないと。
OAI-PMH は HTTP ベースで XML の情報を伝送するためのプロトコルです。
http://www.openarchives.org/OAI/openarchivesprotocol.html
元来が図書館・アーカイブの世界でメタデータ（ここでは書誌目録）を共有するためのものであるわけですが、プロトコル自体にはドメイン依存性はそれほどありません。すごく乱暴に言うと RSS 全文フィードに時間範囲
指定機能をつけたようなものです。XML でシリアライズされるレコードにそれぞれ
identifier がついたものが逐次に発生するならば、新しく発生したものを取得することができます。
蛇足ですが、他に、セット（フォルダみたいなもの）とフォーマット変換の機能があって、WMO 情報システム（WIS）のデータカタログではセットが多用される
（http://www.wmo.int/pages/prog/www/WIS/wiswiki/tiki-index.php?page=oai-pmh-docu&structure=WIS+up）のですが、それは今回は捨象できます。
さて、差分取得に話を戻します。CGIみたいなクエリパラメタ from と until が指定出来て（どちらもオプショナル）、時間範囲（片方または両方の端が未指定でありうる）の取得ができるわけです。
ふつうは、from に前回実行時刻を指定して、差分だけを取得します。ところが、これを長期間運用すると色々の事情で抜けが生じる。そこをモニターするのが課題です。
一番素朴には、モニターが定期的に過去一切のレコード（識別子だけ取得可能）を取得して、手持ちと見比べるということが考えられます。シンプルなのはいいですが、レコード数に比例して取得時間がかかり、モニター取得間隔が延びていってしまいます。また、エラーレートとと掛け算すると、あるていど多数のレコードを扱う場合には成功率が無限に小さくなってしまいます。
次は、再取得を区分的に行うことが考えられます。このとき、どこからどこまでを再取得したかを保存しておかなければなりません。素朴に考えると
CREATE TABLE harvest(
tfrom DATETIME -- 開始日時 --,
tuntil DATETIME -- 終了日時 --,
tdone DATETIME -- 再取得日時 --,
count DATETIME -- レコード数 --)
みたいなことになりますが、あるレコードの tfrom は前のレコードの tuntil と同じ、という制約を考えると邪魔くさいので、tfrom はヤメにして、
CREATE TABLE harvest(
tuntil DATETIME -- 終了日時 --,
tdone DATETIME -- 再取得日時 --,
count DATETIME -- レコード数 --)
だけあればいいことになります。
再取得は、一定速度でやるのがいいでしょう。定期的にトリガーすると、いつか全数取得の間隔がトリガー間隔を超えたときに二重起動になってしまいます。手前の負荷は耐えられるかもしれませんが、サーバ側で二重アクセスするとエラーレートが増えることが疑われます。
あるいは、WIS では ListSets メソッドでレコード総数を通知する慣例があるので、それがトリガに使えるかもしれません。
（ http://www.wis-jma.go.jp/meta/oaiprovider.jsp?verb=ListSets の
ListSets/set/setDescription/dc/description 要素が "This set contains 161
records" のようなテキストになっている
このへんは、実経験でもんでないので、ちゃんと考えられていません。
OAI-PMH は HTTP ベースで XML の情報を伝送するためのプロトコルです。
http://www.openarchives.org/OAI/openarchivesprotocol.html
元来が図書館・アーカイブの世界でメタデータ（ここでは書誌目録）を共有するためのものであるわけですが、プロトコル自体にはドメイン依存性はそれほどありません。すごく乱暴に言うと RSS 全文フィードに時間範囲
指定機能をつけたようなものです。XML でシリアライズされるレコードにそれぞれ
identifier がついたものが逐次に発生するならば、新しく発生したものを取得することができます。
蛇足ですが、他に、セット（フォルダみたいなもの）とフォーマット変換の機能があって、WMO 情報システム（WIS）のデータカタログではセットが多用される
（http://www.wmo.int/pages/prog/www/WIS/wiswiki/tiki-index.php?page=oai-pmh-docu&structure=WIS+up）のですが、それは今回は捨象できます。
さて、差分取得に話を戻します。CGIみたいなクエリパラメタ from と until が指定出来て（どちらもオプショナル）、時間範囲（片方または両方の端が未指定でありうる）の取得ができるわけです。
ふつうは、from に前回実行時刻を指定して、差分だけを取得します。ところが、これを長期間運用すると色々の事情で抜けが生じる。そこをモニターするのが課題です。
一番素朴には、モニターが定期的に過去一切のレコード（識別子だけ取得可能）を取得して、手持ちと見比べるということが考えられます。シンプルなのはいいですが、レコード数に比例して取得時間がかかり、モニター取得間隔が延びていってしまいます。また、エラーレートとと掛け算すると、あるていど多数のレコードを扱う場合には成功率が無限に小さくなってしまいます。
次は、再取得を区分的に行うことが考えられます。このとき、どこからどこまでを再取得したかを保存しておかなければなりません。素朴に考えると
CREATE TABLE harvest(
tfrom DATETIME -- 開始日時 --,
tuntil DATETIME -- 終了日時 --,
tdone DATETIME -- 再取得日時 --,
count DATETIME -- レコード数 --)
みたいなことになりますが、あるレコードの tfrom は前のレコードの tuntil と同じ、という制約を考えると邪魔くさいので、tfrom はヤメにして、
CREATE TABLE harvest(
tuntil DATETIME -- 終了日時 --,
tdone DATETIME -- 再取得日時 --,
count DATETIME -- レコード数 --)
だけあればいいことになります。
再取得は、一定速度でやるのがいいでしょう。定期的にトリガーすると、いつか全数取得の間隔がトリガー間隔を超えたときに二重起動になってしまいます。手前の負荷は耐えられるかもしれませんが、サーバ側で二重アクセスするとエラーレートが増えることが疑われます。
あるいは、WIS では ListSets メソッドでレコード総数を通知する慣例があるので、それがトリガに使えるかもしれません。
（ http://www.wis-jma.go.jp/meta/oaiprovider.jsp?verb=ListSets の
ListSets/set/setDescription/dc/description 要素が "This set contains 161
records" のようなテキストになっている
このへんは、実経験でもんでないので、ちゃんと考えられていません。
2013-05-08
WMO Manual on Codes の 2013年第1回ファストトラック改正（BUFR・共通符号表）
昨日の続き。
２．BUFR
（１）CGMS提案衛星関係
CGMS から五月雨で提案が出てきたというか、各国の提案をとりまとめたので、チケット
http://redmine.toyoda-eizi.net/issues/140 はいささか読みにくいですが、整理すると次のようになります。
ａ．Ｃｒｙｏｓａｔ−２関係
ＥＳＡの地球観測衛星
http://www.wmo-sat.info/oscar/satellites/view/39
追加内容：
衛星 Cryosat-2 (C-5:47)
測器 SIRAL (C-8:177)
ｂ．ＣＯＭＳ関係
韓国の静止気象衛星
http://www.wmo-sat.info/oscar/satelliteprogrammes/view/23
追加内容：
衛星分類 COMS (0-02-020:281)
衛星番号や測器番号は、まあ、そのうちでてくるのでしょう。
ｃ．しずく関係
日本の地球観測衛星
http://www.wmo-sat.info/oscar/satellites/view/130
追加内容：
衛星分類 GCOM (0-02-020:122)
衛星 GCOM-W1 (C-5:122)
測器 AMSR2 (C-8:478)
ｄ．ひまわり関係
日本の静止気象衛星
http://www.wmo-sat.info/oscar/satelliteprogrammes/view/72
追加内容：
衛星分類 Himawari (0-02-020:273)
衛星 Himawari-8 (C-5:173)
衛星 Himawari-9 (C-5:174)
測器 AHI (C-8:297)
日本の運輸多目的衛星
http://www.wmo-sat.info/oscar/satelliteprogrammes/view/71
変更内容
測器 C-8:294 を JAMI に改称
測器 C-8:295 を IMAGER/MTSAT-2 に改称
ｅ．仏・印関係
追加内容：
測器 AltiKa (C-8:62)
http://www.wmo-sat.info/oscar/instruments/view/21
測器 MADRAS (C-8:942)
http://www.wmo-sat.info/oscar/instruments/view/271
ｆ．多種衛星混合プロダクト用の衛星番号
追跡風なんかでそういうプロダクトを作るという説明です。
追加内容
衛星 "Non specific mixture of geostationary and low earth orbiting
satellites" (C-5:854)
（２）米国提案ゾンデ用センサー
ゾンデ用の気圧、温度、湿度センサーが追加になっています。
http://redmine.toyoda-eizi.net/issues/147
（３）米国提案、作成中枢 UCAR
作成中枢番号（C-1/C-11, RSMC東京なら34）に UCAR (175) が追加になりました。
http://redmine.toyoda-eizi.net/issues/149
（４）微量気体としての酸素
大気には無数の微量気体があり、これらの濃度を表わすにそれぞれGRIBパラメータ・BUFR要素番号を割り当てていると番号が枯渇するので、共通符号表 C-14 に登録した微量気体番号と、種別を捨象したパ
ラメータ（0-18-10 Air concentration [Bq.m-3], 0-20-0 Mass density [kg.m-3]
など）や要素 (0-15-027 Concentration of pollutant [mol.mol-1] など) を使うようになっています。
さて今般米国が酸素 O2 を微量気体として登録提案してきました。対流圏では酸素濃度の予報などあり得ない話で、聞いてみると、宇宙天気関係プロダクトに使いたいからだそうです。
http://redmine.toyoda-eizi.net/issues/150
（５） AEOLUS 関係
ESA のウィンドプロファイラ衛星 AEOLUS に C-5:48 が割り当てられました。
2015年以降打ち上げ予定だそうです。
http://www.wmo-sat.info/oscar/satellites/view/4
http://redmine.toyoda-eizi.net/issues/151
（６）副中枢指定関係
ルクセンブルク（227-1）、オーストリア（78-224）、EUMETSAT（78-254） が割り当てられました。
http://redmine.toyoda-eizi.net/issues/152
２．BUFR
（１）CGMS提案衛星関係
CGMS から五月雨で提案が出てきたというか、各国の提案をとりまとめたので、チケット
http://redmine.toyoda-eizi.net/issues/140 はいささか読みにくいですが、整理すると次のようになります。
ａ．Ｃｒｙｏｓａｔ−２関係
ＥＳＡの地球観測衛星
http://www.wmo-sat.info/oscar/satellites/view/39
追加内容：
衛星 Cryosat-2 (C-5:47)
測器 SIRAL (C-8:177)
ｂ．ＣＯＭＳ関係
韓国の静止気象衛星
http://www.wmo-sat.info/oscar/satelliteprogrammes/view/23
追加内容：
衛星分類 COMS (0-02-020:281)
衛星番号や測器番号は、まあ、そのうちでてくるのでしょう。
ｃ．しずく関係
日本の地球観測衛星
http://www.wmo-sat.info/oscar/satellites/view/130
追加内容：
衛星分類 GCOM (0-02-020:122)
衛星 GCOM-W1 (C-5:122)
測器 AMSR2 (C-8:478)
ｄ．ひまわり関係
日本の静止気象衛星
http://www.wmo-sat.info/oscar/satelliteprogrammes/view/72
追加内容：
衛星分類 Himawari (0-02-020:273)
衛星 Himawari-8 (C-5:173)
衛星 Himawari-9 (C-5:174)
測器 AHI (C-8:297)
日本の運輸多目的衛星
http://www.wmo-sat.info/oscar/satelliteprogrammes/view/71
変更内容
測器 C-8:294 を JAMI に改称
測器 C-8:295 を IMAGER/MTSAT-2 に改称
ｅ．仏・印関係
追加内容：
測器 AltiKa (C-8:62)
http://www.wmo-sat.info/oscar/instruments/view/21
測器 MADRAS (C-8:942)
http://www.wmo-sat.info/oscar/instruments/view/271
ｆ．多種衛星混合プロダクト用の衛星番号
追跡風なんかでそういうプロダクトを作るという説明です。
追加内容
衛星 "Non specific mixture of geostationary and low earth orbiting
satellites" (C-5:854)
（２）米国提案ゾンデ用センサー
ゾンデ用の気圧、温度、湿度センサーが追加になっています。
http://redmine.toyoda-eizi.net/issues/147
（３）米国提案、作成中枢 UCAR
作成中枢番号（C-1/C-11, RSMC東京なら34）に UCAR (175) が追加になりました。
http://redmine.toyoda-eizi.net/issues/149
（４）微量気体としての酸素
大気には無数の微量気体があり、これらの濃度を表わすにそれぞれGRIBパラメータ・BUFR要素番号を割り当てていると番号が枯渇するので、共通符号表 C-14 に登録した微量気体番号と、種別を捨象したパ
ラメータ（0-18-10 Air concentration [Bq.m-3], 0-20-0 Mass density [kg.m-3]
など）や要素 (0-15-027 Concentration of pollutant [mol.mol-1] など) を使うようになっています。
さて今般米国が酸素 O2 を微量気体として登録提案してきました。対流圏では酸素濃度の予報などあり得ない話で、聞いてみると、宇宙天気関係プロダクトに使いたいからだそうです。
http://redmine.toyoda-eizi.net/issues/150
（５） AEOLUS 関係
ESA のウィンドプロファイラ衛星 AEOLUS に C-5:48 が割り当てられました。
2015年以降打ち上げ予定だそうです。
http://www.wmo-sat.info/oscar/satellites/view/4
http://redmine.toyoda-eizi.net/issues/151
（６）副中枢指定関係
ルクセンブルク（227-1）、オーストリア（78-224）、EUMETSAT（78-254） が割り当てられました。
http://redmine.toyoda-eizi.net/issues/152
2013-05-07
WMO Manual on Codes の 2013年第1回ファストトラック改正（GRIB関係分)
WMO Manual on Codes の本年第1回ファストトラック改正が4月23日に成立しました。発効は5月8日からです。明日ですね。
WMO Operational Newsletter の CODES って見出しのあたりに掲示があります。
http://www.wmo.int/pages/prog/www/ois/Operational_Information/Newsletters/current_news_en.html
以下、Redmineチケットは自分の覚えのためにつけているものです。
１．ＧＲＩＢ
（１）プロダクト定義テンプレート 4.33 と 4.34 が追加されました。
これらは、数値予報に基づいて放射モデルを動かして予想された雲画像相当品のためのものです。前者は瞬間値、後者は時間統計値です。ＥＣＭＷＦ提案で気候再解析のために使うんだそうです。
http://redmine.toyoda-eizi.net/issues/92
（２）ランベルト正積方位図法が追加になりました。
これもECMWF提案で、洪水予報に使われるのだそうです。気象ではふつう正角図法を使いますが、利用ドメインによっては正積図法の地図に重ね合わせできるプロダクトが求められることもあるのでしょう。
http://redmine.toyoda-eizi.net/issues/93
（３）陸面分類別被覆率ためのプロダクト定義テンプレート 4.53 および 4.54 が追加になりました。
これもECMWF提案で、IFSのために開発中の陸面モデルでは各格子が単一の植生区分ではなく、20種類（符号表4.234として追加されたが変更も可能）の植生分布あるいは7種類の土壌（符号表4.236）それぞれの割合が各格子に与えられるんだそうです。陸面モデルの計算負荷が増えてもどうってことないから精緻化したいというと聞こえはよいですが、増えすぎた自由度をどのように検証しているのやら。まあとにかく開発中でも提案してきます。
http://redmine.toyoda-eizi.net/issues/94
あれ、でも、よく考えたら、別の符号表を追加していって番号が255を超えたらこのテンプレートは使えなくなるよね。まあ、そんなことはあまりないだろうけど。
２．BUFR
あとで作業します。
WMO Operational Newsletter の CODES って見出しのあたりに掲示があります。
http://www.wmo.int/pages/prog/www/ois/Operational_Information/Newsletters/current_news_en.html
以下、Redmineチケットは自分の覚えのためにつけているものです。
１．ＧＲＩＢ
（１）プロダクト定義テンプレート 4.33 と 4.34 が追加されました。
これらは、数値予報に基づいて放射モデルを動かして予想された雲画像相当品のためのものです。前者は瞬間値、後者は時間統計値です。ＥＣＭＷＦ提案で気候再解析のために使うんだそうです。
http://redmine.toyoda-eizi.net/issues/92
（２）ランベルト正積方位図法が追加になりました。
これもECMWF提案で、洪水予報に使われるのだそうです。気象ではふつう正角図法を使いますが、利用ドメインによっては正積図法の地図に重ね合わせできるプロダクトが求められることもあるのでしょう。
http://redmine.toyoda-eizi.net/issues/93
（３）陸面分類別被覆率ためのプロダクト定義テンプレート 4.53 および 4.54 が追加になりました。
これもECMWF提案で、IFSのために開発中の陸面モデルでは各格子が単一の植生区分ではなく、20種類（符号表4.234として追加されたが変更も可能）の植生分布あるいは7種類の土壌（符号表4.236）それぞれの割合が各格子に与えられるんだそうです。陸面モデルの計算負荷が増えてもどうってことないから精緻化したいというと聞こえはよいですが、増えすぎた自由度をどのように検証しているのやら。まあとにかく開発中でも提案してきます。
http://redmine.toyoda-eizi.net/issues/94
あれ、でも、よく考えたら、別の符号表を追加していって番号が255を超えたらこのテンプレートは使えなくなるよね。まあ、そんなことはあまりないだろうけど。
２．BUFR
あとで作業します。
2013-04-28
メルボルンに来ました
今年のGWはオーストラリア…ではなく、WMO第V地区WIS/TDCFワークショップ（URL忘れた）でWISメタデータ関係の講師を務めます。
火曜のぶんのプレゼンがさきほど脱稿。ここ数週間ばかりちょっとどうにかなりそうでしたが、そろそろ峠を越えるでしょうか。
宿のインターネットがずいぶんお値段が張るので、まるでダイヤルアップ時代のように「接続したらtodoリスト」を作って待ち構えています。そう、通信て高価な時代があって、それってとてもワークスタイルに影響するんだよねとか思います。
火曜のぶんのプレゼンがさきほど脱稿。ここ数週間ばかりちょっとどうにかなりそうでしたが、そろそろ峠を越えるでしょうか。
宿のインターネットがずいぶんお値段が張るので、まるでダイヤルアップ時代のように「接続したらtodoリスト」を作って待ち構えています。そう、通信て高価な時代があって、それってとてもワークスタイルに影響するんだよねとか思います。
2013-04-26
ISO19115-2のCEOPプロファイル、JMSJに出しているとは知らんかった Xie et al. (2007)
R Xie, R Shibasaki, M Ono, 2007: Metadata Development for the Integration of
CEOP Satellite-Observation Data.
J. Meteor. Soc. Japan, vol 85A, pp 487-517.
http://dias.tkl.iis.u-tokyo.ac.jp/metadata/pdf/Xie_CEOP_Metadata.pdf
ISO 19115-2 を継承（たぶん拡張）する形でプロファイルを作った記録。
というか
http://dias.tkl.iis.u-tokyo.ac.jp/metadata/
もブックマークしておくべき。
しかし、いったい誰が査読したんだろうかね。
CEOP Satellite-Observation Data.
J. Meteor. Soc. Japan, vol 85A, pp 487-517.
http://dias.tkl.iis.u-tokyo.ac.jp/metadata/pdf/Xie_CEOP_Metadata.pdf
ISO 19115-2 を継承（たぶん拡張）する形でプロファイルを作った記録。
というか
http://dias.tkl.iis.u-tokyo.ac.jp/metadata/
もブックマークしておくべき。
しかし、いったい誰が査読したんだろうかね。
2013-04-21
2013-04-17
[CF-Metadata] 分光●●という量は波長あたりか波数あたりか周波数あたりか、より一般的には何をもって物理量を同じとするかの問題
ＣＦメーリングリストで標記問題のスレッドが起こっている。
発端
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2013/056412.html
大御所ジョナサンの方針呈示
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2013/056413.html
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2013/056416.html
実務者の賛意
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2013/056415.html
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2013/056419.html
ここで示された方針は、標準名の表に単位が１つしか書かれない以上、２つの計量の単位が物理的次元を異にするようなときは、同じ標準名のもとに収容すべきではない、ということであり、要は
物理的次元が異なる量は異なる物理量とする （※）
ということである。まあ、そうするほかない。逆の裁定がでたら、規定を全部換えたうえで m.s-1 単位の鉛直速度といわゆるωの違いはなくするということだな、と詰め
寄らねばならないところであった。
さて、※は違いだけを書いていて、任意の２つの計量が同じ物理量と判定できるような条件をあたえない。「物理量とは同じ現象に対して同じ単位を持つ計量である」といった安心感あふれる言い方はおそらくできない。同じ現象かどうかに争いがあるのが常だからである。
たとえば単位が同じケルビンであっても、気温と温位と相当温位は常識的に区別されるし、偽断熱相当温位と可逆相当温位を区別する向きもあるだろう。実務上、ホルトンの相当温位とボルトンの偽断熱相当温位を区別せねばならないことは多い。
全部区別すればいいじゃないかといわれるかもしれないけれど、ちょっと修飾語がつくと違った仕切りになるということはままあって、温位時間変化率と相当温位時間変化率を同一視する（同じハコに入れて管理したい）といったことは考えられなくもない。
残念ながらそこに銀の弾丸はないので、用途しだいでございますといって明解な理論なく終わる。
発端
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2013/056412.html
大御所ジョナサンの方針呈示
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2013/056413.html
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2013/056416.html
実務者の賛意
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2013/056415.html
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2013/056419.html
ここで示された方針は、標準名の表に単位が１つしか書かれない以上、２つの計量の単位が物理的次元を異にするようなときは、同じ標準名のもとに収容すべきではない、ということであり、要は
物理的次元が異なる量は異なる物理量とする （※）
ということである。まあ、そうするほかない。逆の裁定がでたら、規定を全部換えたうえで m.s-1 単位の鉛直速度といわゆるωの違いはなくするということだな、と詰め
寄らねばならないところであった。
さて、※は違いだけを書いていて、任意の２つの計量が同じ物理量と判定できるような条件をあたえない。「物理量とは同じ現象に対して同じ単位を持つ計量である」といった安心感あふれる言い方はおそらくできない。同じ現象かどうかに争いがあるのが常だからである。
たとえば単位が同じケルビンであっても、気温と温位と相当温位は常識的に区別されるし、偽断熱相当温位と可逆相当温位を区別する向きもあるだろう。実務上、ホルトンの相当温位とボルトンの偽断熱相当温位を区別せねばならないことは多い。
全部区別すればいいじゃないかといわれるかもしれないけれど、ちょっと修飾語がつくと違った仕切りになるということはままあって、温位時間変化率と相当温位時間変化率を同一視する（同じハコに入れて管理したい）といったことは考えられなくもない。
残念ながらそこに銀の弾丸はないので、用途しだいでございますといって明解な理論なく終わる。
2013-04-16
XSD の ID 型または NCName 型
とある ISO 19139 準拠 XML ドキュメント（つまりは地理メタデータ）を XSD でバリデートすると、id 属性が ID 型にあわないという。どうやら、コンマがだめらしい。
そういわれてみると、一体何が許されるのか知らないのも気味が悪い。
そういわれてみると、一体何が許されるのか知らないのも気味が悪い。
- NCName ::= (Letter | '_') (NCNameChar)*
- NCNameChar ::= Letter | Digit | '.' | '-' | '_' | CombiningChar | Extender
- Letter ::= 英字のみならず漢字など文字っぽいもの
- Letter ::= BaseChar | Ideographic
- BaseChar ::= [A-Z] | [a-z] | [À-Ö] | [Ø-ö] | [ø-ÿ] | [Ā-ı] | [Ĵ-ľ] | [Ł-ň] | [Ŋ-ž] | [ƀ-ǃ] | [Ǎ-ǰ] | [Ǵ-ǵ] | [Ǻ-ȗ] | [ɐ-ʨ] | [ʻ-ˁ] | Ά | [Έ-Ί] | Ό | [Ύ-Ρ] | [Σ-ώ] | [ϐ-ϖ] | Ϛ | Ϝ | Ϟ | Ϡ | [Ϣ-ϳ] | [Ё-Ќ] | [Ў-я] | [ё-ќ] | [ў-ҁ] | [Ґ-ӄ] | [Ӈ-ӈ] | [Ӌ-ӌ] | [Ӑ-ӫ] | [Ӯ-ӵ] | [Ӹ-ӹ] | [Ա-Ֆ] | ՙ | [ա-ֆ] | [א-ת] | [װ-ײ] | [ء-غ] | [ف-ي] | [ٱ-ڷ] | [ں-ھ] | [ۀ-ێ] | [ې-ۓ] | ە | [ۥ-ۦ] | [अ-ह] | ऽ | [क़-ॡ] | [অ-ঌ] | [এ-ঐ] | [ও-ন] | [প-র] | ল | [শ-হ] | [ড়-ঢ়] | [য়-ৡ] | [ৰ-ৱ] | [ਅ-ਊ] | [ਏ-ਐ] | [ਓ-ਨ] | [ਪ-ਰ] | [ਲ-ਲ਼] | [ਵ-ਸ਼] | [ਸ-ਹ] | [ਖ਼-ੜ] | ਫ਼ | [ੲ-ੴ] | [અ-ઋ] | ઍ | [એ-ઑ] | [ઓ-ન] | [પ-ર] | [લ-ળ] | [વ-હ] | ઽ | ૠ | [ଅ-ଌ] | [ଏ-ଐ] | [ଓ-ନ] | [ପ-ର] | [ଲ-ଳ] | [ଶ-ହ] | ଽ | [ଡ଼-ଢ଼] | [ୟ-ୡ] | [அ-ஊ] | [எ-ஐ] | [ஒ-க] | [ங-ச] | ஜ | [ஞ-ட] | [ண-த] | [ந-ப] | [ம-வ] | [ஷ-ஹ] | [అ-ఌ] | [ఎ-ఐ] | [ఒ-న] | [ప-ళ] | [వ-హ] | [ౠ-ౡ] | [ಅ-ಌ] | [ಎ-ಐ] | [ಒ-ನ] | [ಪ-ಳ] | [ವ-ಹ] | ೞ | [ೠ-ೡ] | [അ-ഌ] | [എ-ഐ] | [ഒ-ന] | [പ-ഹ] | [ൠ-ൡ] | [ก-ฮ] | ะ | [า-ำ] | [เ-ๅ] | [ກ-ຂ] | ຄ | [ງ-ຈ] | ຊ | ຍ | [ດ-ທ] | [ນ-ຟ] | [ມ-ຣ] | ລ | ວ | [ສ-ຫ] | [ອ-ຮ] | ະ | [າ-ຳ] | ຽ | [ເ-ໄ] | [ཀ-ཇ] | [ཉ-ཀྵ] | [Ⴀ-Ⴥ] | [ა-ჶ] | ᄀ | [ᄂ-ᄃ] | [ᄅ-ᄇ] | ᄉ | [ᄋ-ᄌ] | [ᄎ-ᄒ] | ᄼ | ᄾ | ᅀ | ᅌ | ᅎ | ᅐ | [ᅔ-ᅕ] | ᅙ | [ᅟ-ᅡ] | ᅣ | ᅥ | ᅧ | ᅩ | [ᅭ-ᅮ] | [ᅲ-ᅳ] | ᅵ | ᆞ | ᆨ | ᆫ | [ᆮ-ᆯ] | [ᆷ-ᆸ] | ᆺ | [ᆼ-ᇂ] | ᇫ | ᇰ | ᇹ | [Ḁ-ẛ] | [Ạ-ỹ] | [ἀ-ἕ] | [Ἐ-Ἕ] | [ἠ-ὅ] | [Ὀ-Ὅ] | [ὐ-ὗ] | Ὑ | Ὓ | Ὕ | [Ὗ-ώ] | [ᾀ-ᾴ] | [ᾶ-ᾼ] | ι | [ῂ-ῄ] | [ῆ-ῌ] | [ῐ-ΐ] | [ῖ-Ί] | [ῠ-Ῥ] | [ῲ-ῴ] | [ῶ-ῼ] | Ω | [K-Å] | ℮ | [ↀ-ↂ] | [ぁ-ゔ] | [ァ-ヺ] | [ㄅ-ㄬ] | [가-힣]
- Ideographic ::= [一-龥] | 〇 | [〡-〩]
- Digit ::= 各種スクリプトの数字類
- [0-9] | [٠-٩] | [۰-۹] | [०-९] | [০-৯] | [੦-੯] | [૦-૯] | [୦-୯] | [௧-௯] | [౦-౯] | [೦-೯] | [൦-൯] | [๐-๙] | [໐-໙] | [༠-༩]
- CombiningChar ::= ベース文字と結合させるための記号類
- [̀-ͅ] | [͠-͡] | [҃-҆] | [֑-֡] | [֣-ֹ] | [ֻ-ֽ] | ֿ | [ׁ-ׂ] | ׄ | [ً-ْ] | ٰ | [ۖ-ۜ] | [-۟] | [۠-ۤ] | [ۧ-ۨ] | [۪-ۭ] | [ँ-ः] | ़ | [ा-ौ] | ् | [॑-॔] | [ॢ-ॣ] | [ঁ-ঃ] | ় | া | ি | [ী-ৄ] | [ে-ৈ] | [ো-্] | ৗ | [ৢ-ৣ] | ਂ | ਼ | ਾ | ਿ | [ੀ-ੂ] | [ੇ-ੈ] | [ੋ-੍] | [ੰ-ੱ] | [ઁ-ઃ] | ઼ | [ા-ૅ] | [ે-ૉ] | [ો-્] | [ଁ-ଃ] | ଼ | [ା-ୃ] | [େ-ୈ] | [ୋ-୍] | [ୖ-ୗ] | [ஂ-ஃ] | [ா-ூ] | [ெ-ை] | [ொ-்] | ௗ | [ఁ-ః] | [ా-ౄ] | [ె-ై] | [ొ-్] | [ౕ-ౖ] | [ಂ-ಃ] | [ಾ-ೄ] | [ೆ-ೈ] | [ೊ-್] | [ೕ-ೖ] | [ം-ഃ] | [ാ-ൃ] | [െ-ൈ] | [ൊ-്] | ൗ | ั | [ิ-ฺ] | [็-๎] | ັ | [ິ-ູ] | [ົ-ຼ] | [່-ໍ] | [༘-༙] | ༵ | ༷ | ༹ | ༾ | ༿ | [ཱ-྄] | [྆-ྋ] | [ྐ-ྕ] | ྗ | [ྙ-ྭ] | [ྱ-ྷ] | ྐྵ | [⃐-⃜] | ⃡ | [〪-〯] | ゙ | ゚
- Extender ::= おどり字の類
- · | ː | ˑ | · | ـ | ๆ | ໆ | 々 | [〱-〵] | [ゝ-ゞ] | [ー-ヾ]
2013-04-12
台風の暴風域に入る確率 あるいは2つの日時を引数にせざるを得ない関数（2つの時間次元とは別）
ある種のデータは、あたかも日時型（＝年月日時分秒）の引数を２つとる関数のように複数の時間に依存する。しばしば「ＧＩＳみたいに簡単じゃなく複数の時間があるのだ」という言葉を自分でも使うのだけど、そのありようが一様ではなく、いろいろの様相があるなあと考えさせられた。
１つめの類型は、OGC WMSで予報データを扱おうとする場合、経緯度に加えて起算日時（initial time あるいは観測などに一般化するために参照日時 reference time と
いうこともある）と対象日時（valid time）を与えないとデータが特定されないよ、というような話。OGCについてはウィキ（http://goo.gl/BO54w）以上に新しい資料があったような気がするが失念して申し訳ない。データ構造としてはデータベースのキーに日時型のカラムが２つ設けるとか、配列の添字に起算日時と予報時間（対象日時と起算日時の差で得られる時間単位つきのスカラー数値）に結びついた番号を用いるといった実現のされかたをする。
２つめの類型は、1時間積算雨量であったり、30年平均値であったり、なにしろ時間方向の統計処理から生み出されるとされるデータ。
第1類型と第2類型は、排他に起こるわけではなく、たとえば降水量の予報ならば、都合3つの日時（起算日時、積算開始日時、積算終了日時）がある。
これらについて最も壮麗な体系を持っているのはGRIB第2版で、参照日時と予報時間が記述できるほかに、第4節というところに任意個の統計処理のリストを記述できて、それぞれに単位付きスカラー数値のパラメタを最大２つ記述することができる。そしてそのベースとなる量（GRIB用語ではパラメタ）は時間ひとつの関数となるような物理量でなければならない（つまり降水量ではなく降水強度のようなものが基底でなければならない）という仕組みにしようとしていた（2008年頃まで）。
なぜ統計処理がリストかというと、4月の毎日19時台の降水量の平均値を過去30年間にわたって平均したもの、みたいな概念がありうるから。
しかし、この偉大なミニマリスト・プログラムはもう悲しいくらいに理解されていない。通報式マニュアルにおいてすらひどい混乱があったので読みとることさえ困難だったくらいである。現実のユーザ受容としては、特に積算値については、たとえば9日23時から10日0時の降水量といわず9日24時の1時間降水量と言いたがるように、「1時間降水量」というパラメタ付き物理量があって、それが瞬間値として与えられるといういいかたが文章上行われるし、データもその概念を反映してほしいと思う人が多い。
べつになにもGRIB2だけをdisりたいわけではなく、他の気象データ形式においても、次元リストをビルトインの固有名詞にしようとする限りは本質的に同じ問題が発生している。19世紀の言語学では言語は総合から分析に進化するなんて言われたけどどうもそうじゃないように、ここではどうも分析至上主義の旗色が悪くて、日射強度の時間積算なんて言わせようとすると嫌がられる。
ここまでは既知の話。いや、まあ、どこにもまとまった議論なんかないだろうが。
さて、今日、「台風の暴風域に入る確率」「熱低が接近する確率」について議論（http://goo.gl/PokKS）していて気がついたのだけれど、３つめの類型かな、と思ったのは、このようなイベント生起確率。
このような量はある日時範囲に対して定義されるのだけれど、それを日時ひとつだけの関数の統計処理として書き下すことが困難である。「ｔ時間の間に暴風域に入る確率」をｔについて微分したものをナントカ確率密度と定義するのは数理的には自由だけれども、実務上は意味不明になるばかりである。
つまり、本来的に日時を２つ引数にとる関数で表わさざるをえない量があることがわかった。少々おおげさに言えば、日時を１つだけ引数にとる関数と統計処理リストに分解しようとするGRIB2のミニマリズムが原理的に否定されるのである。
まあ、システム屋的には、そんな意地悪をいっていても仕方がないので、「統計じゃないことを示す統計処理番号」（実は日本の天気ガイダンスや発雷確率ガイダンスがそうなっている）を導入して追加的メタデータ記述欄を設けるのがいいのだろう。
さて、ECMWFの熱低遭遇確率GPVはどうなるだろうか。
１つめの類型は、OGC WMSで予報データを扱おうとする場合、経緯度に加えて起算日時（initial time あるいは観測などに一般化するために参照日時 reference time と
いうこともある）と対象日時（valid time）を与えないとデータが特定されないよ、というような話。OGCについてはウィキ（http://goo.gl/BO54w）以上に新しい資料があったような気がするが失念して申し訳ない。データ構造としてはデータベースのキーに日時型のカラムが２つ設けるとか、配列の添字に起算日時と予報時間（対象日時と起算日時の差で得られる時間単位つきのスカラー数値）に結びついた番号を用いるといった実現のされかたをする。
２つめの類型は、1時間積算雨量であったり、30年平均値であったり、なにしろ時間方向の統計処理から生み出されるとされるデータ。
第1類型と第2類型は、排他に起こるわけではなく、たとえば降水量の予報ならば、都合3つの日時（起算日時、積算開始日時、積算終了日時）がある。
これらについて最も壮麗な体系を持っているのはGRIB第2版で、参照日時と予報時間が記述できるほかに、第4節というところに任意個の統計処理のリストを記述できて、それぞれに単位付きスカラー数値のパラメタを最大２つ記述することができる。そしてそのベースとなる量（GRIB用語ではパラメタ）は時間ひとつの関数となるような物理量でなければならない（つまり降水量ではなく降水強度のようなものが基底でなければならない）という仕組みにしようとしていた（2008年頃まで）。
なぜ統計処理がリストかというと、4月の毎日19時台の降水量の平均値を過去30年間にわたって平均したもの、みたいな概念がありうるから。
しかし、この偉大なミニマリスト・プログラムはもう悲しいくらいに理解されていない。通報式マニュアルにおいてすらひどい混乱があったので読みとることさえ困難だったくらいである。現実のユーザ受容としては、特に積算値については、たとえば9日23時から10日0時の降水量といわず9日24時の1時間降水量と言いたがるように、「1時間降水量」というパラメタ付き物理量があって、それが瞬間値として与えられるといういいかたが文章上行われるし、データもその概念を反映してほしいと思う人が多い。
べつになにもGRIB2だけをdisりたいわけではなく、他の気象データ形式においても、次元リストをビルトインの固有名詞にしようとする限りは本質的に同じ問題が発生している。19世紀の言語学では言語は総合から分析に進化するなんて言われたけどどうもそうじゃないように、ここではどうも分析至上主義の旗色が悪くて、日射強度の時間積算なんて言わせようとすると嫌がられる。
ここまでは既知の話。いや、まあ、どこにもまとまった議論なんかないだろうが。
さて、今日、「台風の暴風域に入る確率」「熱低が接近する確率」について議論（http://goo.gl/PokKS）していて気がついたのだけれど、３つめの類型かな、と思ったのは、このようなイベント生起確率。
このような量はある日時範囲に対して定義されるのだけれど、それを日時ひとつだけの関数の統計処理として書き下すことが困難である。「ｔ時間の間に暴風域に入る確率」をｔについて微分したものをナントカ確率密度と定義するのは数理的には自由だけれども、実務上は意味不明になるばかりである。
つまり、本来的に日時を２つ引数にとる関数で表わさざるをえない量があることがわかった。少々おおげさに言えば、日時を１つだけ引数にとる関数と統計処理リストに分解しようとするGRIB2のミニマリズムが原理的に否定されるのである。
まあ、システム屋的には、そんな意地悪をいっていても仕方がないので、「統計じゃないことを示す統計処理番号」（実は日本の天気ガイダンスや発雷確率ガイダンスがそうなっている）を導入して追加的メタデータ記述欄を設けるのがいいのだろう。
さて、ECMWFの熱低遭遇確率GPVはどうなるだろうか。
2013-04-10
2013-04-05
2013-04-04
メモ：TT-AvXMLのほうでやっている restful 符号表サービスは表バージョンを意識しているらしいからまあいいかと思った
BUFR表Ｂというのは、（表バージョン、符号、意味）という形の表で、（表バージョン、符号）まで指定しないと一意に意味が決まらないはずなんだけど、９８％の場合は符号だけで一意に意味が決まるという感じなわけです。そんなところで
Linked Data 的な思惑から符号だけをもって作ったＵＲＬを使って restful な符号表をウェブサービスするとプレゼンしたもんだから、大丈夫ですかと聞いたら、大丈夫だというので、まあ詳細はわからないけど問題認識しているならいいんじゃないでしょうか、という話。
https://groups.google.com/a/wmo.int/d/msg/cbs-tt-avxml/C72w5zxYdRg/LEO8eqF8TfsJ
まあ、サービスするだけじゃなくて符号表の管理（提案・採択のプロセス）とリンクしなきゃいけないよ、ということを念押ししておいたので、なんとかなるんじゃなかろうか。
Linked Data 的な思惑から符号だけをもって作ったＵＲＬを使って restful な符号表をウェブサービスするとプレゼンしたもんだから、大丈夫ですかと聞いたら、大丈夫だというので、まあ詳細はわからないけど問題認識しているならいいんじゃないでしょうか、という話。
https://groups.google.com/a/wmo.int/d/msg/cbs-tt-avxml/C72w5zxYdRg/LEO8eqF8TfsJ
まあ、サービスするだけじゃなくて符号表の管理（提案・採択のプロセス）とリンクしなきゃいけないよ、ということを念押ししておいたので、なんとかなるんじゃなかろうか。
2013-04-02
OUTLINE OF THE OPERATIONAL NUMERICAL WEATHER PREDICTION AT JMA 2013
OUTLINE OF THE OPERATIONAL NUMERICAL WEATHER PREDICTION AT JMA は気象庁の現業数値予報モデルの概要を説明したもので、数年に一度発行されています。
http://www.jma.go.jp/jma/jma-eng/jma-center/nwp/outline2013-nwp/index.htm
モデルがどうこう言えた知見はないのですが、FAX図の図郭を説明する地図がカラーになっています。
http://www.jma.go.jp/jma/jma-eng/jma-center/nwp/outline2013-nwp/pdf/outline2013_04.pdf#page=3
ここで出てくるFAX図は、すべてポーラーステレオ図法（※）かメルカトル図法なので、ポーラーステレオ図法の地図の上にならべて描くと長方形と扇形になるのでありました。
※ 北極を中心とする平射図法は気象界ではこう呼ばれる。方言かどうかわからない
http://www.jma.go.jp/jma/jma-eng/jma-center/nwp/outline2013-nwp/index.htm
モデルがどうこう言えた知見はないのですが、FAX図の図郭を説明する地図がカラーになっています。
http://www.jma.go.jp/jma/jma-eng/jma-center/nwp/outline2013-nwp/pdf/outline2013_04.pdf#page=3
ここで出てくるFAX図は、すべてポーラーステレオ図法（※）かメルカトル図法なので、ポーラーステレオ図法の地図の上にならべて描くと長方形と扇形になるのでありました。
※ 北極を中心とする平射図法は気象界ではこう呼ばれる。方言かどうかわからない
2013-04-01
JPEG2000 の codestream の構造
ISO/IEC 15444-1:2000 Annex A "Codestream Syntax" に規定がある。
なんというか、わかった気になるための概要。
・コードストリームはマーカー・マーカーセグメント・データの羅列である。
これらはすべてオクテットの倍数（BUFRと同様にパディングが行われる）。
・マーカーは 0xFF で始まる２オクテット。名前がついている。
・マーカーセグメントはマーカーの種類によって異なる構造を持つ固定長メタデータで、マーカーの種類によってはまったく存在しないこともある。
セグメントが存在する場合には、先頭２オクテットがセグメント長（セグメント長自身を含むがマーカーは含まない）。
・コードストリームは巨視的にみると次のような構造を持つ：
メインヘッダ, (タイルヘッダ, データ)+, EOC{FFD9}
・メインヘッダはSOC{FF4F}で始まるマーカー群である。
・タイルヘッダはSOT{FF90}で始まりSOD{FF93}で終わるマーカー群である。
SOTに続くセグメントの第4オクテット（SOTの最初＋6オクテット）から32ビットがタイル長で、SOTの最初からデータの終わりまでの長さである。SODに長さを書かないでSOTに書くのは読み飛ばしを効率化しようとしているのだろう。
・マーカーで素人眼にも見るべきものは、COM{FF64} つまりコメントで、セグメント第2-3オクテットが種別（0がバイナリ、1がISO 8859-15文字列）、そのあとが任意長の文字列である。まあ実際
のところ "Creator: JasPer Version 1.900.1" が入っている。
ほんとうはファイルをダンプして確認するといろいろ発見もあるだろうのだが、まだやっていない。
あとはウェーブレットとかよう説明せんので、たぶん読書ノートはこのへんでお仕舞い。
なんというか、わかった気になるための概要。
・コードストリームはマーカー・マーカーセグメント・データの羅列である。
これらはすべてオクテットの倍数（BUFRと同様にパディングが行われる）。
・マーカーは 0xFF で始まる２オクテット。名前がついている。
・マーカーセグメントはマーカーの種類によって異なる構造を持つ固定長メタデータで、マーカーの種類によってはまったく存在しないこともある。
セグメントが存在する場合には、先頭２オクテットがセグメント長（セグメント長自身を含むがマーカーは含まない）。
・コードストリームは巨視的にみると次のような構造を持つ：
メインヘッダ, (タイルヘッダ, データ)+, EOC{FFD9}
・メインヘッダはSOC{FF4F}で始まるマーカー群である。
・タイルヘッダはSOT{FF90}で始まりSOD{FF93}で終わるマーカー群である。
SOTに続くセグメントの第4オクテット（SOTの最初＋6オクテット）から32ビットがタイル長で、SOTの最初からデータの終わりまでの長さである。SODに長さを書かないでSOTに書くのは読み飛ばしを効率化しようとしているのだろう。
・マーカーで素人眼にも見るべきものは、COM{FF64} つまりコメントで、セグメント第2-3オクテットが種別（0がバイナリ、1がISO 8859-15文字列）、そのあとが任意長の文字列である。まあ実際
のところ "Creator: JasPer Version 1.900.1" が入っている。
ほんとうはファイルをダンプして確認するといろいろ発見もあるだろうのだが、まだやっていない。
あとはウェーブレットとかよう説明せんので、たぶん読書ノートはこのへんでお仕舞い。
2013-03-28
JPEG2000について 続き（ウィキペ、特許問題、ファイル形式は公表されている）
ちょっと補足。
１．ウィキペディア記事は見るに値する。
http://en.wikipedia.org/wiki/JPEG-2000
２．jp2 ファイル形式は公表されている。
http://www.jpeg.org/public/15444-1annexi.pdf
↑
http://www.jpeg.org/jpeg2000/CDs15444.html
３．特許問題があるようだ。
http://en.swpat.org/wiki/JPEG_2000
http://www.codinghorror.com/blog/2007/02/beyond-jpeg.html
弁護士じゃないし、そもそも JPEG2k の技術的内容をこれから検討しようという状況なので、あてになるようなことは何も言えないが…
ISO 15444-1 の Annex L は ISO に対して特許があると言ってきた者のリスト（17社）を挙げてつつ、他にもあるかもしれないので責任はもたんと言っているけれど、そんなことを言っていては普及しないことは策定関係者もよく自覚していて、ロイヤルティフリーにはするように話をとりまとめているようではある。
http://en.wikipedia.org/wiki/JPEG-2000#Legal_issues
http://www.itscj.ipsj.or.jp/forum/forum20050907/5Current_status_of_JPEG%202000_Encoder_standard.pdf
Firefox はサポートしていないので、議論があるが、特許問題が主因では必ずしもなく、
JPEG-XR など色々他にもある中で、普及していない物に労力をかける判断に至っていない、というべきなのだろう。
https://bugzilla.mozilla.org/show_bug.cgi?id=36351#c129
ImageMagick は JasPer まかせで俺は知らんとの立場。
http://www.imagemagick.org/discourse-server/viewtopic.php?f=1&t=19918
この違いは、セキュリティ対応体制の差と、依存ライブラリをひっくるめたバイナリ配布をしているか否かなど複数の要因によるだろう。
１．ウィキペディア記事は見るに値する。
http://en.wikipedia.org/wiki/JPEG-2000
２．jp2 ファイル形式は公表されている。
http://www.jpeg.org/public/15444-1annexi.pdf
↑
http://www.jpeg.org/jpeg2000/CDs15444.html
３．特許問題があるようだ。
http://en.swpat.org/wiki/JPEG_2000
http://www.codinghorror.com/blog/2007/02/beyond-jpeg.html
弁護士じゃないし、そもそも JPEG2k の技術的内容をこれから検討しようという状況なので、あてになるようなことは何も言えないが…
ISO 15444-1 の Annex L は ISO に対して特許があると言ってきた者のリスト（17社）を挙げてつつ、他にもあるかもしれないので責任はもたんと言っているけれど、そんなことを言っていては普及しないことは策定関係者もよく自覚していて、ロイヤルティフリーにはするように話をとりまとめているようではある。
http://en.wikipedia.org/wiki/JPEG-2000#Legal_issues
http://www.itscj.ipsj.or.jp/forum/forum20050907/5Current_status_of_JPEG%202000_Encoder_standard.pdf
Firefox はサポートしていないので、議論があるが、特許問題が主因では必ずしもなく、
JPEG-XR など色々他にもある中で、普及していない物に労力をかける判断に至っていない、というべきなのだろう。
https://bugzilla.mozilla.org/show_bug.cgi?id=36351#c129
ImageMagick は JasPer まかせで俺は知らんとの立場。
http://www.imagemagick.org/discourse-server/viewtopic.php?f=1&t=19918
この違いは、セキュリティ対応体制の差と、依存ライブラリをひっくるめたバイナリ配布をしているか否かなど複数の要因によるだろう。
2013-03-27
Jpeg2000 の画像ファイルを読んでみる
諸般の事情で JPEG2000 圧縮されたデータを読まなければいけないことになった。
JPEG というと画像だろうと思われるかもしれないが、GRIB第2版なんかでも使われている。ただ、Data template 7.40 を見ると
Octet No. 6-nn: JPEG 2000 code stream as described in Part 1 of the JPEG
2000 (ISO/IEC 15444–1:2000)
とだけあって、ぜんぜんブラックボックス化している。で、ISO規格票
http://www.iso.org/iso/catalogue_detail.htm?csnumber=37674
が 238 フランもするので、なかなか手が届かない。しかしこの規格は ITU-T T.800
でもあるのだ… http://www.itu.int/rec/T-REC-T.800/en と見に行くと、なんとISOが話をつけていて特別にお買い求めくださいとかなっている。
いろんな人がやってきて、jasperのリファレンスマニュアル読んで関数呼び出すだけでいいんだよ、大人になろうよというのだが、規格票に照らして正誤を確認できないプログラミングなんかナンセンスであって、まあ、なんかググると
http://www.jpeg.org/public/fcd15444-1.pdf とか怪しげなものが引っかかるが、けっこうこいつは古くてぜんぜんだめである。かかる非オープン標準なんぞ断固として相手にしないと忌み嫌ってきたのだが、まあ、いろいろあって、そうもいかなくなってきたという浮世の悲しさ。すべて貧乏が悪いのよ。
なお、私の説明は雑なのでお読みになった諸兄にいかなる損害を生じても一切関知しない。繰り返すが、私と同程度のパラノイアであったなら、今すぐISO に238フランを払ってすぐにダウンロードしてほ
しい。なお、買ったのに意味不明だったと言われても関知しない。投資は自己責任でお願いいたします。
さて、規格票を概観すると本文と Annex A から Annex L からなる。本文は超ざっくりいって用語の定義である。で、 .jp2 ファイルフォーマットの説明は Annex I である。本当は
コーデックの吐いた code stream だけに興味があるのだけど、例を得るためにはファイルを用いるので、まず確認しておこう。
ファイルはボックスの羅列である（ボックスの中にボックス列が入ることもある）。ボックスは可変長のデータ構造で先頭4オクテットがビッグエンディアンのオクテット数で、ボックス長にはこの４を含む。Fortranのシーケンシャルファイルとは違って後ろにボックス長はつかない。ファイルの最後のボックスについてだけ長さ不明を示す０が許される。シークしないで書けるのはすばらしい。なかなかいいヒントをもらった。
ボックス長の次にはボックス種別を指示する4オクテットが続いていてこれは
printable な文字から選ばれている。
ボックス長が4ギガバイトを超える場合は、ダミーの１を埋めて、ボックス種別のあとに8オクテットで書く。
まるでXMLのように種別ごとに必須性、反復可能性、内部にボックス列を含むか否かがきまっていて、大略こうである。
jp, ftyp, jp2h{ ihdr bpcc? colr+ pclr? cmap? cdef? res{ resc? resd? }?},
jp2c+ & jp2i? & xml* & uuid* & uinf{ ulst? url? }*
で、細かい説明をすっとばして、8ビットグレイスケールのファイル先頭はこんなふうになる。
[0x30-0x33] = 0xBF が高さ、 [0x34-0x37] = 0x140 が幅、[0x3a] = 07 が深さから1を減じたものである。あとは固定値か、違っていればグレイスケールではないかへんてこなメタデータが存在することを示している。
その次のオクテットからが本題である。が、疲れたので今回はここまで。また次回お楽しみに（ないかもしれません）。
JPEG というと画像だろうと思われるかもしれないが、GRIB第2版なんかでも使われている。ただ、Data template 7.40 を見ると
Octet No. 6-nn: JPEG 2000 code stream as described in Part 1 of the JPEG
2000 (ISO/IEC 15444–1:2000)
とだけあって、ぜんぜんブラックボックス化している。で、ISO規格票
http://www.iso.org/iso/catalogue_detail.htm?csnumber=37674
が 238 フランもするので、なかなか手が届かない。しかしこの規格は ITU-T T.800
でもあるのだ… http://www.itu.int/rec/T-REC-T.800/en と見に行くと、なんとISOが話をつけていて特別にお買い求めくださいとかなっている。
いろんな人がやってきて、jasperのリファレンスマニュアル読んで関数呼び出すだけでいいんだよ、大人になろうよというのだが、規格票に照らして正誤を確認できないプログラミングなんかナンセンスであって、まあ、なんかググると
http://www.jpeg.org/public/fcd15444-1.pdf とか怪しげなものが引っかかるが、けっこうこいつは古くてぜんぜんだめである。かかる非オープン標準なんぞ断固として相手にしないと忌み嫌ってきたのだが、まあ、いろいろあって、そうもいかなくなってきたという浮世の悲しさ。すべて貧乏が悪いのよ。
なお、私の説明は雑なのでお読みになった諸兄にいかなる損害を生じても一切関知しない。繰り返すが、私と同程度のパラノイアであったなら、今すぐISO に238フランを払ってすぐにダウンロードしてほ
しい。なお、買ったのに意味不明だったと言われても関知しない。投資は自己責任でお願いいたします。
さて、規格票を概観すると本文と Annex A から Annex L からなる。本文は超ざっくりいって用語の定義である。で、 .jp2 ファイルフォーマットの説明は Annex I である。本当は
コーデックの吐いた code stream だけに興味があるのだけど、例を得るためにはファイルを用いるので、まず確認しておこう。
ファイルはボックスの羅列である（ボックスの中にボックス列が入ることもある）。ボックスは可変長のデータ構造で先頭4オクテットがビッグエンディアンのオクテット数で、ボックス長にはこの４を含む。Fortranのシーケンシャルファイルとは違って後ろにボックス長はつかない。ファイルの最後のボックスについてだけ長さ不明を示す０が許される。シークしないで書けるのはすばらしい。なかなかいいヒントをもらった。
ボックス長の次にはボックス種別を指示する4オクテットが続いていてこれは
printable な文字から選ばれている。
ボックス長が4ギガバイトを超える場合は、ダミーの１を埋めて、ボックス種別のあとに8オクテットで書く。
まるでXMLのように種別ごとに必須性、反復可能性、内部にボックス列を含むか否かがきまっていて、大略こうである。
jp, ftyp, jp2h{ ihdr bpcc? colr+ pclr? cmap? cdef? res{ resc? resd? }?},
jp2c+ & jp2i? & xml* & uuid* & uinf{ ulst? url? }*
で、細かい説明をすっとばして、8ビットグレイスケールのファイル先頭はこんなふうになる。
00000000 00 00 00 0C 6A 50 20 20 - 0D 0A 87 0A 00 00 00 14 ....jP ........ 00000010 66 74 79 70 6A 70 32 20 - 00 00 00 00 6A 70 32 20 ftypjp2 ....jp2 00000020 00 00 00 2D 6A 70 32 68 - 00 00 00 16 69 68 64 72 ...-jp2h....ihdr 00000030 00 00 00 BF 00 00 01 40 - 00 01 07 07 00 00 00 00 .......@........ 00000040 00 0F 63 6F 6C 72 01 00 - 00 00 00 00 11 00 00 00 ..colr.......... 00000050 00 6A 70 32 63 - .jp2c
[0x30-0x33] = 0xBF が高さ、 [0x34-0x37] = 0x140 が幅、[0x3a] = 07 が深さから1を減じたものである。あとは固定値か、違っていればグレイスケールではないかへんてこなメタデータが存在することを示している。
その次のオクテットからが本題である。が、疲れたので今回はここまで。また次回お楽しみに（ないかもしれません）。
Cygwin + gcc4 で cygwin1.dll などのいらない Windows 実行ファイルを作る
ほとんど次のブログ記事できまりなのだが、パッケージ名は mingw64-i686-gcc-core
でいいのだけど、コマンド名が i686-w64-mingw32-gcc になるのがわからなくて、
cygcheck せざるを得なかった（その方法もブログに書いてある。親切だ）
Cygwinでcygwin1.dllフリーなWindows実行ファイルを作る (MinGW-w64) - wltの日記
http://d.hatena.ne.jp/wlt/20111231/1325289060
でいいのだけど、コマンド名が i686-w64-mingw32-gcc になるのがわからなくて、
cygcheck せざるを得なかった（その方法もブログに書いてある。親切だ）
Cygwinでcygwin1.dllフリーなWindows実行ファイルを作る (MinGW-w64) - wltの日記
http://d.hatena.ne.jp/wlt/20111231/1325289060
2013-03-25
2013-03-22
さいきんのCF標準名は長すぎやしないか
WMOでは現在、論理データモデルといって、地理情報標準 ISO 19156 Observations
and measurements を拡張してすべての気象データを表わすことのできる応用スキーマを開発中です。地理情報標準とは、正直手にあまるので http://www.gsi.go.jp/GIS/stdind/nyumon.html あた
りみてください。
具体的にやっていることは
http://www.wmo.int/pages/prog/www/WIS/wiswiki/tiki-download_wiki_attachment.php?attId=2123
あたりでも見るとわかるか（かえってわからなくなるかも）と思いますが、データを物理量の identification と単位その他もろもろと値を直交分離するという美しい構想
（なんだそう）です。すると、all WMO wide で調整された物理量の表のようなものがほしいから作るのを手伝ってくれという話がきたので、まずは既存の表を同じフォーマットにしてみました。
GRIB2 Table 4.2
http://toyoda-eizi.net/xmlvw/gmdct_html/http://toyoda-eizi.net/2013/0315tdcftable/GRIB2_10_0_0_CodeFlag_en.xml
BUFR/CREX Table B
http://toyoda-eizi.net/xmlvw/gmdct_html/http://toyoda-eizi.net/2013/0315tdcftable/BUFRCREX_19_0_0_TableB_en.xml
CF Standard Name
http://toyoda-eizi.net/xmlvw/gmdct_html/http://toyoda-eizi.net/2013/0315tdcftable/CFv22.xml
都合により表の形式が得体のしれない ISO 19139 ですが、まあXSLスタイルシートがかけてあるのでブラウザで眺める分にはきにならないでしょう。
ところが CF の標準名が長いのであきれました。一番長いのは「tendency_of_atmosphere_mass_content_of_particulate_organic_matter_dry_aerosol_expressed_as_carbon_due_to_emission_from_residential_and_commercial_combustion」（http://goo.gl/cDiog）で156文字もあります。表が崩れるので慌てて CSS に手をいれました。
まあ、いちおう命名法
http://cf-pcmdi.llnl.gov/documents/cf-standard-names/guidelines があってこうなっているのはわかるのですが、それにしてもツイッターにも書けない長い名前はちょっとどうかと思いました。
and measurements を拡張してすべての気象データを表わすことのできる応用スキーマを開発中です。地理情報標準とは、正直手にあまるので http://www.gsi.go.jp/GIS/stdind/nyumon.html あた
りみてください。
具体的にやっていることは
http://www.wmo.int/pages/prog/www/WIS/wiswiki/tiki-download_wiki_attachment.php?attId=2123
あたりでも見るとわかるか（かえってわからなくなるかも）と思いますが、データを物理量の identification と単位その他もろもろと値を直交分離するという美しい構想
（なんだそう）です。すると、all WMO wide で調整された物理量の表のようなものがほしいから作るのを手伝ってくれという話がきたので、まずは既存の表を同じフォーマットにしてみました。
GRIB2 Table 4.2
http://toyoda-eizi.net/xmlvw/gmdct_html/http://toyoda-eizi.net/2013/0315tdcftable/GRIB2_10_0_0_CodeFlag_en.xml
BUFR/CREX Table B
http://toyoda-eizi.net/xmlvw/gmdct_html/http://toyoda-eizi.net/2013/0315tdcftable/BUFRCREX_19_0_0_TableB_en.xml
CF Standard Name
http://toyoda-eizi.net/xmlvw/gmdct_html/http://toyoda-eizi.net/2013/0315tdcftable/CFv22.xml
都合により表の形式が得体のしれない ISO 19139 ですが、まあXSLスタイルシートがかけてあるのでブラウザで眺める分にはきにならないでしょう。
ところが CF の標準名が長いのであきれました。一番長いのは「tendency_of_atmosphere_mass_content_of_particulate_organic_matter_dry_aerosol_expressed_as_carbon_due_to_emission_from_residential_and_commercial_combustion」（http://goo.gl/cDiog）で156文字もあります。表が崩れるので慌てて CSS に手をいれました。
まあ、いちおう命名法
http://cf-pcmdi.llnl.gov/documents/cf-standard-names/guidelines があってこうなっているのはわかるのですが、それにしてもツイッターにも書けない長い名前はちょっとどうかと思いました。
GRIB2負の予報時間の件つづき
ECMWF GRIB API のメンテナのエンリコも入ってきました。ソフトウェア挙動に文句をつけられたのだから当然ですね。
https://groups.google.com/a/wmo.int/d/msg/cbs-ipet-drmm/IZMyfxgkSc8/qlSnyavWgZsJ
私のコメントと同趣だが細かいことを言わず例を出せというのはうまいやりかたです。
ところで、彼の話ででてきた
http://www.ecmwf.int/publications/manuals/d/gribapi/fm92/grib2/show/sections
は一義的には GRIB API ソフトウェアのリファレンスなんだけど、GRIB2 そのもののリファレンスとしても有用でしょう。
https://groups.google.com/a/wmo.int/d/msg/cbs-ipet-drmm/IZMyfxgkSc8/qlSnyavWgZsJ
私のコメントと同趣だが細かいことを言わず例を出せというのはうまいやりかたです。
ところで、彼の話ででてきた
http://www.ecmwf.int/publications/manuals/d/gribapi/fm92/grib2/show/sections
は一義的には GRIB API ソフトウェアのリファレンスなんだけど、GRIB2 そのもののリファレンスとしても有用でしょう。
2013-03-21
メモ：2012年度宇宙天気ユーザーズフォーラム
2月26日に開かれた由。かんたんな報告つき。
http://www-seg.nict.go.jp/SpaceWeather/forum2012/forum2012.html
http://www-seg.nict.go.jp/SpaceWeather/forum2012/forum2012.html
2013-03-19
単位記号はプレーンテキストでは旧ISO 2955によるべきだと思うが、Unicodeに上付き数字があると言われると反論できないので文字コードを貼っていきますよ
中央列の文字の一つでも見えない、読めないほどつぶれている、あるいは左列と区別できないのであれば、ISO 2955 を廃止した連中に文句を言ってください。私も極力避けようとはしているけれど、UTF-8 ならなんでもありの文脈ではいかんともしようがありません。
あと、もっと悪趣味したいなら、Unicode の Superscripts and Subscripts Block をご参照のこと。
| base letter | superscript | entity reference | |
|---|---|---|---|
| - | ⁻ | ⁻ | |
| 0 | ⁰ | ⁰ | |
| 1 | ¹ | ¹ | |
| 2 | ² | ² | |
| 3 | ³ | ³ | |
| 4 | ⁴ | ⁴ | |
| 5 | ⁵ | ⁵ | |
| 6 | ⁶ | ⁶ | |
| 7 | ⁷ | ⁷ | |
| 8 | ⁸ | ⁸ | |
| 9 | ⁹ | ⁹ |
あと、もっと悪趣味したいなら、Unicode の Superscripts and Subscripts Block をご参照のこと。
気象学会機関紙「天気」2013年1月号を読んで
1月号がウェブに出てきたので
http://www.metsoc.jp/tenki/result.php?no[]=1&volume[]=60&page_max=50&sort=ASC
読書ノート。
・巻頭言（新野宏）
http://www.metsoc.jp/tenki/pdf/2013/2013_01_0003.pdf
ぼやっと読むと、公益社団法人たるために不特定多数に裨益しなければならないと言われたから、ジャーナルをオープンアクセス化するというロジックにみえてしまうけど、時系列をよくみれば学会が内閣府に指導されたという図ではないことがわかる…はず。
学会費払ってない人に裨益するのはけしからんとか心の狭いことを言う人がいたらこれからの情報流通を考えるとオープンアクセス化しないことは自らの価値を棄損するだけとがんばってほしいです。
・気象観測史的に見た気象官署における1958年２月11日のオーロラー観測（二宮洸三）
http://www.metsoc.jp/tenki/pdf/2013/2013_01_0021.pdf
さりげなく「IGY当時は有人気象官署が最も拡充された時期であり」と書いておられるのが胸に刺さります。
1960年代のスタイル、あるいは観測から予報まで人手による業務をアプリオリの価値とするならば、ここ50年間は後退戦ともいえます。が、感傷にひたっていても何も生まれません。ひとまず現場としてはどうやって文明を維持していくかと考えなければなりません。
本題についても考えさせられるところです。参加することに意義がある、で済ませるわけにはいかないでしょうから。
・気象観測とデータ（二宮洸三）
http://www.metsoc.jp/tenki/pdf/2013/2013_01_0037.pdf
「２．気象観測の目的」が印象的です。今は防災にとにかく重点がおかれるわけですが、必ずしもすべてが防災だけではないし、「約1世紀以前では、国土自然環境の基本情報である気候状態の把握が重要な目的でした」というのが目を開かれる思いがします。そういえば函館は最初「気候測量所」と称したし、東京気象台は内務省地理寮だったわけです。
・北極低気圧（田中博）
http://www.metsoc.jp/tenki/pdf/2013/2013_01_0043.pdf
熱帯低気圧、温帯低気圧にならぶ第3類型として教科書にあげられるべきというんです。
寒気核で乾燥しているって、惰性で回転しているだけなんですかね。
・地域気象観測ネットワーク「学校気象台」—岩手大学発信地域連携事業— （名越さんほか）
http://www.metsoc.jp/tenki/pdf/2013/2013_01_0057.pdf
政府機関または地方公共団体以外の方が、観測結果をインターネットで提供するために、気象業務法第6条第2項第1号にいう「その成果を発表するための気象の観測」にあたらないようなやりかたを工夫したという話です。 観測部計画課と調整したという話が書かれていて、そこは真偽を請け合いかねますが、まあたぶんそうなのでしょう。
http://www.metsoc.jp/tenki/result.php?no[]=1&volume[]=60&page_max=50&sort=ASC
読書ノート。
・巻頭言（新野宏）
http://www.metsoc.jp/tenki/pdf/2013/2013_01_0003.pdf
ぼやっと読むと、公益社団法人たるために不特定多数に裨益しなければならないと言われたから、ジャーナルをオープンアクセス化するというロジックにみえてしまうけど、時系列をよくみれば学会が内閣府に指導されたという図ではないことがわかる…はず。
学会費払ってない人に裨益するのはけしからんとか心の狭いことを言う人がいたらこれからの情報流通を考えるとオープンアクセス化しないことは自らの価値を棄損するだけとがんばってほしいです。
・気象観測史的に見た気象官署における1958年２月11日のオーロラー観測（二宮洸三）
http://www.metsoc.jp/tenki/pdf/2013/2013_01_0021.pdf
さりげなく「IGY当時は有人気象官署が最も拡充された時期であり」と書いておられるのが胸に刺さります。
1960年代のスタイル、あるいは観測から予報まで人手による業務をアプリオリの価値とするならば、ここ50年間は後退戦ともいえます。が、感傷にひたっていても何も生まれません。ひとまず現場としてはどうやって文明を維持していくかと考えなければなりません。
本題についても考えさせられるところです。参加することに意義がある、で済ませるわけにはいかないでしょうから。
・気象観測とデータ（二宮洸三）
http://www.metsoc.jp/tenki/pdf/2013/2013_01_0037.pdf
「２．気象観測の目的」が印象的です。今は防災にとにかく重点がおかれるわけですが、必ずしもすべてが防災だけではないし、「約1世紀以前では、国土自然環境の基本情報である気候状態の把握が重要な目的でした」というのが目を開かれる思いがします。そういえば函館は最初「気候測量所」と称したし、東京気象台は内務省地理寮だったわけです。
・北極低気圧（田中博）
http://www.metsoc.jp/tenki/pdf/2013/2013_01_0043.pdf
熱帯低気圧、温帯低気圧にならぶ第3類型として教科書にあげられるべきというんです。
寒気核で乾燥しているって、惰性で回転しているだけなんですかね。
・地域気象観測ネットワーク「学校気象台」—岩手大学発信地域連携事業— （名越さんほか）
http://www.metsoc.jp/tenki/pdf/2013/2013_01_0057.pdf
政府機関または地方公共団体以外の方が、観測結果をインターネットで提供するために、気象業務法第6条第2項第1号にいう「その成果を発表するための気象の観測」にあたらないようなやりかたを工夫したという話です。 観測部計画課と調整したという話が書かれていて、そこは真偽を請け合いかねますが、まあたぶんそうなのでしょう。
2013-03-18
3月8～10日の黄砂・風じん関係の特殊気象報
気象庁防災気象情報XML形式で提供されている情報の中に特殊気象報というものがあります。もともとの電報時代は１行程度のきわめて簡潔な電文で、強風、気圧、不連続線の通過など、官署間で総観場のリアルタイムの情報共有をするに値するイベントが起こったときに報じられます。不連続線はフレと呼ばれていて毎度 Untidy Bookshelves さんが解析しておられます。
この中に黄砂と風じんというものがあって、３月８日から１０日にかけて多数発信されました。せっかく収集しているのでデータベースから引っ張り出して、こんなXSLTスタイルシートで要点だけ抽出するとタブ区切りファイルができます。これをGoogle Fusion Tableに放り込むと簡単にデータベースができます。
一点留意しておくべきは、黄砂は長時間継続するもので、そういうときは１日１回くらい特殊気象報を出すようにしているように見受けられる点です。事後的に黄砂の消長をきちんと見ようとすれば定時の視程の観測を集計したほうがいいにはきまっていますが、今回は生の情報でもこのくらいは見えるということをチェックしたということになりましょうか。
この中に黄砂と風じんというものがあって、３月８日から１０日にかけて多数発信されました。せっかく収集しているのでデータベースから引っ張り出して、こんなXSLTスタイルシートで要点だけ抽出するとタブ区切りファイルができます。これをGoogle Fusion Tableに放り込むと簡単にデータベースができます。
一点留意しておくべきは、黄砂は長時間継続するもので、そういうときは１日１回くらい特殊気象報を出すようにしているように見受けられる点です。事後的に黄砂の消長をきちんと見ようとすれば定時の視程の観測を集計したほうがいいにはきまっていますが、今回は生の情報でもこのくらいは見えるということをチェックしたということになりましょうか。
2013-03-14
libtool とMakefile内の依存関係
身の回りでは Makefile 内の依存関係を作るためにソースコードをスキャンするプログラムを書くことはよく行われるのだが、うわばみさんによるとどうもそれは普通ではないことであるらしい（https://twitter.com/uwabami/status/310003176466161664 以下一連の会話参
照）。
Libtoolって一体なんだろう状態のままでは寝覚めがわるいので、texinfo日本語版らしきもの http://www.bookshelf.jp/texi/libtool/libtool-ja.html を読んでみたが、
Makefileを作ってくれるものではなさそうだ。どうもそこはAutomakeの仕事らしい。
http://www.bookshelf.jp/texi/libtool/libtool-ja_5.html#SEC24
とりあえず。
照）。
Libtoolって一体なんだろう状態のままでは寝覚めがわるいので、texinfo日本語版らしきもの http://www.bookshelf.jp/texi/libtool/libtool-ja.html を読んでみたが、
Makefileを作ってくれるものではなさそうだ。どうもそこはAutomakeの仕事らしい。
http://www.bookshelf.jp/texi/libtool/libtool-ja_5.html#SEC24
とりあえず。
2013-03-13
気象庁XML利活用セミナーでわかったこと
12日に開かれた気象庁ＸＭＬ利活用セミナーにいってきました。なぜか誰もつだっていませんでしたが大変な人気だったと思います。また気象庁が一般公衆に公開情報の二次利用を例示するなど、画期的なことだと思います。
まあそういったことはおいといて、そこで新たにわかったことをメモしておきましょう。他人事のようなというか、ユーザ目線で書いていて異様に思われるかもしれませんが、私は中の人ではありません。 私も気象庁XMLについては迷えるユーザの一人です。
気象庁防災XMLフォーマットの中核となる文書はフォーマット仕様（ワードPDF）、辞書（エクセルPDF）、XSDスキーマだといいます。辞書と XSDスキーマは本質的には同じことを書いたものでヒューマンリーダブルなのが辞書ですが、実際に規格策定者は辞書だけ見ているので、注釈は辞書にしかはいっておらず、辞書をリファレンスにする（仕様はその辞書の読み方を説明する）ことが想定されているというあたりは、まあ ISO 19139 にかぎらず世間でよくある光景です。
それでも、構文規則として機械検証可能なXSDを頼りに読もうという人も多いと思いますが、ルート要素 jmx:Report の3番目の子が
しかし今回、 jmx_mete:Body, jmx_seis:Body, jmx_volc:Body のいずれかだけが用いられる現状運用であると明言されました。これで、追っていくことができるようになるので、すこしは安心感が持てるものとおもいます。XSDをダウンロードして使う人は、choice とか any の名前空間列挙になおしたらいいでしょう。
（追記：辞書やXSDの役割は、気象庁XML全体がとりうる構造の規定と各要素の注釈ですが、それとは別に個々の情報種類ごとにきまった構造があります。それは解説資料が規定するもので、プロファイルといってもいいという説明が腑に落ちました。残念ながら、このプロファイルこそが機械可読版があるとアプリケーション開発に大きく力になるはずなのですが、辞書を簡略化したようなフォーマットで書かれていて場所によってスタイルが違い、また「データ作成者が変化範囲を限定することでアプリケーション開発者が備えるべきことが減って助かる」という発想が希薄だったと思われる節があります。ひとつには XSD は名前空間毎に別ファイルなのでファイル管理が面倒になるということもあり、 Relax NG か Schematron を使えば改善できると思います。試しに台風でつくってみたRNCがこちらになります。）
ついでに、たぶんほとんどの方に通じないと思われるので、方言的事項の説明
サンプルデータ整理表の備考欄に一部 #3④ のような記号が入っていますが、これは項番毎にいくつかのシナリオに沿って継起すべきサンプルが揃えてあって（#3がシナリオ3番）、その4番目という意味だそうです。
だそうです。あくまで現状の運用と理解するべきだと思います。
現行の配信スキームでは、 受信サブスクライバに PubSubHubbub （PuSH）ハブからのアクセスが来た時、その内容が真正の気象庁起源のものであるか知るすべは、AtomフィードURL と hub.verify_token パラメタしかありません。
残念ながら、hub.verify_token パラメタは HTTP GET メソッドによる登録確認時だけで、POST メソッドでフィードが送り込まれる段階では、Atom フィード URL の先頭マッチに拠らざるを得ないということに PuSH プロトコル上はなっていたのでした。
ところが、Google Alert Hub では、POST メソッドのリクエストヘッダ HTTP_X_HUB_SIGNATURE として hub.verify_token をキーにして HTTP リクエストボディから得た HMAC-SHA1 ハッシュ値が与えられるらしいです。PHP での認証コード例が示されたわけですが、いくらなんでもPHPばかりは御助けを…とお考えの諸兄は ruby OpenSSL::HMAC みたいなのは結構あるので適当にぐぐってがんばっていただきたいと思います。
まあそういったことはおいといて、そこで新たにわかったことをメモしておきましょう。他人事のようなというか、ユーザ目線で書いていて異様に思われるかもしれませんが、私は中の人ではありません。 私も気象庁XMLについては迷えるユーザの一人です。
Report直下Body要素のXSD規定がゆるすぎる件
気象庁防災XMLフォーマットの中核となる文書はフォーマット仕様（ワードPDF）、辞書（エクセルPDF）、XSDスキーマだといいます。辞書と XSDスキーマは本質的には同じことを書いたものでヒューマンリーダブルなのが辞書ですが、実際に規格策定者は辞書だけ見ているので、注釈は辞書にしかはいっておらず、辞書をリファレンスにする（仕様はその辞書の読み方を説明する）ことが想定されているというあたりは、まあ ISO 19139 にかぎらず世間でよくある光景です。
それでも、構文規則として機械検証可能なXSDを頼りに読もうという人も多いと思いますが、ルート要素 jmx:Report の3番目の子が
<xs:any maxOccurs="1" minOccurs="1" namespace="##other" processContents="lax"/>（日本語訳すると「なんでもあり」）と書いてあるので途方にくれるという意見があるんだそうです。
しかし今回、 jmx_mete:Body, jmx_seis:Body, jmx_volc:Body のいずれかだけが用いられる現状運用であると明言されました。これで、追っていくことができるようになるので、すこしは安心感が持てるものとおもいます。XSDをダウンロードして使う人は、choice とか any の名前空間列挙になおしたらいいでしょう。
（追記：辞書やXSDの役割は、気象庁XML全体がとりうる構造の規定と各要素の注釈ですが、それとは別に個々の情報種類ごとにきまった構造があります。それは解説資料が規定するもので、プロファイルといってもいいという説明が腑に落ちました。残念ながら、このプロファイルこそが機械可読版があるとアプリケーション開発に大きく力になるはずなのですが、辞書を簡略化したようなフォーマットで書かれていて場所によってスタイルが違い、また「データ作成者が変化範囲を限定することでアプリケーション開発者が備えるべきことが減って助かる」という発想が希薄だったと思われる節があります。ひとつには XSD は名前空間毎に別ファイルなのでファイル管理が面倒になるということもあり、 Relax NG か Schematron を使えば改善できると思います。試しに台風でつくってみたRNCがこちらになります。）
運用整理表は重要
運用整理表は、どんな種類のデータがあるのか一覧することができるとても便利な表です。これに気付かないと、よくわからないので全部受信してしばらく貯めてから /Report/Control/Title を抽出して「ほんとうにこれで全部かなあ」と言いつつアプリ開発、とかいった闇雲になりますが、脱することができます。ついでに、たぶんほとんどの方に通じないと思われるので、方言的事項の説明
- 「ナントカ管理表」、は「ナントカ一覧表」のことです。
- 管理部の「管理」はちょっと違っていて、通信処理、とか、キーといって説明しようとしているのは、せんじつめれば処理または配信先の振り分けのことです。/Report/Control 以下はそのための情報です。/Report/Head と /Report/Body が処理されるべきペイロードです。
サンプルデータ整理表の＃数字
サンプルデータ整理表の備考欄に一部 #3④ のような記号が入っていますが、これは項番毎にいくつかのシナリオに沿って継起すべきサンプルが揃えてあって（#3がシナリオ3番）、その4番目という意味だそうです。
Google Alert Hub は5日おきに登録確認をしてくる件
だそうです。あくまで現状の運用と理解するべきだと思います。
Google Alert Hub が POST にも認証情報を入れてくれている件
現行の配信スキームでは、 受信サブスクライバに PubSubHubbub （PuSH）ハブからのアクセスが来た時、その内容が真正の気象庁起源のものであるか知るすべは、AtomフィードURL と hub.verify_token パラメタしかありません。
残念ながら、hub.verify_token パラメタは HTTP GET メソッドによる登録確認時だけで、POST メソッドでフィードが送り込まれる段階では、Atom フィード URL の先頭マッチに拠らざるを得ないということに PuSH プロトコル上はなっていたのでした。
ところが、Google Alert Hub では、POST メソッドのリクエストヘッダ HTTP_X_HUB_SIGNATURE として hub.verify_token をキーにして HTTP リクエストボディから得た HMAC-SHA1 ハッシュ値が与えられるらしいです。PHP での認証コード例が示されたわけですが、いくらなんでもPHPばかりは御助けを…とお考えの諸兄は ruby OpenSSL::HMAC みたいなのは結構あるので適当にぐぐってがんばっていただきたいと思います。
2013-03-12
（WMOメタデータ、議論中）格子データの空間・時間解像度
議論の途中だけど頭の整理のためにメモ。
Xiaobo の質問に Ted 答えていわく、
https://groups.google.com/a/wmo.int/d/msg/cbs-ipet-mdrd/q4p_Vh3I-cE/V3ljcRqNe1EJ
「時間解像度は update frequency とすることもできるが、本当は違う概念。ISO
19115-1 には追加された」
元問いを読み返すにそうなのだろう。私のメールが失当であった。
これはよくある２つの時間次元の問題で、update frequency は発出間隔つまり参照時間の次元における解像度であり、1回の発出で提供されるデータの予報時間の次元における解像度は別概念である。GRIB1のヘッダ粒度での記述しかしないなら予報時間は1点になるからこの問題を逃げることができていただけのことである。
さて最初版 ISO 19139 では
spatialRepresenntationIfo/MD_GridSpatialRepresentaton などしかなく、そこには時間軸は予定されていないということであろうが、実際には MD_DimensionNameType が値 time をとりうるので、 "Spatial" という名前にとらわれなければ、書いてしまうことができる。まあ、べつにいいんじゃないか。
http://toyoda-eizi.net/xmlvw/gmdct_html/http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/codelist/gmxCodelists.xml#MD_DimensionNameTypeCode
Xiaobo の質問に Ted 答えていわく、
https://groups.google.com/a/wmo.int/d/msg/cbs-ipet-mdrd/q4p_Vh3I-cE/V3ljcRqNe1EJ
「時間解像度は update frequency とすることもできるが、本当は違う概念。ISO
19115-1 には追加された」
元問いを読み返すにそうなのだろう。私のメールが失当であった。
これはよくある２つの時間次元の問題で、update frequency は発出間隔つまり参照時間の次元における解像度であり、1回の発出で提供されるデータの予報時間の次元における解像度は別概念である。GRIB1のヘッダ粒度での記述しかしないなら予報時間は1点になるからこの問題を逃げることができていただけのことである。
さて最初版 ISO 19139 では
spatialRepresenntationIfo/MD_GridSpatialRepresentaton などしかなく、そこには時間軸は予定されていないということであろうが、実際には MD_DimensionNameType が値 time をとりうるので、 "Spatial" という名前にとらわれなければ、書いてしまうことができる。まあ、べつにいいんじゃないか。
http://toyoda-eizi.net/xmlvw/gmdct_html/http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/codelist/gmxCodelists.xml#MD_DimensionNameTypeCode
2013-03-07
WMO基礎組織委員会第１５回会合（CBS-15）議事録および同管理部会第１４回会合（CBS-MG-14）議事録発行
WMO事務局よりアナウンスがありました。
CBS Reports
http://www.wmo.int/pages/prog/www/CBS/CBSsession-index.html
CBS-MG Reports
http://www.wmo.int/pages/prog/www/CBS-Reports/MG-index.html
CBS Reports
http://www.wmo.int/pages/prog/www/CBS/CBSsession-index.html
CBS-MG Reports
http://www.wmo.int/pages/prog/www/CBS-Reports/MG-index.html
2013-03-05
OSCAR - WMO/WIGOS の観測ニーズ・衛星データベース
WMO/WIGOS での観測ニーズ・能力データベース OSCAR
http://www.wmo-sat.info/oscar/ について知った。
WIGOS (WMO Integrated Global Observing System) というのは衛星地上とわず気象観測（宇宙天気も含む）の国際調整をしようというフレームワークで、各使途に応じたニーズにあわせて観測能力を調整するという建前である。
で、その本来用途じゃなくても、次の資料は使えるだろうと思った。
地球観測衛星リスト（測器まで載っている）
http://www.wmo-sat.info/oscar/satellites
分野リスト（ＷＭＯの組織上ではなく実効性のあるコミュニティになっている）
http://www.wmo-sat.info/oscar/applicationareas
鉛直層リスト (ISO 19115 の keyword[keywordType="stratum"] として使える）
http://www.wmo-sat.info/oscar/layers
変数（物理量）リスト（ＣＦのそれより比較用に粗くまとめたものと解してほしい）
http://www.wmo-sat.info/oscar/variables
物理量リストとしては次のようなものがあるが、もちろんこれからアップデートされるリストのほうがいいにきまっている。
http://www.wmo-sat.info/oscar/ について知った。
WIGOS (WMO Integrated Global Observing System) というのは衛星地上とわず気象観測（宇宙天気も含む）の国際調整をしようというフレームワークで、各使途に応じたニーズにあわせて観測能力を調整するという建前である。
で、その本来用途じゃなくても、次の資料は使えるだろうと思った。
地球観測衛星リスト（測器まで載っている）
http://www.wmo-sat.info/oscar/satellites
分野リスト（ＷＭＯの組織上ではなく実効性のあるコミュニティになっている）
http://www.wmo-sat.info/oscar/applicationareas
鉛直層リスト (ISO 19115 の keyword[keywordType="stratum"] として使える）
http://www.wmo-sat.info/oscar/layers
変数（物理量）リスト（ＣＦのそれより比較用に粗くまとめたものと解してほしい）
http://www.wmo-sat.info/oscar/variables
物理量リストとしては次のようなものがあるが、もちろんこれからアップデートされるリストのほうがいいにきまっている。
- 超古典的な WMO Technical Regulations 冒頭の requirements
- GCOS Essential Climate Variables
- INSPIRE Spatial Data Themes
2013-03-04
ミネアポリスの暴風雪警報（外出への警告あり）
さきの北海道の暴風雪によるいたましい人命被害が報告されている。
考えさせられたのが車が雪に埋まったことによる排ガス中毒で、一般的な解説としては、雪に埋まったらエンジンを止めろという。しかし車両の防寒性など知れたものですぐに凍えてしまう。なので、まずは「大雪ならば命を賭けるに値する理由でもなければ外出してはならない」というところに力点がおかれるべきだと思うのだが、それでも万一天候を読み誤ったときに備え冬場は寝袋か毛布などを用意しておけと誰かに聞いたのだが誰か忘れてしまった。
ちょうど今、米国中西部でも大雪となっているので、ミネアポリス地台は次のような警報文 http://goo.gl/0xvfz を出している。末尾の１段落が外出しようとする者への注意である。
「暴風雪警報は厳しい気象条件が予想されるか現に発生していることを意味しています。相当な量の大雪が予測されており、外出は危険です。真に緊急な場合以外は外出しないでください。どうしても外出しなければならない場合は、緊急事態に備え予備の懐中電灯、食糧、水を車両に備えてください。」
ここでは毛布等を挙げていないが、閉じ込められる可能性があることを伝えれば十分ということだろうか。
==============================================================
URGENT - WINTER WEATHER MESSAGE
NATIONAL WEATHER SERVICE TWIN CITIES/CHANHASSEN MN
913 PM CST SUN MAR 3 2013
...SNOW SPREADING IN TONIGHT AND LASTING THROUGH TUESDAY...
.SNOWFALL ACCUMULATIONS OF 6 TO 10 INCHES ARE EXPECTED ACROSS
MUCH OF CENTRAL AND SOUTHERN MINNESOTA AND FAR WESTERN WISCONSIN
DEVELOPING TONIGHT AND LASTING THROUGH TUESDAY...AS A WINTER
STORM MOVES ACROSS THE NORTHERN PLAINS AND UPPER MIDWEST. SOME
STORM TOTALS COULD APPROACH 12 INCHES DEPENDING ON WHERE PRIMARY
SNOW BANDS SET UP.
THIS SNOWFALL LOOKS TO BE SPLIT UP INTO TWO WAVES OF SNOW. THE
FIRST WILL COME TONIGHT THROUGH MONDAY MORNING...WITH A SECOND
ROUND EXPECTED MONDAY NIGHT THROUGH TUESDAY MORNING. SNOWFALL
RATES ARE EXPECTED TO DECREASE FOR A PERIOD MONDAY AFTERNOON AND
EVENING BETWEEN THESE TWO WAVES.
MNZ043>045-050>053-059>063-068>070-076>078-084-085-093-WIZ014-
023>026-041115-
/O.CON.KMPX.WS.W.0003.130304T0600Z-130306T0000Z/
MORRISON-MILLE LACS-KANABEC-BENTON-SHERBURNE-ISANTI-CHISAGO-
WRIGHT-HENNEPIN-ANOKA-RAMSEY-WASHINGTON-CARVER-SCOTT-DAKOTA-
LE SUEUR-RICE-GOODHUE-WASECA-STEELE-FREEBORN-POLK-ST. CROIX-
PIERCE-DUNN-PEPIN-
INCLUDING THE CITIES OF...LITTLE FALLS...PRINCETON...MORA...
FOLEY...ELK RIVER...CAMBRIDGE...CENTER CITY...MONTICELLO...
MINNEAPOLIS...BLAINE...ST. PAUL...STILLWATER...CHASKA...
SHAKOPEE...BURNSVILLE...LE SUEUR...FARIBAULT...RED WING...
WASECA...OWATONNA...ALBERT LEA...AMERY...BALSAM LAKE...HUDSON...
NEW RICHMOND...RIVER FALLS...PRESCOTT...MENOMONIE...BOYCEVILLE...
DURAND...PEPIN
913 PM CST SUN MAR 3 2013
...WINTER STORM WARNING REMAINS IN EFFECT UNTIL 6 PM CST
TUESDAY...
A WINTER STORM WARNING REMAINS IN EFFECT UNTIL 6 PM CST TUESDAY.
* TIMING: TWO PERIODS OF MODERATE TO HEAVY SNOW EXPECTED TONIGHT
THROUGH MONDAY MORNING AND AGAIN MONDAY NIGHT INTO TUESDAY
MORNING. SNOW WILL SLOWLY DIMINISH TUESDAY AFTERNOON.
* MAIN IMPACTS: SNOW ACCUMULATION OF 6 TO 10 INCHES...WITH
ISOLATED AMOUNTS NEAR 12 INCHES POSSIBLE BY TUESDAY AFTERNOON.
* OTHER IMPACTS: SOUTHEAST WINDS GUSTING TO AROUND 25 MPH MONDAY
WILL RESULT IN SOME BLOWING AND DRIFTING SNOW IN OPEN AREAS.
PRECAUTIONARY/PREPAREDNESS ACTIONS...
A WINTER STORM WARNING FOR HEAVY SNOW MEANS SEVERE WINTER WEATHER
CONDITIONS ARE EXPECTED OR OCCURRING. SIGNIFICANT AMOUNTS OF
SNOW ARE FORECAST THAT WILL MAKE TRAVEL DANGEROUS. ONLY TRAVEL IN
AN EMERGENCY. IF YOU MUST TRAVEL...KEEP AN EXTRA FLASHLIGHT...
FOOD...AND WATER IN YOUR VEHICLE IN CASE OF AN EMERGENCY.
&&
$$
考えさせられたのが車が雪に埋まったことによる排ガス中毒で、一般的な解説としては、雪に埋まったらエンジンを止めろという。しかし車両の防寒性など知れたものですぐに凍えてしまう。なので、まずは「大雪ならば命を賭けるに値する理由でもなければ外出してはならない」というところに力点がおかれるべきだと思うのだが、それでも万一天候を読み誤ったときに備え冬場は寝袋か毛布などを用意しておけと誰かに聞いたのだが誰か忘れてしまった。
ちょうど今、米国中西部でも大雪となっているので、ミネアポリス地台は次のような警報文 http://goo.gl/0xvfz を出している。末尾の１段落が外出しようとする者への注意である。
「暴風雪警報は厳しい気象条件が予想されるか現に発生していることを意味しています。相当な量の大雪が予測されており、外出は危険です。真に緊急な場合以外は外出しないでください。どうしても外出しなければならない場合は、緊急事態に備え予備の懐中電灯、食糧、水を車両に備えてください。」
ここでは毛布等を挙げていないが、閉じ込められる可能性があることを伝えれば十分ということだろうか。
==============================================================
URGENT - WINTER WEATHER MESSAGE
NATIONAL WEATHER SERVICE TWIN CITIES/CHANHASSEN MN
913 PM CST SUN MAR 3 2013
...SNOW SPREADING IN TONIGHT AND LASTING THROUGH TUESDAY...
.SNOWFALL ACCUMULATIONS OF 6 TO 10 INCHES ARE EXPECTED ACROSS
MUCH OF CENTRAL AND SOUTHERN MINNESOTA AND FAR WESTERN WISCONSIN
DEVELOPING TONIGHT AND LASTING THROUGH TUESDAY...AS A WINTER
STORM MOVES ACROSS THE NORTHERN PLAINS AND UPPER MIDWEST. SOME
STORM TOTALS COULD APPROACH 12 INCHES DEPENDING ON WHERE PRIMARY
SNOW BANDS SET UP.
THIS SNOWFALL LOOKS TO BE SPLIT UP INTO TWO WAVES OF SNOW. THE
FIRST WILL COME TONIGHT THROUGH MONDAY MORNING...WITH A SECOND
ROUND EXPECTED MONDAY NIGHT THROUGH TUESDAY MORNING. SNOWFALL
RATES ARE EXPECTED TO DECREASE FOR A PERIOD MONDAY AFTERNOON AND
EVENING BETWEEN THESE TWO WAVES.
MNZ043>045-050>053-059>063-068>070-076>078-084-085-093-WIZ014-
023>026-041115-
/O.CON.KMPX.WS.W.0003.130304T0600Z-130306T0000Z/
MORRISON-MILLE LACS-KANABEC-BENTON-SHERBURNE-ISANTI-CHISAGO-
WRIGHT-HENNEPIN-ANOKA-RAMSEY-WASHINGTON-CARVER-SCOTT-DAKOTA-
LE SUEUR-RICE-GOODHUE-WASECA-STEELE-FREEBORN-POLK-ST. CROIX-
PIERCE-DUNN-PEPIN-
INCLUDING THE CITIES OF...LITTLE FALLS...PRINCETON...MORA...
FOLEY...ELK RIVER...CAMBRIDGE...CENTER CITY...MONTICELLO...
MINNEAPOLIS...BLAINE...ST. PAUL...STILLWATER...CHASKA...
SHAKOPEE...BURNSVILLE...LE SUEUR...FARIBAULT...RED WING...
WASECA...OWATONNA...ALBERT LEA...AMERY...BALSAM LAKE...HUDSON...
NEW RICHMOND...RIVER FALLS...PRESCOTT...MENOMONIE...BOYCEVILLE...
DURAND...PEPIN
913 PM CST SUN MAR 3 2013
...WINTER STORM WARNING REMAINS IN EFFECT UNTIL 6 PM CST
TUESDAY...
A WINTER STORM WARNING REMAINS IN EFFECT UNTIL 6 PM CST TUESDAY.
* TIMING: TWO PERIODS OF MODERATE TO HEAVY SNOW EXPECTED TONIGHT
THROUGH MONDAY MORNING AND AGAIN MONDAY NIGHT INTO TUESDAY
MORNING. SNOW WILL SLOWLY DIMINISH TUESDAY AFTERNOON.
* MAIN IMPACTS: SNOW ACCUMULATION OF 6 TO 10 INCHES...WITH
ISOLATED AMOUNTS NEAR 12 INCHES POSSIBLE BY TUESDAY AFTERNOON.
* OTHER IMPACTS: SOUTHEAST WINDS GUSTING TO AROUND 25 MPH MONDAY
WILL RESULT IN SOME BLOWING AND DRIFTING SNOW IN OPEN AREAS.
PRECAUTIONARY/PREPAREDNESS ACTIONS...
A WINTER STORM WARNING FOR HEAVY SNOW MEANS SEVERE WINTER WEATHER
CONDITIONS ARE EXPECTED OR OCCURRING. SIGNIFICANT AMOUNTS OF
SNOW ARE FORECAST THAT WILL MAKE TRAVEL DANGEROUS. ONLY TRAVEL IN
AN EMERGENCY. IF YOU MUST TRAVEL...KEEP AN EXTRA FLASHLIGHT...
FOOD...AND WATER IN YOUR VEHICLE IN CASE OF AN EMERGENCY.
&&
$$
2013-03-01
米ＮＷＳ水文気象予測センター（ＨＰＣ）が天気予測センター（ＷＰC）に改称
米ＮＷＳ発表。
http://www.nws.noaa.gov/os/notification/pns13hpc_name_change.txt
しょうもない個人的感想になってしまうけれど、
・HPC は High Performance Computing の略でもあるのでまぎらわしくなくてありがたい。
・水文気象より天気のほうが広い概念という説明はいまひとつよくわからない。
http://www.nws.noaa.gov/os/notification/pns13hpc_name_change.txt
しょうもない個人的感想になってしまうけれど、
・HPC は High Performance Computing の略でもあるのでまぎらわしくなくてありがたい。
・水文気象より天気のほうが広い概念という説明はいまひとつよくわからない。
PTWCのインド洋津波アドバイザリ業務終了
米ＮＷＳ発表
http://www.nws.noaa.gov/os/notification/scn13-17ptwc_iotwsproducts.txt
２００４年のスマトラ津波を受けて、ＰＴＷＣは暫定的にインド洋域の津波アドバイザリを出す業務をしていたところ、ユネスコＩＯＣの調整のおとでのインド洋地域３国（豪、印、尼）の体制整備を受けて２０１３年３月３１日をもって業務を終了するとのこと。
基本的には当庁と同じ流れです。
http://www.nws.noaa.gov/os/notification/scn13-17ptwc_iotwsproducts.txt
２００４年のスマトラ津波を受けて、ＰＴＷＣは暫定的にインド洋域の津波アドバイザリを出す業務をしていたところ、ユネスコＩＯＣの調整のおとでのインド洋地域３国（豪、印、尼）の体制整備を受けて２０１３年３月３１日をもって業務を終了するとのこと。
基本的には当庁と同じ流れです。
2013-02-26
OGC Approves "Semantic annotations in OGC standards" Best practice document
OGC プレスリリースのお知らせがきた。
https://groups.google.com/a/wmo.int/d/topic/cbs-ipet-mdrd/ficIoIDiB6s/discussion
モノはこちら： 08-167r2
https://portal.opengeospatial.org/files/?artifact_id=47857
ISO 19139 との関係では、たとえば GEMET のようにシソーラス
http://www.eionet.europa.eu/gemet/inspire_themes?langcode=en
だけではなく概念
http://www.eionet.europa.eu/gemet/concept?ns=1&cp=4612
に URI がある場合には Anchor を使って各語句に URL を annotate するのが望ましいという。
https://groups.google.com/a/wmo.int/d/topic/cbs-ipet-mdrd/ficIoIDiB6s/discussion
モノはこちら： 08-167r2
https://portal.opengeospatial.org/files/?artifact_id=47857
ISO 19139 との関係では、たとえば GEMET のようにシソーラス
http://www.eionet.europa.eu/gemet/inspire_themes?langcode=en
だけではなく概念
http://www.eionet.europa.eu/gemet/concept?ns=1&cp=4612
に URI がある場合には Anchor を使って各語句に URL を annotate するのが望ましいという。
2013-02-21
（重箱の隅…で済むといいなあ） codeList の中のテキストノード値
先日のエントリ（２）
http://toyoda-eizi-ja.blogspot.com/2013/02/wmo_18.html
で
「本当は、codeListValue 属性が機械可読な語句で、内部のテキストノード
gmd:LanguageCode/text() は多言語化ができるらしいのですが、WMO では結局英語をデフォルト言語にしろといっているので両方同じ文字列を入れろということになります。 」
とさらっと逃げていますが、本当は
… codeListValue="eng">English</ …
みたいなのが正しいかもしれないという議論があります。INSPIRE Implementation
Rule http://inspire.jrc.ec.europa.eu/index.cfm/pageid/101 §2.2.7 は
1) Most interoperable: the element value repeats the codeListValue, 2) Most
compliant: the element value is the name of the codeListValue expressed in
the default language of the Metadata
てなことをいっていて、ISOの規定通りに実装している人が少ない、ということのようです。
http://toyoda-eizi-ja.blogspot.com/2013/02/wmo_18.html
で
「本当は、codeListValue 属性が機械可読な語句で、内部のテキストノード
gmd:LanguageCode/text() は多言語化ができるらしいのですが、WMO では結局英語をデフォルト言語にしろといっているので両方同じ文字列を入れろということになります。 」
とさらっと逃げていますが、本当は
… codeListValue="eng">English</ …
みたいなのが正しいかもしれないという議論があります。INSPIRE Implementation
Rule http://inspire.jrc.ec.europa.eu/index.cfm/pageid/101 §2.2.7 は
1) Most interoperable: the element value repeats the codeListValue, 2) Most
compliant: the element value is the name of the codeListValue expressed in
the default language of the Metadata
てなことをいっていて、ISOの規定通りに実装している人が少ない、ということのようです。
WMO地理メタデータ（３というほどではないが）リファレンス書きかけ
一日あきましたが、前項の続き。
2回かけてUMLとXMLの対応関係（バインディングといったけどISO的にはエンコーディングというほうが正しいのかも）の話で終始していて、中身の話をしてません。つまり、ドメイン知識ぜんぜんつかっていない。地理学会公式アカにRTされて、これで終わるわけにはいかんでしょう。
で、各項目について語ろうとすると、トップダウン的アプローチと逐条解説的アプローチがあると思うのですが、 どっちにしても全体像と各要素の近傍の構造を見えるようにしておかないと話ができないなあ、とおもうわけです。
…すんませんカッコつけすぎました。あたしの脳内マップが心もとないので確認するというのが本当のところ…
で、リファレンスをちょっと作ってみました。
http://redmine.toyoda-eizi.net/projects/wcmp/wiki/MD_Metadata
とりあえず、WMOプロファイル１．３の範囲は辛うじてカバーです。ただ、codeList がまだなので、実は半分なんですが。
2回かけてUMLとXMLの対応関係（バインディングといったけどISO的にはエンコーディングというほうが正しいのかも）の話で終始していて、中身の話をしてません。つまり、ドメイン知識ぜんぜんつかっていない。地理学会公式アカにRTされて、これで終わるわけにはいかんでしょう。
で、各項目について語ろうとすると、トップダウン的アプローチと逐条解説的アプローチがあると思うのですが、 どっちにしても全体像と各要素の近傍の構造を見えるようにしておかないと話ができないなあ、とおもうわけです。
…すんませんカッコつけすぎました。あたしの脳内マップが心もとないので確認するというのが本当のところ…
で、リファレンスをちょっと作ってみました。
http://redmine.toyoda-eizi.net/projects/wcmp/wiki/MD_Metadata
とりあえず、WMOプロファイル１．３の範囲は辛うじてカバーです。ただ、codeList がまだなので、実は半分なんですが。
2013-02-18
WMO地理メタデータ解説 （２）バインディングの続き
http://toyoda-eizi-ja.blogspot.com/2013/02/wmo.html の続き。
XML要素名の命名規則、あまり抽象的に書きすぎたのはよくなかったのでもう一度。
実例持ってない人は http://goo.gl/ZPuyi の view source でもみてください。
ISO 19139 にしたがうXML文書のルート要素は gmd:MD_Metadata です。大文字で始まるのはクラスを表わしています。クラスわかんなかったらデータ型の名前と思ってください。MD_Metadata型。その中に gmd:fileIdentifier だの gmd:language だのといった要素が並んでいます。
まず、gmd:fileIdentifier は一番単純な例で、この項目は文字列型です（ええと、項目は、UML的には属性というのが正しいんですが、XMLの属性と紛らわしいので、私は日本では項目といって逃げています）。なので中に gco:CharacterString という要素があって、その中に値が入ります。
<gmd:fileIdentifier><gco:CharacterString>urn:x-wmo:md:int.wmo.wis::SMDL01EDZW</gco:CharacterString></gmd:fileIdentifier>
わざわざ型名を表わす CharacterString を書くのは面倒ですが、XPath でいえば
string(/中略/gmd:fileIdentifier) としてしまえばその中のテキストノードが取得できますから、読む手間はあってもなくてもあまり変わりません。
次の類型が、gmd:language 列挙型（C や Java の enum）です。任意の文字列値じゃなくて、メタデータレコード（この XML 文書）の外で誰かが決めたリストに制約されるということで
すね。この場合、どのリストを使ったかをＵＲＬで指示するようになっています。一見
LinkedData かと思われるのですが、URL で指示されるのは語句じゃなくて複数の語句を連ねたリストです。
<gmd:language>
<gmd:LanguageCodecodeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/Codelist/gmxCodelists.xml#LanguageCode"codeListValue="eng">eng</gmd:LanguageCode></gmd:language>
本当は、codeListValue 属性が機械可読な語句で、内部のテキストノード
gmd:LanguageCode/text() は多言語化ができるらしいのですが、WMO では結局英語をデフォルト言語にしろといっているので両方同じ文字列を入れろということになります。
さいごに、値が文字列１つじゃなくて、さらに内部に項目がたくさんあるのはクラスといいます（C なら構造型といったところ）。下の例だと gmd:contact 要素は
CI_ResponsibleParty クラスで、その中には organisationName やら positionName
といった項目が含まれるわけです。
<gmd:contact>
<gmd:CI_ResponsibleParty>
<gmd:organisationName><gco:CharacterString>Deutscher Wetterdienst</gco:CharacterString></gmd:organisationName>
<gmd:positionName><gco:CharacterString>RTH Focal Point</gco:CharacterString></gmd:positionName>
...
</gmd:CI_ResponsibleParty>
</gmd:contact>
あるクラスのなかに他のクラスの項目が入るといったことがありえて、全体でいうとけっこう複雑です。その関係をあらわした図が UML です。
どのくらい複雑かというとですね、ISO 19115 そのものの UML は ISO から規格票を買っていただく必要があって困るのですが、WMO プロファイルバージョン 1.1 はかなりそれに近いのでご
らんいただけばいいと思います。
http://wis.wmo.int/2010/metadata/version_1-1/WMOCoreVer1.1_UML20100318.pdf
いかがです？ 覚えなくていいですよ。ごく控えめに言って、これをそのまま非専門家に使いこなしてもらうことは期待できません。
要はいろいろ欲張るから肥大化するので、本当に必要なところはどこですかというのを煮詰めていった結果が今回発行されたバージョン 1.3 の Part 1 p.20 にある UML です。
http://wis.wmo.int/2012/metadata/WMO_Core_Metadata_Profile_v1.3_Specification_Part_1_v1.0FINALcorrected.pdf#page=20
…ながくなったのでこの辺で。
（飽きるまで続きます）
XML要素名の命名規則、あまり抽象的に書きすぎたのはよくなかったのでもう一度。
実例持ってない人は http://goo.gl/ZPuyi の view source でもみてください。
ISO 19139 にしたがうXML文書のルート要素は gmd:MD_Metadata です。大文字で始まるのはクラスを表わしています。クラスわかんなかったらデータ型の名前と思ってください。MD_Metadata型。その中に gmd:fileIdentifier だの gmd:language だのといった要素が並んでいます。
まず、gmd:fileIdentifier は一番単純な例で、この項目は文字列型です（ええと、項目は、UML的には属性というのが正しいんですが、XMLの属性と紛らわしいので、私は日本では項目といって逃げています）。なので中に gco:CharacterString という要素があって、その中に値が入ります。
<gmd:fileIdentifier><gco:CharacterString>urn:x-wmo:md:int.wmo.wis::SMDL01EDZW</gco:CharacterString></gmd:fileIdentifier>
わざわざ型名を表わす CharacterString を書くのは面倒ですが、XPath でいえば
string(/中略/gmd:fileIdentifier) としてしまえばその中のテキストノードが取得できますから、読む手間はあってもなくてもあまり変わりません。
次の類型が、gmd:language 列挙型（C や Java の enum）です。任意の文字列値じゃなくて、メタデータレコード（この XML 文書）の外で誰かが決めたリストに制約されるということで
すね。この場合、どのリストを使ったかをＵＲＬで指示するようになっています。一見
LinkedData かと思われるのですが、URL で指示されるのは語句じゃなくて複数の語句を連ねたリストです。
<gmd:language>
<gmd:LanguageCodecodeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/Codelist/gmxCodelists.xml#LanguageCode"codeListValue="eng">eng</gmd:LanguageCode></gmd:language>
本当は、codeListValue 属性が機械可読な語句で、内部のテキストノード
gmd:LanguageCode/text() は多言語化ができるらしいのですが、WMO では結局英語をデフォルト言語にしろといっているので両方同じ文字列を入れろということになります。
さいごに、値が文字列１つじゃなくて、さらに内部に項目がたくさんあるのはクラスといいます（C なら構造型といったところ）。下の例だと gmd:contact 要素は
CI_ResponsibleParty クラスで、その中には organisationName やら positionName
といった項目が含まれるわけです。
<gmd:contact>
<gmd:CI_ResponsibleParty>
<gmd:organisationName><gco:CharacterString>Deutscher Wetterdienst</gco:CharacterString></gmd:organisationName>
<gmd:positionName><gco:CharacterString>RTH Focal Point</gco:CharacterString></gmd:positionName>
...
</gmd:CI_ResponsibleParty>
</gmd:contact>
あるクラスのなかに他のクラスの項目が入るといったことがありえて、全体でいうとけっこう複雑です。その関係をあらわした図が UML です。
どのくらい複雑かというとですね、ISO 19115 そのものの UML は ISO から規格票を買っていただく必要があって困るのですが、WMO プロファイルバージョン 1.1 はかなりそれに近いのでご
らんいただけばいいと思います。
http://wis.wmo.int/2010/metadata/version_1-1/WMOCoreVer1.1_UML20100318.pdf
いかがです？ 覚えなくていいですよ。ごく控えめに言って、これをそのまま非専門家に使いこなしてもらうことは期待できません。
要はいろいろ欲張るから肥大化するので、本当に必要なところはどこですかというのを煮詰めていった結果が今回発行されたバージョン 1.3 の Part 1 p.20 にある UML です。
http://wis.wmo.int/2012/metadata/WMO_Core_Metadata_Profile_v1.3_Specification_Part_1_v1.0FINALcorrected.pdf#page=20
…ながくなったのでこの辺で。
（飽きるまで続きます）
2013-02-17
WMO地理メタデータプロファイルについて解説めいたこと（ちょっと追補あり）
英語版のブログとツイッターに最低限のアナウンス http://dlvr.it/2y1zVP をして、それなりに見ていただいている方もいるようなのだけど、多分どこから理解したものか途方に暮れると思うので、というと恩着せがましいけれど、現状の覚えとしても少々書いておいたほうがいいと思う。
まず、正式名称は WMO Core Metadata Profile という。そもそもプロファイルprofileというのは地理メタデータ標準 ISO 19115 が汎用であるのに対してWMOあるいは気象水文の応用に特化
したものであるという意味である[追記：ISO地理情報標準シリーズでの通則はISO 19106で規定されている、らしい]。それじゃ core profile とは何であるかというと、WMOといってもいささか分野が広くて中に無数のコミュニティを包含していて、それぞれにプロファイルを形成することが可能ではあるが、その共通部分たるべきもの、ということだと説明している。[ISO 19115 の中にも core profile というものがあったが、意味的に
ISO の必須要素との関係が不明確であり、また][訂正：似たような概念として ISO 19115:2003 では core metadata elements あるいは core metadata componentsというものを決めていて、すべてのプロファイルはこれを含まねばならない(下図参照）としていたのだが、必須でないものをプロファイルに含めねばならないという意義が不明確ということと、]内容的にもどうだかということで削除される方向と聞いている。
[追記：
次に、UML と XML の関係。少なくとも現行の ISO 19115 は UML であって XML はそのエンコーディング方法の一つと言う位置づけで ISO/TS 19139 という別文書になっている。そのこと自体を
論じるのはおいておいて、でも、UML クラスが XML 要素に対応するといったように用語が二重になってしまっていることはわずらわしいが付き合わざるをえない。
面白い技法と思うのは、UML クラス名に対応する XML 要素（大文字始まり）の中に、そのクラス中の属性名に対応する XML 要素（小文字始まり）が入って、その中にはその要素のク
ラスに対応する XML 要素が入る、と言う交互構造である。
・属性名はなるべく直感的に選ばれ、酷いときは重複することもあるけれど、クラス名を明示すれば微視的に特定することができる。
・クラスの特殊化、属性追加は XML スキーマの継承で行われているけれど、それは大文字のクラス名が変わるだけで、小文字部分は変わらないので、継承によって変わらない指示のしかたは
identificationInfo/*/citation/*/date のように /*/ が多用されることになる
（ちょっとちゅうだん）
まず、正式名称は WMO Core Metadata Profile という。そもそもプロファイルprofileというのは地理メタデータ標準 ISO 19115 が汎用であるのに対してWMOあるいは気象水文の応用に特化
したものであるという意味である[追記：ISO地理情報標準シリーズでの通則はISO 19106で規定されている、らしい]。それじゃ core profile とは何であるかというと、WMOといってもいささか分野が広くて中に無数のコミュニティを包含していて、それぞれにプロファイルを形成することが可能ではあるが、その共通部分たるべきもの、ということだと説明している。[
[追記：
]
次に、UML と XML の関係。少なくとも現行の ISO 19115 は UML であって XML はそのエンコーディング方法の一つと言う位置づけで ISO/TS 19139 という別文書になっている。そのこと自体を
論じるのはおいておいて、でも、UML クラスが XML 要素に対応するといったように用語が二重になってしまっていることはわずらわしいが付き合わざるをえない。
面白い技法と思うのは、UML クラス名に対応する XML 要素（大文字始まり）の中に、そのクラス中の属性名に対応する XML 要素（小文字始まり）が入って、その中にはその要素のク
ラスに対応する XML 要素が入る、と言う交互構造である。
・属性名はなるべく直感的に選ばれ、酷いときは重複することもあるけれど、クラス名を明示すれば微視的に特定することができる。
・クラスの特殊化、属性追加は XML スキーマの継承で行われているけれど、それは大文字のクラス名が変わるだけで、小文字部分は変わらないので、継承によって変わらない指示のしかたは
identificationInfo/*/citation/*/date のように /*/ が多用されることになる
（ちょっとちゅうだん）
2013-02-10
「配列を値としてもつ連想配列」の入力方法
承前： （http://toyoda-eizi-ja.blogspot.jp/2013/02/blog-post.html の続き）
1レコードがキーバリューで、バリューが単なるスカラーでなくて配列にしたいということはあるが、入力方法が課題。
エクセルを使い続けるとすると、
1セルにマルチラインを押し込む（Ａｌｔ＋Ｅｎｔｅｒってちょっとトリッキーだよね）か、
プライマリーキーがない行は「継続行」とするか。
1レコードがキーバリューで、バリューが単なるスカラーでなくて配列にしたいということはあるが、入力方法が課題。
エクセルを使い続けるとすると、
1セルにマルチラインを押し込む（Ａｌｔ＋Ｅｎｔｅｒってちょっとトリッキーだよね）か、
プライマリーキーがない行は「継続行」とするか。
2013-02-09
「配列を値としてもつ連想配列」の応用範囲の広さ
またぞろメタデータの仕事をやらねばならない季節がやってきた。
最終製品は ISO 19115 なのだが、コテコテのオブジェクト指向は本当に嫌だ（どうせ誰も理解してくれない）というのと、エクセル表をメールで送るといった紙文化（ビットにアトムのふりをさせる処理）と戦うよりは利用しないと話が進まないということから、エクセルでなんとかしたいということをずっとやっている。
しかし１レコードが単なるキーバリューではちょっとものたりない。
以前こんなスキーマをつくった。
http://www.gisc.kishou.go.jp/xsd/jmd0.1/jmd.rnc
名前だけを決めて、順序と数は問わないという構造は、
ＯＡＩ−ＰＭＨ用ダブリンコアスキーマ
http://www.openarchives.org/OAI/2.0/oai_dc.xsd
にならったのだが、この構造、結構応用範囲が広いと感じている。
ＲＦＣ８２２とかＣＧＩとかもそうだし。
最終製品は ISO 19115 なのだが、コテコテのオブジェクト指向は本当に嫌だ（どうせ誰も理解してくれない）というのと、エクセル表をメールで送るといった紙文化（ビットにアトムのふりをさせる処理）と戦うよりは利用しないと話が進まないということから、エクセルでなんとかしたいということをずっとやっている。
しかし１レコードが単なるキーバリューではちょっとものたりない。
以前こんなスキーマをつくった。
http://www.gisc.kishou.go.jp/xsd/jmd0.1/jmd.rnc
名前だけを決めて、順序と数は問わないという構造は、
ＯＡＩ−ＰＭＨ用ダブリンコアスキーマ
http://www.openarchives.org/OAI/2.0/oai_dc.xsd
にならったのだが、この構造、結構応用範囲が広いと感じている。
ＲＦＣ８２２とかＣＧＩとかもそうだし。
2013-01-31
FORTRANででかい配列のアサーション
FORTRANプログラムのリファクタリングをしている。そんなことをするからにはデータフローもなんだかよくわからない悲惨なプログラムである。
で、ロジックを推測して論理的に書きなおすのであるが、プログラムを壊してしまっていないことを確認しながらバージョン管理をすすめていかないと険呑このうえない。 そこでアサーション（想定していない動作をしたら落ちるような確認）をほうぼうに入れていくのだが、なにせFORTRANだからその対象はきまって巨大な配列である。1行で確認するためには、定数データをプログラムに埋め込むわけにいかないから、外部にファイルで持つべきである。
で、こんなサブルーチンを書いてみた。
で、ロジックを推測して論理的に書きなおすのであるが、プログラムを壊してしまっていないことを確認しながらバージョン管理をすすめていかないと険呑このうえない。 そこでアサーション（想定していない動作をしたら落ちるような確認）をほうぼうに入れていくのだが、なにせFORTRANだからその対象はきまって巨大な配列である。1行で確認するためには、定数データをプログラムに埋め込むわけにいかないから、外部にファイルで持つべきである。
で、こんなサブルーチンを書いてみた。
2013-01-30
いろいろURLメモ（銚子積雪事例、CBS-MG14, RA-II, media type suffix）
ぜんぜんかんけいないのだがご容赦。
銚子積雪事例のＮＣＥＰ再解析データによる図など
http://taket.at.webry.info/201301/article_21.html
デイリーポータルZ：街路樹に名札がついている国、日本
http://portal.nifty.com/kiji/130125159288_1.htm
（桜が枯れなくなったのは、百年で地下水位が下がったということではないのか）
WMO/CBS-MG-14
http://www.wmo.int/pages/prog/www/WIS/wiswiki/tiki-index.php?page=CBS-MG-14
WMO/RA-II-15
http://raii-15.wmo.int/documents-english
RFC6838 "Media Type Specifications and Registration Procedures"
http://tools.ietf.org/html/rfc6838
メディアタイプのサフィックス +xml が一般化されて +zip +json とかが使えるようにサフィックスレジストリを立てるという。
初期登録設定値は RFC 6839 http://tools.ietf.org/html/rfc6839
Java の jar ファイルは application/java-archive+zip であるべきだったということになろう。
ちなみに、zip ファイルの内容物の URI スキームは jar: という
https://www.iana.org/assignments/uri-schemes/prov/jar
ところで +fastinfoset てのが ITU-T X.891 なんだが、EXI とは別のバイナリXMLなんだそうだ。
http://en.wikipedia.org/wiki/Fast_Infoset
銚子積雪事例のＮＣＥＰ再解析データによる図など
http://taket.at.webry.info/201301/article_21.html
デイリーポータルZ：街路樹に名札がついている国、日本
http://portal.nifty.com/kiji/130125159288_1.htm
（桜が枯れなくなったのは、百年で地下水位が下がったということではないのか）
WMO/CBS-MG-14
http://www.wmo.int/pages/prog/www/WIS/wiswiki/tiki-index.php?page=CBS-MG-14
WMO/RA-II-15
http://raii-15.wmo.int/documents-english
RFC6838 "Media Type Specifications and Registration Procedures"
http://tools.ietf.org/html/rfc6838
メディアタイプのサフィックス +xml が一般化されて +zip +json とかが使えるようにサフィックスレジストリを立てるという。
初期登録設定値は RFC 6839 http://tools.ietf.org/html/rfc6839
Java の jar ファイルは application/java-archive+zip であるべきだったということになろう。
ちなみに、zip ファイルの内容物の URI スキームは jar: という
https://www.iana.org/assignments/uri-schemes/prov/jar
ところで +fastinfoset てのが ITU-T X.891 なんだが、EXI とは別のバイナリXMLなんだそうだ。
http://en.wikipedia.org/wiki/Fast_Infoset
2013-01-22
豆：WebサーバのSSL証明書の有効期間を表示するコマンド
echo 'HEAD / HTTP/1.0' | \
openssl s_client -connect www.example.com:443 2>&1 | \
openssl x509 -text -noout | awk '/Validity/,/After/'
うまくいけばこんなふうに表示される。
Validity
Not Before: Jan 20 12:54:09 2013 GMT
Not After : Apr 23 11:57:43 2017 GMT
openssl s_client -connect www.example.com:443 2>&1 | \
openssl x509 -text -noout | awk '/Validity/,/After/'
うまくいけばこんなふうに表示される。
Validity
Not Before: Jan 20 12:54:09 2013 GMT
Not After : Apr 23 11:57:43 2017 GMT
2013-01-16
[気象庁防災XML] 流量調査
流量について話題になっていたのでちょっと調べてみた。
- 日通数は最小６００、最大１０００
- 日電文量は最小１０ＭＢ，最大２０ＭＢ
- 流量の多い日には通数に比例よりはやや多くなる（つまり荒天時の電文は通常より長い傾向があることを含意する）
2013-01-11
被積分関数をかえてみる
簡単な例なので被積分関数をいじってみる。dy/dx = f(x, y) = 2x というのは y に依存しないので簡単すぎたのだ。ならば、 f(x,y) = x + sqrt(y) とやっても解析的には同じことである
が、 y がずれると積分結果がずれていってしまうという意味でよい感じになる。
次の結果で上が４次ルンゲクッタ、下が前進差分。もちろんバイアスがないルンゲクッタで定数倍改善していることも注目に値するが、ステップを 1/10 にしたときに１桁以上精度が改善しているこ
とに注目される。
0.3000000000000000 0.9717281348583426 -0.0282718651416574
0.1000000000000000 0.9945397310971597 -0.0054602689028403
0.0300000000000000 0.9991023660366382 -0.0008976339633618
0.0100000000000000 0.9998272390531332 -0.0001727609468668
0.0030000000000000 0.9999716121300442 -0.0000283878699558
0.0010000000000000 0.9999945367413657 -0.0000054632586343
0.0003000000000000 0.9999991022947341 -0.0000008977052659
0.0001000000000000 0.9999998272366565 -0.0000001727633435
0.0000300000000000 0.9999999716130413 -0.0000000283869587
0.0000100000000000 0.9999999945402596 -0.0000000054597404
0.0000030000000000 0.9999999991117637 -0.0000000008882363
0.0000010000000000 0.9999999998104413 -0.0000000001895587
0.0000003000000000 1.0000000000950195 0.0000000000950195
0.0000001000000000 1.0000000004349120 0.0000000004349121
0.0000000300000000 0.9999999989783790 -0.0000000010216210
0.0000000100000000 0.9999999959029633 -0.0000000040970367
0.3000000000000000 0.5100000000000001 -0.4899999999999999
0.1000000000000000 0.8100000000000004 -0.1899999999999996
0.0300000000000000 0.9410999999999989 -0.0589000000000011
0.0100000000000000 0.9800999999999989 -0.0199000000000011
0.0030000000000000 0.9940109999999988 -0.0059890000000012
0.0010000000000000 0.9980009999999985 -0.0019990000000015
0.0003000000000000 0.9994001100000743 -0.0005998899999257
0.0001000000000000 0.9998000100001390 -0.0001999899998610
0.0000300000000000 0.9999400011009805 -0.0000599988990195
0.0000100000000000 0.9999800001035221 -0.0000199998964779
0.0000030000000000 0.9999940000204693 -0.0000059999795307
0.0000010000000000 0.9999979999842054 -0.0000020000157946
0.0000003000000000 0.9999994001235168 -0.0000005998764832
0.0000001000000000 0.9999998004403844 -0.0000001995596156
0.0000000300000000 0.9999999389792776 -0.0000000610207224
0.0000000100000000 0.9999999759031382 -0.0000000240968618
import java.text.DecimalFormat;
public strictfp class Z {
static double gradient(double x, double y) {
return x + Math.sqrt(y);
}
public static double rk4(double xmin, double xmax, double ymin,
double step) {
double dx = step;
double xstop = xmax - dx;
double inv6 = 1.0/6.0;
double k1, k2, k3, k4;
double x = xmin;
double y = ymin;
boolean continuep = true;
while (continuep) {
if (x > xstop) {
dx = xmax - x;
continuep = false;
}
k1 = gradient(x, y);
k2 = gradient(x + 0.5 * dx, y + 0.5 * dx * k1);
k3 = gradient(x + 0.5 * dx, y + 0.5 * dx * k2);
k4 = gradient(x + dx, y + dx * k3);
y += dx * (k1 + 2.0 * (k2 + k3) + k4) * inv6;
x += dx;
}
return y;
}
public static double euler(double xmin, double xmax, double ymin,
double step) {
double dx = step;
double xstop = xmax - dx;
double dydx;
double x = xmin;
double y = ymin;
boolean continuep = true;
while (continuep) {
if (x > xstop) {
dx = xmax - x;
continuep = false;
}
dydx = gradient(x, y);
y += dydx * dx;
x += dx;
}
return y;
}
public static void main(String[] args) {
DecimalFormat df = new DecimalFormat(" 0.0;-0.0");
df.setMinimumIntegerDigits(1);
df.setMaximumIntegerDigits(1);
df.setMinimumFractionDigits(16);
df.setMaximumFractionDigits(16);
double dxs[] = {3.0e-1, 1.0e-1, 3.0e-2, 1.0e-2, 3.0e-3, 1.0e-3, 3.0e-4,
1.0e-4, 3.0e-5, 1.0e-5, 3.0e-6, 1.0e-6, 3.0e-7,
1.0e-7, 3.0e-8, 1.0e-8};
double xmin = 0.0;
double xmax = 1.0;
double ymin = 0.0;
for (double step: dxs) {
double y = rk4(xmin, xmax, ymin, step);
System.out.println(
df.format(step)
+ " " + df.format(y)
+ " " + df.format(y - (xmax * xmax - xmin * xmin))
);
}
System.out.println("");
for (double step: dxs) {
double y = euler(xmin, xmax, ymin, step);
System.out.println(
df.format(step)
+ " " + df.format(y)
+ " " + df.format(y - (xmax * xmax - xmin * xmin))
);
}
}
}
が、 y がずれると積分結果がずれていってしまうという意味でよい感じになる。
次の結果で上が４次ルンゲクッタ、下が前進差分。もちろんバイアスがないルンゲクッタで定数倍改善していることも注目に値するが、ステップを 1/10 にしたときに１桁以上精度が改善しているこ
とに注目される。
0.3000000000000000 0.9717281348583426 -0.0282718651416574
0.1000000000000000 0.9945397310971597 -0.0054602689028403
0.0300000000000000 0.9991023660366382 -0.0008976339633618
0.0100000000000000 0.9998272390531332 -0.0001727609468668
0.0030000000000000 0.9999716121300442 -0.0000283878699558
0.0010000000000000 0.9999945367413657 -0.0000054632586343
0.0003000000000000 0.9999991022947341 -0.0000008977052659
0.0001000000000000 0.9999998272366565 -0.0000001727633435
0.0000300000000000 0.9999999716130413 -0.0000000283869587
0.0000100000000000 0.9999999945402596 -0.0000000054597404
0.0000030000000000 0.9999999991117637 -0.0000000008882363
0.0000010000000000 0.9999999998104413 -0.0000000001895587
0.0000003000000000 1.0000000000950195 0.0000000000950195
0.0000001000000000 1.0000000004349120 0.0000000004349121
0.0000000300000000 0.9999999989783790 -0.0000000010216210
0.0000000100000000 0.9999999959029633 -0.0000000040970367
0.3000000000000000 0.5100000000000001 -0.4899999999999999
0.1000000000000000 0.8100000000000004 -0.1899999999999996
0.0300000000000000 0.9410999999999989 -0.0589000000000011
0.0100000000000000 0.9800999999999989 -0.0199000000000011
0.0030000000000000 0.9940109999999988 -0.0059890000000012
0.0010000000000000 0.9980009999999985 -0.0019990000000015
0.0003000000000000 0.9994001100000743 -0.0005998899999257
0.0001000000000000 0.9998000100001390 -0.0001999899998610
0.0000300000000000 0.9999400011009805 -0.0000599988990195
0.0000100000000000 0.9999800001035221 -0.0000199998964779
0.0000030000000000 0.9999940000204693 -0.0000059999795307
0.0000010000000000 0.9999979999842054 -0.0000020000157946
0.0000003000000000 0.9999994001235168 -0.0000005998764832
0.0000001000000000 0.9999998004403844 -0.0000001995596156
0.0000000300000000 0.9999999389792776 -0.0000000610207224
0.0000000100000000 0.9999999759031382 -0.0000000240968618
import java.text.DecimalFormat;
public strictfp class Z {
static double gradient(double x, double y) {
return x + Math.sqrt(y);
}
public static double rk4(double xmin, double xmax, double ymin,
double step) {
double dx = step;
double xstop = xmax - dx;
double inv6 = 1.0/6.0;
double k1, k2, k3, k4;
double x = xmin;
double y = ymin;
boolean continuep = true;
while (continuep) {
if (x > xstop) {
dx = xmax - x;
continuep = false;
}
k1 = gradient(x, y);
k2 = gradient(x + 0.5 * dx, y + 0.5 * dx * k1);
k3 = gradient(x + 0.5 * dx, y + 0.5 * dx * k2);
k4 = gradient(x + dx, y + dx * k3);
y += dx * (k1 + 2.0 * (k2 + k3) + k4) * inv6;
x += dx;
}
return y;
}
public static double euler(double xmin, double xmax, double ymin,
double step) {
double dx = step;
double xstop = xmax - dx;
double dydx;
double x = xmin;
double y = ymin;
boolean continuep = true;
while (continuep) {
if (x > xstop) {
dx = xmax - x;
continuep = false;
}
dydx = gradient(x, y);
y += dydx * dx;
x += dx;
}
return y;
}
public static void main(String[] args) {
DecimalFormat df = new DecimalFormat(" 0.0;-0.0");
df.setMinimumIntegerDigits(1);
df.setMaximumIntegerDigits(1);
df.setMinimumFractionDigits(16);
df.setMaximumFractionDigits(16);
double dxs[] = {3.0e-1, 1.0e-1, 3.0e-2, 1.0e-2, 3.0e-3, 1.0e-3, 3.0e-4,
1.0e-4, 3.0e-5, 1.0e-5, 3.0e-6, 1.0e-6, 3.0e-7,
1.0e-7, 3.0e-8, 1.0e-8};
double xmin = 0.0;
double xmax = 1.0;
double ymin = 0.0;
for (double step: dxs) {
double y = rk4(xmin, xmax, ymin, step);
System.out.println(
df.format(step)
+ " " + df.format(y)
+ " " + df.format(y - (xmax * xmax - xmin * xmin))
);
}
System.out.println("");
for (double step: dxs) {
double y = euler(xmin, xmax, ymin, step);
System.out.println(
df.format(step)
+ " " + df.format(y)
+ " " + df.format(y - (xmax * xmax - xmin * xmin))
);
}
}
}
4次ルンゲクッタの威力（？）
さて、4次ルンゲクッタにしたところ、困ったことに誤差がなくなってしまった。
前進差分と違って、バイアスがないし、高次なものだから２次関数のシミュレートなんて厳密にできてしまう。刻みが 0.3 ですら解析解と全ビット同じ値をたたき出すのである。結果
として、ステップが小さくなるにつれて大きくなる情報落ちだけが誤差となる。
教材としては適当ではないが、情報落ちの可視化としては適当なのでメモしておく。
結果
ステップ 積分結果 誤差（対解析解）
0.3000000000000000 1.0000000000000000 0.0000000000000000
0.1000000000000000 1.0000000000000002 0.0000000000000002
0.0300000000000000 0.9999999999999991 -0.0000000000000009
0.0100000000000000 0.9999999999999990 -0.0000000000000010
0.0030000000000000 0.9999999999999990 -0.0000000000000010
0.0010000000000000 0.9999999999999988 -0.0000000000000012
0.0003000000000000 1.0000000000000695 0.0000000000000695
0.0001000000000000 1.0000000000001080 0.0000000000001079
0.0000300000000000 1.0000000000007920 0.0000000000007920
0.0000100000000000 1.0000000000031826 0.0000000000031826
0.0000030000000000 1.0000000000076747 0.0000000000076747
0.0000010000000000 0.9999999999833878 -0.0000000000166122
0.0000003000000000 1.0000000001106562 0.0000000001106562
0.0000001000000000 1.0000000003876117 0.0000000003876117
0.0000000300000000 0.9999999990878823 -0.0000000009121177
0.0000000100000000 0.9999999963603514 -0.0000000036396486
コード
import java.text.DecimalFormat;
public strictfp class Z {
static double gradient(double x, double y) {
return x * 2.0;
}
public static void main(String[] args) {
DecimalFormat df = new DecimalFormat(" 0.0;-0.0");
df.setMinimumIntegerDigits(1);
df.setMaximumIntegerDigits(1);
df.setMinimumFractionDigits(16);
df.setMaximumFractionDigits(16);
double dxs[] = {3.0e-1, 1.0e-1, 3.0e-2, 1.0e-2, 3.0e-3, 1.0e-3, 3.0e-4,
1.0e-4, 3.0e-5, 1.0e-5, 3.0e-6, 1.0e-6, 3.0e-7,
1.0e-7, 3.0e-8, 1.0e-8};
double xmin = 0.0;
double xmax = 1.0;
double ymin = 0.0;
int midlimit = 1;
for (double step: dxs) {
double dx = step;
double xstop = xmax - dx;
double x, y, k1, k2, k3, k4;
double inv6 = 1.0/6.0;
boolean continuep;
for (x = xmin, y = ymin, continuep = true; continuep; ) {
if (x > xstop) {
dx = xmax - x;
continuep = false;
}
k1 = gradient(x, y);
k2 = gradient(x + 0.5 * dx, y + 0.5 * dx * k1);
k3 = gradient(x + 0.5 * dx, y + 0.5 * dx * k2);
k4 = gradient(x + dx, y + dx * k3);
y += dx * (k1 + 2.0 * (k2 + k3) + k4) * inv6;
x += dx;
}
System.out.println(
df.format(step)
+ " " + df.format(y)
+ " " + df.format(y - (xmax * xmax - xmin * xmin))
);
}
}
}
前進差分と違って、バイアスがないし、高次なものだから２次関数のシミュレートなんて厳密にできてしまう。刻みが 0.3 ですら解析解と全ビット同じ値をたたき出すのである。結果
として、ステップが小さくなるにつれて大きくなる情報落ちだけが誤差となる。
教材としては適当ではないが、情報落ちの可視化としては適当なのでメモしておく。
結果
ステップ 積分結果 誤差（対解析解）
0.3000000000000000 1.0000000000000000 0.0000000000000000
0.1000000000000000 1.0000000000000002 0.0000000000000002
0.0300000000000000 0.9999999999999991 -0.0000000000000009
0.0100000000000000 0.9999999999999990 -0.0000000000000010
0.0030000000000000 0.9999999999999990 -0.0000000000000010
0.0010000000000000 0.9999999999999988 -0.0000000000000012
0.0003000000000000 1.0000000000000695 0.0000000000000695
0.0001000000000000 1.0000000000001080 0.0000000000001079
0.0000300000000000 1.0000000000007920 0.0000000000007920
0.0000100000000000 1.0000000000031826 0.0000000000031826
0.0000030000000000 1.0000000000076747 0.0000000000076747
0.0000010000000000 0.9999999999833878 -0.0000000000166122
0.0000003000000000 1.0000000001106562 0.0000000001106562
0.0000001000000000 1.0000000003876117 0.0000000003876117
0.0000000300000000 0.9999999990878823 -0.0000000009121177
0.0000000100000000 0.9999999963603514 -0.0000000036396486
コード
import java.text.DecimalFormat;
public strictfp class Z {
static double gradient(double x, double y) {
return x * 2.0;
}
public static void main(String[] args) {
DecimalFormat df = new DecimalFormat(" 0.0;-0.0");
df.setMinimumIntegerDigits(1);
df.setMaximumIntegerDigits(1);
df.setMinimumFractionDigits(16);
df.setMaximumFractionDigits(16);
double dxs[] = {3.0e-1, 1.0e-1, 3.0e-2, 1.0e-2, 3.0e-3, 1.0e-3, 3.0e-4,
1.0e-4, 3.0e-5, 1.0e-5, 3.0e-6, 1.0e-6, 3.0e-7,
1.0e-7, 3.0e-8, 1.0e-8};
double xmin = 0.0;
double xmax = 1.0;
double ymin = 0.0;
int midlimit = 1;
for (double step: dxs) {
double dx = step;
double xstop = xmax - dx;
double x, y, k1, k2, k3, k4;
double inv6 = 1.0/6.0;
boolean continuep;
for (x = xmin, y = ymin, continuep = true; continuep; ) {
if (x > xstop) {
dx = xmax - x;
continuep = false;
}
k1 = gradient(x, y);
k2 = gradient(x + 0.5 * dx, y + 0.5 * dx * k1);
k3 = gradient(x + 0.5 * dx, y + 0.5 * dx * k2);
k4 = gradient(x + dx, y + dx * k3);
y += dx * (k1 + 2.0 * (k2 + k3) + k4) * inv6;
x += dx;
}
System.out.println(
df.format(step)
+ " " + df.format(y)
+ " " + df.format(y - (xmax * xmax - xmin * xmin))
);
}
}
}
中間加算バッファによる情報落ち（ごめん桁落ちとは言わなかった）の軽減
さて、差分スキーム自体の話にいく前に、さっきの精度打ち止めの理由が情報落ちであることを確認しておく。
（用語訂正：さっきは桁落ちといったがふつうの用語ではなかった）。
情報落ちとは、指数部が大きく異なる浮動小数点数を加減算すると、増分の精度が数形式の精度より大きく劣ることである。
桁落ちとは、絶対値がほとんど同じで、なおかつ符号の反対な浮動小数点数を加算（符号が同じ数を減算といっても同じこと）すると、結果の相対精度が大きく劣ることで、ちょっと違う。
ステップが非常に小さい積分は、この情報落ちにぴったり当てはまる。
回避法は簡単で、積算時に中間積算を行って、あるていどまとまったところで積算変数への足しこみを行えばよい。次の例では1024回づつ中間積算することによって、ステップが 1e-9 でも精度打ち止めにならないよう
になった。（おそらくは精度を3桁改善できるだろうが、ものすごく時間がかかるので確認しない）
0.0001000000000000 0.9998999999999811 -0.0001000000000189
0.0000300000000000 0.9999700002000160 -0.0000299997999840
0.0000100000000000 0.9999900000000238 -0.0000099999999762
0.0000030000000000 0.9999970000020161 -0.0000029999979839
0.0000010000000000 0.9999989999999600 -0.0000010000000400
0.0000003000000000 0.9999996999999685 -0.0000003000000315
0.0000001000000000 0.9999998999999479 -0.0000001000000521
0.0000000300000000 0.9999999700006352 -0.0000000299993648
0.0000000100000000 0.9999999900010098 -0.0000000099989902
0.0000000030000000 0.9999999970078517 -0.0000000029921483
0.0000000010000000 0.9999999990116513 -0.0000000009883487
import java.text.DecimalFormat;
public strictfp class Z {
public static void main(String[] args) {
DecimalFormat df = new DecimalFormat(" 0.0;-0.0");
df.setMinimumIntegerDigits(1);
df.setMaximumIntegerDigits(1);
df.setMinimumFractionDigits(16);
df.setMaximumFractionDigits(16);
double dxs[] = {1.0e-4, 3.0e-5, 1.0e-5, 3.0e-6, 1.0e-6, 3.0e-7,
1.0e-7, 3.0e-8, 1.0e-8, 3.0e-9, 1.0e-9};
double xmin = 0.0;
double xmax = 1.0;
double ymin = 0.0;
int midlimit = 1024;
for (double step: dxs) {
double dx = step;
double xstop = xmax - dx;
double x, y, xmid, ymid, dydx;
boolean continuep;
int count;
for (x = xmin, y = ymin, xmid = 0.0, ymid = 0.0, continuep = true,
count = 0; continuep; ) {
dydx = (x + xmid) * 2.0;
if (x + xmid > xstop) {
dx = xmax - (x + xmid);
count = midlimit;
continuep = false;
}
ymid += dx * dydx;
xmid += dx;
if (++count > midlimit) {
x += xmid;
y += ymid;
xmid = ymid = 0.0;
count = 0;
}
}
System.out.println(
df.format(step)
+ " " + df.format(y)
+ " " + df.format(y - (xmax * xmax - xmin * xmin))
);
}
}
}
（用語訂正：さっきは桁落ちといったがふつうの用語ではなかった）。
情報落ちとは、指数部が大きく異なる浮動小数点数を加減算すると、増分の精度が数形式の精度より大きく劣ることである。
桁落ちとは、絶対値がほとんど同じで、なおかつ符号の反対な浮動小数点数を加算（符号が同じ数を減算といっても同じこと）すると、結果の相対精度が大きく劣ることで、ちょっと違う。
ステップが非常に小さい積分は、この情報落ちにぴったり当てはまる。
回避法は簡単で、積算時に中間積算を行って、あるていどまとまったところで積算変数への足しこみを行えばよい。次の例では1024回づつ中間積算することによって、ステップが 1e-9 でも精度打ち止めにならないよう
になった。（おそらくは精度を3桁改善できるだろうが、ものすごく時間がかかるので確認しない）
0.0001000000000000 0.9998999999999811 -0.0001000000000189
0.0000300000000000 0.9999700002000160 -0.0000299997999840
0.0000100000000000 0.9999900000000238 -0.0000099999999762
0.0000030000000000 0.9999970000020161 -0.0000029999979839
0.0000010000000000 0.9999989999999600 -0.0000010000000400
0.0000003000000000 0.9999996999999685 -0.0000003000000315
0.0000001000000000 0.9999998999999479 -0.0000001000000521
0.0000000300000000 0.9999999700006352 -0.0000000299993648
0.0000000100000000 0.9999999900010098 -0.0000000099989902
0.0000000030000000 0.9999999970078517 -0.0000000029921483
0.0000000010000000 0.9999999990116513 -0.0000000009883487
import java.text.DecimalFormat;
public strictfp class Z {
public static void main(String[] args) {
DecimalFormat df = new DecimalFormat(" 0.0;-0.0");
df.setMinimumIntegerDigits(1);
df.setMaximumIntegerDigits(1);
df.setMinimumFractionDigits(16);
df.setMaximumFractionDigits(16);
double dxs[] = {1.0e-4, 3.0e-5, 1.0e-5, 3.0e-6, 1.0e-6, 3.0e-7,
1.0e-7, 3.0e-8, 1.0e-8, 3.0e-9, 1.0e-9};
double xmin = 0.0;
double xmax = 1.0;
double ymin = 0.0;
int midlimit = 1024;
for (double step: dxs) {
double dx = step;
double xstop = xmax - dx;
double x, y, xmid, ymid, dydx;
boolean continuep;
int count;
for (x = xmin, y = ymin, xmid = 0.0, ymid = 0.0, continuep = true,
count = 0; continuep; ) {
dydx = (x + xmid) * 2.0;
if (x + xmid > xstop) {
dx = xmax - (x + xmid);
count = midlimit;
continuep = false;
}
ymid += dx * dydx;
xmid += dx;
if (++count > midlimit) {
x += xmid;
y += ymid;
xmid = ymid = 0.0;
count = 0;
}
}
System.out.println(
df.format(step)
+ " " + df.format(y)
+ " " + df.format(y - (xmax * xmax - xmin * xmin))
);
}
}
}
差分スキームの誤差と情報落ち [件名訂正]
差分スキームの誤差は O(Δx) のようにステップの冪であらわされる。つまり、アルゴリズムをなにも改良しなくても、ステップを小さくすれば誤差を小さくできる。しかしそれは無限精度の実数で計算ができる場合で、現実の浮動小数点演算においては別種の誤差もあるので無限高精度の積分を達成することはできない。ステップが小さいのに漫然と加算をしていれば桁落ち[訂正：情報落ち]がまず思いつく脅威である。
あまりいい例ではないかもしれないが、わかりやすいので、前進差分で dy/dx = 2x
を x: [0, 1] で積分してみた。もちろん解析解は ｙ = x^2 で答は 1 である。
出力をみると、ステップ 1e-8 程度で精度は頭打ちになっている。
import java.text.DecimalFormat;
public strictfp class Z {
public static void main(String[] args) {
DecimalFormat df = new DecimalFormat(" 0.0;-0.0");
df.setMinimumIntegerDigits(1);
df.setMaximumIntegerDigits(1);
df.setMinimumFractionDigits(16);
df.setMaximumFractionDigits(16);
double dxs[] = {1.0e-4, 3.0e-5, 1.0e-5, 3.0e-6, 1.0e-6, 3.0e-7,
1.0e-7, 3.0e-8, 1.0e-8, 3.0e-9, 1.0e-9};
double xmin = 0.0;
double xmax = 1.0;
double ymin = 0.0;
double x, y, dydx;
boolean continuep;
for (double step: dxs) {
double dx = step;
double xstop = xmax - dx;
for (x = xmin, y = ymin, continuep = true; continuep; x += dx) {
dydx = x * 2.0;
if (x > xstop) {
dx = xmax - x;
continuep = false;
}
y += dx * dydx;
}
System.out.println(
df.format(step)
+ " " + df.format(y)
+ " " + df.format(y - (xmax * xmax - xmin * xmin))
);
}
}
}
/* output
0.0001000000000000 0.9999000000001081 -0.0000999999998919
0.0000300000000000 0.9999700002007929 -0.0000299997992071
0.0000100000000000 0.9999900000031827 -0.0000099999968173
0.0000030000000000 0.9999970000096747 -0.0000029999903253
0.0000010000000000 0.9999989999833878 -0.0000010000166122
0.0000003000000000 0.9999997001106760 -0.0000002998893240
0.0000001000000000 0.9999999003876101 -0.0000000996123899
0.0000000300000000 0.9999999690878816 -0.0000000309121184
0.0000000100000000 0.9999999863603514 -0.0000000136396486
0.0000000030000000 0.9999999888525976 -0.0000000111474024
0.0000000010000000 1.0000000151388213 0.0000000151388213
*/
あまりいい例ではないかもしれないが、わかりやすいので、前進差分で dy/dx = 2x
を x: [0, 1] で積分してみた。もちろん解析解は ｙ = x^2 で答は 1 である。
出力をみると、ステップ 1e-8 程度で精度は頭打ちになっている。
import java.text.DecimalFormat;
public strictfp class Z {
public static void main(String[] args) {
DecimalFormat df = new DecimalFormat(" 0.0;-0.0");
df.setMinimumIntegerDigits(1);
df.setMaximumIntegerDigits(1);
df.setMinimumFractionDigits(16);
df.setMaximumFractionDigits(16);
double dxs[] = {1.0e-4, 3.0e-5, 1.0e-5, 3.0e-6, 1.0e-6, 3.0e-7,
1.0e-7, 3.0e-8, 1.0e-8, 3.0e-9, 1.0e-9};
double xmin = 0.0;
double xmax = 1.0;
double ymin = 0.0;
double x, y, dydx;
boolean continuep;
for (double step: dxs) {
double dx = step;
double xstop = xmax - dx;
for (x = xmin, y = ymin, continuep = true; continuep; x += dx) {
dydx = x * 2.0;
if (x > xstop) {
dx = xmax - x;
continuep = false;
}
y += dx * dydx;
}
System.out.println(
df.format(step)
+ " " + df.format(y)
+ " " + df.format(y - (xmax * xmax - xmin * xmin))
);
}
}
}
/* output
0.0001000000000000 0.9999000000001081 -0.0000999999998919
0.0000300000000000 0.9999700002007929 -0.0000299997992071
0.0000100000000000 0.9999900000031827 -0.0000099999968173
0.0000030000000000 0.9999970000096747 -0.0000029999903253
0.0000010000000000 0.9999989999833878 -0.0000010000166122
0.0000003000000000 0.9999997001106760 -0.0000002998893240
0.0000001000000000 0.9999999003876101 -0.0000000996123899
0.0000000300000000 0.9999999690878816 -0.0000000309121184
0.0000000100000000 0.9999999863603514 -0.0000000136396486
0.0000000030000000 0.9999999888525976 -0.0000000111474024
0.0000000010000000 1.0000000151388213 0.0000000151388213
*/
2013-01-08
[気象庁防災XML] Title と InfoKind の関係
辞書やフォーマットの解説（ http://xml.kishou.go.jp/tec_material.html で得られる）を読む限り、データ型のサブクラスに相当する物は jmx_ib:InfoKind タグで指示されるようである。しか
し、全内容出力スタイルシートのカタログ（
http://xml.kishou.go.jp/jmaxml_20120615_Verification_StyleSheet_list.pdf ）では
InfoKind を用いずに jmx:Title で振り分けている。どういうことか、ここ２週間ほど入電した電文をデコードして得た (InfoKind, Title) 関係とつきあわせてみた：
・ある Title では同一 InfoKind しか出てこない。
・ある InfoKind は複数の Title で使われうる。
・同一 InfoKind であっても、Title によって異なる XSL を割り当てられている例がある。
・つまり、振り分けは jmx:Title によらざるを得ない。
InfoKind の使い道がわからないが、まあ整理学上のものというべきだろう。なぜこうなったかというと、XSLはデータ型というより所管課によく対応して作られていることはちょっと対象を知っている人ならばお見通しであろう。人だよ人。
InfoKind Title XSL
全般海上警報 全般海上警報（臨時） 120329_umikeiho1.xsl
全般海上警報 全般海上警報（定時） 120329_umikeiho1.xsl
台風解析・予報情報（３日予報） 台風解析・予報情報（３日予報）
120329_kfxc80.xsl
台風解析・予報情報（５日予報） 台風解析・予報情報（５日予報）
120329_kfxc80.xsl
同一現象用平文情報 府県気象情報 120329_ippanho.xsl
同一現象用平文情報 全般台風情報（定型） 120329_ippanho.xsl
同一現象用平文情報 地方気象情報 120329_ippanho.xsl
同一現象用平文情報 地方潮位情報 120329_choui1.xsl
同一現象用平文情報 全般気象情報 120329_ippanho.xsl
同一現象用平文情報 府県潮位情報 120329_choui1.xsl
同一現象用平文情報 全般潮位情報 120329_choui1.xsl
噴火に関する火山観測報 噴火に関する火山観測報 120615_kazan.xsl
地方海上予報 地方海上予報 120329_chihoumiyoho.xsl
地方海上警報 地方海上警報 120329_chihoumikeiho.xsl
地震情報 震源・震度に関する情報
120615_jishin_tsunami_tokai_decode_all.xsl
天候情報 全般天候情報 120329_TenkoJohoHtmlPlain.xsl
天候情報 府県天候情報 120329_TenkoJohoHtmlPlain.xsl
天候情報 地方天候情報 120329_TenkoJohoHtmlPlain.xsl
季節予報 全般１か月予報 120329_KisetuYohoHtmlPlain.xsl
季節予報 地方３か月予報 120329_KisetuYohoHtmlPlain.xsl
季節予報 全般３か月予報 120329_KisetuYohoHtmlPlain.xsl
季節予報 地方１か月予報 120329_KisetuYohoHtmlPlain.xsl
平文情報 府県天気概況 120329_ippanho.xsl
平文情報 全般週間天気予報 120329_ippanho.xsl
平文情報 地方週間天気予報 120329_ippanho.xsl
府県天気予報 府県天気予報 120329_ippanho.xsl
府県週間天気予報 府県週間天気予報 120329_shukan.xsl
東海地震関連情報 東海地震観測情報
120615_jishin_tsunami_tokai_decode_all.xsl
気象警報・注意報 気象警報・注意報 120329_kei_all_line_div.xsl
火山の状況に関する解説情報 火山の状況に関する解説情報
120615_kazan.xsl
特殊気象報 特殊気象報 120329_tokusyu.xsl
特殊気象報 季節観測 120329_tokusyu.xsl
環境気象情報 紫外線観測データ 120329_tokusyu.xsl
生物季節観測報告気象報 生物季節観測 120329_Sbt.xsl
異常天候早期警戒情報 異常天候早期警戒情報 120329_SoukeiHtmlPlain.xsl
竜巻注意情報 竜巻注意情報 120329_tatsumaki.xsl
震度速報 震度速報 120615_jishin_tsunami_tokai_decode_all.xsl
震源速報 震源に関する情報
120615_jishin_tsunami_tokai_decode_all.xsl
し、全内容出力スタイルシートのカタログ（
http://xml.kishou.go.jp/jmaxml_20120615_Verification_StyleSheet_list.pdf ）では
InfoKind を用いずに jmx:Title で振り分けている。どういうことか、ここ２週間ほど入電した電文をデコードして得た (InfoKind, Title) 関係とつきあわせてみた：
・ある Title では同一 InfoKind しか出てこない。
・ある InfoKind は複数の Title で使われうる。
・同一 InfoKind であっても、Title によって異なる XSL を割り当てられている例がある。
・つまり、振り分けは jmx:Title によらざるを得ない。
InfoKind の使い道がわからないが、まあ整理学上のものというべきだろう。なぜこうなったかというと、XSLはデータ型というより所管課によく対応して作られていることはちょっと対象を知っている人ならばお見通しであろう。人だよ人。
InfoKind Title XSL
全般海上警報 全般海上警報（臨時） 120329_umikeiho1.xsl
全般海上警報 全般海上警報（定時） 120329_umikeiho1.xsl
台風解析・予報情報（３日予報） 台風解析・予報情報（３日予報）
120329_kfxc80.xsl
台風解析・予報情報（５日予報） 台風解析・予報情報（５日予報）
120329_kfxc80.xsl
同一現象用平文情報 府県気象情報 120329_ippanho.xsl
同一現象用平文情報 全般台風情報（定型） 120329_ippanho.xsl
同一現象用平文情報 地方気象情報 120329_ippanho.xsl
同一現象用平文情報 地方潮位情報 120329_choui1.xsl
同一現象用平文情報 全般気象情報 120329_ippanho.xsl
同一現象用平文情報 府県潮位情報 120329_choui1.xsl
同一現象用平文情報 全般潮位情報 120329_choui1.xsl
噴火に関する火山観測報 噴火に関する火山観測報 120615_kazan.xsl
地方海上予報 地方海上予報 120329_chihoumiyoho.xsl
地方海上警報 地方海上警報 120329_chihoumikeiho.xsl
地震情報 震源・震度に関する情報
120615_jishin_tsunami_tokai_decode_all.xsl
天候情報 全般天候情報 120329_TenkoJohoHtmlPlain.xsl
天候情報 府県天候情報 120329_TenkoJohoHtmlPlain.xsl
天候情報 地方天候情報 120329_TenkoJohoHtmlPlain.xsl
季節予報 全般１か月予報 120329_KisetuYohoHtmlPlain.xsl
季節予報 地方３か月予報 120329_KisetuYohoHtmlPlain.xsl
季節予報 全般３か月予報 120329_KisetuYohoHtmlPlain.xsl
季節予報 地方１か月予報 120329_KisetuYohoHtmlPlain.xsl
平文情報 府県天気概況 120329_ippanho.xsl
平文情報 全般週間天気予報 120329_ippanho.xsl
平文情報 地方週間天気予報 120329_ippanho.xsl
府県天気予報 府県天気予報 120329_ippanho.xsl
府県週間天気予報 府県週間天気予報 120329_shukan.xsl
東海地震関連情報 東海地震観測情報
120615_jishin_tsunami_tokai_decode_all.xsl
気象警報・注意報 気象警報・注意報 120329_kei_all_line_div.xsl
火山の状況に関する解説情報 火山の状況に関する解説情報
120615_kazan.xsl
特殊気象報 特殊気象報 120329_tokusyu.xsl
特殊気象報 季節観測 120329_tokusyu.xsl
環境気象情報 紫外線観測データ 120329_tokusyu.xsl
生物季節観測報告気象報 生物季節観測 120329_Sbt.xsl
異常天候早期警戒情報 異常天候早期警戒情報 120329_SoukeiHtmlPlain.xsl
竜巻注意情報 竜巻注意情報 120329_tatsumaki.xsl
震度速報 震度速報 120615_jishin_tsunami_tokai_decode_all.xsl
震源速報 震源に関する情報
120615_jishin_tsunami_tokai_decode_all.xsl
登録:
投稿 (Atom)