現在、マイOSM地図は標準OSMと同じ思うが、陸地だけをシェープファイルで描画している。
データベース osm はレコード数では建物が全体の半分以上を占める。 planet_osm_polygon のサイズ(日本)は 3,342MB であるが、 建物だけのテーブルが 2,531MBになる。
zoom 15のアーカイブ更新時間は約100分であるが、建物だけの描画で50分を超える。 アーカイブ更新時間には png圧縮データ作成時間(20%前後)が含まれるため、 建物レンダリング時間が全体の半分というわけではない。
色々突き止めると、タイル地図のレンダリングでは、 PostgreSQL+PostGISのオーバヘッドが非常に大きいことが分かってきた。
建物の描画はシンプルで、量が大きい。 シェープファイルはファイルベースでPostgreSQLは関与しない。 もし、シェープファイルによる描画が高速ならば、 陸地、建物の描画はシェープファイルを使い、 その他の描画にPostgreSQL+PostGISを使うように変更したい。
ごく一部の建物に限り、後からPostgreSQL+PostGISで描画するが、それは率では微々たるものである。
そこでまず、シェープファイルによる陸地、建物の描画時間を確認する。
陸地描画の Layer および Style は下のように極めてシンプルである。
<Style name="coast-poly">
<Rule>
&min_zoom8;
<PolygonSymbolizer fill="#f3f0ea"/>
</Rule>
</Style>
<Layer name="coast-poly" status="on" srs="&srs900913;">
<StyleName>coast-poly</StyleName>
<Datasource>
<Parameter name="type">shape</Parameter>
<Parameter name="file">&world_boundaries;/land_polygons</Parameter>
</Datasource>
</Layer>
pgsql2shp.exe か ogr2ogr.exe を使ってみよう[1]。
下記[1]では、最後の例がテスト的に使うには一番良さそうなので、 まずは ogr2ogr を使ってみよう。 本格的に使うときは imposm で建物だけをデータベースにインポートする。
pgsql2shp -f c:\temp\test.shp -u postgres yourdatabase yourtable -- localhost, port 5432 を前提としている ogr2ogr -t_srs EPSG:4326 -f "ESRI Shapefile" c:\temp\test.shp \ PG:"host=localhost dbname=yourdatabase user=postgres password=***" yourtablename ogr2ogr -t_srs EPSG:4326 -f "ESRI Shapefile" c:\temp\test.shp \ PG:"host=localhost dbname=yourdatabase user=postgres password=***" \ -sql "select * from check_prediction"
まず、ogr2ogr をインストールした。
hatada@dell:/media/sf_gis$ ogr2ogr --version Command 'ogr2ogr' not found, but can be installed with: sudo apt install gdal-bin hatada@dell:/media/sf_gis$ sudo apt install gdal-bin
まず、つぎのコマンド実行した。4326 は 3857 に変えるべきかもしれない。
ogr2ogr -t_srs EPSG:4326 -f "ESRI Shapefile" /media/sf_gisdata/mapnik/shp/buildings.shp \ PG:"host=localhost dbname=osm user=postgres password=postgres" \ -sql "select * from planet_osm_polygon where building is not null"
Warningが出たが、カラムは way, building だけでいいと思うので、このままとする。
Warning 6: Normalized/laundered field name: 'admin_level' to 'admin_leve' Warning 6: Normalized/laundered field name: 'intermittent' to 'intermitte' Warning 6: Normalized/laundered field name: 'information' to 'informatio' Warning 6: Normalized/laundered field name: 'construction' to 'constructi' Warning 1: One or several characters couldn't be converted correctly from UTF-8 to ISO-8859-1. This warning will not be emitted anymore.
思ったよりファイルサイズが大きい。次のWarningが出た。共有フォルダではなく、 Ubuntuに割り当てた領域に置いた方がよさそうだ。
Warning 1: 2GB file size limit reached for /media/sf_gisdata/mapnik/shp/buildings.dbf. Going on, but might cause compatibility issues with third party software
ここで打ち切り、次のように変更した。
ogr2ogr -t_srs EPSG:3857 -f "ESRI Shapefile" ./shp/buildings.shp \ PG:"host=localhost dbname=osm user=postgres password=postgres" \ -sql "select building, way from planet_osm_polygon where building is not null"
つぎのWarningが出た。多分,buildingカラムに不正文字があったのだろう。
Warning 1: One or several characters couldn't be converted correctly from UTF-8 to ISO-8859-1. This warning will not be emitted anymore.
次の Warning は出た。
Warning 1: 2GB file size limit reached for shp/buildings.shp. Going on, but might cause compatibility issues with third party software
buildings.shp, buildings.shx は 2.2GB, 111MB となった。実行時間は 12分であった。
land_polygonsに倣って
<Style name="buildings">
<Rule>
&min_zoom14;
<PolygonSymbolizer fill="#e0d7d0"/>
</Rule>
</Style>
<Layer name="buildings" status="on" srs="&srs900913;">
<StyleName>buildings</StyleName>
<Datasource>
<Parameter name="type">shape</Parameter>
<Parameter name="file">/home/hatada/shp/buildings</Parameter>
</Datasource>
</Layer>
正常に描画できることは確認した。I/O負荷は数％であるが、描画に時間がかかりすぎる。 一時間かけても沖縄と九州の一部が描画できたに過ぎない。 規格では *.shp ファイルの上限は 2GB になっている。
レコード数が多く、空間インデックスではないのが時間がかかる原因であろう。 land_polygons.shx は 5MB強である。buildings.shx はその20倍のサイズである。
念のため、ファイルサイズを縮小するためにノードを間引いてみる。 shpファイルは 1.9GBとなり規格内に収まった。
ogr2ogr -t_srs EPSG:3857 -f "ESRI Shapefile" ./shp/buildings.shp \ PG:"host=localhost dbname=osm user=postgres password=postgres" \ -sql "select building, ST_SimplifyPreserveTopology(way, 10.0) as way from planet_osm_polygon where building is not null"
夜中に実行してみたが、385分もかかっていた。
前回の海岸線更新から１年以上たっている。何か、インデックスらしきものを後から作ったことを 思い出した。以前のホームページに「海岸線データの更新手順」もあった。
これまでは Windowsソフトを使ってきたが、さいわい、Mapnik を Ubuntu にインストールしたとき、 shapeindex をインストールされたようだ。 次のコマンドで buildings.index 167MB が作成できた。
shapeindex buildings.shp
これでOK、後は何もしなくても、空間インデックスが使用されるようになり、描画は格段に速くなった。
PostgreSQL+PostGIS で建物だけを描画したときよりいくらか速いようだ。 zoom 15のアーカイブ更新時間は42分となった。 これには、 png圧縮データ作成時間などが含まれているため、 建物のレンダリング時間は30分程度と推測される。
今回のテストでは、建物のシェープファイルを osm2pgsql でインポートしたデータベースから作成したが、 imposmなど別の方法で作成する。osm2pgsql ではタグ変換オプションでベースとなる建物レコードは インポートしない。データベースはその分軽量になり、建物の描画を除いたとき、 現在の100分が70分で済むだろうか。無理なような気がする。レコード数は半分以下になるのであるが。
zoom 19の建物描画時間も実測しておく。全体では 42.5分であったが、建物シェープファイルでは 27分となった。思ったより時間がかかる。
zoom 15と異なり、日本全土の建物ではなく、一部の地域の建物だけの描画である。
念のため、陸地だけの描画時間も調べておく。こちらも予想外に大きく、 zoom 15, 19 が 39分,19分 となった。png圧縮時間も含まれる。こんなに時間がかかるとは思っていなかった。
以前のページには、zoom 8, 9 の描画時間は 0.03時間、0.02時間と書いている。 zoom 8〜11 でも同じようにシェープファイルで陸地を描画している。この時は描画時間は確かに短い。 zoom が大きくなるほど、シェープファイルの描画時間が大きくなるのだろうか？ どうにも納得がいかない。
陸地シェープファイルを共有フォルダ(USBメモリ)に置いているのが良くないのかも知れない。 Ubuntu上にコピーした。しかし、ディスク負荷は数％にすぎないので、大差がないかもしれない。 今度は zoom 15, 19 が 38分, 19分 となった。前回は更新中にシェープファイルを共有フォルダから ubuntu領域にコピーしたので、この負荷が差の１分の主な原因だろう。あるいはMapnikの処理時間が大きいのかも 知れない。 陸地はレコード数は少ないが、広大な広さから、空間インデックスの探索時間がかかるのかも知れない。
今度は、陸地の描画はやめて、建物の描画のみとしてみる。 zoom 15, 19 が 12分, 14分 となった。zoom 19の方がタイル数は少ないが、描画する面積では zoom 15 より 大きい。
これで、陸地より建物の描画時間の方が小さいことが分かった。png圧縮時間が含まれる。 正確な数値は分からないが、多分、２分前後であろう。 そう考えると、zoom 15の100分中、建物のレンダリング時間は10分程度すむ。しかし、 zoom 19 では 43分中の 12分ということになるが、それほど比重が高いとも思えない。 何か、大きな見落としがあるのだろうか？
建物の描画をシェープファイルに移せば、PostgreSQL+PostGIS経由の描画が軽くなり、 全体のアーカイブ更新時間が短縮できる可能性が見えてきた。 しかし、効果は限定的であろう。
陸地の描画時間が予想外に大きいことが分かった。 zoom 15では現在の 100分中、30分前後が陸地の描画時間かも知れない。 zoom 19 では現在の 43分中、15分前後が陸地の描画時間かも知れない。
あまりに大きく、にわかには信じがたい値である。どこかに大きな見落としがあるかも知れない。 この通りだとしても、初めて気づいたことでもあり、この時間の短縮が可能かどうかも分からない。