地理院地図Vector の従来版と最適化版の比較メモ

## はじめに

国土地理院では、地理院地図Vector をはじめとして、ベクトルタイルの提供実験を行っていますが、2022年9月6日に、最適化ベクトルタイルの提供が開始されました。

>「最適化ベクトルタイル」は、これまで地理院地図Vector（仮）において試験提供してきた地理院ベクトルタイルの課題を踏まえて、設計改良を施したものです。

「最適化ベクトルタイル」は、以下従来提供されていた地理院地図Vectorのベクトルタイルとは大きく異なるようですが、具体的にどこを変更したのか明記はされておりませんでした。そこで、私が見つけた「最適化」の内容をメモしていきたいと思います。

### 「最適化ベクトルタイル」のレポジトリ

https://github.com/gsi-cyberjapan/optimal_bvmap

### 従来の地理院地図Vector（仮称）提供実験のレポジトリ

https://github.com/gsi-cyberjapan/gsimaps-vector-experiment

## 追記について

### 2023/01/08 追記
第14回地理院地図パートナーネットワーク会議（2022/12/06）で、国土地理院が[国土地理院最適化ベクトルタイルの特徴](https://maps.gsi.go.jp/pn/meeting_partners/data/20221206/03_%E6%9C%80%E9%81%A9%E5%8C%96%E3%83%99%E3%82%AF%E3%83%88%E3%83%AB%E3%82%BF%E3%82%A4%E3%83%AB%E3%81%AE%E7%89%B9%E5%BE%B4.pdf)という資料を公開しておりましたので、こちらの情報を踏まえて追記しました。

https://maps.gsi.go.jp/pn/meeting_partners/14th_meeting.html

## 比較方法

きちんと網羅的に比較するのであれば、上記のレポジトリで提供されている仕様書等を比較したり、実際にデータを触ってみたりするべきだと思いますが、横着して、以下のような比較サイトを作って、「気づいたところ」をメモすることにしました。

### 比較サイト

https://mghs15.github.io/compare-vector-tiles/index.html

![スクリーンショット 2022-09-24 143348.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2842832/76f3b151-b0c3-1261-b3b0-c8a07c2a7ce9.png)

上記サイトのレポジトリ

https://github.com/mghs15/compare-vector-tiles


## データ上の気づき

最適化ベクトルタイルのデータそのものについて、気づいた点を列挙してみます。

* ベクトルタイルの source-layer の構成が整理されています。また、source-layer の命名法則について、どちらも、地物の大まかな分類と、図形の種類（点、線、面）で構成されているのは変わらないようですが、言葉の省略方法等が変更されているようです。また、最適化版でも、図形の種類が混在する source-layer があります。

    * 従来：`symbol`, `boundary`, `road`, `railway`, `searoute`, `coastline`, `river`, `lake`, `waterarea`, `elevation`, `transp`, `contour`, `landforma`, `structurea`, `wstructurea`, `wstructurea`, `building`, `transl`, `structurel`, `landformp`, `landforml`, `label`

     * 最適化：`AdmArea`, `AdmBdry`, `RdEdg`, `RdCompt`, `RdCL`, `RailTrCL`, `BldA`, `StrctLine`, `StrctArea`, `WA`, `Cstline`, `WL`, `RivrCL`, `WStrA`, `WStrL`, `WRltLine`, `SpcfArea`, `Cntr`, `Isbt`, `TpgphArea`, `TpgphLine`, `RailCL`, `Anno`

* ZL 毎に格納されている地物が整理されています。一般論として、タイルの設計を考えるときに、ZL が大きくなるにつれて、細かいデータを格納・表示していくのが自然だと思います。従来では地物の種別ごとにタイルに格納されていましたが、最適化版では、地物の相対的な重要さ？（大きさ？）を考慮して、格納される ZL が決定されているようです。
	* 例えば、小さな ZL は、「高層建物」や「都道府県道」が入っているが、「普通建物」や「市町村道」は一切入っていないという設計でした。最適化版では、大きな建物や道路は、たとえ「普通建物」や「市町村道」であっても、小さな ZL へ格納されているようです。

![スクリーンショット 2022-09-24 152510.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2842832/7c00d073-f903-7573-d1a0-048c15afce1f.png)
![スクリーンショット 2022-09-24 153542.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2842832/3e7b99ce-3a6f-0451-3f1d-5f7e91649d08.png)
下の画像は、source-layer と地物の種類だけでスタイリングしたものです。スタイル上、表示されていないということもなく、データの段階で整理がされています。

* データを削減傾向にあり、地物の数が減ったように思われます。地物は、より大きな ZL に格納されるようになっているようです。目につくところだと、建物データがだいぶ削減されているほか、建物の外周線データは削除されているようです。
	* 東京付近のタイルデータを簡単に見てみましたが、かなり軽くなっています。建物データが影響する ZL13 以上だと、1/2～1/4 にも軽くなっているケースがありました。
	* 国土地理院によると、1枚のタイルサイズを最大 256 kB 以下となるよう設計したとのこと。
	* また、建物データの削減（外周線の削除や建物ポリゴンの間引き）の他、水域（河川）や等高線の削除（ZL8）、岩・崖・雨裂等を削除（ZL14）、水域ポリゴンの間引き・水涯線の削除（ZL14～15）がなされているようです。（詳しくは、[国土地理院の資料](https://maps.gsi.go.jp/pn/meeting_partners/data/20221206/03_%E6%9C%80%E9%81%A9%E5%8C%96%E3%83%99%E3%82%AF%E3%83%88%E3%83%AB%E3%82%BF%E3%82%A4%E3%83%AB%E3%81%AE%E7%89%B9%E5%BE%B4.pdf)を参照。）

* 属性値が整理されています。従来は、ZL 間で属性値の体系が分断されているところがありましたが、全体を通して属性値名が統一されています。
	* 属性値が日本語になっています。日本人にはわかりやすいかもしれません。ただ、文字コード等でのトラブルがないか少し不安を感じます。
	* 属性値の `vt_dsppos` で文字のアンカーに対する表示位置を設定していますが、ほかの属性値の `vt_arrng` や `vt_arrngagl` と組み合わせて調整が必要であるため、もう少しシンプルな構成にできないだろうかと考えてしまいます。（Mapbox GL JS や Maplibre GL JS での利用を前提とした場合、スタイルが煩雑になるのも気になるところです。）

* 属性値の整理に伴い、データを分離しやすくなりました。鉄道データは、従来は複雑なコードで分類していましたが、シンプルになりました。また、水面データが海、湖、川を分けられるようになったようです。

    * 小縮尺では、河川の水面ポリゴンが表示されなくなっています。これが、水面ポリゴンを属性値で分類した大きな理由かもしれません。（国土地理院の資料を確認したところ、ZL15でも水涯線の削除や大きさに応じた水面ポリゴンの削除をしているとのこと。）
![スクリーンショット 2022-09-30 000147.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2842832/ca284291-4c85-a6a9-94f4-9aba980930ef.png)

* 新しいデータとして、小縮尺と大縮尺で陸地を示すポリゴンデータが入っています。
	* これにより、ZL4～6 で、海の表現ができるようになっています（海自体は、 `background` レイヤを水色で塗りつぶすことで表現。）
	* ZL14以上で、「行政区画」というデータが入りました。ただし、市町村名等の属性値は存在しないようですので、現状の使い道は不明です。

* 注記の表現として、今まで点として格納されていたが、ラインデータとして格納されているデータがあります。
	* 従来では、１文字ずつばらばらに表示されているような注記を、ラインデータに一括で格納したように思われます。
	* 国土地理院によると、元データで「表示角度」が設定されている注記も線データに加工したとのことです。これで、回転しても、元の線状地物（鉄道や道路、河川）に沿わせることができます。

![スクリーンショット 2022-09-24 145034.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2842832/e59a04eb-6e6b-25cf-46e4-4d888800553c.png)
たとえば、上記の「北関東自動車道」の場合、従来は「北」「関」「東」……の各文字が単独で格納されたポイントデータとなっていましたが、最適化版では、「北関東自動車道」が一括で格納されたラインデータとなっています。

* 水上・海上交通を示すフェリーのマークが、従来はラインデータでしたが、ポリゴンデータとして直接形状を再現する方式に変わっています。
    * 国土地理院によれば、凹地方向線の矢印記号も直接形状をラインデータで表現する作戦としたようです。
    * ただし、同じ矢印でも、流水方向は、点データで、矢印のアイコン（画像）を流水方向に応じて回転させています。

![フェリー比較_属性値付き.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2842832/ae40858f-f43c-488a-a52d-919731738b5a.png)

## スタイル上の気づき

スタイル自体は、場面ごとに最適な設定が異なるので、両レポジトリのスタイルを単純に比較することはできないですが、以下のような点に気がつきました。


* ZL を大きくしていく際に、新しい地物がいきなり現れるのではなく、透過度を変えて、だんだんと表示されてくるような表現が採用されています。

* 描画順を制御するための `symbol-sort-key`、`line-sort-key` 等の設定を積極的に利用している様子。
	* データにも、例えば、道路では、描画順のための属性値 `vt_drworder` が設定されています。

* データの属性値は整理されたが、スタイルの filter 等はかなり複雑になっています。従来のスタイルとは別の部分の複雑性を感じます。
	* filter に `step` を適用している例は初めてです。そんな使い方ができるのですね。


## 課題として残っていそうな部分

従来から、個人的に気になっていた部分で、今回の最適化の変更点から漏れていた部分を紹介します。

* 注記のアンカー部分の座標値は調整されていないようです。そのため、以下の「とうきょうスカイツリー駅」のように、対象物からだいぶ離れてしまう注記がある、という問題は、今回の最適化でもまだ対応はできていないようです。
	* ポイントデータ（ POI ）であれば、対象地物に注記も含めてしまうのが、最高の解決策な気がします。駅のような、点としてもとらえられる地物も、この方式でよいのではと感じています。
	* ラインデータも、対象地物に含められるとよいと思いますが、ラインデータが細かくわかれていると、扱いが難しそうです。長い注記を表示するのに、対象地物の長さが十分でないかもしれません。

* Mapbox GL JS では、`text-writing-mode` で縦書き表示ができるのですが、これを用いると、縦書き時に長音符（ー）が縦書きにならないようです。なお、これは、データやスタイルの問題ではなく、使用しているライブラリの問題です。（地理院地図Vector では、プラグイン等で解決しているようです。）

![スクリーンショット 2022-09-24 153913.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2842832/a844ec4a-77d3-7b52-b3fe-07f1739e5d0e.png)
「とうきょうスカイツリー駅」という注記の座標値や長音符（ー）の表示の違い

* 河川の水面ポリゴンは、細いことが多いですが、小縮尺だと、タイル内座標や Mapbox GL JS での描画の解像度の影響もあり、データ自体でも見た目でも、かなり細切れになってしまいます。小縮尺の河川は、ポリゴンで表現するよりも、ラインデータとした方が、個人的に使いやすいような気がします。

## 終わりに

以上の通り、なるほどと思う変更点が多かったです。今回の最適化は、破壊的な変更になりますので、かなり根本のデータ設計から見直したのではないかと予想しております。

他に気づいた点があれば、追記していきたいと思います。