map3 では大きな変更を行わなかったが、今回は OSMデータの自作パースを SAXParser に変えて、 パフォーマンス上、問題ないことを確認した。
OSMバイナリデータ構造についても原点に返り、抜本的なシンプル化を図りたい。
レンダリングではメモリ使用量やパフォーマンスを考えて、メッシュ分割したファイルをそっくり そのままメモリにキャッシュする方式を採ってきたが、メモリ上ではレコード単位で管理する方法を試みたい。 大幅なメモリ使用量の増加がなければ、柔軟性が高まり、空間検索のシンプル化とパフォーマンス向上も期待できる。
拙速ではなく、じっくり時間をかけて、スリムでハイパフォーマンスなアプリの開発を目指したい。
レンダリング上のバイナリレコード形式は次のような単純な構造とする。
key、val は OSMタグだけでなく、レンダリングに関わるすべてのデータに適用する。 出現順序は自由とする。
key は予め enum で決めた値であるが、val は key 毎に決められた様々な形式となる。 OSMタグの場合には、enum で決めたコードになるもの、整数、浮動小数点、文字列になるものがある。
文字列についてはこれまで辞書をつかって、コード化していたが、そのまま、utf-16コードの文字列とする。
レンダリングを管理するデータについては、key だけで val を持たないもの、ひとつの値を val とするもの、 および、複数の値をもつものからなる。
num_kvs, {key, val}*, lon, lat ----- Point
num_kvs, {key, val}*, num_nds, {lon, lat}* ----- Line/Polygon
num_kvs, {key, val}*, {num_nds}*, {lon, lat}* ----- Multipolygon
メモリ上の OSMオブジェクトは空間検索用の境界ボックスを持つ。 この境界ボックスは {lon, lat}* から算出するが、ノード数(num_nds)が大きい場合は、 予め算出して、バイナリレコードに含めるが、小さい場合は、 ファイル読み込み時に算出する方が、レコードサイズが小さくなることから、総合的には有利になる可能性がある。
Lineレコードは論理的には一つであっても、レンダリング上は細分されていても問題はない。 このため、バウンダリーボックスは小さくできるため、同じレコードを多数のメッシュに置く必要はない。
Polygon/Multipolygonは領域の塗りつぶしを行うためには容易に分割できない。 陸地ポリゴンについては予め専用ソフトで細かく分割したデータを使う。 大域ポリゴンについては地域によっては人手で分割されている。 分割されていない場合は、多数のメッシュに同じレコードを置くことになり、また、レンダリングにも時間がかかる。
都道府県境界や市区町村境界も領域を塗りつぶそうとすれば、大きなポリゴンとなるものが多いため、厄介である。 しかし、境界線の内側に都道府県名、市区町村名を描画するだけの場合には、 レンダリングに使うデータにポリゴンを含む必要はない。バイナリレコード作成処理では、一旦、閉ループを形成する必要はあるが、 境界線の内側が分かれば、それを、個々の境界線データに書き込んでおくだけでよい。 個々の境界線レコードのバウンダリーボックスは小さいので、多数のメッシュに重複しておく必要はないし、レンダリング時間も短い。
要するに、パフォーマンス向上のためには、大きなポリゴン/マルチポリゴンを工夫して減らすことが必要である。