Androidは一つのアプリの最大メモリ使用量の制限が厳しい。そこで、レンダリングは地図表示アプリから分離する。 OSMバイナリレコードのキャッシュ(Blockキャッシュ)は必要であるが、地図表示は行わず、 レンダリング結果をファイルに書き込むだけであるから、ビットマップタイル画像のキャッシュはいらない。
バス路線図とか特定の地物だけの描画をどうするかが問題となる。レンダリング専用アプリによるサポートが望まれる。
二つのアプリが動くことから電池使用量は増えるであろう。しかし、レンダリングアプリはスリープ状態が多いだろう。 電池使用量の大半は多分GPSであろうから、極端には増えないであろう。
レンダリング側をHTTPサーバーとした場合はファイル共有はない。タイル画像ファイルの保存は地図表示アプリで行う場合、 国土地理院地図と同じ扱いになる。
バス路線図については、ボス路線画像データだけを受け取り、地図表示アプリで重ね書きをする。 適宜、地図表示アプリから現在の zoom、地図中心座標 x、y をサーバーに送り、先行レンダリングを行う。
先行レンダリングのためには、保存ファイルを知る必要があり、また、保存自体をサーバーで行うべきである。 国土地理院地図についても先行読み込みのためには、保存ファイルの管理はサーバーに任せた方がいい。 その場合は、地図表示アプリには保存ファイルがないため、タイル画像ファイルの読み込みは常にサーバーを介すことになるため、 通信負荷は増える。
先行レンダリングを地図表示アプリで管理する場合には、保存ファイル管理は地図表示アプリとなり、通信負荷は小さくなる。
ダウンロードやレンダリング中のファイル名は一時的ファイル名として、完了時に正式のファイル名に変更する。
地図表示アプリからレンダリングアプリへのリクエストは broadcast を使う。 レンダリングアプリから地図表示アプリへのレスポンスも broadcast を使う。リクエストを出してレスポンスが帰るまで待つのではなく、一部のリクエストは、zoom 変更などにより、無視されることもある。 レスポンスはタイル画像ファイルが準備できたことを通知するだけであり、ファイル読み込みは地図表示アプリが行う。 先行レンダリング/ダウンロードの場合、実際の読み込みは起きないケースも多くなる。先行リクエストより即時リクエストの方が優先 される。
タイルの有効期間、保存期間は低ズームほど長くする。一旦は古いタイル画像を表示して、更新リクエストを出す。 更新されたとき、書き換える。
効果は精々２，３％に過ぎないので、プログラムを全面的に見直すときに検討する。
man_made=bridge の layer は不適切なことが多い。該当する道路や鉄道が見つかった場合、補正が可能である。
man_made=bridgeは概ね細長い長方形である。 中心線を算出して、その中心線と近接する道路または鉄道が一つであれば、それにかかる橋げたと言える。
タイルのレンダリング時に調べる場合、道路、鉄道の数は限られているが、それなりに時間がかかる。
予め、パソコンで補正する場合、ByteEncoderで行えば、道路、鉄道の数が抑えられる。 しかし、レンダリング時に比べれば桁違いに多い。また、レンダリング時ではXY平面座標であるが、 ByteEncoderでは極座標である。極座標のまま、橋げたがどの道路、鉄道にかかるものか見つけることができる としても、XY平面座標に比べれば分かりずらい。
man_made=bridge の数は少ないので、まずは、空間検索の後処理としてみるのが楽であろう。 highwayまたはrailwayにはbridge=yesがあるのが普通であるから、角度計算をするまでもなく、 交差判定だけでも、該当道路または鉄道が見つかるケースが多いであろう。
タイルをまたぐ文字列の描画がごくまれに途切れることがある。多分、千分の一か万分の一に過ぎない。 よくよく気にしないと見つからない程度である。
タイル毎の判断ではこの途切れを完璧になくすことはおそらく不可能と思われる。 文字とアイコンの描画を例えば西から東、北から南へ規則正しく行い、 描画の可否を事前決定すれば、完璧を期すことができる。 道路名や境界線上に繰り返し描く市区町村名などは面倒である。 長い道路名があるため、複数タイルにまたがることを禁止することはできない。
事前決定は容易ではないが、もし、これができれば、空間検索でのマージンを減らすことができるため、 パフォーマンス向上が期待できる。
現在のOSMバイナリレコード形式は次のようにシンプルな形をしている。ただし、 {key,val}* にはOSMタグ以外の情報も含むため、その中身はやや複雑といえる。 osm_id もここに含めることができる。レンダリングには不要なため、今は、入れていない。 デバッグでは osm_id がある方が助かる。
length の次に置くことも考えられる。陸地ポリゴンには osm_id はない。osm_id の有無を head上の１ビット で示せば、LandParserは変更が要らない。可変長バイトコードでは平均的には約４バイトの追加となる。 {key,val} に含める場合は約６バイトの追加となる。
head, length, tags_length, [num_nodes], {lon,lat}*, {key,val}* ... point/line/polygon
head, length, tags_length, num_polys, {num_nodes}*, {lon,lat}*, {key,val}* ... multipolygon
head:
第0,1bit(0x03) 0: point、 1: line、 2: polygon、 3: multipolygon
line と polygon の区別は簡単ではない。閉ループ(先頭ノードと最終ノードが一致する)でなければ、 line であることは単純明快である。また、閉ループが polygon の必要条件であることも確かである。
しかし、例えば、boundary は、通常、閉ループであっても line として扱う。 また、highway=pedestrian や highway=service は閉ループのときは area=yes があれば polygon、なければ line となる。
自作OSMではタグ type=multipolygon であっても、 実体として inner polygon が存在せず、outer polygon だけとなったときは、OSMバイナリレコード上の type は polygon としている。標準OSM地図では multipolygon 扱いかも知れない。
例えば、学校敷地 amunity=school は polygon であるが、塀があるため、 このレコードの barrier=wall (line) が同居しているケースがある。
OSMバイナリレコード上の type は polygon が複数のとき type=3、閉ループのとき type=2、そうでないとき type=1、 点データ(num_nodesはない、lon、latは一つ)のとき type=0 という形式による値としている。
バス路線relationの場合、relationのid(osm_id)、路線番号(refタグ)、路線名(nameタグ)は一覧表として 独立ファイルにしている。バス路線relationにはバス停と路線が含まれているが、該当する、バス停(pointレコード)、 道路(lineレコード)のタグ部にrelationのid(osm_id)を振り分けている。
境界線は二つ以上のrelationで共有している。これをrelation毎のラインレコードにしている。 境界線レコードは一つで、これに relation id列を持たせるのが最も効率的である。 逆方向はidを負の値にすればよい。
しかし、境界線描画負荷はそれほど高いわけではないので、効果は小さい。
ズームイン/ズームアウトはピンチイン/ピンチアウトで操作するか、ボタン操作としているが、 ボタン操作の反応が悪い、メニュー、ボタンとも全く反応しなくなることもある。 そんなときでも、ピンチイン/ピンチアウトは効くことが多い。