通常地図アプリは、高ズームで使うことが多い。 この場合、タイルのレンダリングに使うバイナリレコードは比較的すくないため、パフォーマンス不足は感じない。
低ズームでは全体のファイルサイズが小さいので、メモリに常駐可能である。 中ズームで日本地図を広範囲に見ようとするときが、現状では一番レスポンスが悪い。 タイルのレンダリングに使用するレコードが10万、20万になると、レンダリング処理自体に時間がかかるため、 レコード数を減らす対策も必要となるが、ファイルの見込み時間が占める比重も大きいと思われる。
世界全体の低ズーム用ファイルは14.2MB、高ズーム用ファイルは 535MBである。
高ズーム用を zoom 5 で分割すると、2.16GB となる。 約４倍の大きさになるのは、重複があるためである。低ズーム用ファイルではポリゴンの分割はないが、 高ズーム用ではポリゴンは分割されているが、それでも巨大なポリゴンが存在するため、 平均的にひとつのレコードが４ブロックに置かれる。
しかし、日本地図のレンダリングに使うブロックファイルはごくわずかであるため、大きな支障はない。
あえて言えば、高ズーム用ファイルのポリゴンのノードを間引いて、中ズーム用ファイルを作った方が 中ズームでのパフォーマンスが向上するであろう。
改めて、ブロック分割においてどの程度の重複が起きているかを調べた。
驚くほど重複が少ない。 以前はもっと重複があったと思う。 広域森林は分割が進んだのかも知れない。 都道府県境界などは分割できないはずなので、プログラムにバグが残っているのかもしれない。 今のところ、地図を見ても不審な点はない。
c:\map>java -Dfile.encoding=UTF-8 -Xmx5g -classpath ./class OSMUtil -devide 3 3 japan-low レコード数=256781, 最大レコード長=15418, 平均レコード長=40.6, 平均タグ数=1.2, 平均タグ長=4.9B, 最大タグ長=316B レコード数 = 256906/256780(1.00), ファイルサイズ = 11358001/11325490(1.00) 実行時間: 0.07分 c:\map>java -Dfile.encoding=UTF-8 -Xmx5g -classpath ./class OSMUtil -devide 7 7 japan-mid レコード数=2835121, 最大レコード長=94202, 平均レコード長=85.8, 平均タグ数=1.0, 平均タグ長=4.2B, 最大タグ長=327B レコード数 = 2840899/2835120(1.00), ファイルサイズ = 279667400/268269513(1.04) 実行時間: 1.28分 c:\map>java -Dfile.encoding=UTF-8 -Xmx5g -classpath ./class OSMUtil -devide 12 7 japan-high レコード数=34256113, 最大レコード長=442383, 平均レコード長=78.9, 平均タグ数=1.3, 平均タグ長=7.7B, 最大タグ長=1824B レコード数 = 34715142/34256112(1.01), ファイルサイズ = 3229590013/3047884547(1.06) 実行時間: 13.88分
レコード数を異なる変数でカウントしている。なぜか１だけ異なる。原因はまだ見つからない。