LFM GPV

振興協議会HP http://www.w-shinkou.org/ にありますように、7日づけでお知らせ「局地予報モデルGPV の提供開始時期について(配信資料に関する技術情報(気象編)第 388 号関連)」が発行されています。
要するに3月27日00Zという文字が書いてあります。配信のお申し込みは支援センターにお願いいたします。

DQ_DataQuality.report に許される下部構造

いまごろになって恐縮ですが SchemaCentral.com を読んでいたら DQ_DataQuality.report の下部構造は時空間・属性などの定性・定量いろいろの表現が選べるのですね。

http://www.schemacentral.com/sc/niem21/e-gmd_report-1.html

INSPIRE プロファイルにあるので DomainConsistency しかないのかと思い込んでいました。

まあ、しかし、選べるとはいっても、その内部構造は同一なんですよね。なんだかなあ。

http://www.schemacentral.com/sc/niem21/e-gmd_DQ_DomainConsistency.html
http://www.schemacentral.com/sc/niem21/e-gmd_DQ_QuantitativeAttributeAccuracy.html

大木、吉田（2008） 海上気象データの長期保管フォーマット

測候時報第７５巻特別号 pp. S139-S156.
http://www.jma.go.jp/jma//kishou/books/sokkou-kaiyou/75/vol75s139.pdf

探し物をしていて偶然みつけた。

SHIP通報式そのものではなく、それを受けて編纂する資料（どんな業務なんだか知らない）の形式。CMM/JCOMMの過去の決議にさかのぼって調査した結果は貴重。

XML埋込の伝送では低水準の同一性が保証されなくなることとPubSubHubbubで全文フィードじゃなくてコールバックさせること

コールバックにもいいこともあるんだな、と気がついたので、メモ。

SRU、OAI-PMHなど、伝送すべきXML文書をサブツリーとして含み、まわりにメタデータが張り付いたようなものをHTTPレスポンスにするようなプロトコルはしばしばある。PubSubHubbubはAtomエントリをHTTP POSTするんだけど、全文フィードから抜いたエントリをPOSTしてその埋め込みデータを利用させることもできるし、要約フィードでURLだけ伝えてコールバックさせることもできる。

コールバックなんか無駄じゃんか、というとさにあらず。という屁理屈を考えてみた、ということになる。

パーザの文書ツリーに伝送すべきXML文書の読み込み結果を（次々）張り付けて、またシリアライズすると、属性まわりのスペースだとか、改行コードだとか、文字実体参照だとかは必ずしも元の文書のとおりに再現されるわけではない。ひどい場合には名前空間宣言がぐちゃぐちゃになったりする。もちろん、利用者がみなお行儀よろしくXMLインフォセットだけを見てくれればいいのだが、DOM APIで名前空間を無視してパーズしたり、ひどい場合には sed でタグを抜き出したりすると、そういう低水準の非保存性で災厄が起こる。決してやれとは言っていないがそういうことはあるし自分もやっつけ仕事でやったりする。

だから、信頼できるのは、オクテット列を忠実に伝送することしかないのだ、となることはある。なんたる荒廃といわれればその通りだが、まあ、そういうこともある。

I feel I need to write English version also, but the priority of the time is not here right now, sorry.

セルビア語の硬音 n は歯音（だから日本語の歯茎音 n が軟音に聞こえるん）じゃないのか

セルビア語の n の発音が難しいという話。
https://twitter.com/adonis_fish/status/436356744445296640

n のときに舌が上がらないように気をつけて低い母音を続けても、やっぱり軟音に聞こえちゃうというんだろうから、調音点がずれてるんじゃないのか。

と思ってウィキペをみると、残念ながら n 硬音は歯茎音（つまり日本語と同じ）とある。
http://en.wikipedia.org/wiki/Serbo-Croatian_phonology#Consonants
t は歯音で n と調音点がずれちゃってるが、スペイン語の例もあるから、それだけであり得ないわけでもない。

でも、本当かな。

南スラブ語の仲間、ブルガリア語では n が歯音らしい。
http://en.wikipedia.org/wiki/Bulgarian_phonology#Consonants

そして、遠くなるけどロシア語では、n の硬軟が 歯音jなし-歯茎音jつき の対立になっている。
http://en.wikipedia.org/wiki/Russian_phonology#Consonants

というわけで、ロシア語風に発音されるのであれば、表題のようなセオリーにならんとも限らん。ような気がする。

以上、単なる半可通の憶測、まったく無保証であります。

JSONでGPV, あるいは「データとホームページの対立」の止揚

このあいだ、Cameron Beccario 氏の作った風流線のサイトが話題になっていましたね。
ふと気がついて調べてみると、これはとてつもない革命的な変化を体現しているんですよ。

描画はすべて JavaScript で行われています。GIFやPNGなどの画像ファイルは一切使われていません。ぐりぐり視点を変えても、通信は一切行われません。時間や高度を変えたときだけ、通信が行われるのですが、そこでロードされる風データは、なんとJSON形式です。

http://earth.nullschool.net/data/weather/current/current-wind-isobaric-500hPa-gfs-1.0.json

ついでに、海岸線データもJSONです。

http://earth.nullschool.net/data/earth-topo.json?v2

こっちはきれいな GeoJSON ですかね。

これまで、ネットワークを使った資料提供とひとくちにいっても、次の大きな２択があって、どちらかを選ばねばならないという状況がありました。私だけの思いこみではないでしょう。

データ提供

バイナリファイルをサーバに置いてダウンロードさせる。形式はGRIB、netCDF、あるいはnus.tar.gzなど。
いずれにしても気象界に特殊なものであって、利用者側でインストールしたソフトウェアを使ってバイナリファイルを解析しないと意味のある出力は得られない。
そのかわり、自由に再加工できる。

一般向けホームページ

HTMLをサーバにおいてブラウザで閲覧させる。数表を書く、画像を貼りこむなどする。画像ならば形式はPNGやJPEG/JFIFなど。
ほぼ誰でも持っているブラウザさえあれば追加のソフトウェアなしで閲覧できる。
そのかわり、画像は天気図としてレンダリングが完了したものであって、別の見栄えには再加工が困難である。

この二項対立への対処として、まず現れたのがサーバサイド描画です。ユーザが見栄えの諸元を指定して、サーバにリクエストを出すと、画像が返ってくるというものです。ブラウザで見られる画像が返ってくれば特別なソフトウェアは不要ですし、利用者のニーズに応じた見栄えを選ぶことができて、データ提供に（及ばないまでも）近い自由度が利用者には与えられます。

具体的にはOGC WMSだけ挙げておけばいいでしょう。透明PNGとか、ブラウザのレイヤという技を駆使して、複数の情報を重ねあわせて表示するのも広く行われます。我が国ではGISアクションプラン2010で推進されていますし、気象界でいうなら OGC MetOcean DWG が多数時間次元拡張などのベストプラクティスをまとめています。すばらしいですね。

でも、欠点もあります。スケールしないのです。

なにしろ、一人ひとりのお客様に別の絵を描いてお渡しするわけですから、他のお客様に流用もできません。利用者数に比例して計算負荷がかかります。一般公衆が興味をもつ気象実況なんかだと、万単位、たぶん百万単位のユーザが同時アクセスなどということがありうるわけですが、そんなアクセスに耐えるサーバ、とてもじゃないけど用意出来ません。

サーバがだめなら、クライアントがあるじゃない、となるわけです。

そこで現れたのは地図タイリングです。具体的にはグー…地理院地図を挙げておきましょう。マウスでぐりぐり場所を変えたりズームできるわけですが、縮尺は離散的に設定されており、地図は描画済みのもの256×256ピクセルのの画像群としてサーバに用意されていて、それを必要なところだけダウンロードしてきて貼り合わせて表示するようになっています。

これで、計算負荷はあらかじめ準備できるようになりました。がしかし、見栄えの自由度が減ってしまいます。地形図のように、常識的な見栄えが決まっているものならば唯一または少数の選択肢を用意すればよいのですが、500 hPa面気温をどういう色遣いにしたいのかは、状況によるといわざるを得ない人が多いでしょう。

そこで今回の真打が登場するわけです。

いまどきのブラウザは、JavaScriptで絵が描けちゃったりします。なので、JavaScriptで自然に扱える形式のデータをウェブに置いておけば、ブラウザ上で描画できるわけです。JSONはそういうファイル形式の代表的なものです。

しかし、いくらなんでも数万点オーダー（360×180=64,800）の格子点データをJSONで表現して、ブラウザ内で解析して描画するなんていったらメモリ的にも演算能力的にも無理だろうと思い込んでいたのですが、いつのまにかそんなことが携帯端末ですらできる時代になっていたわけです。

結局、JSONで表現された格子点データは、気象に特化したソフトウェアをインストールすることなしに利用できて、しかも再利用の可能性が一切損なわれていないわけです（nullschool.netでは色は変えられないようですが、原理的には可能であることは容易に見て取れます）。

つまるところ、上の二項対立は見事に止揚されたわけです。あるいは、全球1度格子予報値がスモールデータになったといえるかもしれません。

実をいうと、私は１６年前からそういうことを考えてきました。なので、やられた、という感傷もなくはないのですが、自分ひとりでなんでもできるわけではないおっさんであることはよくわかっています。文明の進歩を素直に喜びたいと思います。

配信資料に関する技術情報381〜384号発売（週間アンサンブル予報システムの高度化、1か月予報および早警の発表日変更）

気象業務支援センター http://www.jmbsc.or.jp/hp/book/g_j0080.htm によると、
配信資料に関する技術情報 381〜384 号が発売になったそうです。

数値予報関係では次のものが含まれます：

383 週間アンサンブル予報システムの高度化について

382 平成26年3月からの1か月予報及び異常天候早期警戒情報の発表日変更と配信資料変更について