ベクトルタイルの必然性について

このエントリは、tmcw の　How we got here をヒントに、ベクトルタイルの必然性について論理的な解説を行うことを目的としたものです。

ウェブ地図の本質は選別

ウェブ地図はなぜ難しいのでしょうか。難しさの核心はファイルフォーマット（例えば、vector-tile-spec）だとかスタイル言語の文法（例えばMapbox Style）にある訳でないのです。ウェブ地図の本質は選別(culling)にあります。ここで、選別とは、膨大な量のデータの中から選び出したり、さまざまな情報源から情報を入手したりすることです。検索、キャッシュ、ビン分別といったキーワードも参考にしてください。

ウェブ地図のパフォーマンスを最も向上するには、何を描画しないかを確定することです。不要な地物、不要な詳細、今注目していない世界中のあらゆる場所、そういったものを描画しないことが重要です。

この観点から、ウェブ地図の歴史的な段階をみてみましょう。

第1段: タイル化前の WMS

WMSでは、描画範囲での選択はしているのです。他方、全てが0から生成され、何も再利用されません。

第2段: Google 式のタイル

この段階では、地理的座標ではなくて、タイル座標で選択をしています。地理的座標と異なり、タイル座標は先が読めます。

フィラデルフィアを見る2人のユーザは同じタイルを見ます。タイルは再利用され、キャッシュされているのです。これは大きな進歩でした。タイルがなければ、ウェブ地図の進展はありませんでした。

第2.5段: タイルと重ね合わせ情報(Leaflet の時代)

この段階では、内容が複雑な基本図は画像タイルにし、重ね合わせ情報をベクトルデータで SVG, HTML または Canvas を使って重ね合わせます。

この段階が利便性を提供してくれた時期は長かったですが、基本図提供のための技術と重ね合わせ情報のための技術が乖離したのは、不幸なことでした。どちらにも使えるスケーラブルな技術があれば、基本図を高度に使え、重たい重ね合わせ情報も容易に使うことができ、重ね合わせ情報の高度な可視化も可能になります。その技術というのが、ベクトルタイルなのです。

整理: ベクトルタイルとは

この先、ベクトルタイルが出てくる訳ですが、そもそもベクトルタイルとは何でしょうか。ここで整理してみましょう。

ベクトルタイルとは、非視覚的で、非地理的で、効率的な、タイル化されたデータです。

SVG と違って、ベクトルタイルにはスタイルがなく、ただ点・線・面だけがあります。その意味で、ベクトルタイルは非視覚的です。

GeoJSON と違って、ベクトルタイルには地理的座標が含まれていません。経緯度ではなく、タイル内のピクセルオフセットを使っています。

また、ベクトルタイルは、重ね合わせ情報だけではなく、基本図を含めたあらゆる地図のために使えるよう、効率的に符号化されるように設計されています。

ベクトルタイルは、非視覚的で非地理的でありながら、今日みられるようなあらゆる種類のベクトル地理空間情報のユースケースに対応します。なぜなら、ベクトルタイルを逆投影すれば、（量子化はされているものの）地理空間情報を復元することができるからです。

ベクトルタイルはデータベースへの小窓

画像タイルは巨大な画像の小片ですが、ベクトルタイルはデータベースへの小窓です。ちなみに、データベースとは、ブランド名がついたデータ構造です。

第2.75段: ベクトルタイルに支援された画像タイル

ブラウザサイドのライブラリが十分に進化した現在では、この第2.75段はスキップすることができますが、歴史的な説明を行います。

この段階では、ブラウザには普通の画像タイルが見えますが、その画像タイルはベクトルタイルからオンザフライで描画されています。Mapbox は1年間これをやりましたし、Googleもこれをやっていました。つまり、WebGLを使わないのにベクトルタイルを内部的に使っていたのです。これはなぜでしょうか。その理由は、やはり選別です。

画像タイルは出力をキャッシュします。ベクトルタイルは前処理後の入力をキャッシュします。これは大きな進歩でした。

地図のレンダリングに使われる時間の多くは、PostGISへの問い合わせや、ネットワークレイテンシや、地物単純化といった選別に使われているのです。描画は十分に高速であり、そのために要する時間は非常に少ないです。

なお、選別は圧縮ではありません。データを捨てることです。OpenStreetMap id や座標のようなものは圧縮が効くものではありません。圧縮するのではなく、捨てることが重要なのです。

ベクトルタイルは、選別と描画を分離します。選別をキャッシュ可能にし、結果として描画を選別から独立させ、ゆえに高速にします。

第3段: ベクトル

この段階では、ベクトルタイルがブラウザで直接可視化されます。実際上、この段階では視覚的出力がキャッシュされることがありません。なぜなら、視覚的出力が非常に高速に再生成される状態が確保されているからです。

まとめ

確かにベクトルタイルは効率的に符号化されており、等価な GeoJSON よりも劇的に小さいですが、重要なのは選別です。OSM Planet は 29GB ありますが、可視化のために選別すれば 0.00172% になります。

ベクトルタイルは、ウェブ地図のアーキテクチャを真に変革するものです。