これまで、Relationの扱いは osm2pgsql に準拠してきた。 OSMの xml形式のデータを 単純にコード化した場合、日本地図の場合、 ファイルサイズは node 136MB、way 3.42GB、relation 37.0MB、計3.57GBとなった。
relation は非常に小さい。
例えば、行政境界の場合、 多くは、多数の線分(way)がつながった一つの 単純な polygon である。しかし、A市の中に、B市の飛び地があると、 A市の polygon には穴(B市の飛び地)がある。外側を outer polygon、穴を inner polygon と呼ぶ。
飛び地や島しょ部があると、一つの行政区域には複数の outer polygon があり、それぞれの outer polygon の 中には 0個以上の inner polygon が含まれる。これを一般には multipolygon と呼んでいる。
一つの行政区域内(市区町村未満)の境界内でも multipolygon がある。例えば、横浜市泉区和泉町は三つの polygon で構成される。
OSM、osm2pgsql では、outer polygon が複数の場合、複数のレコード(point, line, polygon/multipolygon) に分ける。 従って、レンダリング上の multipolygon は outer polygon は一つである。
OSM xmlデータでは一つの relationオブジェクトから生まれた複数の polygon/multipolygon の osm_id は同じである。
つまり、osm_id はレコードを特定するユニークなものではないことに注意を要する。
バス路線リレーションは lineレコードに変換される。一般には、一つながりの lineレコードになるが、 つながりのない、二つ以上の区間が同じバス路線扱いであったり、マッパーのミスにより、繋がりのない複数の lineレコード に分かれることもある。
注目すべきは、Relationから生まれるレコードには長大なlineレコード(高速バス路線など)、 広大な polygon/multipolygon(本州、九州、都道府県境界など)になることである。
自作OSM地図では、本州、九州などはレンダリングしないため、レコードから除外している。
少なくとも、二つの区域が同じ境界線を共有する。例えば、横浜市と町田市のある境界線は 現在、東京都、町田市、神奈川県、横浜市、青葉区、奈良、奈良四丁目 の７つの relation で共有されている。
目下のところ、成瀬台や成瀬台二丁目などの境界線は登録されていないが、これらが登録されれば、 ９つの relation で共有されることになる。
パソコン処理で一時的に polygon/multipolygon を作成することは必要であるが、 地図アプリに取り込むのは元の一つの境界線レコードと relation定義としたい。
区別に色分けするときなどでは、現在、 画面に表示されない範囲の境界線レコードも必要となることへの対策がいるが、 境界線にそってその内側に区名などを描画することは容易である。
行政境界だけを変更して、その他のリレーションはこれまで通りとする案もあるが、 プログラムが複雑になるので、できれば、全てのリレーションを同じように扱いたい。
まだ、うまくいくという確信はないが、新しいバイナリレコード生成を試したい。
パソコンであれば、日本全体のOSMデータをメモリに読込めるが、スマホではそれを望めない。
パフォーマンスを気にしなければ、全レコードを一つまたは少数のファイルとして、ランダムアクセスする方法もある。 距離的に近いレコードがファイル上も近いところに置かれるように工夫することが望ましい。
市区町村(ここでの区は東京都23区)および大都市の区以上に限定すれば、日本全体を一つのファイルとすることも容易である。 だが、大字、小字レベルの境界線については、少なくとも将来的には大きなものとなる。 分割する場合、タイル別よりも都道府県別の方が分かりやすいであろう。
都道府県をまたぐタイルのレンダリングでは当然複数のファイルをメモリに読込む必要がある。