昨日ので変換はできるようになったんだけど、出来上がった地図データのファイルサイズが小さい。等高線ありzipデータ(7/7)比で675MBが635MBに減少してる。タイル単位のデータは1〜131まで抜けなく生成できてそうだし。mkgmap r3676→r3683の改善内容に関係してるのか？一旦このまま公開することにする。
和歌山北部の橋本→貴志を39km。自宅側も合わせると57km。そんなに遠くないのに2回も輪行してしまった。たま駅長以外の観光情報は何も知らないで行ったんだけど、ほぼ全区間がサイクリングロードだったのと、紀の川越しに見る南の山がなかなかいい景色だったので満足した。満喫してたので和歌山駅からの特急を予定より1時間遅らせることとなった。
サイクリングロードはまだ改善の余地があり、ところどころにしか目印のブルーラインが引かれてないので、いつの間にかサイクリングロードから外れてることが多々あった。
7/7の時は変換できてたのに、7/22時点だとsplitterの分割位置決定中に下記エラーが発生。
Best solution until now: 141 tile(s). The smallest node count is 702312 (70 %), the worst aspect ratio is near 3.97, elapsed search time: 177 s searching for split with min-nodes 709420, learned 3093523 good partial solutions Elapsed time: 4m 6s Memory: Current 1156MB (964MB used, 192MB free) Max 1156MB Elapsed time: 6m 8s Memory: Current 1156MB (991MB used, 165MB free) Max 1156MB Elapsed time: 8m 10s Memory: Current 1156MB (1008MB used, 148MB free) Max 1156MB Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded at uk.me.parabola.splitter.Tile.splitHoriz(Tile.java:287) at uk.me.parabola.splitter.SplittableDensityArea.findSolution(SplittableDensityArea.java:673)
3ヶ月前に変換した時のログだと、メモリは400MB程度しか使わず、時間も127秒で完了してたみたい。splitterのバージョンは今回と同じr427なので、違いはデータ側。メモリ割り当てを2Gにしてみたけど、45分かかっても処理が終わらない。何かの臨界点を超えて急に遅くなったんだろうか。--resolution=12 オプションを追加すると429秒で終わるようになった（デフォルトは13）。でも従来より5分長くなってるのは耐えられないので、--split-file=areas.list も追加し、131分割された今回の分割位置を今後は流用することにする。
箕面まではいつものコース、その後珍しく勝尾寺から茨木に抜けてみた。50km。明らかにできたばかりで、しかもOSMにも描かれてない道を発見したので寄り道してみると、彩都の新興住宅地に抜けた。見渡す限りの新しい住宅（と新しい中学校）で羨ましさを感じた。