FOSS4G はベクトルタイルの生産と消費の要
2014年に提案された vector-tile-spec が様々なソフトウェアで採用され、バイナリベクトルタイルの相互運用が確保されつつあります。私はバイナリベクトルタイルの生産と消費を広めたいと考えています。そのためには、下図のオレンジ色の四角で示されたような各ソフトウェアが重要であると考えています。濃いオレンジ色のソフトウェアがオープンソースソフトウェアで、薄いオレンジ色のソフトウェアがオープンソースではないソフトウェアです。オープンソースソフトウェアが重要な役割を果たしていることが分かりますね。
バイナリベクトルタイル、バイナリベクトルタイルスキーマ、スタイル記述
オレンジ色の四角で示されたソフトウェアについてご紹介する前に、灰色の四角で示される仕様について説明させてください。
バイナリベクトルタイルの仕様 vector-tile-spec
vector-tile-spec が他の追従を許さないほどよく練られており、また良い実装を持っていることから、バイナリベクトルタイルの相互運用が可能になりつつあります。
バイナリベクトルタイルスキーマ
しかし、バイナリベクトルタイルの中には任意の属性を持った任意のベクトルデータのレイヤを含めることができます。しかし、特に基本図のようなデータを、ユーザのニーズに応じて使ってもらえるようにするためには、属性やレイヤ構成のルールが一貫していること、また可能な限り相互運用できることが重要です。
このような、属性やレイヤ構成のルールを、ここでは「バイナリベクトルタイルスキーマ」と呼びます。gh:openmaptiles/openmaptilesで Vector Tile Schema という表現が使われているからです。
ベクトルタイルスキーマについては、ベクトルタイル Advent Calendarの、特に１２月７日あたりでよく説明できたらと考えています。
バイナリベクトルタイルのスタイル記述
バイナリベクトルタイルを解釈して、画面上にどのように表現するかについて、そのためのドメイン特化言語のようなものでテキストとして表現しておくことがよく行われます。
Mapbox Style Specifications
現在、バイナリベクトルタイルのスタイル記述で最も広く使われていると思われるのが、Mapbox Style Specificationsです。よく style.json という名前で置かれているファイルです。Mapbox GL JS のみならず、ArcGIS API for JavaScript や OpenLayers でも使われるようになっています。ところで、Mapbox Style Specifications のライセンスについては明確な記述を把握していません。少し確認してみる価値がありそうですね。
scene.yaml
Tangram だけが、scene.yamlという別種のスタイル記述を使っています。かなり発想が異なっており、比較的簡潔に書けるよさがあるように思います。すべてが Mapbox さんに任されがちになる世界で、多様性を与えてくれているように思います。
それでは、個別のソフトウェアについて簡単に紹介させてください。
Mapbox GL JS
ウェブブラウザの環境で vector-tile-spec 形式のバイナリベクトルタイルを消費するための環境としておそらく現時点で最強なのは、Mapbox さんが精力的に開発を進められている Mapbox GL JS です。このソフトウェアが十分な性能を持つことが、バイナリベクトルタイルの普及を支えて来たと観察しています。
これまで Mapbox さんは、非常に大規模な開発を高速に進めて来ました。そろそろだんだんと、バージョン 1.0 の絵が見えてきたような気がします。
2018 年に Mapbox GL JS 1.0 が出るとすれば、それはオープンソース系のバイナリベクトルタイルの運用において一つの大きな通過点になるような気がします。
OpenLayers + ol-mapbox-style
OpenLayers でも、特有の実装方法で、バイナリベクトルタイルがレンダリングできるようになってしましたが、レンダリングのスタイルについては、OpenLayers の世界観と API に従う必要があったようです。このため、Mapbox Style でスタイル記述を行う Mapbox GL JS および ArcGIS API for JavaScript との間には、やや距離があったように思われます。
その状況の中で、Boundless さんが、OpenLayers を Mapbox Style 記述に対応させるol-mapbox-styleを開発されたようです。
今後、このソフトウェアによってバイナリベクトルタイルのスタイル込みでの相互運用性が高まるのか、確認していく必要がありそうです。
Leaflet + Tangram
Leaflet の開発者を要する Mapbox さんは、ブラウザでのバイナリベクトルタイル対応を Mapbox GL JS で行なっていますが、これに対して、Mapzen さんは Leaflet に組み合わせるソフトウェアとして Tangram を提供しています。
Mapbox GL JS と Tangram とは、やや異なる世界観があり、Tangram では簡単に実装できるが、Mapbox GL JS では実現が難しい表現があります。そのような表現は、どちらかというとアーティステックな表現が多いようです。Mapbox GL JS は、ユースケースの大半を占めるリアルな利用に集中しているのに対し、Tangram は特別なビジュアライズを簡単に書けるというところに特徴を持っているように感じられます。
ベクトルタイルのスタイル記述言語が schene.yaml という YAML ベースの書きやすい言語であることも、この特徴の違いを反映しているように思います。
ここまで、ベクトルタイルを消費する側の、ブラウザで実行されるライブラリの話でした。
gh:openmaptiles/openmaptiles
gh:openmaptiles/openmaptilesは、planet.osm.pbf 形式のデータおよび Natural Earth 等のデータから、基本地図バイナリベクトルタイルを生産するためのツールです。PostGIS や mapnik、imposm3 などの定評あるツールを Docker コンテナーに詰めて、docker-compose で構成管理し、バッチ処理で生産を行うプログラムです。
tippecanoe
tippecanoe は、任意の GeoJSON 又は「GeoJSON の NDJSON」ファイルから、バイナリベクトルタイルを生産するためのツールです。C++ で書かれていて非常に高速ですが、Windows 環境での導入が難しいなどの課題がありました。
最近の tippecane は、Dockerfile も合わせて配布しているので、gh:openmaptiles/openmaptiles を使うために導入した Docker を有効活用して、tippecanoe も docker ベースで使うようにすると、ツールの可搬性が確保しやすくて良いかもしれません。
turf
turfは、ブラウザでの計算幾何処理を実装するのにも便利ですが、ベクトルタイル生産にあたってのデータのバッチ前処理にも使いやすいです。node で使うことができます。npm で簡単に、さまざまな OS 環境に導入可能なところが魅力的であると考えています。
Docker と node
Docker と node は、実際には地理空間情報処理に特化したソフトウェアではなく、IT 全般で使われるインフラストラクチャですが、私はこれらのソフトウェアが地理空間情報処理の世界でもより多く使われるようになってくると感じています。