バイナリベクトルタイルの生産と消費を広めるために、なるべくフットプリントの小さい技術体系を構築し、なるべく多くの人たちとの共有をはかります。そのために私が選択した技術体系は、次の通りです。
gh:openmaptiles/openmaptiles
バイナリベクトルタイルを生産する技術はいくつかの系統がありますが、私は次のような経緯で gh:openmaptiles/openmaptiles を選択し、評価・検討することにしました。執筆時点で、このソフトウェアを使いこなしていこうという考えは変わっていません。
オープンソースソフトウェアを使ってバイナリベクトルタイルを生産する技術は、やはり OpenStreetMap (OSM) データを使ってビジネスをする企業の方々が多く公開されています。その技術を他のソースデータでも使い、相互運用性を確保することが、全体にとって大きなメリットになると私は感じています。
上記のような方々が公開されている基本地図バイナリベクトルタイルの生産技術体系としては、次の３つがあります。
- Mapbox さんが主体で構築されている mapnik をベースとしているらしき技術体系
- Klokan Technologies さんが主体で構築されている openmaptiles シリーズの技術体系
- Mapzen さんが自らの vector tile service のための構築されている tilezen の技術体系
これらは、単一または少数の GIS データをバイナリベクトルタイルに変換する、tippecanoe などのソフトウェアとは異なり、おおむね GB を超えるサイズの多種類のデータを大規模に変換し、データの更新にも対応させようとしているものとお見受けしています。
うち、mapnik は複合的な技術体系であり、また、ウェブの情報によれば Mapbox さんもバイナリベクトルタイル生産をクラウド環境の特性に特化したものに作り込んでおられるらしく、その上、Mapbox さんはベクトルタイルスキーマについて知的所有権を保護する施策も一部でとられているところがあります。このことについては、アドベントカレンダーの別のエントリでご紹介します。いずれにせよ、Mapbox さんそのものがお使いになっている技術は、なかなか、共有したい側による作り込みなしには共有しづらい技術であるとお見受けしています。
他方で、openmaptiles は、そもそも maputnik などを用いたバイナリベクトルタイル生産体系をオープンソースで実装しようというモチベーションで行われた研究に基づいて作成されたものであり、その目的としてバイナリベクトルタイル生産体系を共有しようというものがあります。
また、tilezen については、どうもコンパクトな技術体系のようではあるのですが、使用方法のドキュメント化は openmaptiles と比べるとそれほど進んでいないようであり、また Mapzen さんのバイナリベクトルタイルサービスは、バイナリベクトルタイルのバージョンが古いままであるようにも見受けられます。
このような状況を観測した結果、まずは openmaptiles を追って見るべきであり、openmaptiles が使いにくい技術であるのであれば、tippecanoe を使いこなすことによって対応して行くのが良いのではないかと私は考えました。
Docker と node
バイナリベクトルタイルの生産を広めたいとすれば、それが依拠する下位技術のフットプリントは、小さければ小さいほど良いと考えます。特に、ミドルウェアやライブラリの導入が煩雑であったり、それらがさらに下位のOSを選ぶ技術であったりすると、なかなか技術は広まりません。
gh:openmaptiles/openmaptiles を選択したことをきっかけとして、なるべく生産技術を広めたいと考えた結果、おそらく技術インフラストラクチャーとしては「Docker と node」を選ぶことが良いであろうと考えています。
Docker
私にとって Docker は、まずはサーバサイド処理をコンテナ化するための技術として親しんだ技術でしたが、gh:openmaptiles/openmaptiles を試す過程で、バイナリベクトルタイル生産のようなバッチ処理や、あるいは一般に OS を超えての地理空間情報技術のポータビリティの確保のために便利な技術ではないかと思うに至りました。
Docker の下位技術はまだまだ様々な移行にさらされているようであり、Docker を使い始めるにはまだ奥の深い設定が必要なところもありますが、ジオの人たちにとっても、そろそろこの技術を本格運用し始めると、メリットが大きいように感じ始めています。
node
node は JavaScript というプログラミング言語を使ってデータフローを扱うための環境であり、ジオ界では特に Mapbox さんが多く使ってきた印象があります。データフローを扱うための工夫が多いのと、JavaScript を使うためウェブとの相性が良いこと、それから導入先OSについてそれほど心配する必要がないこと（特に、Windows 系で動作の不安定があまり心配されないこと）が特徴かと思います。
私自身は、これまでジオのバッチ処理には Ruby を使ってきました。しかし、私が現在置かれている環境で、なるべく技術を横に広げようとすると、より入手しやすい環境で仕事をするのが有利になってきます。
最近、node でもブラウでも、ES6 が普通に使えるようになってきました。従前、JavaScriptはタイプ数が多く、ユーティリティ機能あるいはシンタックスシュガーが少ないという印象がありましたが、ES6のおかげで、ずいぶんいい感じで書けるようになってきたと感じています。
私にとっては、テンプレート文字列とアロー関数のおかげで、いったん Ruby から離れて node で作業をする決心がつきました。いずれ紹介していきたいと考えています。
クライアントサイドライブラリは相互運用性を確認し続ける
バイナリベクトルタイルは、現在、vector-tile-spec が事実上の標準の立場を維持していて、Mapbox GL JS、ArcGIS API for JavaScript、Tangram、OpenLayers がそれぞれに vector-tile-spec 準拠のバイナリベクトルタイルを消費できる形になっています。
コンテンツプロバイダとしては、バイナリベクトルタイルの仕様が独占されるなどして不安定になることなく、安定した標準の立場を維持しているという状態が望ましいわけです。
バイナリベクトルタイルの相互運用性を維持するには、あるいはまた、バイナリベクトルタイルの相互運用性の果実を得て行くためには、「同じバイナリベクトルタイルを、多くのクライアントサイドライブラリで相互運用し続ける」努力が必要であると思います。
このためには、次には「バイナリベクトルタイルスキーマの安定化」が必要なのですが、これについてもこのアドベントカレンダーの別のエントリでお話しすることになると思います。また、バイナリベクトルタイルスキーマの下にある、「バイナリベクトルタイルのスタイル記述」についても、単一の標準に統合されるのか、単一化は阻まれるのか、なかなか面白いところです。ここでも、Mapzen さんが面白いポジションを維持されています。これについても、いずれ書くことがあるかもしれません。また、Boundless さんが OpenLayers で mapbox-style を読めるようにするための ol-mapbox-style を開発されており、ここも面白いところです。
バイナリベクトルタイルスキーマおよびバイナリベクトルタイルスタイルの相互運用の問題をにらみながら、技術的な作業としては、これら複数のクライアントサイドライブラリで問題なくバイナリベクトルタイルが消費されることを確認し続けることが必要であると考えており、そのための作業を行なっていこうと考えています。
なお、私自身はモバイルデバイスOS用アプリのためのウェブ地図ライブラリには詳しくないので、それについては当面、他の方による議論を期待せざるを得ません。
図解
これらの技術体系を図解してみると、次の図のような形になると思います。この構図の中で、技術を深めていきたいと考えています。
