osm2pgsql で OSMデータを PostgreSQL に読み込んだ場合、独立したラインレコードになったと記憶する。 通常は一つのレコードとなるはずであるが、バス路線relationオブジェクトに誤りがある場合などでは、 同じ osm_id（負の値）をもつラインレコードが二つ以上になる。
バス路線リレーションに含まれるバス停についてはどのようなレコードが作られるかについては知らない。
一方、自作OSM地図では、これまで、バス路線relation id、路線番号、路線名のみ独立ファイルで管理している。 バス路線ラインレコードは作らず、個々の道路ラインレコードにバス路線relationオブジェクトの osm_id を 特殊タグとして持たせている。
これまでは別ファイルとしてきたバス路線ファイルは特殊なラインレコードとする案もある。 osm_id は relationオブジェクトの id として、route=bus、路線名(name)、路線番号(ref) をタグとする。 type=1 とするが、路線を表すポイントデータ列データは持たず、境界ボックスのみは持つ。
こうすれば、タイルのレンダリングでは、バス路線ラインレコードやバス停レコードを処理するとき、その そのバス路線 osm_id に相当するバス路線情報が レンダリングで使う同じ Block ファイルに必ず含まれる。
バス路線は細い青線を道路の中心に描画する。ここまでのタイル画像は保存対象である。
メニューでバス路線にチェックを入れた場合、 その時点で、地図画面に含まれているバス路線がバス路線表示候補となる。
レンダリングはタイル単位であるが、バス路線表示候補の抽出は画面単位となる。 バス路線管理データに境界ボックスを含んでおれば、該当路線の抽出は簡単になる。 しかし、境界ボックスを求める事前処理が必要となる。また、特に、高速道路バスの場合、 境界ボックスが広すぎる問題がある。
したがって、再描画によって、バス路線IDを求める方式とする。
まず、道路レコードにバス路線Idを含める(ハイズームのみ)。
含める前は japan-high12 は 2.94GB、japan-high8 は 351MBであった。
バス路線Idを含めると 2.95GB、351MB となった。
バス路線情報は少なくとも当面はこれまで通り、osm_id、路線名(name)、路線番号(ref)とする。 これまではCSV形式のテキストファイルとしてきたが、OSMバイナリレコードのサブセットとする。
length:4, osm_id:8, {key:2,val:2*}*
文字列は UTF-8形式ではなく UTF-16形式とする。 UTF-8形式では１バイト境界となるが、UTF-16形式では２バイト境界となる。 OSMバイナリレコードでの数値は２バイトの倍数としているため、文字列のバイト長も偶数にする方が 読み込み処理時間の短縮が図れる。
文字列のサイズ(バイト長)は、半角文字(ASCIIコード)が多い場合は UTF-8形式の方が短く、 日本語が多い場合は UTF-16形式の方が短い。実際の所は大差がなかったと記憶する。
CSV形式でも出力および入力プログラムともさほど難しくはないが、 将来的にはバス会社名(operatorタグ)などタグを追加する可能性もある。 このことを考えると、バス路線情報ファイルはOSMバイナリレコード形式に合わせておく方がプログラム は楽であろう。
kanto.osm での TSVファイル(UTF-8)のサイズは 579KB、OSMバイナリレコード形式(UTF-16)では 568KB で ほぼ同じとなった。 それぞれを ZIP圧縮すると、135KB および 151KB となり、約10％、TSVファイルの方が小さい。
OSMバイナリレコードにこだわらなければ、length は２バイト、osm_id は４バイトにできる。 しかし、バス路線情報ファイル(日本全体で 1MB)は、japan.zip 3.5GB に比べると微々たるものであるから、 length ４バイト、osm_id ８バイトに統一した方がプログラムが分かりやすい。