概ね前地図アプリGISと同じ方法による実装は問題なかった（前ページ）。 この方法ではタイルキャッシュを一旦空にしてタイル画像データを書き換えている。 スクロールでは路線データの描画は起きない。
タイル地図画像データとは別にビットマップを用意して、バス路線データをそこに書き込み重ね合わせ描画を行う方法もある。 地図データのレンダリングは起きないため、選択路線の変更などがスムースになる。 メモリ使用量が増えるが、フルカラーでは 256KB/タイルであるから、96タイルキャッシュの場合、24MBの増加となる。
フルカラーは要らないため、もし 8ビット/画素で済ますことができるならば、6MB増で済む。
中間的な画像データは使わず、スマホ画面のCanvas に直接上書きする方法もある。 この場合、スクロール毎に再描画となるため、路線が多いと、描画時間がかかり、スクロールが重くなる。
現在は路線ごとに描画している。１回の描画で済むようにすれば、レスポンスの問題は解消する可能性が高い。
過去のGPS軌跡の描画も行いたい。この場合も、複数回通った道の描画を１回で済ませたいが、バス路線と異なり、 同じ道であることの判定が難しい。
バス路線については、現在はバス路線毎に独立したレコードとしているが、これをやめ、道路レコードに、そこを通る バス路線のリレーション ID 列を拡張データとして持てばよい。 バス路線リレーションの情報(nameタグ,refタグなど)は、日本全体で 10MB 程度で済む OSMバイナリレコードとは独立した専用ファイルとしてもよい。 あるいは、路線全体の境界ボックスを持つポリゴンレコードとすした方がプログラム的には楽かも知れない。 空間検索で、バス路線情報を抽出できる。 座標値列データは使わないが、OSMバイナリレコードとして形式を合わせた方が無難であろう。
日本のバス停は約40万という数字をどこかで見た。現在、OSMデータに登録されているバス路線リレーション数は 世界全体で約26万である。
バス路線管理データは osm_id、nameタグ、refタグ等である。osm_id は規格では 8バイトであるが、実際上は 4バイトでよい。 nameタグ、refタグはコード化しているため、それぞれ４バイトで表せる。 その他の情報が加わったとしても、20バイトで収まるであろう。 路線（リレーション）数の設計値を 10万としても所要メモリは 2MB に過ぎない。 従って、日本全体のバス路線情報をメモリに常駐させるのは容易である。
個々の way レコードに拡張データとして、バス路線リレーションの id 列を持たせる。 特殊なタグとする案もあるが、タグの後ろに独立した拡張データとする方がプログラムは分かりやすいであろう。 このような拡張データがあるかないかはヘッダ(レコード先頭)のフラグで示す。
OSMParser.java は既に少々大きくなりすぎている。これを機会にいくつかに分割すべきであろう。
因みに 地図アプリ Map で最も大きいプログラムは OSM.java であるが 700行に満たない。 一方、OSMParser.java は 2024行に達している。
中・低ズーム用データ作成(Simplify 約560行)、リレーション処理（約370行）はそれぞれ別プログラムとする。
HashMap<Long,long[]> mapWays を HashMap<Long,Way> mapWays に変える。
しかし、残ったプログラムは計算上 約1,100行である。もう一つ分離するものを探して、 最大は 700～800行以下に抑えたい。
OSMParser は思ったより大きくなりすぎている。抜本的な見直しで、スリム化が図れればそれが一番望ましい。
class Way {
long[] nodes;
List<Long> listBusRoutes; // bus=routeリレーションの osm_id のリスト
}