スキップしてメイン コンテンツに移動

GeoPackage で ポータブル OSM

FOSS4G Advent Calendar 2016 14 日目の記事です!

Advent Calendar でしか更新されないブログへようこそ。
NPO法人 オープンコンシェルジュ とか OSGeo.JP の松浦です。

みなさんは GIS データをどんな形式で保存していますか?
私のようなリッチメンは家計簿兼暖房用に購入した Oracle Exadata に Oracle Locator のSDO_Geometry と SDO_Georaster で管理していますが(真っ赤なウソ)、大抵の場合は Shapefile じゃないでしょうか。

Shapefile は米国Esri 社が開発した空間データを格納するフォーマットで、仕様が公開されていることもあり多くの GIS ソフトウェアで使用可能です。
ただ、ハードウェア、ソフトウェアの急速な進化に伴って、いろいろ不都合が生じてきました。

Shapefile の闇


1. なんかファイルいっぱい必要


「データ添付しました。ご査収ください。」っていうメールが来て確認したら、満を持して登場する【データ.shp】。「どうも、一人できました。てへっ」つって。
開けねーよ。ご査収できねぇよ。

なんて経験、ありますよね?
Shapefile は最低でも .shp, .dbf, .shx という 3 つのファイルが必要です。
必須以外にも、.prj、.sbn、.shp.xml、.cpg などなどいろいろ構成員がいらっさいます。これら合わせて 1 つの Shapefile です。

2. なんか、もう文字コードがつらい


最近はソフトウェアが頑張るのでましですが、たいてい CP932 の Shapefile は一発目化ける。

3. 容量制限


今時 2 GB って・・・
まぁ 2 GB のベクターデータって結構でかいんですがね。
とはいっても、TB を超えるディスクが 1, 2 万で買える時代に 2 GB はきつい。

4. 属性名足りない、短いよ...


10 バイトまで (UTF-8 だと 3 文字とか・・・)。なので「都道府県」という属性名にしたくても「都道府」になってしまうという・・・


とまぁきりがないのですが、決して Shapefile を陥れたいわけでもディスりたいわけでもないんです。
このフォーマットが GIS の普及やソフトウェアのデータ相互運用性の確保に大きく貢献をしたことは言うまでもありません。

そう、ただ次の時代がやってきただけです。

GeoPackage を使おう


じゃぁ、ポスト Shapefile はなんでしょう。
個人的には、PostgreSQL にぶっこんどけばよくない?とか思うけど。おらの捕まえたGISデータを交換とかする友達いねーし。

ファイル形式で、追加ソフトやライブラリがいらなくて、大容量に対応していて仕様がオープンなフォーマットって考えたとき、脳内には GeoPackage しか残りませんでした。
ほかにあるのかもしれないけど。

GeoPackage はベクターデータおよびタイル化されたラスターデータを格納できますが、その実態は SQLite データベースです。空間インデックス(R-Tree)にも対応しています。

単一ファイル (.gpkg) で構成されますが、データベースですので 1 つの GeoPackage 内に複数のスキーマの異なるベクターデータやタイル化されたラスターデータを格納できます。この点は Shapefile と大きく異なります。

また、OGC (Open Geospatial Consortium) によって定義されており、すでに GDAL/OGR や QGIS や ArcGIS などの地理空間データを扱うソフトウェアが対応しています。

詳しくはこちら(私が言っていることと違うことが書いてあったら、こちらのサイトのほうを信じてください)。

GeoPackage に Planet.osm をぶっこむ

はい。やっと本題。
結局でかいデータを高パフォーマンスで扱えるかなんてやってみなきゃわからんのだよ。
ってことで恒例の Planet.osm 登場。

Planet.osm は Open Street Map の地図描画用の元データで、全世界の道路や建物、POI、行政界、国境などが含まれます。
OSM より提供されており Protocol Buffers 形式で 35 GB 強あります。通常は全球データを落として 1 ファイルにするなんてクレイジーなことはせず、PostgreSQL などの RDBMS に展開して使用します。たぶん。
ちなみに PostgreSQL に展開すると、ぼんやりした記憶ですがインデックスこみこみで 200 GB 前後になったと思います。ポリゴンデータは 2 億レコードを超え、ラインでも軽く 1 億レコード越えです。

さて、冒頭で Exadata の話をしましたが、現実世界の私の家にはおそらく Exadata の筐体より小さな冷蔵庫ぐらいしかないので、データ作成はクラウドを活用することにします。
AWS? え? あれもえもえしないので今回は Conoha でいきます。
Conoha な理由は、root ディスク、データディスクすべてSSDで、時間で課金形式だけどデータ転送量の課金がなく、最大コストを見積もりやすいからです。庶民の味方。(GMOさん、宣伝したからなんかちょうだい)

今回はメモリ 4GB の Arch Linux のインスタンスに 500 GB の追加 SSD をつけてデータ作成を実施しました。

結論から言うと、ほぼ弊害なさくっと Planet.osm から、ポリゴン、ライン、ポイント を含んだ GeoPackage を作成することができました。

以下は簡単な手順と、それぞれにかかった時間です。

  1. GDAL/OGR の導入
    以下コマンドを実行

    # pacman -S gdal

    処理時間: 1分
  2. Planet.osm のダウンロード
    今回はお隣、台湾のサーバーからダウンロード。
    Planet の情報は http://wiki.openstreetmap.org/wiki/Planet.osm 参照。

    nohup /usr/bin/time curl -O http://free.nchc.org.tw/osm.planet/pbf/planet-161205.osm.pbf > download_planet.log 2>&1 &
    処理時間: 53 分
  3. ogr2ogr で変換

    GDAL/OGR の  ogr2ogr で変換。

    nohup /usr/bin/time ogr2ogr --config CPL_TMPDIR /data/osmtest/tmp -progress -f GPKG planet_osm.gpkg planet-161205.osm.pbf > ogr2ogr.log 2>&1 &

    処理時間: 22 時間 30 分
    GeoPackage サイズ: 170 GB

    Conoha 利用料: (なんだかんだ 3 日間くらいあーだこーだして) 1000円弱


    ポイントは --config CPL_TMPDIR オプションで、処理の一時ファイルの出力先に空き領域に余裕のあるディレクトリを指定すること。
    最初の数回はここでは待ってディスク不足で処理が止まりました。

    あと、メモリも 4GB ぐらいはあったほうがいいみたい。最初 512 MB のインスタンスに swap 積んでやったんですが out of memory でお亡くなりになりました。

    ちなみに上記処理は空間インデックスの作成も含みます。その他のカラムに対するインデックスは張られていません。
  4. gpkg のダウンロード

    これが予想外に時間がかかった・・・
    nginx をたてて、HTTPでダウンロードしましたが、4時間以上かかりましたよ・・・。そしてこの時間ですよ。
予想外に処理時間が短く済みましたし、容量も 170 GB という現実的な数字に収まりました(もはや麻痺)。

あとはこれが現実的な速度で使用できるかということです。

QGIS で描画してみる

QGIS の出番です。
意気揚々と「ベクタレイヤの追加」ボタンから作成した planet_osm.gpkg を追加したら・・・ 15分以上沈黙・・・ その後レイヤ選択のウィンドウが出てきてデータ追加できました。
ただ、毎回これじゃぁ・・・ ねぇ?

これ、レイヤのプロパティ用にすべてのレイヤに対して select count(*) 的なクエリを流してフィーチャ数を毎回カウントしているからだと思われます。

なんとかこのプロセスを端折る方法はないか10秒程度悩んだんですが、1個だけありました。

VRT (http://www.gdal.org/drv_vrt.html)

VRTは仮想的なレイヤを定義する XML 形式のデータフォーマットです。通常は複数のデータをあたかも1つのデータとして扱うためなどに使われます。
VRTの定義の中にメタ情報的な要素もあり、その中に FeatureCount という要素があったことを思い出しました。神がかってます。

こんな感じで定義しました。

これを poly.vrt として保存し、QGIS で開くと、さくっ!といきましたよ。同じ要領でポイント、ラインの VRT も作成しました。
フィーチャ数は適当に2億にしておきましたw ちゃんと数える場合は sql で直接カウントしてください。
ちなみにポリゴンのレイヤは 247647486 フィーチャあります。

描画速度も実用に耐えうるもので、ある程度拡大していればさくさくと行きます。

東京


New York

多すぎるのでポイントは非表示

結論

GeoPackage 使える。

想像してみてください。
全球の地図データをポケットに入れて持ち運べる時代がきたんですよ?

興奮しませんか?


よいお年を。

※深夜および過労気味で文章のテンションがおかしく、かつ文も乱れております。詳細をお聞きになりたい方は私の実態を捕まえるか、SNSで連絡ください。
twitter: @PEmugi2

注意点なぐりがき

  • データの細部まで検証してないので、中身がすべてまともにインポートできてるかは謎。
  • Conoha の料金は参考値
  • 空間インデックスしか張ってないので、たとえば国境ポリゴンを表示させようと admin_level in ('0', '1') とかやっても、インデックスは空間的な絞り込みにしか聞かないので小縮尺ではえらい時間かかります。フィルタとかする場合は適切にインデックスを追加しましょう。
  • ogr2ogr の osm に関する情報はこちら
  • デフォルトで属性として取り込まれる osm のタグは限られます。たとえばname:jaなどはその他のタグとしてまとめられます。この設定を変えるには上記のogr2ogrのページの osmconf.ini で定義します。

コメント

このブログの人気の投稿

PostgreSQL(PostGIS) でベクトルタイルを作る決意を固めたものの挫折しそう

この記事は FOSS4G Advent Calendar 2014 の 12/13 (土) の記事です。 さて、ここ1年色々環境が変化したわけで、あまり FOSS4G 関連の場に出ていけてないそんな私ですが、今年は久しぶりに書きたいと思います。 ブログもうやってなかったんですが、このために作りました。来年また使うと思います。 ベクトルタイルです。ベクトルタイルですってよ。 新卒で某オレンジ色のWebで地図な会社に入って、退職するまでずっと地図画像作ったり、配信していたわけですが、ベクトルタイルに関してはちょっと距離を置いていたわけです。 数学的な素養がないとか、クライアントサイドでの描画を行なうための某フリーダムな言語およびデザイン等にあまり明るくないなど色々理由はあるわけですが。 普段タイルタイル言ってるだけではだめだなーって。そう思ったのでベクトルタイルを作ろうと思ったんです。SQLで(オカシイ)。 趣味でいじっている地理空間データはすべて PostgreSQL (PostGIS) に格納しているんですが、RDBMS 内でデータ管理からタイル生成、隙をみてタイル配信までできやしないかとふと思ったのでやってみたら挫折した記録をお届けしたいと思います。 特に PostgreSQL の JSON 関連機能が最近がんがん実装されてきたりしているので、色々夢が広がったんでしょうね、数時間前の私は。 ちなみに RDBMS は前職でも触ってたし、現職では RDBMS 担当なわけですが、どちらかというと DBA 的な部分の仕事が多くて実は SQL 力が低いです。 すごい頑張ったんですが、結果的にはタイルの境界線を発生させる関数しか現状できていません。以下です。 引数に zoom レベルをとります。RECORD 型で zoom レベルと LineString を返します。使い方はこんな感じ。 insert into tileline (zoom, geom) select zoom, geom from create_tileline(16) as (zoom integer, geom geometry); QGIS で表示するとこんな感じ。 zoom レベルにはそのラインが存在する最大レベルが入ります。この値によっ

Windows で Node.js の開発環境を作る

ここからパクッてる。 http://tyru.hatenablog.com/entry/2017/03/13/162318 nodist のインストール Pyenv のようなもの。ちなみに Pyenv は好きじゃないので使ってない。 https://github.com/marcelklehr/nodist nodist をインストールできたら安定板の node.js をインストールする。 nodist + 8 nodist 8.11.1 windows-build-tools のインストール npm を使用するうえで c++ のコンパイラや python のランタイムがいるらしい。へぇ。 Administrator として起動した PowerShell で以下コマンドを実行。cmd でやってエラーをいただいた。 npm install --global --production windows-build-tools