osmium と Tippecanoe をパイプでつないで planet.osm.pbf からベクトルタイルを生産する、前回の記事の続きです。
320neo の整備延期
前回の記事では、osmium export と Tippecanoe をパイプでつなぐプログラムである produce-320 を試作しましたが、osmium-tool の理論上は、osmium extract と osmium export をパイプでつなぐことも可能であるように思えました。
そこで、produce-320 の new extract option として、osmium extract と osmium export、modify.js と Tippecanoe を全部パイプでつなぐ produce-320neo の試作を試みました。
結果としては、osmium extract にパイプ経由でデータを入れた場合、入れるデータの形式が pbf であった場合、opl であった場合の両方において、osmium extract が、入力の形式を判別できないというエラーを出して正常に機能しないという現象に当たりましたので、320neo を現時点でうまく動かすことはできていません。
当面、320 のままで運用実績を積みたいと思います。320 の特性については、次の通りであると考えています。
- 320neo の試作の際に実感したことであるが、osmium extract が出力を始めてるタイミングはプログラム実行時間の中でもかなり遅いので、neo オプションをとるメリットは、実はそれほど大きくないようである。
- osmium export および Tippecanoe の処理時間と比べて、osmium extract に要する時間は長いので、extract した osm.pbf をファイルとして出しておく 320 のやり方には、modify.js の変更などによるベクトルタイル再生産で手戻りを小さくできる利点がある。
produce-320 が生産するファイルの諸元
produce-320 でのベクトルタイル生産が一通りできましたので、その入出力の諸元をメモしておきます。
- 大元のソースデータである planet-19128.osm.pbf のサイズは 44GB であった。
- そこから produce-320 の作業領域を切り出したファイルである 320.osm.pbf のサイズは 5.3GB であった。
- 上記の 320.osm.pbf を材料として produce-320 を実行したところ、生産された pbf ファイルの総計は 5.1GB、mbtiles ファイルの総計は 8.3GB であった。
- 生産された z=5 タイル範囲を単位とするモジュール pbf ファイルのうち、最大は 6-31-24.osm.pbf であり、そのサイズは 248MB であった。
- 生産された z=5 タイル範囲を単位とするモジュール mbtiles ファイルのうち、最大は、同じく 6-31-24.mbtiles であり、そのサイズは 404MB であった。
- 最小のモジュールは、データが全く含まれないモジュールであり、pbf は 73B、mbtiles は 24KB であった。
これまでの試作とくらべて、320 からは Tippecanoe の --clip-bounding-box オプションを使用しています。どうも、最近追加されたオプションのようです。これを使うことにより、モジュール範囲外にタイルが生産されることを防ぐことができました。これまでは、自前でタイル範囲との intersection をとるコストを回避するため、余計なタイルがモジュールに混ざってくることを許容していました。
今回の試作の結果は https://hfu.github.io/tapioca-six/ に反映済みですが、タイルが抜けることも、ビクトリア湖が消滅するようなこともなく、問題なくタイルが生産されているようです。他方で、mbtiles ファイルのサイズは、数割減少しているように思います。--clip-bounding-box の恩恵を享受できることが確認できたと感じています。
320 が assembly で運用可能であることの確認
今回の試作では、それぞれ thanks および assembly と名付けた複数の計算機環境を使っています。
osmium extract の計算負荷が大きいことから、しばらく thanks でテストをしていましたが、本来ベクトルタイル生産は assembly のような機械でも行われるべきと考えているので、thanks での動作確認後、assembly でも運用できることを確認しています。
thanks では 2並列で実行しましたが、assembly では１並列で実行するほうが安心感があります。その1並列での処理時間レコードの最初の方を例示すると、次のとおりです。
- 6-22-25 19:26 (19分26秒)
- 6-22-26 19:13
- 6-22-27 19:34
- 6-22-28 18:17
- 6-22-29 18:26
- 6-22-30 18:07
thanks では同じような処理に7分程度でしたので、２倍強の時間はかかりますが、安定的に運用できているように見えます。
なお、上記の数値をとっているモジュールは、いずれもデータが存在しないモジュールです、空読みでこのくらいの時間がかかる、ということになります。