maplibre-tile-sources

MapLibre タイルソース

MapLibre GL JS には地図データは付属していません。ソース（MapLibre が取得して描画する URL またはインラインデータ）を参照するスタイルを指定します。MapLibre は、住所が 200 件の店舗検索地図、市内の交通地図、世界規模のベースマップのいずれにも同様に適しています。適切なソースタイプは、地理的な規模や詳細度、更新頻度、インフラストラクチャの制約、用途によって異なります。

このスキルでは、ソースタイプの選択について説明します。設定済みのソースを描画する方法については、maplibre-source-wiring を参照してください。

このスキルを使う場面

• 新しい MapLibre マップを設定し、データの取得元を選ぶとき
• 特定のサイズのデータセットについて、GeoJSON とタイルのどちらを使うか判断するとき
• タイルインフラストラクチャがそもそも必要かどうか検討するとき
• ベースマップと独自データをどのように組み合わせるか計画するとき

スタイルとソースの仕組み

スタイル（スタイル JSON、スタイルドキュメント、またはスタイルオブジェクト）は、MapLibre に渡す設定です。MapLibre GL JS と MapLibre Native の双方で互換性を保ちながら管理されているMapLibre スタイル仕様に基づく描画ルールが含まれます。

プロバイダーが提供するスタイル URLを利用できます。この URL は、ソース、レイヤー、グリフ、スプライトを含むスタイルを参照します。または、独自のスタイルを作成し、それぞれを自分で設定することもできます。

スタイルには、主に 3 つの構成要素があります。

• ソース — 実際のデータを参照します。各ソースには type があり、インラインデータまたは URL のいずれかが指定されます。ビューポートの変化に応じて、MapLibre がタイルまたはデータをリクエストします。同じソースを複数のレイヤーで使用できます（例：道路、水域、ラベルのすべてを 1 つのベクター URL から取得）。
• レイヤー — 描画する内容とその方法を定義する順序付きリストです。各レイヤーはソース（ベクタータイルの場合は source-layer 名も）を参照し、ペイント／レイアウトプロパティを指定します。
• グリフとスプライト — フォントの SDF スタックとアイコンスプライトシートの URL です。sprite にフォールバックはありません。アイコンが見つからない場合は省略され、コンソールに Image "<id>" could not be loaded という警告が表示されます。アイコン ID が定義されているかどうかは map.hasImage(id) で確認できます。glyphs には GL JS ≥ 5.11.0 でフォールバックがあります（ローカルフォントまたはシステムフォントでテキストが描画されます）。仕組みと制限については、maplibre-fonts-glyphs を参照してください。本番用のスタイルでは、引き続き両方を明示的に指定する必要があります。

ソースタイプ：

タイプ	説明
vector	ベクタータイル — ジオメトリと属性をバイナリー形式でエンコードしたもの。ベースマップやデータオーバーレイの主要フォーマットです
raster	ラスタータイル画像 — 衛星写真、WMS／WMTS レイヤー
raster-dem	標高タイル — 地形の描画や陰影起伏図に使用します
geojson	GeoJSON データ — インラインオブジェクトまたは URL。タイルサーバーは不要です
image	ジオリファレンスされた単一の画像 — スキャンした地図、注釈付きオーバーレイ
video	ジオリファレンスされた動画

vector と raster は、ベースマップやデータオーバーレイで最もよく使われます。geojson は、小規模なデータセットや、タイル化が不要なインタラクティブデータに最適です。raster-dem は地形や陰影起伏の効果のほか、科学的な可視化における新たな用途にも使用されます。image と video のソースはあまり一般的ではありませんが、静止画像（スキャンした地図、図表、オーバーレイなど）やジオリファレンスされた動画を、地図レイヤーとして配置できます。

GeoJSON と直接データソース

多くのユースケースでは、タイルサービスは必要ありません。MapLibre は、インラインの GeoJSON オブジェクトまたは GeoJSON ファイルの URL から、ポイント、ライン、ポリゴンを直接描画できます。データセット全体がダウンロードされ、ブラウザー内で解析されます。MapLibre はクライアント側で描画を処理します。

map.addSource('my-data', {
  type: 'geojson',
  data: '/path/to/data.geojson' // or an inline GeoJSON object
});
map.addLayer({
  id: 'my-layer',
  type: 'fill',
  source: 'my-data',
  paint: { 'fill-color': '#0080ff', 'fill-opacity': 0.5 }
});

GeoJSON のパフォーマンスの目安

GeoJSON は読み込みのたびにファイル全体をダウンロードします。小規模なデータには適していますが、規模が大きくなるにつれて予測可能な形でパフォーマンスが低下します。

範囲	ファイルサイズ／フィーチャー数	動作
最適な範囲	< 2 MB／< 5,000 フィーチャー	瞬時に読み込まれ、操作もスムーズです
遅延が発生する範囲	5–20 MB／最大約 50,000 フィーチャー	解析に 1～3 秒かかります。モバイル端末では処理が難しくなる場合があります。ジオメトリの簡略化と座標精度の低減で最適化できます
クラッシュの危険がある範囲	> 50 MB／> 100,000 フィーチャー	ブラウザーがフリーズまたはクラッシュするリスクが高くなります。ベクタータイルに切り替えてください

GeoJSON はロスレス（座標が正確に保持されます）で、フィーチャーのプロパティにクライアント側から完全にアクセスできます。インタラクティブなデータ、動的な更新、サーバーとの往復なしにフィーチャーをクエリまたは変更する必要があるデータセットに最適です。

データセットがこれらの目安を超える場合や、ズームに応じた描画（低いズームレベルでは詳細度を下げる）が必要な場合は、代わりにベクタータイルを検討してください。

その他の形式とクラウドネイティブなエコシステム

データソースの選択は、パフォーマンスだけで決まるわけではありません。データ型、更新頻度、アクセスパターン、より広範な地理空間エコシステムもすべて関係します。FlatGeobuf、GeoParquet、Cloud-Optimized GeoTIFF、KML、GPX など、多くの形式をプラグインやカスタムプロトコル経由で MapLibre に表示できます。HTTP レンジリクエストと分散ストレージ向けに設計された形式を扱うクラウドネイティブな地理空間エコシステムは急速に進化しており、ウェブマップとの関連性も高まっています。awesome-maplibre の 地図描画プラグイン と ユーティリティライブラリ のセクションを参照してください。

タイルが必要な場合

ベクタータイルは、現在のビューポートに表示されているデータのみを、コンパクトなバイナリ形式で読み込みます。次の場合に使用してください。

• データセットが GeoJSON の実用的な上限を超える場合
• ズームに応じた描画（ズームレベルごとに異なる詳細度）が必要な場合
• 陸地や水域、道路、地名などのグローバルまたは地域の参照レイヤー（つまり、ベースマップデータ）が必要な場合
• 大規模な運用で帯域幅の効率が重要な場合

ベクタータイルとラスタータイルの比較

タイルが必要な場合は、次の2種類から選択します。

ベクタータイルは、ジオメトリとフィーチャー属性をコンパクトなバイナリデータ（Mapbox Vector Tile 形式、または新しい MapLibre Tile / MLT）としてエンコードします。MapLibre はクライアント側でレンダリングとスタイル設定を行います。

• タイルを再生成せずにスタイルを変更できます
• フィーチャーをクエリできます（クリックやホバーによるインタラクション）
• どのズームレベルや画面密度でも、テキストが鮮明に表示されます
• 同等のラスタータイルよりファイルサイズを大幅に小さくできます

ラスタータイルは、各ズームレベルで事前にレンダリングされた画像（PNG、JPEG、または WebP）で、MapLibre にそのまま表示されます。

• クライアント側でのスタイル設定やフィーチャーのクエリには対応していません
• ファイルサイズは大きくなりますが、生成と配信はより簡単です
• 衛星画像や航空画像、WMS/WMTS との連携、またはクライアント側でのカスタマイズが不要なレンダリング済みスタイルに適しています

MapLibre のワークフローの多くはベクタータイルを使用します。地形のレンダリングなどに raster-dem ソースを組み合わせるケースも増えています。衛星画像や航空画像が必要な場合、既存の WMS または WMTS サービスと連携する場合、あるいは事前にレンダリングされた地図スタイルが必要な場合は、ラスタータイルを使用してください。

Leaflet で MapLibre を使用する

Leaflet は広く使われている JavaScript マッピングライブラリで、コア機能ではラスタータイルのみを描画します。アプリが Leaflet をベースにしている場合は、MapLibre GL Leaflet を使うと、ライブの MapLibre GL JS マップを Leaflet レイヤーとして追加でき、ホストされたベクタータイルソースからベクタースタイルを描画できます。

ソースタイプの組み合わせ

MapLibre のスタイルでは、任意の数のさまざまなタイプのソースを同時に使用できます。異なるソースのレイヤーは、描画順に合成されます。そのため、用途に応じてソースを組み合わせるのが自然です。

• ベクターベースマップ + GeoJSON オーバーレイ — 最も一般的なパターンです。プロバイダーのスタイル URL（または任意のベクタータイルソース）をベースマップとして使い、その上に独自のデータを追加します。ラベルを読みやすく保つには、レイヤーをスタックの最上部に追加するのではなく、最初のシンボルレイヤーより前に挿入します（maplibre-source-wiring を参照）。
• ラスター画像 + ベクターラベル — 衛星画像、気象レーダー、過去の画像、サーバー側でレンダリングされたヒートマップなど、ベクターデータとして利用できない画像には、ラスターソースを追加します。道路、地名、その他のラベルにはベクターソースを追加します。これにより、鮮明な画像の上に、鮮明で解像度に依存しないベクタージオメトリとラベルを重ねて表示できます。
• ベクターベースマップ + raster-dem 地形 — raster-dem ソース（標高タイル）を使うと、任意のベクターベースマップに陰影起伏図や3D地形を追加できます。これは、MapLibre が別のベースマップスタイルなしで地形や陰影起伏をレンダリングする方法です。

各アプローチを選ぶ場面

実際のアプリでは、参照レイヤーにホスト型ベースマップを使い、独自データを別のソースとして追加するなど、複数のソースタイプを組み合わせることがほとんどです。独自データのためだけにカスタムタイルパイプラインを構築する必要は、ほとんどありません。

シナリオ	推奨するソース構成
< ~5,000 個のフィーチャーで、クリック／ホバー操作やライブ更新が必要	GeoJSON — タイルサーバーは不要
5,000–100,000 個のフィーチャー	簡略化でき、読み込みに 1–3 秒かかることを許容できるなら GeoJSON、それ以外はベクタータイル
> 100,000 個のフィーチャー、または > 50 MB	ベクタータイル — tippecanoe または Planetiler で生成
道路、地形、または地名のベースマップ	ホスト型タイルサービス（OpenFreeMap、MapTiler）またはセルフホスト（Martin）
任意のベースマップに重ねる独自データ	ホスト型ベースマップのスタイル URL ＋ 独立した GeoJSON またはベクタータイルソースとしての独自データ
衛星／航空画像 ＋ ラベル	画像用のラスタタイルソース ＋ 道路とラベル用のベクターソース

重要なのは、ベースマップと独自データは、両方がベクタータイルであっても、ほぼ常に別々のソースであるという点です。ベースマップは背景情報を提供し、独自のソースはアプリケーションのデータを提供します。

誰かが自分のデータをベースマップのタイルセットに統合する方法を尋ねてきた場合

この依頼には、よくある形があります。「道路、水域、ラベル、自分のポリゴンを単一のタイルセットにまとめて、マップが 1 つのソースだけを参照するようにしたい。パイプラインはどうすればいい？」 問題なのは前提そのものです。質問どおりに答えると、ユーザーは後で元に戻さなければならないものを構築することになります。ビルド手順は書かないでください。該当する例外に当てはまる場合に限り、それを実現するツール（tippecanoe、Planetiler）を挙げ、ドキュメントを案内します。

まず前提を正してください。「ソースを 1 つにする」ことはパフォーマンス最適化ではありません。スタイルの sources は任意の数の名前付きソースを保持するオブジェクトです（スタイル仕様）。MapLibre はそれらのタイルを並行してリクエストし、回避すべきソースごとの描画ペナルティはありません。公開されているベースマップスタイル自体も、通常は複数のソースを宣言しています。ユーザーは、コストのかからないものを最適化しようとしています。

次に、統合によって実際に生じるコストを説明してください。「その必要はありません」とだけ伝えても、たいてい依頼は撤回されないからです。

• 独自データを変更するたびに、ベースマップ全体を含む統合タイルセット全体を再生成する必要があります。数十個のポリゴンを編集して公開するために、惑星全体または地域の抽出データをビルドすることになります。
• ベースマップを切り替えたりアップグレードしたりできなくなります。ベースマップが組み込まれているためです。
• ホスト型スタイルを利用する場合と異なり、派生データの再配布者として、ベースマップの帰属表示とライセンス上の義務を負うことになります。

**代わりに、2 つのソースを使うパターンを提案してください。**ホスト型ベースマップのスタイル URL またはベクターソースに加えて、配達区域（またはユーザーのデータ）を、同じスタイル内の独立した geojson または vector ソースとして指定します。これが標準的な構成であり、ユーザーが実際に求めているものです。

統合タイルセット 1 つだけで正当化できるのは、限られたケースです。ネットワーク接続も 2 つ目のファイルもなしで描画する必要がある、自己完結型の成果物、つまりオフライン環境やエアギャップ環境に 1 つのアーカイブとして配布する場合です。それ以外は該当しません。「自分のタイルをセルフホストしている」、キオスク端末でのバンドルサイズ、デモ、概念実証は、いずれも 2 つのソースが適切で、構築コストも低いケースです。

関連スキル

• maplibre-fonts-glyphs — glyphs URL の設定、PBF フォントのセルフホストまたは生成、非ラテン文字のサポート。
• maplibre-sprites-icons — sprite URL の形式、複数のシートの読み込み、スプライトアセットのセルフホスト、ルートシールド。
• maplibre-source-wiring — TileJSON、source-layer、レイヤーの順序、CORS、空白の地図のデバッグ。
• maplibre-pmtiles-patterns — サーバーレスの PMTiles ホスティングと MapLibre との統合。
• maplibre-mapbox-migration — Mapbox のタイルを MapLibre 互換のソースに置き換える方法。

参考資料

1. GeoJSON のパフォーマンスしきい値（ファイルサイズ／フィーチャー数の範囲） — Stack Overflow、Reddit、Medium、Cesium Community Forum の議論から集約した、コミュニティによる経験則です。⚑ 権威あるものでも、標準的なものでもありません
2. MapLibre Style Specification — maplibre.org/maplibre-style-spec/
3. MapLibre Tile（MLT）仕様 — maplibre.org/maplibre-tile-spec/
4. Planetiler（OSM からベクタータイルを生成） — GitHub
5. tippecanoe（GeoJSON からベクタータイルを生成） — github.com/felt/tippecanoe
6. Leaflet — leaflet.js
7. MapLibre GL Leaflet — github.com/maplibre/maplibre-gl-leaflet
8. クラウドネイティブな地理空間フォーマット：FlatGeobuf（flatgeobuf.org）、GeoParquet（GeoParquet）、Cloud-Optimized GeoTIFF（COG website）
9. awesome-maplibre — github.com/maplibre/awesome-maplibre

---

このスキルはある時点のスナップショットです。 ここに記載された内容が一次情報（上記の参考資料、MapLibre の最新ドキュメント、または MapLibre の実際の動作）と矛盾する場合は、一次情報を優先してください。一次情報に従い、出典と MapLibre のバージョンを明記して不一致を報告してください。インストール済みのコピーを編集しても他の人の役には立たず、次回の更新時に上書きされます。