OpenStreetMap の planet.osm.pbf から直接に、かつなるべく速く、また柔軟にベクトルタイルを生産するコマンドラインツールである produce-320 が形を見せてきたので、そろそろ私の個人 GitHub アカウント所属から、un-vector-tile-toolkit 組織 GitHub アカウントに移管できないかと思っています。
その移管の前に、少し考察をしてみたものを共有してみます。
次期リリースの構成
前回リリースの総括
国連ベクトルタイルツールキットの組織アカウントの前回リリースは、OSGeo.JP Workshop for the UN Vector Tile Toolkit のハンズオン資料としての、spinel および spinel-produce のリリースでした。spinel がベクトルタイルサーバで、spinel-produce がベクトルタイル生産ツールです。
この時には、計算機環境の前提条件をなるべく低くするために、例えば HTTP/2 の使用も避けるといった、教材であることに徹した設計にしています。また、スタイルに関する知見も溜まっていなかったので、スタイルも非常に素朴なものになっています。
次回リリースの構成
私のプロジェクトは、（１）まず個人アカウントでコードを大量に書き捨てながら成果物を特定していき、（２）落ち着いた段階で組織アカウントに移す、というアプローチで進めています。次回の組織アカウントからのリリースは、次の２点になるでしょう。
- onyx: シンプルな HTTP/2 ベクトルタイルサーバ（４代目）
- produce-320: planet.osm.pbf からのベクトルタイル生産ツール
onyx については、すでに組織アカウントに移管を済ませています。
produce-320 については、近いうちに「リリースの機会に行う掃除」を行なって組織アカウントに移したいと思います。
名前、どうしましょうかね。私はプロジェクト名になるべく意味がこもらないものを選ぶので、現在の名前は onyx と produce-320 になります。
あまり名前に気合を入れすぎると、次のリリースがやりにくくなるので、この二つの名前のままでいくと思います。
onyx については、あえて次の機能は積み残している状態です。
- タイミングをずらしながらサーバを再起動していき、クラスタとしては落とさないながらも気軽に再起動ができるようにする工夫の追加。ベクトルタイルの入れ替えのところで、まだぎこちないところがあるので、運用ツールに近いレベルで整える必要があるでしょう。
- ArcGIS Server Vector Tile Service に互換させるための route の追加。適当なタイミングを選んで、pietra に実装済の route をコピーします。ベクトルタイルサーバは、tile-block -> pietra -> spinel -> onyx と進んできているので、onyx で４代目となります。
produce-320 について
produce-320 は（外付けの 500GB 程度の SSD を装備した）Macbook Pro 程度の計算機で５日以内に全世界分のベクトルタイルを生産することを目指したツールになっています。
結果的に、それほど大きくない一国程度の領域であれば、$200 PC で１日以内に生産ができる、ということも目指すことになります。
アフリカを含む優先領域のモジュールの個数を数えたら 320 だったというのがきっかけで、320 という数字が入った名前になっています。
非力な計算機環境でなんとか全世界を回すために、次のような工夫をしています。
- いまの planet.osm.pbf のサイズは 42GB 程度ですが、これのスキャンというのは今の計算機にはそこそこ重たいです。このため、生産バッチが対象とする、大陸程度規模以下の領域をまず切り出して、そこから z=6 のタイルの領域ごとにモジュールを作っていくというアプローチをとります。この大陸程度規模以下の領域のことを、miniPlanet と呼んでいます。
- 世界の７割は海です。planet.osm.pbf をスキャンすることで、「地物がまったく存在しない z=6 のタイルの領域」を 1500 以上特定することができます。z=6 の領域の総数は 4096 ですから、この 1500 をスキップすることで性能を稼ぐことができます。この 1500 程度の領域を nfm (no-feature-module) と呼び、そのタイル番号をみたら後続の処理はしないという工夫をしています。
- Tippecanoe と osmium と modify.js をパイプで繋いでおき、そのパイプラインを、計算機環境に応じた個数だけ並列に並べることで、計算機の性能を限界まで発揮させることを目指します。
リリースまでにやる整理
- OSM に依存した設定については、tapioca という別レポジジトリで開発作業をしていましたが、リリースの機会に produce-320 側にコピーして、tapioca を deprecated にすると思います。具体的には、modify.js と osmium-export-config.json を移すことになると思います。
- no-feature-module は nfm という別レポジトリで管理していますが、これも必要なコードをコピーします。ただし、nfm というプロジェクト自体は生かしているという整理をし、nfm.json や nfm.js が更新された時には、適宜 produce-320 に上書きするということにするのだと思います。npm のモジュールにする、ということは、たぶん大げさなのでやりません。
再び10万レベルの応用領域へ
produce-320 は 1:5000 の内容を持つ領域もあるという OpenStreetMap を主要対象としていますが、もう少し縮尺が小さく、よってデータ量も少ない領域への展開についても興味があります。
そこで、神戸市「地域の範囲」データを２枚のベクトルタイルにする方向の展開もやっていくのだろうなと思っています。
なお、神戸市ベクトルタイルについては、その後、minzoom を 7 に、maxzoom を 14 に変更して再生産し、拡大しても図形が崩れないように改善しています。図形が崩れた原因は、オーバーズームを効かせ過ぎたことです。
これにより、神戸市ベクトルタイルは２枚ではなくなりましたが、「CMS に気軽に掲載できる静的ファイル」という性質は保っています。現在のタイルデータの量は、1.4MB です。詳細は、hannibal レポジトリを clone してご覧ください。
2016 年夏の状況との比較
自分で 2016 年夏に書いた zero-server maps 日本語版 を見直す機会がありました。2016 年夏に、2018年を想定して書いたものですが、2019年という現在位置から見ると、現在の私の方針について、こういうことが言えると思います。
- 私は現在は 10GB を超える領域を扱っているので、サーバ環境は gh-pages のようなものというよりも、より IaaS 的な環境を想定して動いているところですね。コミュニティサイドの実験では、Digital Ocean の Droplet を使っています。たまたま私の作業環境では、安いオブジェクトストレージにアクセスできるというわけでもないので、mbtiles モジュールで送り込んで express サーバの中で引っ張り出してサーブする、というやや保守的な設計を onyx シリーズで使っています。
- mvt (vector-tile-spec) と Tippecanoe を選択したのは間違っていません。ベクトルタイルは画像タイルよりも速くなって初めて意味があります。まずは最も性能が出せる環境で確かな性能を出した上で、相互運用を確定していくべきです。
- Tangram は Mapzen のシャットダウンとともに、結果的には力を失ってしまいました。まずは Mapbox GL JS の上で確かな性能と成果を出すのが先決です。他方で、OpenLayers の 6 ではベクトルタイルを頑張られるようですね。
- データについては、地球地図を扱う段階から、OpenStreetMap を使う段階に進むことができました。
- その後、vt-optimizer と、tile-join に出会うことができたので、mbtiles や pbf のファイルを直接自分のスクリプトで扱うことは少なくなりました。fan_out という名前のツールを書く必要は、もうなくなってしまいました。
- また、FOSS4G Asia 2018 の機会に、ローカル言語で考えて発信することの重要性に気がついています。共通言語（英語）ですらすらと書けなくて悩む暇があれば、まずはローカル言語で殴り書きでも書く、そこから得たものを使って共通言語で書いていく、というアプローチをとることが有効な場合も多い、と思うに至っています。だから、2016 年のこの時のように、英語で書かなければならないから言葉少なになる、ということは避けるべきなのだろうと思います。英語で書こうとも、ローカル言語で書こうとも、そもそも専門性が高い話です。最終的な成果を除いては、ほぼ自分自身と、近い友人のために書くことになるというのが実際でしょう。どんどん書きましょう。