本稿執筆時点で https://sli.do/A727 に頂いた質問に応答します。
ベクトルタイルのカテゴリに関する質問
ベクトルタイルという言葉の権威ある定義はなく、またある形式がベクトルタイルにカテゴライズされるかされないかは、その形式が応用可能か、あるいは相互運用可能か、とは直接関係することはないと考えますが、それは申し上げた上で、頂いたご質問に次のとおり応答します。
MVT タイルはベクトルタイルですか？
vector-tile-specに基づくタイルが、現在もっとも相互運用性を確保しつつあるベクトルタイルであると感じています。
ベクトルタイルの成功は、なるべく広いウェブ環境のもとで必要な性能を出せるかどうかにかかっていますが、vector-tile-spec はそのために必要な値域の工夫、符号化の工夫を施しており、性能の面で成功の可能性が最も高いベクトルタイルの形式であろうと考えています。
セマンティックなバージョニングにも気を使っており、また、ライセンスについても次の通り明記されています。
The text of this specification is licensed under a Creative Commons Attribution 3.0 United States License. However, the use of this spec in products and code is entirely free: there are no royalties, restrictions, or requirements.
現時点で、複数のオープンソースソフトウェアおよび ArcGIS Pro によってバイナリベクトルタイルが生産できると認識しています。（生産されたベクトルタイルの相互運用性については、検証の上、さまざまな努力により確保していく必要があると考えます。）
GeoJSON タイルはベクトルタイルですか？
Mapzen さんのVector Tile Serviceは、ベクトルタイルのファイル形式の一つとして GeoJSON を採用しています。また、国土地理院ベクトルタイル提供実験でも、GeoJSON をベクトルタイルのファイル形式としています。このため、GeoJSON タイルはよく使われているベクトルタイルの形式の一つであると考えられます。
GeoJSON ベクトルタイルの仕様というものは存在せず、単に「slippy map tilenames と RFC 7946 の組み合わせ」ということで規定されることになるフォーマットです。この結果、タイル番号が規定するグリッドと、タイル内部の座標との間で情報の冗長性が存在します。また、莫大な数値を扱うにも関わらず、テキストベースの形式ですので、格納効率・読み書き速度ともに不安が存在します。
性能を犠牲にしつつも、分かりやすさや規格の固まり具合を重視しようとするならば、GeoJSON ベクトルタイルを選択することがあると考えます。
また、GeoJSON ベクトルタイルに明示的に対応したライブラリは実は少なく、Tangram が対応しています。なお、GeoJSON ベクトルタイルには、特有のスタイル記述言語が存在しません。
Shape タイル（もしそんなものがあるとすれば）はベクトルタイルですか？
もしそんなものがあるとすれば、Shapefile 形式はベクトルデータの形式ですから、ベクトルタイルとは言えない、ということにはならないと思います。他方、多様な座標系の問題や多様な文字コードの問題を解決せずにウェブに持ち込むことになりますので、相互運用性において、通常の Shapefile 形式と同様の問題を抱えることになると思います。
また、一つの SHP ファイルに対して、付随する複数のファイルを持つという構造を持っていることから、ナイーブにやればサーバとクライアントの間でのやり取りの数も一般的なベクトルタイルとくらべて数倍となることが予想されます。
属性の仕様も含めれば、仕様が明確な形で共有されているとも言いづらく、それゆえに権利関係も完全にクリアとは言い切れません。また、スタイル記述言語はおそらく存在しません。
CSV タイル（たとえば地理院DEMテキスト形式）はベクトルタイルですか？
地理院標高タイル（CSV形式）は、ラスタタイルのグリッド点群に割り当てられた標高値を格納していますので、ベクトルタイルというよりはラスタタイルであろうと思われます。
ところで、基盤地図情報（数値標高モデル）のベクトルタイルというものも存在します。地理院標高タイルとの違いは、slippy map filenames のタイル番号が規定するグリッドに縛られるか、縛られないかの違いです。「タイル番号が規定するグリッドに縛られるか、縛られないか」が、「ラスタか、ベクトルか」を意味するという理解は、ひとつの理解かもしれません。
なお、CSV形式でベクトルデータを表現することは可能であることから、CSVによるベクトルタイルということは可能だと思います。ただし、相互運用性が確保できる定義を安定的に保つことは、CSVの汎用性が高すぎることから、難しいかもしれません。
PNG タイル（たとえば地理院DEM PNG 形式）はベクトルタイルですか？
地理院標高タイル（PNG形式）は、ラスタタイルのグリッド点群に割り当てられた標高値を格納していますので、ベクトルタイルというよりはラスタタイルであろうと思われます。
ところで、基盤地図情報（数値標高モデル）のベクトルタイルというものも存在します。地理院標高タイルとの違いは、slippy map filenames のタイル番号が規定するグリッドに縛られるか、縛られないかの違いです。「タイル番号が規定するグリッドに縛られるか、縛られないか」が、「ラスタか、ベクトルか」を意味するという理解は、ひとつの理解かもしれません。
データの単位をタイルとするかレコードとするかに関する質問
ベクトルタイルというのは既存の地図ライブラリで扱いやすいのですが、ベクトルという性質上、ノードor地物単位で詳細版を持っていてズームレベルに応じたリダクションはクライアントベースでやったほうが良いのではないでしょうか。これにより、例えば自分が進むルートに関しては詳細にしてそれ以外は荒くするなどの調整ができると思います。
まず一般論として、ベクトルタイルよりも優れた地理空間情報の配布手段が開発され、しかもその手法が知的財産権の管理といった（正当な）コスト回収手法のもとに置かれることなく自由に使えるのであれば、すなわち、vector-tile-spec で言われるような「the use of this spec in products and code is entirely free: there are no royalties, restrictions, or requirements」といった例外的に気前の良い条件で公共の用途に置かれるのであれば、しかもその実装ができれば複数手にはいるのであれば、その手法の採用は非常に魅力的だと思います。
他方で、質問で頂いた方式と現在のバイナリベクトルタイルの方式を比較して、私がベクトルタイルのほうが優れると思われる点は、次の通りです。
- ノードまたは地物単位での詳細版がサーバにあり、それをクライアントサイドで自在にダウンロードした上でリダクションなどの処理をクライアントで行おうとする場合、必要な描画が完成する時間が予測可能な度合いが下がりそうです。その理由は、大きく次の２点にあります。
- ノードまたは地物を単位とした場合、空間的に機械的にあらかじめ切り分けたタイルを単位とする場合とくらべて、単位の数が大きくなります。これは、タイルに含まれるノードまたは地物の数は１を超える場合が多い（ようにタイルの区画が設計されている）ことから明らかです。そうした場合、サーバとクライアントの間で行われる通信の単位の数（リクエストの数）は、増大してしまいます。これは、アプリケーションの性能の低下とサーバ側の運用コストの増大に直結するように思われます。
- また、例えば「本州の海岸線」を想像していただければよいと思うのですが、地物主義の理想を貫徹した場合、その理想的な地物の大きさは非現実的なほど巨大になります。そのような巨大な地物の、しかも詳細版をネットに通そうとした場合、通信量も莫大となる上に、通信の終了予想時刻が得にくくなります。また、「本州の海岸線」をローカルにキャッシュできているクライアントと、まだそうしていないクライアントとの間で、アプリケーションの反応が大きく異なってしまうのも、サービス提供者としては非常に管理しづらい性質になります。地理空間情報を現実的に配布しようとする場合、地理空間情報を空間的に分割することは必須です。そのような分割を、場当たり的ではなく、非常に単純に機械的に行おうとするアプローチがタイルになります。分割することが必ず必要なら、非常なほどに単純にやってしまおう、というアプローチです。地形図の図郭のアプローチにも似ていると思います。
- 加えて、地物はノードはその定義から、空間的に機械的には切り分けられていないため、クライアントからの空間をキーにしたクエリに対して、サーバ側ではオンデマンドで空間検索をかける必要が必要になり、サーバ側の計算機の負担が大きくなります。そのようなサーバを基本地図のために運用しようとする主体が良いバランスシートを保とうとするのは至難の業となりそうに感じます。なお、空間をキーにしたクエリを事前にやっておき、キャッシュしておくという発想自体が、タイルという発想です。
私はたまたま地理空間情報の新規な配布方式を研究開発する者ではありませんが、上記の予想にもかかわらず、何らかの新規な地理空間情報配布方式が提案され、それが自由に使え、さらにそれが性能上およびコスト上の優位を有するのであれば、それは採用に値すると思います。
ご質問のなかにある「既存の地図ライブラリで扱いやすい」ということこそが、すなわち、既存の複数の自由な実装で支えられているということが、バイナリベクトルタイルの非常に強力な利点です。また、その利点というのは場当たり的にあるいは偶然に形作られたものではなく、技術的な必然が巧みなマーケティングに加速されて形作られたものであると私は感じます。
なお、個人的には「自分が進むルートに関しては詳細にしてそれ以外は荒くするなどの調整」がクリティカルなユースケースであるのか、それを実現するためにサーバサイドの負担がかえって上昇していないか、というところも気になりました。提供者側の負担は、ウェブ地図にとってあきらかに律速要因となっており、ウェブ地図（タイル）の提供者が増えなかったり、提供者がコスト回収手段に苦労されるのは、提供者側の負担がまったく無視できないことが原因です。新たな技術が提案されるのであれば、それが提供者側のコストが減少する技術であれば、普及する可能性があると思います。しかし、人間の生活を変えるようなレベルの地理空間情報の新技術であるためには、そのデータが現実的に経済的なコストモデルで「湯水のように」流通するような新技術でなければならないと（現実の状況に基づいて）私は感じています。
そのような技術として、私はバイナリベクトルタイルの技術に最も可能性を感じています。