トップMy OpenStreetMap > OSMバイナリデータ縮小

OSMバイナリデータ縮小

はじめに

OSMデータはハイズームでのレンダリング(描画)に合わせた精度(極座標では小数点以下7桁)を持っている。 低・中ズームではこれほどの精度はいらない。接近したノードは間引いてよい。小さなポリゴンは実際上描画できない。 実際に描画する情報は限定的である。

道路、鉄道などラインデータの間引きは問題ないが、森林や水域などのポリゴンデータの間引きについては要注意である。 ポリゴンの境界線は自己交差のない単純な閉ループでなければならないが、間引きにより、自己交差が生まれることがある。

描画プログラムによっては、小さな自己交差があっても実用上問題ではないこともあるが、描画がおかしくなるケースがある。

一つの outer polygon の中に一つ以上の inner polygon があるマルチポリゴンの場合には、自己交差だけでなく、 ポリゴン同士の交差も問題になる。

先に作成したWindowsパソコン/タブレット用地図システム(C#)では、交差を回避して間引きを行った。 これは非常に難しい。ポリゴンは部分的な線分の繋がりで形成されている。この線分は複数のポリゴンで共有される。

ポリゴンを形成してからでないと交差があるかないか判定できない。自分の都合だけで共用部分を間引きと、 共用部分の描画が不自然なものになる。

このような事情から、交差が起きないように、また、共用部分での不都合が起きないように間引くのは複雑な処理になる。

このため、スマホ用の地図アプリでは、これまで、交差回避は行っていない。 C# にはマルチポリゴン対応の描画APIがあるが、Android Java にはないため、自作プログラムで描画している。 このプログラムでは、polygon同士の交差があっても問題はない。

一つのポリゴンの塗りつぶしは Android Javaのメソッドを使っている。1年以上になるが、特に、問題点は見つかっていない。 よくよく調べれば、どこかに描画がおかしいところがあるかも知れないが、日常では高ズーム地図を見ることが多く、 低・中ズームで多少の不具合があっても気づかないのが実情である。

不具合が見つかったときに、対応を検討する。

間引きプログラムの見直し

上記のように、現状では、描画上の不具合は見つかっていない。 パフォーマンス上の改善項目がある。

低ズームでは全ての inner polygon を無視している。また、中ズームでは面積の小さい inner polygon を無視している。 OSMバイナリレコードでは、マルチポリゴンの場合、ポリゴン毎のノード数をノード座標値列データの前に置いている[1]。 低・中ズームで inner polygon がなくなった場合、ノード数を 0 としている。

動作上は問題ないが、0 のところは省いて前に詰める方がよい。全て 0 の場合は、outer polygon のノード数だけとして、 レコードタイプは マルチポリゴンではなくポリゴンとする方がよい。

修正前と修正後の陸地ポリゴンとOSMデータの空間検索時間とレンダリング時間の実測結果を下に示す。 この修正は陸地ポリゴンには無関係であり、実行時間はほぼ一致している。

OSMデータの空間検索とレンダリング時間が僅かに(1~2%)短縮した。 空間検索時間の短縮の方がやや多いのも想定通りの結果である。 [修正前]

zoom       6     7     8     9    10    11    12    13    14    15    16    17    18    19    20    平均
陸検索    2.1   3.1   2.6   1.4   2.2   2.4   1.2   0.9    0     0     0     0     0     0     0    1.1ms 
陸描画   39.7  51.6  41.1  21.1  36.0  31.5  16.2  13.2    0     0     0     0     0     0     0   16.7ms 
OSM検索  30.0  56.0  25.7  36.4  48.5  32.5  50.0  92.2  94.1 119.3 118.5  89.0 109.3  88.1  87.1  71.8ms
OSM描画 162.9 132.8 229.2 140.0  99.3  18.1  12.6  19.8  12.2  11.8  11.1   4.6   4.9   2.6   1.6  57.6ms
[修正後]
      低ズーム   <----     中ズーム       --> <-----------------    高ズーム --------------->
zoom       6     7     8     9    10    11    12    13    14    15    16    17    18    19    20    平均
陸検索    2.6   2.8   3.2   1.5   2.2   2.5   1.0   0.9    0     0     0     0     0     0     0    1.1ms 
陸描画   39.6  55.0  43.6  21.0  35.6  25.6  15.7  13.2    0     0     0     0     0     0     0   16.6ms 
OSM検索  30.5  50.3  25.2  37.1  50.7  36.2  43.6  94.7  94.2 115.0 113.4  90.1 109.7  82.0  85.0  70.5ms
OSM描画 164.1 130.1 228.2 142.2  92.1  19.4  10.7  20.2  12.2  10.9   9.1   4.7   4.8   3.2   1.6  56.9ms

低、中、高ズームの範囲は多少変更できる。zoom 8 までを低ズーム、zoom 13までを中ズームとすれば、 zoom 8、zoom 13の実行時間は短縮する。低中ズームの間引きを強めればこの範囲の実行時間が短縮する。

しかし、これらの修正は地図の精度に関係するため、少なくとも当面は見送る。

このページの主題ではないが、ハイズームの空間検索時間が大きいのが最大の課題であろう。

現在は試みに zoom 6 と zoom 12 で分割している。地図アプリGISでは zoom 7 と zoom 13 で分割している。 やはりその方は、空間検索時間を短縮できるであろう。

リファレンス

[1] マイOSMバイナリレコード形式