地図タイルへの入門知識を考える

## はじめに

Web 地図で利用するための **「地図タイル」を作成・管理する**というのはかなりマニアックな分野だと思います。そんなマニアックな分野に新しく来られた方へどのような知識をお伝えすればよいでしょうか？

これまで、Web 地図用のタイル（slippy map tilenames 形式）の記事をいくつか書いてきましたので、その整理も兼ねて、関連知識をまとめてみたいと思います。

:::note
* 基本的に、**本記事はリンク集**です。
* 自分の記事多めですが、足りない部分は、参考になる記事・資料へのリンクを掲載させていただいております。
* とはいえ、まだ偏り・不足が否めないです。
* 随時更新していければと思います。（大規模に変更する可能性もあります。）
:::

## 「タイルという仕組み」の名称

経験論として、「地図」の話をしている中で「タイル」という言葉が出てきたら、基本的に本記事で説明する slippy map tilenames 形式を示しているものと理解して良いかと思います。本記事タイトルの「地図タイル」はあまり使われない表現かもしれませんが、この経験に基づいて採用しています。

「地図タイル」にまつわる表現を少し例示してみます。

* OpenStreetMap Wiki ではタイルの仕組みを説明するのに、[slippy map tilenames](https://wiki.openstreetmap.org/wiki/Slippy_map_tilenames) というページが設定されています
* 内閣府の「スマートシティ・リファレンスアーキテクチャ」の別冊「[地理空間データ連携基盤](https://www8.cao.go.jp/cstp/society5_0/smartcity/scra-geospatialdata.pdf)」では、そのまま「地図タイル」という表現が出てきます
* また、国土地理院は、自ら提供するタイルを「地理院タイル」と呼んでいますが、一般的な表現として、「いわゆるXYZ方式」という呼び名を使っています
* 国連から提供されている「[Mapping for a sustainable world](https://digitallibrary.un.org/record/3898826?v=pdf)」という冊子では、tile-based (web) map や tileset という表現が出てきます
* タイルの仕組みに関係する標準技術としては、[Tile Map Service](https://wiki.osgeo.org/wiki/Tile_Map_Service_Specification) や [Web Map Tile Service (WMTS)](https://www.ogc.org/standard/wmts/) があります

この記事における「地図タイル」は、基本的に、slippy map tilenames をはじめとする上記の様々な表現で示された形式を指していますが、**広義では「あらかじめ分割された地図データ」** と考えても良いでしょう。

## 前提知識

タイルの仕組みを話す前に、地図の基本的な知識は必要になるかと思います。また、実際にタイルを作成・ホスト・配信・消費するには、情報科学分野（Web まわり）の知識が必要になるでしょう。

参考に、自分が勉強している間に出会ったキーワードをあまり系統や粒度を気にせず雑多に並べてみます。

<details>
<summary>地図関係のキーワード</summary>
地図投影法、測地系、メルカトル図法、経緯度、測量、地図編集（総描、省略、転位）、縮尺、地図情報レベル、GIS、ラスタデータ、ベクタデータ、メッシュデータ、ポリゴン、ライン、ポイント、POI、GeoJSON、Shapefile、KML、クラスタリング、ヒートマップ、地域メッシュ
</details>

<details>
<summary>Web 関係のキーワード</summary>
OS（Windows、Linux）、ファイルシステム、ブラウザ、デベロッパーツール、JavaScript、HTML、CSS、HTTPS、REST、Ajax、WebGL、canvas、非同期処理、（様々な）キャッシュ、PNG、JPEG、JSON、Protocol Buffers、クラウドサービス、クラウドネイティブ、サーバレス、Web サーバ、DNS、CDN、オブジェクトストレージ、データベース、オープンデータ、OSS、各種ライセンス（クリエイティブ・コモンズ・ライセンス等）、シングルページアプリケーション
</details>

## タイルの仕組み

### タイルの概要・分割方法

地図タイル（slippy map tilenames 形式）の概要や分割方法については、以下のサイトが参考となります。特に「**ズームレベル**」（ZL）という概念が重要です。

* [国土地理院「地理院タイルについて」](https://maps.gsi.go.jp/development/siyou.html)
* [佐藤 崇徳「Googleマップの投影法」](https://user.numazu-ct.ac.jp/~tsato/tsato/document/mapcenter460/)

タイルの基本的な考え方をまとめると、以下のようになるかと思います。
* まず、世界を正方形の地図とする
* ズームレベル（ZL）という指標に基づき、この正方形の世界をタイルへと分割する
* ZL が１つ大きく（深く）なると、１つのタイルは、縦横２分割ずつ、計４枚のタイルに分割される
* 各地図タイルは ZL (z)、経線方向座標（x）、緯線方向座標（y）で特定できる

（ズームレベルとタイル座標）
![ズームレベルとタイル座標（国土地理院HPより）.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2842832/3170eeae-0760-1c5a-08af-644191a42b82.png)
※国土地理院の「[地理院タイルについて](https://maps.gsi.go.jp/development/siyou.html)」のページより転載

なお、以下のサイトによれば、地図タイル（サイト中の表現は「zxyタイル」）は「標準仕様がない」ものであり、現状、**デファクトスタンダードとして普及**しているものと言えます。

* [松澤 太郎「OpenStreetMap Foundation Japanコミュニティ向けタイルサーバの構築事例」](https://knowledge.sakura.ad.jp/27416/)

### タイルの URL について

タイルデータを読み込む場合、ZL、X 座標、Y 座標をぞれぞれ `{z}`、`{x}`、`{y}` という表記で埋め込んだ **URL テンプレート**で扱うことが一般的です。

たとえば、地理院地図（標準地図）を読み込む場合、以下のような URL テンプレートを利用するツール（Web 地図ライブラリや GIS ソフトウェア）へ登録します。

```text:地図タイルの URL テンプレート代表例（地理院地図（標準地図））
https://cyberjapandata.gsi.go.jp/xyz/std/{z}/{x}/{y}.png
```

一般化すると以下のようになるでしょう。このような `{z}`、`{x}`、`{y}` が入った URL（URI）を見た場合は、地図タイルを示す URL テンプレートだと考えて良いかと思います。 

```text:一般化した地図タイルの URL テンプレート例
(通信プロトコル)://（ドメイン・フォルダパス）/{z}/{x}/{y}.（拡張子）?（クエリ等）
```

実際にデータを読み込むときは、テンプレート中の `{z}`、`{x}`、`{y}` を具体的な数字（たとえば、`{z}/{x}/{y}`→`2/3/1`）に置き換えてタイルデータへアクセスします。多くの場合、ツール側で状況に応じて必要なタイルを読み込んでくれます。

多くのタイルデータは、`{z}/{x}/{y}` という階層になっていることが多いですが、必ずしもこのような構造にこだわる必要はありません。

たとえば、`{x}` と `{y}` が逆になっている場合もあります。もっとテクニカルな例としては、GitHub Pages でタイルデータをホストするような場合、１レポジトリ当たりの制限にぶつかるかもしれませんが、その際に、レポジトリを ZL 毎に分けてしまうという方法も考えられます。

```text:変則的な地図タイルの URL テンプレート例
https://example.com/example-tile-{z}/tile/{x}/{y}.png （架空のタイル URL）
```

なお、このアイデアは以下の記事からいただいています。

* [gh-pagesで OSM 日本ベクトルタイル提供@hfu](https://qiita.com/hfu/items/e7c0318bba67827d4327)

ただ、このような変則的な URL テンプレートは、後々問題を起こす懸念があります。たとえば、以下の記事では、タイル URL から、ZL、X 座標、Y 座標を復元する際に混乱を生じる可能性を（やや極端ではありますが）例示しています。タイルを提供する際は、理由がなければ、`{z}/{x}/{y}` のテンプレートを採用することをおすすめします。

* [Maplibre GL JS の addProtocol の使い方を調べる@mg_kudo](https://qiita.com/mg_kudo/items/cc88be1ed46fa77871fd)


### 投影法（Web メルカトル）

この slippy map tilenames 形式では、Web メルカトル（Pseudo メルカトルとも）と呼ばれる投影法が用いられています。**WGS84で得られた経緯度を、真球を仮定してメルカトル投影を行う図法**です。

メルカトル図法は、地球上の角度と紙面上の角度が等しくなるように表現した図法です。経線は紙面上で平行に表されるため、緯度が大きくなるほど、経線間の差が拡大して表示されることになりますから、角度を正しく表示するため、緯線の間隔を、経線の間隔に合わせて拡大して表示しています。ただし、極へ近づくほど、図上距離が無限大に大きくなってしまいます。

そこで、**Web メルカトルでは、ちょうど正方形で示すことができる南緯約85度～北緯約85度の範囲を対象**としています。

ちなみに、Webメルカトルでは、楕円体で得られた WGS84 の経緯度を、楕円体ではなく真球を仮定して投影しているため、実は、厳密には正角図法ではありません。

Web メルカトルについては、以下の通り、整理を試みています。

* [Web メルカトル（EPSG:3857）について整理する@mg_kudo](https://qiita.com/mg_kudo/items/089e257570c19aa15100)
* [Web メルカトル（真球）と World メルカトル（楕円体）を比較する@mg_kudo](https://qiita.com/mg_kudo/items/1dd3ab9eda34321d3eb1)

（Web メルカトルにおける位置の取得～投影までの流れ）
![Web メルカトルにおける位置の取得～投影までの流れ](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2842832/eaeb0ce6-2791-c8da-ec30-74e6294284f0.png)

### タイル座標の計算

OpenStreetMap の Wiki には、経緯度とタイル座標を互いに変換する計算式が、各プログラミング言語の実装例とともに掲載されています。

* [Slippy map tilenames (OpenStreetMap Wiki)](https://wiki.openstreetmap.org/wiki/Slippy_map_tilenames)

### ラスタタイルとベクトルタイル

GIS データがラスタデータとベクタデータに分別されるように、それぞれの形式をタイル化した **ラスタタイルとベクトルタイル（ベクタタイル）** が存在します。１枚１枚のラスタタイルは、一定の大きさの画像データ（PNG や JPEG 等）となっています。ベクトルタイルも、広義には、特定のベクタデータ（例えば GeoJSON）を各タイル領域に分割したデータとなりますが、最近は、効率的に符号化された [Mapbox Vector Tile](https://github.com/mapbox/vector-tile-spec) という形式が普及しています。

:::note
この記事でも、ベクトルタイルは主に Mapbox Vector Tile を想定して記載しています。
:::

ラスタタイルとベクトルタイルの違い・特徴は、以下のサイトが参考となります。

* [国土地理院「国土地理院ベクトルタイル提供実験」](https://maps.gsi.go.jp/development/vt_expt.html)

### タイルの縮尺・解像度

１枚のタイルが示す縮尺（範囲）や解像度（つまりピクセルの大きさ）が気になることはあると思います。

そのような需要は多いのか、主な地図サービスには、タイルの縮尺や精度のイメージを説明するページが準備されています。

これらの解説ページでは、ズームレベル毎にタイル１枚又は１ピクセルがどのくらいの大きさになるのか、スクリーン解像度毎に画面上での縮尺はどれくらいになるか、という説明が主です。なお、**タイル１枚のピクセル数や画面上に表示するサイズによって、数字は変わってきます**ので、あくまで大まかな数字として捉えておくことが重要だと思います。

* [Slippy map tilenames#Resolution_and_Scale (OpenStreetMap Wiki)](https://wiki.openstreetmap.org/wiki/Slippy_map_tilenames#Resolution_and_Scale)
* [Zoom levels (OpenStreetMap Wiki)](https://wiki.openstreetmap.org/wiki/Zoom_levels)
* [Glossary | zoom level (mapbox)](https://docs.mapbox.com/help/glossary/zoom-level/)
* [Zoom levels and scale (esri Developer)](https://developers.arcgis.com/documentation/mapping-and-location-services/reference/zoom-levels-and-scale/)
* [Bing Maps Tile System#ground-resolution-and-map-scale (Bing Maps)](https://learn.microsoft.com/en-us/bingmaps/articles/bing-maps-tile-system#ground-resolution-and-map-scale)
* [Understanding Scale and Resolution (Bing Maps)](https://learn.microsoft.com/en-us/bingmaps/articles/understanding-scale-and-resolution)

私も日本周辺のタイルにまつわる数字を整理してみましたので、[この記事の最後の方](#タイル周りの数字)に掲載しています。


## タイルの生産

### 利用可能なツール等

タイルの生産方法については、以下の @Kanahiro 様の記事にて、最近のトレンドがまとまっており大変参考になります。

* [ラスタータイルの作り方（2024年版）@Kanahiro](https://qiita.com/Kanahiro/items/09abaa4ed80429b3ef28)
* [ラスタータイルのつくりかた（2022年版）@Kanahiro](https://qiita.com/Kanahiro/items/4b5f8db5743c69741220)
* [ベクトルタイルのつくりかた（2024年版）@Kanahiro](https://qiita.com/Kanahiro/items/ceeb20c158b4c70b62b6)

### タイルの設計

ツールによっては、データを流し込めばよしなにタイルを作成してくれるかもしれませんが、場合によっては、パラメータや作業フローを調整する必要があるでしょう。

特に、地図タイルの重要なコンセプトである **ズームレベル（ZL）がタイルデータ生産以後に及ぼす影響は非常に大きい**ので、必要精度やコスト等をよく考えて ZL を設定する必要があるというのが私の持論です。

* [地図タイルを ZL １つ分深く作るための覚悟@mg_kudo](https://qiita.com/mg_kudo/items/b3ae4071a69d4026550c)

また、ベクトルタイルの場合、ラスタタイルと異なり、どのようなデータ構造とするか、より深い検討が必要になります。特に、ベクトルタイルでは、**何も考えずにタイルを作成すると、非常に大きなサイズのタイル**が生じてしまいます。そのため、適切に各 ZL で表示する地物を選んでタイルを作成する必要性が強くなります。以下は、ZL に応じてどのように地物を取捨選択するかを検討した例です。

* [小縮尺地図におけるポイントデータのデザイン@mg_kudo](https://qiita.com/mg_kudo/items/69976494b9a95893db11)

また、以下はベクトルタイル（Mapbox Vector Tile）特有の構造の違いが表示速度に及ぼす影響を検証をしてみた記事です。

* [Mapbox Vector Tile の source-layer 数が描画速度に及ぼす影響@mg_kudo](https://qiita.com/mg_kudo/items/b09440ab915b2e4dc52d)

巨大なデータを取り扱う場合は、データの分割処理を含めて、作業フローの検討が必要です。参考に、以下は、全世界のデータをベクトルタイルへ変換するための取り組みが紹介された論文となります。「4.2.3 Module-wise Hosting」「5.1.2 Division of the globe into 12 areas」あたりが、大規模なデータを取り扱う考え方のヒントになると思います。

* [Fujimura et al. (2019) DESIGN AND DEVELOPMENT OF THE UN VECTOR TILE TOOLKIT](https://isprs-archives.copernicus.org/articles/XLII-4-W14/57/2019/)

なお、上記論文で紹介されている UN VECTOR TILE TOOLKIT は、ベクトルタイルの設計にあたり「生産→ホスト→地図デザイン（スタイル）→最適化→生産→……」というサイクル（see Figure 1.）を回すことを主なターゲットとしており、このサイクルもベクトルタイルの設計実務において参考になるかと思います。

## タイルのホスト・配信

タイルを配信する場合は、Web サーバなどにホストする必要があります。利用する環境次第ということもあり、本記事での詳細は割愛しますが、**タイルデータは静的コンテンツである**という点を活かして、AWS の S3に置くだけで配信できたり、GitHub Pages でのホストも可能です。

ただし、タイル管理の関係上、タイル用のサーバを設定することもあり得ます。以下は、再掲ですが、タイルサーバについて解説されたサイトです。

* [松澤 太郎「OpenStreetMap Foundation Japanコミュニティ向けタイルサーバの構築事例」](https://knowledge.sakura.ad.jp/27416/)

タイル周辺知識が分かりやすく解説されていますが、ポイントは以下の点です。

> インフラ系の人なら、「これを静的にファイル持ってたら死ぬんじゃない？」って気づくかもしれません。実際のところ静的なファイルとしてホスティングしてしまうとファイルシステムの限界に当たってしまいます。今回作成しているタイルサーバではtileserver-glおよびmbtilesというファイルを使うことでこれを解決しています。なお、地理院地図ではCDNにホスティングをしてこの問題を解決しています。

上記の通り、大規模なタイルセットをそのまま静的ファイルとして保持すると、**ファイル数が非常に多くなり、管理が非常に難しくなる**点は認識しておく必要があります。

:::note
どの程度のファイル数になるかは、この記事の最後の方（[タイルの管理](#タイルの管理)）にてご紹介します。また、再掲ですが、「[地図タイルを ZL １つ分深く作るための覚悟@mg_kudo](https://qiita.com/mg_kudo/items/b3ae4071a69d4026550c)」でも、タイル数にまつわるコストについて説明しています。
:::

## タイルの消費・活用

### ウェブ地図として閲覧する

タイルを作成した主目的は、Web 地図で利用するためである場合が多いと思います。

タイルデータを表示できる主要なライブラリを列挙してみますが、利用したいユースケースに合わせて選択できればよいと思います。このほか、QGIS 等の GIS ソフトでも対応している場合が多いです。

* [Leaflet](https://leafletjs.com/) / [OpenLayers](https://openlayers.org/) / [Mapbox GL JS](https://docs.mapbox.com/mapbox-gl-js/api/) / [MapLibre GL JS](https://maplibre.org/)

個人的な感覚ですが、ラスタタイルだけの場合は Leaflet が利用されている場合が多く、ベクトルタイル（Mapbox Vector Tile）が利用される場合は、Mapbox GL JS か MapLibre GL JS が使われています。

* [MapLibre GL JSをLeafletとの違いに注目して紹介する@Kanahiro](https://qiita.com/Kanahiro/items/452cc021de0e11287cc0)

MapLibre GL JS は、Mapbox GL JS から派生したウェブ地図用のライブラリですが、分岐して久しく、それぞれ機能の違いがあります。特に、MapLibre GL JS の場合、`addProtocol()` という大変便利な機能があり、大きな差別化点となっています。（この `addProtocol() ` については[後述](https://qiita.com/mg_kudo/items/9f0b7a4f108ad96d9c25#%E5%A4%9A%E6%A7%98%E3%81%AA%E3%83%87%E3%83%BC%E3%82%BF%E5%BD%A2%E5%BC%8F%E3%82%84%E5%88%86%E5%89%B2%E6%96%B9%E6%B3%95%E3%81%B8%E3%81%AE%E5%BF%9C%E7%94%A8)します。）

また、三次元表現に強い [deck.gl](https://deck.gl/) というライブラリも各種タイルデータに対応しています。ご参考に、この deck.gl と Mapbox GL JS/MapLibre GL JS を用いて、国土地理院から提供されているベクトルタイルを三次元風に表示するサンプルを作成してみました。国土地理院でも、[点群タイル閲覧サイト](https://github.com/gsi-cyberjapan/3dpc-3dtiles)の構築に、deck.gl と MapLibre GL JS を利用しているようです。

* [地理院地図Vector を 3D っぽく見せる@mg_kudo](https://qiita.com/mg_kudo/items/6079ac10b7994e391228)
* [地理院のベクトルタイルを 3D っぽく見せる（2025 新年版）@mg_kudo](https://qiita.com/mg_kudo/items/f6ea34938d5d0f3d326a)


### ベクトルタイルのスタイルについて

ベクトルタイルを利用する場合、別途、地図をどのように描画するかの設定を行う必要があります。Mapbox GL JS や MapLibre GL JS では、Style Specification という、地図のデザイン（私は「スタイル」と呼んでいます）を指定する設定があります。

#### スタイルの事例

好きなデザインを実現するためには、地道に公式サイト（[Mapbox](https://docs.mapbox.com/style-spec/guides/)/[MapLibre](https://maplibre.org/maplibre-style-spec/)）を読んでいくことになると思いますが、たとえば、以下のアドベントカレンダーには、Style Specification の解説・実装例が充実しており、参考になるかと思います。

* [MapLibre Advent Calendar 2023](https://qiita.com/advent-calendar/2023/maplibre)

また、既にあるスタイルを改造する、という方法も有効かと思います。以下は、国土地理院提供のスタイルを改造する方法です。

* [地理院の最適化ベクトルタイル用にオリジナルスタイルを作成する@mg_kudo](https://qiita.com/mg_kudo/items/2560f663d657c3ce1125)

工夫すれば、遊び的なデザインも可能で、以下はクレヨン風のスタイルを試作してみた記事です。

* [クレヨン風の地図@mg_kudo](https://qiita.com/mg_kudo/items/d58dd35499f7e83d553f)

#### スタイルとパフォーマンス

また、**スタイル設定も複雑になるにつれ、表示速度へ影響が生じます**。タイルの設計にも関係しますが、大規模・複雑なデータの場合、スタイルの部分でもパフォーマンスに検討が必要です。

* [スタイルレイヤ数を減らすとベクトルタイルの描画が速くなるという検証@mg_kudo](https://qiita.com/mg_kudo/items/f9b6ab97b2ab670b638c)

#### （参考）OpenLayers について
<details>
<summary>OpenLayers について</summary>

OpenLayers 関係の情報はかなり少ない印象ですが、以下のように[水戸地図(β)](https://cieloazul310.github.io/2022/09/ol-gsi-vt/)様から、国土地理院のベクトルタイルの表示に関するツール・情報が提供されています。

* [ol-gsi-vt](https://cieloazul310.github.io/ol-gsi-vt/)

私も OpenLayers でのベクトルタイル表示方法を検討してみたことがあります（私の実装での性能はそんなによくありません）。

* [OpenLayers で地理院地図Vector を表示する@mg_kudo](https://qiita.com/mg_kudo/items/e29853c7d3976b52ca29)

</details>

### データベース代わりに使う

タイルは、Web 地図上で可視化するだけでなく、タイル１枚１枚をデータベースの断片として、データ取得 API のように利用することができます。この場合、１枚のタイルは**事前に空間検索・地物のフィルタ等を完了させた結果のキャッシュ**と考えてよいでしょう。

#### グリッド PNG タイル

たとえば、国土地理院では、[標高タイル](https://maps.gsi.go.jp/development/demtile.html)が提供されていますので、以下のように、タイルデータを用いて特定地点の標高を得ることができます。

1. 標高を知りたい地点の経緯度をタイル座標とタイル内のピクセル座標へ変換する
2. 目的のタイル座標の標高タイルをダウンロードする
3. タイルの中の目的のピクセル座標の情報を標高値へデコードする

（参考：[標高を求めるプログラム](https://maps.gsi.go.jp/development/elevation.html)）

産総研では、このような使い方のできるタイルを「グリッド PNG タイル」という考え方で整理しているようです。

* [産総研「グリッド PNG タイル」](https://gsj-seamless.jp/labs/datapng/gridpngtile.html)

私も、過去、標高タイルや重ねるハザードマップのオープンデータを用いて、標高値や洪水・津波などの浸水深を取得・利用させていただいたことがあります。

* [Web 上で島や湖の体積を概算する@mg_kudo](https://qiita.com/mg_kudo/items/812af66783a2126999ca)
* [駅の浸水リスクをざっくり可視化する@mg_kudo](https://qiita.com/mg_kudo/items/a6b4b53f2cacfacac9a0)
* [洪水時の浸水深をボクセル風に立体化する@mg_kudo](https://qiita.com/mg_kudo/items/7ee95f1d79a26d86bef2)

#### メッシュ統計としてのラスタタイル

ラスタタイルは、地図データを一定の大きさ（一般的に 256 px 又は 512 px 四方）の画像データに分割したものですが、それぞれの画像データ（タイル）は、さらに個々の画素（ピクセル）に分割されたものとなります。そのため、この１つ１つのピクセルをデータと考えると、ラスタタイルは 「（タイル状に分割された）メッシュデータ」 とみなすことができます。

基本的に、同じ仕様のラスタタイルであれば、メッシュのサイズは同一であるため、結果的に「**どのラスタタイルも統一的なメッシュデータとして扱える**」ということになります。

タイルデータは今や様々な機関から提供されているので、大規模なメッシュ統計のリソースとして活用できる可能性があります。

以下の記事は、ラスタタイルが統一的なメッシュであることを活かして、複数のタイルを組み合わせて色々な演算をしてみた例となります。

* [ラスタタイルと addProtocol でメッシュ統計@mg_kudo](https://qiita.com/mg_kudo/items/62498b053d841644c4e2)
* [MapLibre でタイルの差分確認@mg_kudo](https://qiita.com/mg_kudo/items/d934b7bd51a2605284d3)

また、以下は、日本でよく利用されている地域メッシュとタイルのグリッドの比較や変換の際の ZL 設定について調べた記事です。

* [地域メッシュとタイルのグリッド比較@mg_kudo](https://qiita.com/mg_kudo/items/567ac5837d6c075081b5)

#### 多様なデータ形式や分割方法への応用

データとして使う場合は、これまで説明したラスタタイルやベクトルタイルの形式にこだわる必要はありません。たとえば、分割方法に slippy map tilenames 以外の方法（地域メッシュ等）を採用しても良いかもしれませんし、GeoJSON ファイルや CSV ファイルをタイル状に分割して管理するという方法も考えられます。

:::note
本記事で、地図タイルの広義な定義を「あらかじめ分割された地図データ」と考えたのは、上記のような slippy map tilenames 以外の分割方法を想定したためです。
:::

例えば、国土地理院からは、「対象タイルにどのような種類のタイルが存在するか」を示した CSV 形式のメタデータ（ココタイル）をタイル状に分割して提供するというアイデアが示されています。

* [ココタイル仕様/cocotile-spec（国土地理院 GitHub レポジトリ）](https://github.com/gsi-cyberjapan/cocotile-spec) 

また、GeoJSON は Web 地図でよく利用されるデータ形式ですが、これを地図タイルとして分割して配信するという方法（GeoJSON タイル）もありえます。GeoJSON タイルは、他ではあまり見かけませんが、地理院地図ではよく利用されている方法です。各 Web 地図ライブラリではネイティブでサポートされていませんので、独自実装が必要になります。以下は、MapLibre GL JS を利用した実装例です。

* [MapLibre で GeoJSON タイルを読む@mg_kudo](https://qiita.com/mg_kudo/items/832ee30ed39b6c25df60)

Mapbox GL JS の v3 とともにリリースされた Mapbox の新スタイルでは、各都市のトレードマーク的な建物の美しい三次元表現が追加されましたが、データ実装としては、3D データ（`.b3dm`）を地図タイルの形式に分割して、配信されているようです。

* [Mapbox の新スタイルと GL JS v3 の新機能@mg_kudo](https://qiita.com/mg_kudo/items/92283d017f7528f06c5e)

:::note
なお、オリジナル形式のタイルを採用する場合、タイル読込機能自体を独自実装する必要もあるでしょう。以下は、オリジナル形式のデータを読み込む自作タイルローダーを組み込んだ Web 地図の例です。

* [3次元電子国土基本図を Web 地図にしてみた@mg_kudo](https://qiita.com/mg_kudo/items/722431f979f846f426e0)

MapLibre GL JS の場合、`addProtocol()` という便利な機能があり、タイルデータを自由に生成・加工しながら Web 地図で消費することが可能です。本記事で引用している MapLibre GL JS を用いた各種実装（例：GeoJSON タイル）でも、この機能が多用されています。 

* [MapLibre GL JSのaddProtocolとは何なのか@Kanahiro](https://qiita.com/Kanahiro/items/2058c74df7149595d569)
* [Maplibre GL JS の addProtocol の使い方を調べる@mg_kudo](https://qiita.com/mg_kudo/items/cc88be1ed46fa77871fd)

:::

このように地図タイルをベースに様々な工夫が施されるかと思いますが、独自の分割方法やデータ形式を利用する場合は、将来的な相互運用性をよく考慮すべきだと思います。以下の記事はタイル分割に関する注意点が示唆されています。

* [業界標準ではないタイルに分割したいという問いに対するいけ好かない答え@hfu](https://qiita.com/hfu/items/df8b29226825f6a38058)

## タイルの管理

### タイルにまつわるコスト
タイルは細かいデータの集まりです。そのため、あまりにも多いタイルをファイルシステム上で保持すると、**データのコピー等で時間がかかる**ことが多くなるなど、弊害も生じてきます。（本記事でも何度か言及している通りです。）

以下の記事では、どの程度のタイルデータ（ファイル数や容量）があるのか、タイルごとのサイズがどのように分布するのか、日本全国をカバーするようなデータの規模感（国土地理院のラスタタイル・ベクトルタイルの例）を調べてみました。

* [ベクトルタイルのサイズ分布を観察する@mg_kudo](https://qiita.com/mg_kudo/items/f6d3a1ec5c0117237fd3)
* [PMTiles からタイル一覧とサイズを取得する（国土地理院最適化ベクトルタイルを例に）@mg_kudo](https://qiita.com/mg_kudo/items/9f87fca0c579fd2b645d)


### タイルセットを１ファイルにまとめる
大量のファイルが問題であれば、１つのファイルにまとめるというのはアプローチの１つです。

タイルを１セットにまとめた「MBTiles」は、大量のタイルデータを扱う上でよく使われるデータ形式です。ただし、SQLite ベースなので、タイルを取り出すには**サーバ側の実装**が必要となります。

* [Glossary | MBTiles (mapbox)](https://docs.mapbox.com/help/ja/glossary/mbtiles/)

すでに紹介させていただいる[タイルサーバの構築事例](https://knowledge.sakura.ad.jp/27416/)も MBTiles を用いていますね。

最近は、サーバ側の実装を必要としない形式でタイル一式を１つのファイルにまとめた「PMTiles」というファイル形式も普及しつつあります。こちらは、サーバ側の実装の代わりに**クライアント側の実装**でもデータを取り出すことができます。

* [PMTiles の仕様と取扱いを勉強してみる@mg_kudo](https://qiita.com/mg_kudo/items/3179639c79c1734fd373)
* [ウェブ地図で複数の PMTiles をひとつの Source として扱う方法@mg_kudo](https://qiita.com/mg_kudo/items/6fa899f4532ba2fe879b)（←こちらは結構マニアックかもしれません）

### タイル管理用のメタデータ

また、特に大規模にタイルを管理する場合においては、各タイルセット（レイヤ）の情報や、タイル１枚１枚の所在情報をメタデータとして持っておく必要も出てくるかもしれません。国土地理院では各種メタデータの仕様を整理していますので、以下の記事でその一部を紹介しています。

* [地理院タイル周りの３つのメタデータとその応用を考える@mg_kudo](https://qiita.com/mg_kudo/items/0d4a010db7e513a4d58e)


## タイル周りの数字

日本周辺のタイルに関する数字をまとめた１枚紙を作成してみました。何かの参考になれば幸いです。（中の数字は「[地図タイルを ZL １つ分深く作るための覚悟](https://qiita.com/mg_kudo/items/b3ae4071a69d4026550c)」で扱ったものです。）

（地図タイルにまつわる数字（日本周辺））
![地図タイルにまつわる数字（日本周辺）（2024-01-11更新）.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2842832/5317cf62-fa86-395b-cbc1-2dc1e5dc0452.png)

## おわりに

これまでの記事の整理と合わせて、地図タイルにまつわる関連知識をまとめてみました。おそらく足りない部分や、初めての方にはマニアックすぎるものもあるかと思います。目的によって、ロードマップも変わってくるかと思います。また機会があれば、この記事にも手を入れていきたいです。