ぼくじょう日記

てらお牧場に起こる出来事を書きつらねていきます。

Windows10上のMSI版Office2016のアップデート

最近のOffice(2013以降)のアップデートは、Windows Updateによるものではなく、クイック実行という形式に変更になっています。 しかし、ボリュームライセンス製品の場合にはクイック実行形式によるアップデート機能が備わっておらず、Windows Updateによる更新の設定をしておく必要があるようです。 「Windowsの設定」→「更新とセキュリティ」→「Windows Update」→「詳細オプション」のなかで、「Windowsの更新時に他のMicrosoft製品の更新プログラムも入手します」を選択しておきます。 あとはWindowsの更新と同じタイミングでアップデートされます。

古いボリュームライセンス製品だと、Office2016の奇妙な振る舞いが残されている場合があると思います。例えば、

  • 「○」(「まる」・変換)を入力すると、勝手に確定されてカーソルが一つ勝手に進む現象
  • 「○」の確定に成功するものの、その部分の言語が勝手に「英語」と判断されてしまい、その更新ができず、フォントの変更もできない現象

などです。アップデートにより、これらの現象は解消されます。

GMTの図中文字のフォントについて

GMTのpstextによるフォント指定は、 http://kdo.la.coocan.jp/gmt10_pstext.html を参照のこと。 とりあえずバングラデシュ周辺の地図の作成に用いてみました。 イタリックがきちんと表示されて見やすいです。

latexのファイルのコンパイルについて

latexのファイル.texコンパイルして.pdfをつくる過程については、少しずつ変遷もしていてなかなかややこしい。 今の環境では、.pngファイルを図の張り込みに使っている場合にはBoundingBoxを解析して別ファイル.xbbに書き出しておき、 その後latexに移るのが良いようだ。

BoundingBoxの抽出にはextractbbを使おう

まず最初に、pngファイルからBoundingBoxを抽出する必要がある。

その際のツールは、検索するとだいたい二通り(ebbextractbb)出て来て、どちらが正しいのだろう? と疑問に思っていた。 このページ http://qiita.com/zr_tex8r/items/5413a29d5276acac3771 によると、この二つの違いは大きいものであるらしく、dviファイルからpdfファイルをつくる際の、これもまた似たものが二つあるのでなんだろうと思っていたdvipdfmdvipdfmxの、それぞれのための非互換のツールになっているとのことでした。 この二つのdviをpdfに変換するツールはほとんど同じ名前なのに、実は互換ではなく、そのうえ時にはdvipdfmがdvipdfmxのエイリアスになって動いているシステムもあるという話である。 実際この記事に倣ってdvipdfm --helpしてみると、実はやはりこのdvipdfmdvipdfmxであったことが分かった。 ということは、BoundingBoxを抽出するためのコマンドとしては、extractbbを使うべき。ということになる。

% extractbb *.png

次はlatexを何回か

ここは昔と変わらない。

% latex hoge.tex

とりあえずdvipdfmxを実行するのが僕の環境

自分の環境ではdvipdfmxを使ってうまく動いていて、今のところ問題は出ていない。 ただし、graphicxパッケージを使う際には

\usepackage[dvipdfmx]{graphicx}

として、dvipdfmxでうまく動くようにしておく必要がある。 これでlatexのpdf化ができる。

京都の最近のレーダーアメダスデータの解析

最近のレーダーアメダスデータは、経度方向1/80度、緯度方向1/120度グリッドの制度を持っている。だいたい1km四方の精度ということになる。これを京都北部-琵琶湖にかけての領域について解析してみる。 以前四国周辺エリアについて行った解析プログラムをそのまま利用する。この時は、北緯32.0-35.0度、東経131.0-135.0度を切り出していた。今回は、北緯33.0-36.0度、東経134.5-137.5度を対象にしてみようと思う。

作業はデータサーバで行う。作業ディレクトリは、/hoge/terao/radar_amedas。データ展開用ディレクトkinki_res3を作成し、領域定義ファイルdefs.txtを作成する。

type=lonlat
x1=134.5
nx=320
y1=36.0
ny=360
nodata=-999.9

作業を行うためのshell script extract_kinki_res3.20170107.shを作成してこれを実行する。dvdのisoイメージを各年ごとに2006-2013年についてマウントし、作業を行う。その結果を平均することで、kinki_rese_productsディレクトリに様々な平均ファイルを作成する。 2006年1月2日05JSTのデータのみが欠けている。 また、2011年のデータはどうも形式が違うようで、異なるscriptを使う必要がある。

これを実際に描画する作業は、解析サーバで行う。作業ディレクトリはtopics/kinki_climate/analである。ここにkinki_res3_productsの内容をコピーしてくるとよいだろう。 まずは、全期間平均と月平均を作成。 季節を決めて日変化も作成してみたいところだ。

標高データはucsdからSRTM30_PLUSをとってくる。

http://topex.ucsd.edu/cgi-bin/get_srtm30.cgi

上記の解析エリアより少し広い領域を採用。

データの描画はGMTで行う。 降水量のグリッドデータはただの4バイバイナリである。緯度北から南、経度西から東で入っている。 データ数が360x320個、レコード長460800バイトのファイルとなっている。 地形のデータは30秒ごと3カラムのテキストデータで、各カラムが経度(deg)、緯度(deg)、標高(m)となっている。

まずは、降水量データをgrdimageで書く。 その上に、grdcontourで地形のコンターを重ねつつ、海岸線と緯度経度を置くのが良いだろう。 grdimagegrdcontourで許されるグリッドデータの形式はどのようなものがあるか、GMTのマニュアルを参照する。

http://gmt.soest.hawaii.edu/doc/latest/index.html

Cのnativeなバイナリもサポートしているようだから、単純な4バイ浮動小数点実数も大丈夫だと思われる。 ただ、データはgrd形式のファイルが便利そうではある。 地形データ(x,y,z)からはどうやらxyz2grdコマンドによってgrd形式のファイルをつくれそうである。 単純な浮動小数点実数データからも、xyz2grdコマンドのオプション指定により、grd形式のファイルが作れそうである。

まずは以上の見通しをもって、作業にあたった。

枠と海岸線を書く

まず最も簡単そうなことから。枠と海岸線を書いてみる。 参考にしたのはまずはこのページ。

http://www.creator.club.ne.jp/~kami/tips/gmt/japan.html

マニュアルはフルにあらゆる使い方に対応するコマンドラインオプションを説明してくれているため参照するにはちょっと重すぎ。 ふつうこの程度で使うのだぞ、という情報としてはこのページの方が分かりやすい。以下を実行してみる。

gmt pscoast -R134.5/137.5/33.0/36.0 -JM12c -Df -W2 -Ba1/f0.5/g0.2 > kinki.eps

まずはまったのは、 ペンの指定の-Wオプション。 上記ページの例示には、-W1/0/0/250という記述がなされている。 ところが、これは正しく解釈されないという警告が出る。おそらく書式が古い推奨されないのだろうと思う。 まずは-W2で動くかどうかやってみることにしたら、いちおう警告は消えた。

次にはまったのは、 pscoastコマンド(最近はgmt pscoastとラッパーに包んで使う)が海岸線データを見つけられない。 という事態。 上記-Dfオプションが、full resolutionの海岸線データを使うという意味。 ほかにも、h, i, l, cがあり、この順で粗くなっていく。 とりあえず、i ならば対応できるようだ。 エラーメッセージの中に GSHHG がないという表示が出るので、おそらく解像度の高い海岸線データがインストールされていないのだろうと思い、gshhgをyum searchしてみたところ、

[terao@gkmodel anal]$ sudo yum search GSHHG
gshhg-gmt-nc4.noarch : Global Self-consistent Hierarchical High-resolution

ところが、

[terao@gkmodel anal]$ sudo yum install gshhg-gmt-nc4
パッケージ gshhg-gmt-nc4-2.3.3-1.el7.noarch はインストール済みか最新バージョンです

だから既にインストールされているが、gmtが見つけられなくなっている、ということのようだ。 環境変数を指定する必要があるのだろうと想像する。

ちなみに-Di指定で見ると、この程度。

f:id:teraogk:20170107172349p:plain

いまいち・・・ですね。 そこで、あくまでも full resolution を目指すことに。 一体問題のファイルはどこに入っているのだろう。 パッケージの中にあるファイルのインストール位置を知るコマンドがあったはずだ・・ いろいろ検索してようやく思い出す。

[terao@gkmodel anal]$ repoquery --list gshhg-gmt-nc4
/usr/share/doc/gshhg-gmt-nc4-2.3.3/README.TXT
/usr/share/gshhg-gmt-nc4
/usr/share/gshhg-gmt-nc4/binned_border_c.nc
/usr/share/gshhg-gmt-nc4/binned_border_i.nc
/usr/share/gshhg-gmt-nc4/binned_border_l.nc

ありゃ。full resolutionはないぞ。

[terao@gkmodel anal]$ yum search gshhg
gshhg-gmt-nc4-full.noarch : GSHHG - full resolution
gshhg-gmt-nc4-high.noarch : GSHHG - high resolution

あ、そういうこと。解決。

f:id:teraogk:20170107173222p:plain

地形データのgrdファイル化

地形データはテキストファイルなので、xyz2grdサブコマンドでgrdファイル化することにする。

[terao@gkmodel anal]$ gmt xyz2grd topo/shikoku.txt -Gtopo/shikoku.grd
xyz2grd: Syntax error: Must specify -R option
xyz2grd: Syntax error -I option: Must specify positive increment(s)

とのことなので、-R, -Iオプションを検討する。 -Iは、gtopo30を持ってきているのだから、30秒(30 arcseconds)に設定するべきだろう。つまり-I30s/30s。 -Rは、今書きたいと思っている領域にするなら、-R134.5/137.5/33.0/36.0が良いだろう。

[terao@gkmodel anal]$ gmt xyz2grd topo/shikoku.txt -Gtopo/shikoku.grd -I30s/30s -R134.5/137.5/33.0/36.0

これで地形のgrdファイルtopo/shikoku.grdができた模様。

地形をコンターで描く

コンターを書くならgrdcontourである。

gmt pscoast -R134.5/137.5/33/36 -JM12c -Df -W2 -Ba1f0.5g0.2 -K > kinki_topo.eps
gmt grdcontour topo/kinki.grd -R -JM -W1 -C200 -L200/3000 -O >> kinki_topo.eps

うまくいくかと思いきや、妙なことになってしまった。

f:id:teraogk:20170108123714p:plain

たぶんgrdファイルが特定の格子点上のグリッドだけについて変換されたのではないか、と推察する。 これらのグリッドだけコンターがかかれ、他がゼロだとこうなるだろう。

グリッドの定義は通常gridline registrationであることと関係がありそうだ。 topo30は、pixel registrationでデータが定義されている。

gridline registrationで、かつグリッド幅を、-Rオプションで指定された領域の端がグリッドになるように調整すると、もしかすると等間隔にのみグリッド地が定義されるような状況にもなりうるだろう。

xyz2grdに-rオプションを指定して実行してみる価値があるだろう。 やってみた。

[terao@localhost anal]$ gmt xyz2grd topo/kinki.txt -Gtopo/kinki.grd -I30s/30s -R134.5/137.5/33.0/36.0 -r
[terao@localhost anal]$ gmt pscoast -R134.5/137.5/33/36 -JM12c -Df -W0.5 -Ba1f0.5g0.2 -K > kinki_topo.eps
[terao@localhost anal]$ gmt grdcontour topo/kinki.grd -R -JM -W0.3 -C200 -L200/3000 -O >> kinki_topo.eps

見事解決。

f:id:teraogk:20170108131759p:plain

いよいよデータの描画

データファイルは4byte floatの塊になっている。 これをgrd形式のファイルに持ち込めばあとは簡単である。 そのためには、xyz2grdが使える。具体的には、

[terao@localhost anal]$ gmt xyz2grd rain.m08.bbx -Grain.m08.grd -I0.0125/30s -R134.5/138.5/33.0/36.0 -r -ZTLf

のような感じである。 -Iオプションはグリッド間隔。 -Rオプションはグリッド定義で、-rオプションでpixel registrationを指定。 -Zオプションは、データがどういう向きに入っているかを示す。 この場合、Tつまり、上=北から南。 さらにその各行が、Lつまり、左=西から東。

なお、作成している平均値ファイルは4レコードから構成されているため、 上記xyz2grdだと「余分なデータがある」とはじかれてしまう。 そこで、必要な部分だけを切り出すため、headコマンドを使った。 headコマンドは、-c Nオプションをつけることで、 初めからNバイトの部分を切り出してくれる。 今回の場合、320 x 360グリッドなので、320 x 360 x 4=460,800バイトの切り出し。 すなわち、

head -c 460800

を実行すればよい。

このgrd形式のファイルに基づいてイメージを描く。grdimageを利用する。 さて、その場合、カラーパレットの指定が少し面倒である。 /usr/share/gmt/cptディレクトリに、標準的な多くのカラーパレットが定義されている。 今回は、オンライマニュアルのcook bookの22節, "Color Space: The Final Frontier" を参照してなんとなくよさそうだった、wysiwyg.cptを使ってみた。 雨の表現として結構自然だと思う。

問題はこのカラーパレットを現実のデータに対応させることだ。 このためのツールgrd2cptも用意されていて、そうとう便利。

[terao@localhost anal]$ gmt grd2cpt rain.grd -Cwysiwyg.cpt -L0/10 > hoge.cpt

上記、rain.grdを参照して、0-10mm/hの範囲で、各色の幅が等頻度で現れるように調整したカラーパレットを、hoge.cptに作成してくれる。 実際にはこれをもとにして、何らかの「切りの良い」境界値を決めてやるのがよいだろう。 まずはこれでとりあえずの作業はできるようになったように思う。

明日少し整理して、結果をお示ししたいと思う。 もう寝る時間です。

PostScriptファイルをokularで表示

あと、意外とはまったのは、psファイルはどのコマンドで見たらよいのか、という点。 以前他のマシンでpdfファイルの表示ではまったことがあったのだが、コマンドの固有名詞を忘れてしまうとどうにもならない。 いろいろ検索してようやく思い出したのがokular。 ところが、このマシンにはこれはまだインストールされていなかったため、yum installする必要があった。 153個もパッケージをインストールする必要があったため少し時間を要し、ようやく終了。 無事表示ができた。

convertコマンドでトリミング

convertは周囲の余白をトリミングしてくれる。こんな感じに使う。 [terao@gkmodel anal]$ convert -rotate 90 -resize 50% -trim kinki.eps kinki.png 備忘のため。

昨日・今日は南アジア研究集会

昨日から今日にかけて、京都大学防災研究所共同研究一般研究集会「第11回南アジアにおける自然環境と人間活動に関する研究集会」が開催され、参加して参りました。 南アジアの人間活動と自然環境に関する4つのセッションで構成されていました。気候・気象条件に関する研究、気象災害に関する研究、気候変動と農業に関する研究、人文科学・社会科学的アプローチの4つです。バングラデシュ、インドアッサム地方、ネパール、ミャンマーからも参加があり、国際的色彩の強い研究集会になりました。

今回、できるだけ「どこになぜ人は住むのか」、「どのように人の集住パターンは決まっていくのか」を念頭に聞くようにしました。地球研の村山プロジェクトと関係した問題意識ですね。 奈良女子大学の浅田さんの発表は、アホミヤ・ボド・ネパリという3つの部族の生活に関する聞き取り調査が紹介され、多様な部族のそれぞれの特徴が明らかとなって大変興味深いものでした。特に、3つの部族はそれぞれ同部族の周辺集落との間での交流が強いとのこと。一方でこれらの部族のそれぞれの集住パターンは、それぞれの生活の仕方と関係しており、土地の土壌や気候パターンとも無関係ではないことも事実のようです。 人の集住メカニズムを考えるとき、3つの異なる集団のメカニズムを同時に考えるようなモデルを検討したらおもしろいのではないか。大都市への集中を最適とするものだけではないなんらかの質の違う解が見いだせないか、などとも思いました。

latexの論文をgithub的に書く

投稿論文を準備するため、latexの論文をgithubに載せて書く練習をする。 これでどこに行っても論文のソースの特定のバージョンがダウンロードできるようになる(といいのだけれど)。

githubには一応privateリポジトリを置けるようにしている(有料)。 投稿できたらその時点でpublicリポジトリに移す方向で検討。 ファイルはまずはREADME.mdと論文本体(submit.tex)。 ここに画像ファイルが追加されていくことになる。

githubリポジトリを新たに追加。 private属性にしておく。 出来たリポジトリに作成中の論文をアップロード(push)する。 一応作法としてREADME.mdをつくっておく。 内容は論文のプロジェクト名のみ。 ディレクトリでリポジトリを初期化する。

$ git injit

ファイルを登録する。

$ git add README.md
$ git add submit.tex

初期りビジョンをつくる(commitする)。

$ git commit -m "first commit"

githubで追加しておいたリモートリポジトリをoriginという識別子で登録する。

$ git remote add origin https://github.com/username/repositoryname.git

そこへリポジトリをプッシュする。

$ git push -u origin master

別のマシンからバージョンを取得する場合は、

$ git clone https://github.com/username/repositoryname.git

とすればよい。フォルダが作成されて、その中がリポジトリになっている。

.bash_profile, .bashrcをどうする

bashのPATH設定をどこに書くべきか、上記の選択肢で迷った。 Fedora25ではデフォルトで.bash_profileに書いてあるのだが、デスクトップで使うターミナル上のbashではこれが反映されていない。 これは困る。 なぜこうなるかというと、.bash_profileは、bashをログインシェルとしてログインするタイミングで飲み読まれるからだろう。 X環境は必ずしもログインユーザのbashには依存しておらず、そのうえでターミナル上で動くbashには、.bash_profileの設定は反映されないのだろうと思われる(不確実な推測)。

その点.bashrcはbashが立ち上がるたびに評価されるようだから、好都合。

export PATH=$PATH:$HOME/bin

みたいなことを書くのがよさそう。 ただし、bashからターミナルを呼び出すと上記が再度評価されてしまうため、$HOME/binが二重に設定されてしまうという軽微な問題が起こる。 ただ、おそらくterminalを立ち上げる方法としては、ターミナル上での右クリックメニューを使う場合が多そう(たぶんFedora25の特定の環境だけで意味のある話だけれども)。 であれば、ターミナルに乗っかっているbashは関与しないので、その軽微な問題も生じるケースは少ないだろうと想像する。

以上のことから、.bashrcにPATH設定を記述しておくことにする。.bash_profileにすでに記述されている部分はこの際コメントアウトする。