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 ソフトウェアで使用可能です。
ただ、ハードウェア、ソフトウェアの急速な進化に伴って、いろいろ不都合が生じてきました。
「データ添付しました。ご査収ください。」っていうメールが来て確認したら、満を持して登場する【データ.shp】。「どうも、一人できました。てへっ」つって。
開けねーよ。ご査収できねぇよ。
なんて経験、ありますよね？
Shapefile は最低でも .shp, .dbf, .shx という 3 つのファイルが必要です。
必須以外にも、.prj、.sbn、.shp.xml、.cpg などなどいろいろ構成員がいらっさいます。これら合わせて 1 つの Shapefile です。
最近はソフトウェアが頑張るのでましですが、たいてい CP932 の Shapefile は一発目化ける。
今時 2 GB って・・・
まぁ 2 GB のベクターデータって結構でかいんですがね。
とはいっても、TB を超えるディスクが 1, 2 万で買える時代に 2 GB はきつい。
10 バイトまで (UTF-8 だと 3 文字とか・・・)。なので「都道府県」という属性名にしたくても「都道府」になってしまうという・・・
とまぁきりがないのですが、決して Shapefile を陥れたいわけでもディスりたいわけでもないんです。
このフォーマットが GIS の普及やソフトウェアのデータ相互運用性の確保に大きく貢献をしたことは言うまでもありません。
そう、ただ次の時代がやってきただけです。
個人的には、PostgreSQL にぶっこんどけばよくない？とか思うけど。おらの捕まえたGISデータを交換とかする友達いねーし。
ファイル形式で、追加ソフトやライブラリがいらなくて、大容量に対応していて仕様がオープンなフォーマットって考えたとき、脳内には GeoPackage しか残りませんでした。
ほかにあるのかもしれないけど。
GeoPackage はベクターデータおよびタイル化されたラスターデータを格納できますが、その実態は SQLite データベースです。空間インデックス（R-Tree）にも対応しています。
単一ファイル (.gpkg) で構成されますが、データベースですので 1 つの GeoPackage 内に複数のスキーマの異なるベクターデータやタイル化されたラスターデータを格納できます。この点は Shapefile と大きく異なります。
また、OGC (Open Geospatial Consortium) によって定義されており、すでに GDAL/OGR や QGIS や ArcGIS などの地理空間データを扱うソフトウェアが対応しています。
詳しくはこちら（私が言っていることと違うことが書いてあったら、こちらのサイトのほうを信じてください）。
VRTは仮想的なレイヤを定義する XML 形式のデータフォーマットです。通常は複数のデータをあたかも1つのデータとして扱うためなどに使われます。
これを poly.vrt として保存し、QGIS で開くと、さくっ！といきましたよ。同じ要領でポイント、ラインの VRT も作成しました。
フィーチャ数は適当に2億にしておきましたw ちゃんと数える場合は sql で直接カウントしてください。
ちなみにポリゴンのレイヤは 247647486 フィーチャあります。
描画速度も実用に耐えうるもので、ある程度拡大していればさくさくと行きます。
想像してみてください。
全球の地図データをポケットに入れて持ち運べる時代がきたんですよ？
興奮しませんか？
よいお年を。
※深夜および過労気味で文章のテンションがおかしく、かつ文も乱れております。詳細をお聞きになりたい方は私の実態を捕まえるか、SNSで連絡ください。
twitter:@PEmugi2
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 はなんでしょう。
ファイル形式で、追加ソフトやライブラリがいらなくて、大容量に対応していて仕様がオープンなフォーマットって考えたとき、脳内には 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 を作成することができました。
以下は簡単な手順と、それぞれにかかった時間です。
- GDAL/OGR の導入
以下コマンドを実行
# pacman -S gdal
処理時間: 1分 - 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 分 - 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 でお亡くなりになりました。
ちなみに上記処理は空間インデックスの作成も含みます。その他のカラムに対するインデックスは張られていません。 - gpkg のダウンロード
これが予想外に時間がかかった・・・
nginx をたてて、HTTPでダウンロードしましたが、4時間以上かかりましたよ・・・。そしてこの時間ですよ。
予想外に処理時間が短く済みましたし、容量も 170 GB という現実的な数字に収まりました（もはや麻痺）。
あとはこれが現実的な速度で使用できるかということです。
QGIS で描画してみる
QGIS の出番です。
意気揚々と「ベクタレイヤの追加」ボタンから作成した planet_osm.gpkg を追加したら・・・ １５分以上沈黙・・・ その後レイヤ選択のウィンドウが出てきてデータ追加できました。
ただ、毎回これじゃぁ・・・ ねぇ？
ただ、毎回これじゃぁ・・・ ねぇ？
これ、レイヤのプロパティ用にすべてのレイヤに対して select count(*) 的なクエリを流してフィーチャ数を毎回カウントしているからだと思われます。
なんとかこのプロセスを端折る方法はないか10秒程度悩んだんですが、1個だけありました。
VRT (http://www.gdal.org/drv_vrt.html)
VRT (http://www.gdal.org/drv_vrt.html)
VRTは仮想的なレイヤを定義する XML 形式のデータフォーマットです。通常は複数のデータをあたかも1つのデータとして扱うためなどに使われます。
VRTの定義の中にメタ情報的な要素もあり、その中に FeatureCount という要素があったことを思い出しました。神がかってます。
こんな感じで定義しました。
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| <OGRVRTDataSource> | |
| <OGRVRTLayer name="osm_poly"> | |
| <SrcDataSource relativeToVRT="1">planet_osm.gpkg</SrcDataSource> | |
| <SrcLayer>multipolygons</SrcLayer> | |
| <GeometryField name="geom"> | |
| <SRS>EPSG:4326</SRS> | |
| <ExtentXMin>-180</ExtentXMin> | |
| <ExtentYMin>-90</ExtentYMin> | |
| <ExtentXMax>180</ExtentXMax> | |
| <ExtentYMax>90</ExtentYMax> | |
| </GeometryField> | |
| <FeatureCount>200000000</FeatureCount> | |
| </OGRVRTLayer> | |
| </OGRVRTDataSource> |
これを poly.vrt として保存し、QGIS で開くと、さくっ！といきましたよ。同じ要領でポイント、ラインの VRT も作成しました。
フィーチャ数は適当に2億にしておきましたw ちゃんと数える場合は sql で直接カウントしてください。
ちなみにポリゴンのレイヤは 247647486 フィーチャあります。
描画速度も実用に耐えうるもので、ある程度拡大していればさくさくと行きます。
東京
New York
多すぎるのでポイントは非表示
結論
GeoPackage 使える。想像してみてください。
全球の地図データをポケットに入れて持ち運べる時代がきたんですよ？
興奮しませんか？
よいお年を。
※深夜および過労気味で文章のテンションがおかしく、かつ文も乱れております。詳細をお聞きになりたい方は私の実態を捕まえるか、SNSで連絡ください。
twitter:
注意点なぐりがき
- データの細部まで検証してないので、中身がすべてまともにインポートできてるかは謎。
- Conoha の料金は参考値
- 空間インデックスしか張ってないので、たとえば国境ポリゴンを表示させようと admin_level in ('0', '1') とかやっても、インデックスは空間的な絞り込みにしか聞かないので小縮尺ではえらい時間かかります。フィルタとかする場合は適切にインデックスを追加しましょう。
- ogr2ogr の osm に関する情報はこちら
- デフォルトで属性として取り込まれる osm のタグは限られます。たとえばname:jaなどはその他のタグとしてまとめられます。この設定を変えるには上記のogr2ogrのページの osmconf.ini で定義します。
コメント
コメントを投稿