2017-03-31

(豊田寄稿あり)数値予報課報告・別冊 第63号(平成28年度) 数値予報モデル開発のための基盤整備および開発管理

http://www.jma.go.jp/jma/kishou/books/nwpreport/nwpreport.html

目次は次のようです。第4章4.1に寄稿しました。

>       □ 表紙・序文・目次( 32 KB )
>       □ 第1章:序論( 268 KB )
>       □ 第2章:開発記録とバージョン管理( 5.45 MB )
>       □ 第3章:数値解析予報実験システム(NAPEX) ( 496 KB )
>       □ 第4章:データハンドリングと可視化( 6.93 MB )
>       □ 付録A 電子計算室報告、同別冊、数値予報課報告・別冊発行履歴( 21 KB )

(改訂)配信資料に関する技術情報 第446号 表面雨量指数、精緻化した流域雨量指数、大雨警報(浸水害)の危険度分布、洪水警報の危険度分布、大雨警報(浸水害)・洪水警報の危険度分布(統合版)、速報版解析雨量の提供について

変更点は書いてあります。
http://www.data.jma.go.jp/add/suishin/jyouhou/pdf/446.pdf

2017-03-30

メモ 日本気象学会「天気」第64巻3号(2017年3月)

1ヶ月くらいすればオンラインでよめるのでしょうが、すぐ出すことに意義を感じたので出します。

●ドイツの雲・降水研究プロジェクトHD(CP)2の最終成果報告会UCP2016の参加報告

NICAMの人たちが参加。全球LESなど力学のことは正直まあそちらでやってください、だけれど、物理過程改善の話も少しはあったようです。

●気象談話室:対流圏の気温減率はなぜ6.5K/kmなのか — エネルギー収支からの考察

木村先生。放射対流平衡による温度構造の説明は地球大気には適用できないのではないかという極めてラジカルな新説。

●B・C会員向けの気象集誌の配布方法の変更について

アンケートをしています。 https://www.metsoc.jp/?p=7690 で4月7日まで。

編集委員会が投稿料低減をせねば活路はないなどというのはのっぴきならない事態であると推察します。

●第39期第1回支部長会議議事概要

ひきつづいて極めて厳しい経営状態が語られている。気象学会の経営問題とは、気象庁の問題でもあります。

「天気」のウェブ公開をやめてしまうのはだめでしょう。それでは魅力的な記事が集まらなくなるだけです。

これから大学院生は減っていくのだろうから、学生に過度に頼るのは良いアイデアとは思えない。
気象庁職員に入ってもらいたいと思えるようにするには、漠然と防災などといって他の防災系学会と競合するのではなく気象業務を扱うという方向にすべきだと思う。

リーフレット「静止気象衛星−ひまわり8号・9号−」

http://www.jma.go.jp/jma/kishou/books/himawari/index.html

2017-03-29

配信資料に関する技術情報 461 H29.3.29 衛星データの新規利用開始による全球モデルの予測 精度向上について

http://www.data.jma.go.jp/add/suishin/jyouhou/pdf/461.pdf

RMSE改善率っていつも説明なく使っている気がするけど、

RMSE = sqrt { 面積平均[ (Z予報 - Z解析)^2 ] }

として改修前を RMSE_C, 改修後を RMSE_T とすると

(RMSE_C - RMSE_T) / RMSE_C × 100 [%]

のことね。

ソース:研修テキスト #45 http://www.jma.go.jp/jma/kishou/books/nwptext/45/Appendix_A.pdf

2017-03-28

測候時報 第84巻 海氷自動解析システムの開発について

こちらからごらんください。
http://www.jma.go.jp/jma/kishou/books/sokkou/sokkou.html

なお、WMO標準の色というのが出てきますが、どうやらこれのことのようです。
JCOMM-TR-024, WMO/TD-NO.1215, SPA_ETSI_general_SIM04
Ice Chart Colour Code Standard
http://www.jcomm.info/index.php?option=com_oe&task=viewDocumentRecord&docID=4914

2017-03-27

(改宗しました)ウェブで公開するCSVは、漢字入りならUTF-8よりShift_JIS(charsetは指定しよう)

2月のことですが、さる官庁でオープンデータといってCSVをウェブ公開したはよいが、正規化してないわファイル名はpermalinkを意識しているとは思えないわというのでネット上のエンジニアの注目を浴びるということがありました。そこから派生して、改行コードや文字コード(エンコーディングというのが正しいのだろうが、通じないので以下文字コードでとおす)が話題になりました。

たとえば mishiki さんの例



この件に関して、つい先週まではUTF-8派だったのですが、いろいろ考え議論して改宗しました。現在のお勧めは:

  • 改行は CR+LF
  • 文字コードはShift_JIS
  • 極力 HTTP 応答に charset=Shift_JIS が付くよう設定しよう。

なぜ Shift_JIS なのか。まず、さまざまな利用環境での文字コード対応状況(ベンダ保証でなく実験結果):
  • MS Excel で文字化けせず開けるのは Shift_JIS または BOM つき UTF-8
  • Apple iOS や Android タブレットでは UTF-8 しか開けないアプリが散見される
  • ブラウザ上の JavaScript から文字化けせず開けるのは、正しい charset がついているか、UTF-8
  • Java など現代的なプログラム環境から読む場合も「正しく charset を知っていれば化けない」という意味では同様
  • Cで自作プログラムする場合など、文字コード認識を適切なライブラリに任せず、オクテット列として処理している場合、BOM が問題を起こすことが多い
日本的管理職ふうには、環境×文字コードの星取表を作りたくなって、どの環境でも化けないのは BOM つき UTF-8 だけなのだから、それを普及させるべき(ソフトウェアの問題ならちゃんと改修すればいい)、といいたくなるのですが、複雑な問題でそういうカタログショッピング的な単純思考をしていると立ち行きません。結局、「C で自作プログラムする場合など」が無視できないので BOM つき UTF-8 を避けるとなり、そうだとすると最も多くの環境でサポートされるのが Shift_JIS ということになります。

ソフトウェアの問題というのは、たとえばこういう仮定が成り立たなくなるということです:
  • 複数の CSV ファイルを cat で連結すれば正しい CSV ファイルが得られる
  • CSV ファイルを sort や grep などのコマンドでフィルタした結果も正しい CSV ファイルである
  • CSV ファイルを LF で区切って得られる「行」を U+002C COMMA で区切ったものが各セルである
そういう仮定は国際化とともに終わったものと心得て決して使わず、かならず wchar_t 列を処理する素養と経験を持ったプログラマーがいればいいのですが、理屈ではいろいろ言えるのでしょうが、まあ実際問題としては無理です。

なお、テストに使ったファイルを http://toyoda-eizi.net/2017/csv-utf8/files.html に置いておきますのでよかったらお使いください。

2017-03-07

配信資料に関する技術情報 458 H29.3.7 1か月予報及び異常天候早期警戒情報の配信資料の変更時期と1か月アンサンブル予報システム等の変更について

1ヶ月アンサンブル予報システムが全球アンサンブル予報システム(週間アンサンブルと台風アンサンブルを統合したもの)に統合されます。
これにより、最新の物理過程シミュレーションコードが1ヶ月予報で利用できるようになるなどの改善が図られます。

技術情報
http://www.data.jma.go.jp/add/suishin/cgi-bin/jyouhou/jyouhou.cgi
http://www.data.jma.go.jp/add/suishin/jyouhou/pdf/458.pdf


モデル一覧について
http://www.jma.go.jp/jma/kishou/know/whitep/1-3-4.html