2013年07月のメモ帳


2013/07/31

#1 お届け物

特許庁から一般書留扱いで何か届いたっぽい。9割方、拒絶理由通知だろうなぁ。検索してみると、ちょうど2年前の8月1日に審査請求した物に引用調査データの記載が増えてるし。しかも全て非特許文献からとか・・

2013/07/29

#1 OSMのgarmin地図変換システムの改造検討(4)

結局、システム入れ替えを断念することにした。最初に書いた(1)と(2)の目標は確かに新システムでは達成できたんだけど、変換に時間がかかるようになったこと、変換結果が全体的に悪くなってることのデメリットのほうが大きいと判断したので今回は見送り。

速度については、20GB近いデータの9割以上を占める日本語以外のデータの解析にかかってる時間が大きいと思われるので、perlなどのスクリプトで日本語箇所に絞ってあげればかなり高速化できるとは思うんだけど、64bit環境の整備に苦戦して、結局自力でperl用のモジュールのコンパイルはできなかった。

自分の経験値は上がったと思うので、無駄ではなかったけど、入れ替えできなかったのは残念だ。そのうちperlからのライブラリ利用が簡単にできるようになったら再挑戦したい。

2013/07/27

#1 OSMのgarmin地図変換システムの改造検討(3)

昨日の続き。テストデータを梅田付近の10MBサイズにして、さらに評価を継続。MeCab+デフォルトのIPA辞書では「大阪駅前」が「オオサカエキゼン」に変換されたり、「お好み焼」が「オコノミショウ」に変換されたり、「桜橋」が「サクラキョウ」に変換されたりと、kakasiで正しく変換できていたところすら間違ってる。辞書を、IPA辞書ではなく、NAIST辞書を使うことにするが、こちらはお節介にも日本語以外も変換してしまうため、XML構造が壊れるという状況に悪化。アルファベットなどを変換しないように、辞書から取り除いてあげたら、まともに変換できるようにはなったけど、「お好み焼き」が正しく変換できるようになったくらいで、IPA辞書の時と大差ない感じ。

このままでは明らかに品質ダウン。ある程度は改善対応できることの確認はしておく。MeCabの辞書をいじるにあたって、コストについては理解しておいたほうが良さそう。こちらのページを見ながら、変換がおかしいところの原因を調べる。この段落は、以降、コストが理解できてないと意味不明だと思うけど、メモとして記載。例えば、「"大阪駅前"」は「"/大阪/駅前/"」になって欲しいところが「"/大阪/駅/前/"」に分解されたことが読み間違いの原因。「"」が未知語になってて、NAIST辞書では、未知語の記号は、サ変接続と同じ連接コストになってしまい、「駅前/"」よりも「駅/前/"」のほうがコストが低くなって駅と前が別れてしまったようだ。一般的な日本語で、記号をサ変接続にするのが良いのかは不明だけど、地図上のPOI名には基本的に文章はないので、サ変接続の考慮なんて不要。辞書の、uhk.defファイルの

SYMBOL,1356,1356,10705,名詞,サ変接続,*,*,*,*,*

の部分を

SYMBOL,5,5,3274,記号,一般,*,*,*,*,*

にしてから辞書をコンパイルし直す。このファイル、日本語部分は参考情報扱いで、3つの数値が連接IDとコストなので重要。あ、コンパイルといえば、NAIST辞書はeuc-jpなので、utf-8の文字列を変換するためには、

..\..\bin\mecab-dict-index.exe -f euc-jp -c utf-8

みたいにする必要があることに注意。昨日のローマ字変換辞書はutf-8だったので、昨日と同じように変換してはまってた。それから、同じディレクトリに*.csvファイルを置いておくと、辞書コンパイル時に自動的に取り込まれるようなので、単語を少しだけ入力しておいた。ここまでやったところで、ようやく「大阪駅前」も「オオサカエキマエ」に変換されるようになった。まだkakasiに負けてる気はするけど、後からでもなんとかなる見込みはできたので先に進む。

ネイティブでutf-8対応してなかったkakasiのために、事前に不要な文字を消したりiconvで変換したりしてた処理が不要になるはずなので、これをはずして、文字変換の評価に使ってた梅田近辺のデータを新変換システムに通してみた。意外にも、エラー無しで変換完了。Edge800で確認しても、特に問題は無さそう。フランス語のEにアクセント記号付きの文字は、アクセント記号は消えてるものの、元のEの字は残ってるので、改善してる。(その後、mkgmapのオプションにlatin1をつけて変換し直したら、アクセント記号もEdge800で表示された。)

ということは、次は全国データに挑戦ですよ。なんと、こちらもエラー無しで変換完了。奇跡だ。変換時間は、2時間弱と、kakasiを使う現行システムの1時間半弱からは伸びてるものの、許容範囲。7/23に取得したOSMデータから変換後のデータサイズは、現行システムが703,168,8512バイト、新システムが703,217,664バイトと誤差範囲なので、大きく欠落してることも無さそう。ただ、色々見てると気になる誤変換は多い。少なくとも、まだこれくらいは手を加える必要がありそうだ。

2013/07/26

#1 OSMのgarmin地図変換システムの改造検討(2) MeCabお試し

今日はMeCabを試してみる。ただ、「構文解析精度を必要としないと思われる、日本語のPOI名のローマ字読み化」という目的に完全合致していたkakasiと比べ、変換速度や性能で見劣りしないかが最大のポイント。例のごとく、約1.5MBのご近所データ(日本全体の1/10000以下のデータサイズ)で性能評価をしてみる。

まず、MeCabの標準機能、-Oyomiオプションでカタカナ読み変換を実行。たまにカタカナにならずに漢字のまま残ってるところがある・・。特殊な固有名詞は諦めてもいいけど、「鍼灸」がそのまま残ってるレベルなのでこのままじゃ無理だな。辞書をデフォルト辞書から入れ替えたらなんとかなるかな。

次。-Oyomiではカタカナにしかならないので、カタカナ→ローマ字変換も必要。直接ローマ字出力をする方法は見つからなかったので、2段階でMeCabを通し、1段目でカタカナ変換、2段目でローマ字変換することにする。変換ツールとしての活用を参考に、ローマ字変換辞書を作ってみる。わざわざ自分で作りたくはなかったんだけど、なぜかどこにもそれらしきものが見当たらなかったので、勉強がてら。現状の辞書がこちら。OSM変換用なので、utf-8です。今はASCIIの範囲だけでローマ字出力してるけど、最終的にはマクロン付きの文字も導入したいところ。辞書データを作りながら気がついたんだけど、単純な文字置換は、このフェーズで一緒にやってしまうのもありだな。そもそも、カタカナ→ローマ字変換が単純な置換なので、やってることは基本的に変わらない。

昨日の段階では、perlからライブラリとしてのkakasi利用が難航してたので、ライブラリとしてのMeCab利用を目指してMeCabの評価を始めたんだけど、そもそも、ネイティブにutf-8が処理できるMeCabなら、昨日の方針「perlスクリプトで必要な箇所だけを切り出してkakasiに渡して変換する」にこだわらず、元々の「ファイルごとkakasiに渡す」をベースに、「ファイルごとMeCabに渡す」でもいいかもしれない。となると、わざわざperlスクリプトでXMLパースや日本語文字の抽出をしなくて良くなるし。

2013/07/25

#1 OSMのgarmin地図変換システムの改造検討(1) スクリプトで必要な箇所だけを切り出してkakasiに渡す(未遂)

Garmin GPS用の日本地図の変換の仕組みについて、作成当初から2年近く使い続けるうちに、いくつか不満点が出ていた。そのうち、ローマ字変換に関係するのが2つ。(1)時々、ローマ字読み変換時にXML構造が壊れるデータがOSMの元データに追加され、あらかじめ置換で別の文字に置き換えるためのスクリプト変更作業が必要になる (2)kakasiを通す都合上、一旦SJIS変換するため、フランス語とかのアクセント記号を残せない。

ということで、これら2つの問題を解消すべく、変換方法の改善を考えることにした。今はOSMのXMLデータ全体をkakasiに通して、その中の日本語部分をローマ字に変換してる。(1)のXMLが壊れるのは、例えば全角の「”」みたいなXML構造と無関係な文字が、kakasiを通るとASCIIの「"」になってXML構造に影響してしまうのが原因。XMLをパースしてから、部分的な文字列をkakasiに渡すのであれば、kakasiを通した後にXML構造に影響がないようにさらに置換することもできるので、これで回避できそう。(2)については、そもそもkakasiに渡さなければいい。(1)と合わせて考えると、XMLをパースしてkakasiに渡す文字列を絞るのではなく、単に、連続する日本語文字をkakasiに渡せばそれで(1)も(2)も片付きそう。

ただ、これをやるとなると、例えばperlスクリプトで文字を処理しながら、かなりの回数kakasiを呼び出すことになりそう。部分的にgrepした感じからの推定で、今の日本全体でnameタグだけでも200万回ぐらい出てきそうなので、連続する日本語の回数はこれよりもちょっと多くなると思う。perlからsystem関数でkakasiを呼び出すのを数百万回繰り返すのは、多分かなりオーバーヘッドが大きいはず。ライブラリを使うしかないな。調べてみると、perl用にはText::Kakasiってのがあるらしい。

ここまでの調査は順調だったんだけど、結局、行き止まりにぶつかる。ほぼ開発が止まってるkakasiは公式バイナリに32bitしか存在しないことと、自分が使おうとしてるperlが64bitであることから、呼び出すのが無理っぽい。CPANからText::kakasiのコードを取得してVisual Studioでコンパイルしようとしたけど、64bit用にコンパイルしようとすると、最終的に64bitのkakasiのlibがなくてエラーになってしまう。

開発が止まってるkakasiではなくて、MeCabも試してみるか・・

2013/07/13

#1 今日のサイクリング

56kmくらい。八幡まで。行きはちょっと追い風だったので、河川敷の道を35km/h維持を目標に走ろうとしてみたけど、結局30km/hの維持がやっとだった。帰りは、折り返して向かい風になったので25km/hも出ない状況の中、38km/hで高速走行する二人組がいたので、後ろに付いて行こうとしたけど、30秒で諦めた。俺には無理。

2013/07/10

#1 今日のPLT

149k。異常値マークが消えてる。境界線ギリギリだけど。一時期40k〜80kを行き来してたことを思えば明らかに良化してるけど、1回ぐらい良かっただけでは完全に回復した、とはとても言えない。まだしばらくは様子見。


count: [an error occurred while processing this directive]