地図が3倍速くなる!?MapLibreコミュニティが本気で作った「MapLibre Tile」徹底解説

OSC2026 Tokyo/Spring 発表資料
https://event.ospn.jp/osc2026-spring/session/2274648

Webやモバイルで地図を描画する際に欠かせない「ベクトルタイル」。その標準フォーマットであるMapbox Vector Tiles（MVT）は約10年にわたり業界で広く使われてきましたが、データ量の増大やGPUレンダリングの進化に対応するため、新たなフォーマットが求められていました。

本セッションでは、2024年に発表された新フォーマット「MapLibre Tile（MLT）」を取り上げます。MapLibreの地図描画の仕組みから始め、ベクトルタイルフォーマットの役割、MVTとMLTのアーキテクチャの違い、データ構造、そして今後の展望までを解説します。

Transcript

1. 地図が3倍速くなる!? MapLibreコミュニティが本気で作った 「MapLibre Tile」徹底解説 Haruki Inoue 1
2. 井上 晴稀 Haruki Inoue 千葉県流山市在住 一般社団法人OSGeo日本支部 理事 本業: iOSアプリエンジニア 趣味・副業でGISに触れている SNS X (旧Twitter): kyotonagoya1476 自己紹介 2
3. 45分で MapLibre Tile を理解する 話すこと MVT（Mapbox Vector Tile）と MLT（MapLibre Tile）の違い MLT の内部構造（列指向・ストリーム・型システム） MLT による速度向上のベンチマーク結果 MLT の現状と今後の展望 話さないこと MLT を使った具体的な実装方法・コード タイルサーバーの構築方法 MapLibre GL JS / Native の詳細な使い方 このスライドのゴール 3
4. 1. MapLibre とは？ 2. 地図がWeb上に描画されるまでの流れ 3. Mapbox Vector Tile の中身 4. MVT のメリット・デメリット 5. MapLibre Tile とは？ 6. MapLibre Tile の中身 7. 現状と今後の展望 アジェンダ 4
5. MapLibre とは？ 5
6. MapLibre は Mapbox v1 からフォークされたオープンソース地図ライブラリ MapLibre の概要 6
7. MapLibre は複数のオープンソースプロダクトを提供 プロダクト 概要 MapLibre GL JS Web 向け TypeScript ライブラリ。GPU アクセラレーションによる 高速描画 MapLibre Native モバイル・デスクトップ・組み込み向け C++ ライブラリ。OpenGL / Metal / Vulkan 対応 MapLibre Style Spec 地図の見た目を JSON で定義する仕様。データソース・描画順序・ スタイルを記述 MapLibre Tile Spec 次世代ベクトルタイルフォーマット。圧縮率・デコード性能の向上 （今日お話する部分） MapLibre のサービス 7
8. どうやってクライアントで地図を表示しているのか？ 8
9. サーバから配信されたタイル状の地図データをクライアント上で敷き詰めて表示 地図がクライアントで表示されるまでのイメージ 出典: 地理院タイルについて 国土交通省 国土地理院 https://maps.gsi.go.jp/development/siyou.html 9
10. 位置情報をどうやって配信するか 10
11. 広大な地図データを小さな正方形に分割して配信する仕組み Web 地図で全世界のデータを一度に読み込むのは非効率 地図を タイル（断片） に分割し、見ている範囲だけを取得 ユーザーの操作に応じて 必要なタイルだけを動的に取得 ┌───┬───┬───┐ │ │ │ │ ← ユーザーが見ている範囲のタイルだけを取得 ├───┼───┼───┤ │ │ ★ │ │ ← 中心のタイルから優先的に読み込み ├───┼───┼───┤ │ │ │ │ └───┴───┴───┘ 地図タイルの仕組み 11
12. タイルを特定するための座標体系 要素 説明 Z（ズームレ ベル） 地図の縮尺。Z=0では全世界が1枚のタイルで表され、Z=1では4枚（2×2） に分割、Zが1増えるごとにタイル数は4倍になる X ズームレベルごとのタイルを示す整数値．西から東方向の位置． Y ズームレベルごとのタイルを示す整数値．北から南方向の位置 ． Z=0 : 1 枚 (2⁰ × 2⁰) タイル URL の例: Z=1 : 4 枚 (2¹ × 2¹) https://example.com/tiles/{z}/{x}/{y}.png Z=2 : 16 枚 (2² × 2²) https://example.com/tiles/14/14552/6449.png タイルインデックス（Z/X/Y） 12
13. 地図タイルには2 つの方式がある 項目 ラスタタイル ベクトルタイル 形式 PNG / JPEG 画像 Mapbox Vector Tile レンダリング サーバー側で事前生成 クライアント側でリアルタイム描画 スタイル変更 事前生成なので難しい 動的に変更可能 ズーム時 ぼやける場合あり 常に滑らか インタラクション 難しい 地物クリック等が容易 クライアント負荷 低い 高い（GPU 描画） ラスタタイル vs ベクトルタイル 13
14. Mapbox Vector Tiles とは？ 14
15. Mapbox Vector Tile (MVT)は，ベクトルタイルの業界標準フォーマット Mapbox が策定したベクトルタイルのフォーマット 現在はオープンな仕様として公開 ファイル実体は Protocol Buffers（PBF） でエンコードされたバイナリファイル 拡張子: .mvt または .pbf 現在の安定版: バージョン 2.1（GitHub で公開） MVT の概要 15
16. MVT が広く採用されている理由 特徴 説明 軽量・高速転送 バイナリ + gzip 圧縮で GeoJSON より大幅にサイズ削減 複数レイヤー同梱 道路・建物・水域などを 1 タイルでまとめて取得可能 スタイルとデータの分離 同じデータでデイ/ナイトモード・多言語表示を切替可能 ざっくりとしたイメージ図 1 つのタイルに複数レイヤー: Tile (14/14552/6449.mvt) ├── Layer: roads ← 道路 ├── Layer: buildings ← 建物 ├── Layer: water ← 水域 └── Layer: labels ← ラベル MVT の特徴 16
17. Mapbox Vector Tile の中身 17
18. Tile → Layer → Feature の 3 階層で構成 Tile (.mvt) ├── Layer: roads │ ├── version: 2 ← 仕様バージョン │ ├── name: "roads" ← レイヤー名（一意） │ ├── extent: 4096 ← タイル内の座標グリッドサイズ │ ├── keys[]: ["name", "class", ...] ← 属性キーの辞書 │ ├── values[]: [" 国道1 号", "primary", ...] ← 属性値の辞書 │ └── features[]: [Feature, Feature, ...] └── Layer: buildings └── ... MVT の全体構造 18
19. 各 Layer が持つフィールド フィールド 必須 説明 version ◦ 仕様バージョン（現在は 2 ） name ◦ レイヤー名（タイル内で一意） extent ◦ 座標グリッドサイズ（通常 4096 ） keys[] - 属性キーの文字列リスト values[] - 属性値のリスト（複数型対応） features[] - 地物の配列 Layer の構成要素 19
20. 各 Feature（地物）が持つフィールド フィールド 必須 説明 id - 地物 ID（レイヤー内で一意推奨） type ◦ ジオメトリタイプ（POINT / LINESTRING / POLYGON） tags[] - 属性情報（キー・値インデックスのペア列） geometry[] ◦ ジオメトリデータ（コマンド列） Feature の例: id: 12345 type: LINESTRING tags: [0, 0, 1, 2] ← keys[0]=values[0], keys[1]=values[2] geometry: [9, 4, 4, 18, 0, 16, 16, 0] ← エンコードされた座標 Feature の構成要素 20
21. MVT がサポートする 4 種類のジオメトリタイプ タイプ 説明 例 UNKNOWN 不明（実験用） - POINT 点・複数点 POI、駅、店舗 LINESTRING 線・複数線 道路、河川、鉄道 POLYGON 面・複数面（穴あり可） 建物、湖、行政区域 ジオメトリタイプ type 21
22. 辞書参照方式でキーと値を効率的に圧縮 Layer レベルの辞書: keys: [0="hello", 1="h", 2="count"] values: [0="world", 1=1.23, 2="again", 3=2] Feature 1 の tags: [0, 0, 1, 0, 2, 1] → keys[0]=values[0] → "hello"="world" → keys[1]=values[0] → "h"="world" → keys[2]=values[1] → "count"=1.23 Feature 2 の tags: [0, 2, 2, 3] → keys[0]=values[2] → "hello"="again" → keys[2]=values[3] → "count"=2 属性情報 tags 22
23. MVTでは緯度経度ではなくタイル内のローカル座標系で位置を表現 extent ( 解像度) = 4096 の場合: (0, 0) ──────────────────→ X 正方向（東） │ ┌─────────────────┐ │ │ │ │ │ タイル内 │ │ │ │ ↓ └─────────────────┘ Y 正方向 (4096, 4096) （南） 座標の意味: (0, 0) = 左上端 (4096, 4096) = 右下端（extent の場合） (2048, 2048) = 中心 座標系と extent (解像度) 23
24. 座標は 3 種類のコマンド の列として表現される コマンド ID パラメータ 説明 MoveTo 1 dX, dY カーソルを移動（新しい起点） LineTo 2 dX, dY 現在位置から線を引く ClosePath 7 なし 始点に戻って閉じる ポリゴンの例（時計回りの四角形）: MoveTo(+3, +6) → 起点に移動 LineTo(+5, +6) → 線を引く LineTo(+12, +22) → 線を引く ClosePath → 始点に戻る 座標は 相対座標で定義 することで小さな整数値になりやすく圧縮効率が向上 ジオメトリエンコーディング: コマンド 24
25. コマンドとパラメータは 32bit 符号なし整数 にエンコード CommandInteger の構造: 下位 3bit = コマンド ID （0 〜7 ） 上位 29bit = 繰り返し回数 例: MoveTo を 1 回実行 → (1 << 3) | 1 = 9 LineTo を 2 回実行 → (2 << 3) | 2 = 18 ParameterInteger （座標値）: ZigZag エンコーディングで負の値も効率的に表現 value = (n << 1) ^ (n >> 31) 例: +25 → 50, -25 → 49, +17 → 34, -17 → 33 ジオメトリエンコーディング: 整数表現 25
26. 線分 (2,2) → (2,10) → (10,10) のエンコード コマンド列: MoveTo(+2, +2) → 起点 (2, 2) へ移動 LineTo(+0, +8) → (2, 10) へ線を引く（差分: x=0, y=+8 ） LineTo(+8, +0) → (10, 10) へ線を引く（差分: x=+8, y=0 ） 整数列への変換: [ 9, 4, 4, 18, 0, 16, 16, 0 ] │ │ │ │ │ │ │ └─ dY=0 → ZigZag(0)=0 │ │ │ │ │ │ └─ dX=+8 → ZigZag(8)=16 │ │ │ │ │ └─ dY=+8 → ZigZag(8)=16 │ │ │ │ └─ dX=0 → ZigZag(0)=0 │ │ │ └─ LineTo×2 → (2<<3)|2=18 │ │ └─ dY=+2 → ZigZag(2)=4 │ └─ dX=+2 → ZigZag(2)=4 └─ MoveTo×1 → (1<<3)|1=9 ジオメトリエンコーディング: 具体例 26
27. 面積の符号で外枠（Exterior）と穴（Interior）を区別 巻き順が逆転すると外枠と穴の判定が狂う → 描画エラーの原因 外枠 (Exterior Ring): 時計回り ↻ → 面積が正 (0,0) ────→ (10,0) ↑ │ │ ↓ (0,10) ←── (10,10) 穴 (Interior Ring): 反時計回り ↺ → 面積が負 (13,13) ←── (17,13) │ ↑ ↓ │ (13,17) ──→ (17,17) ポリゴンの巻き順（Winding Order） 27
28. MVT は Array of Structures（AoS・行指向） モデル → 後述する MLT の列指向との対比で 重要 Feature 1: { id: 1, type: LINESTRING, tags: [...], geometry: [...] } Feature 2: { id: 2, type: POLYGON, tags: [...], geometry: [...] } Feature 3: { id: 3, type: LINESTRING, tags: [...], geometry: [...] } ↓ メモリ上の配置: [id1][type1][tags1][geom1] [id2][type2][tags2][geom2] [id3]... └────── Feature 1 ──────┘ └────── Feature 2 ──────┘ 行指向の問題点 「class 属性だけ読みたい」場合でも全 Feature をスキャン → フィルタリング処理が非効率（デメリットで詳しく説明） 行指向のメモリ配置 28
29. MVT のメリット・デメリット 29
30. デファクトスタンダードとして10年以上広く普及 広範な採用: AWS、Meta、Microsoft、OpenStreetMap など 充実したエコシステム（パーサー・サーバー・クライアント） データ削減: Protobuf（PBF） による効率的なシリアライズ タグシステム により重複属性を大幅削減 座標量子化 でコンパクトな整数値表現 クライアントサイドレンダリング: WebGL による GPU 描画でスムーズな操作 スタイル即時変更・インタラクティブな地図表示 MVT のメリット 30
31. 約10年前の設計が現代のハードウェア・データ量に不適合 性能面の限界: 行指向 → デコード時に大量の小オブジェクト生成（GC プレッシャー） ランタイムテセレーション → ポリゴン描画のたびに CPU で三角形分割 重圧縮依存 → Gzip 等が必要で CPU 負荷増大 データ構造の制限: 貧弱な型システム → 文字列・数値のみ（配列・オブジェクトは文字列変換が必要） 3D・m 座標非対応 → 高度 z やリニアリファレンシング用 m 座標がない 量子化精度問題 → 過剰な量子化でポリゴン巻き順逆転のリスク MVT のデメリット 31
32. MapLibre Tile とは？ 32
33. MapLibre Tile（MLT） は MVT の課題を解決する次世代ベクトルタイル仕様 項目 内容 正式名称 MapLibre Tile Specification 目的 MVT の性能限界をゼロから解消 設計思想 列指向・GPU 最適化・高度な型システム ステータス Live Specification（継続的に進化中） MLT の概要 33
34. MapLibre コミュニティと産業界の協働で開発 コミュニティ MapLibre Organization OpenStreetMap コントリビューター Overture Maps データ検証 産業界 AWS — 機能・性能要件定義 Microsoft — 要件定義 Rohde & Schwarz — コア開発 開発体制 34
35. 約10年前に設計された MVT が現代の要件に対応できなくなった データ量の爆発: AI・自動運転・3D 地図で扱うデータが急増 ハードウェアの変化: GPU 性能向上、WebGPU の登場 ムーアの法則の停滞: CPU 単体の性能向上に頼れない時代 MapLibre Tileについては論文も発表されています 「MapLibre Tile: A Next Generation Vector Tile Format」 SIGSPATIAL '25（ACM 国際会議）にて発表 著者: Markus Tremmel、Roland Zink MLT 誕生の背景 35
36. MVT の設計上の課題を MLT がどう解決するか 課題領域 MVT の問題 MLT の解決策 メモリ配 置 行指向（AoS）で特定属性のみ読むにも 全データスキャン 列指向（SoA） で必要な列だけ効率 的にアクセス ポリゴン 描画 クライアントで毎回三角形分割（CPU ボトルネック） 事前テセレーションで GPU に直接 転送 型システ ム 文字列・数値のみ（配列は JSON 文字列 化が必要） List / Struct / 3D 座標をネイティブ 対応 圧縮方式 Gzip 依存で解凍コストが高い 軽量エンコードのみで Gzip+MVT より小さい MVT の課題と MLT の解決策 36
37. MLT が MVT より優れていると言われている主な理由 圧縮効率の向上: データ特性に合わせた軽量圧縮（FastPFOR, RLE, 辞書エンコーディング） 軽量エンコードのみで Gzip+MVT より小さい → 解凍コストも不要 ゼロコピーに近い変換: ストレージ形式とインメモリ形式を密結合 デコード時のオーバーヘッドを最小限に スキーマ最適化が不要: MLT の柔軟な型システムで複雑なデータをそのまま格納 MVT で必要だった属性の文字列変換が不要に MLT の技術的優位性 37
38. MapLibre Tile の中身 38
39. FeatureTable の並列配置で構成（MVT の Tile → Layer → Feature とは異なる） MLT ファイル（ヘッダーなし） ├── FeatureTable: roads │ ├── メタデータサイズ (varint) │ ├── FeatureTableMetadata │ └── 列データ（Column ） ├── FeatureTable: buildings │ └── ... └── FeatureTable: water └── ... 各 FeatureTable は独立して構築・動的に結合可能 MLT の全体構造 39
40. 各 FeatureTable が持つ列（Column） 列 必須 説明 geometry ◦ ジオメトリデータ（OGC Simple Feature Access Model 準拠） id - 地物 ID（u64 以下の整数型推奨） property - 属性列（複数定義可能） FeatureTable: roads ├── geometry 列 ← 必須 ├── id 列 ← オプション ├── name 列 ← property （オプション） ├── class 列 ← property （オプション） └── maxspeed 列 ← property （オプション） FeatureTable の構成要素 40
41. 各 Column は複数の物理 Stream に分割される．ストリームごとに最適なエンコーディング を適用できる． ストリーム 説明 Present Stream nullable 列の NULL フラグ（ビットベクトル） Data Stream 実際の値データ Length Stream 可変長データの要素数（文字列長など） Offset Stream 辞書エンコーディング時のデータオフセット Column の構成要素 41
42. nullable な整数列と文字列列のストリーム分割 論理列: "population" （nullable な整数列） 物理ストリーム: ┌─ Present Stream [1, 1, 0, 1, 1, ...] ← NULL かどうかのフラグ └─ Data Stream [100, 200, 300, ...] ← 実際の値（NULL はスキップ） 論理列: "name" （nullable な文字列列） 物理ストリーム: ┌─ Present Stream [1, 1, 0, ...] ├─ Length Stream [5, 3, ...] ← 各文字列のバイト数 └─ Data Stream ["Tokyo", "LA", ...] ← 文字列本体 ストリームの具体例 42
43. ストレージレイアウトを定義する型 カテゴリ 型 スカラー 型 Boolean, Int8, Int16, Int32, Int64, UInt8, UInt16, UInt32, UInt64, Float, Double, String, Binary 複雑型 List, Map, Struct ベクトル 型 Vec2, Vec3（座標用） 例: List<Int32> → 可変長の整数リストを各地物に格納 例: Struct<name: String, population: Int64> → 構造体 型システム: 物理型 43
44. データのセマンティック（意味）を定義する型 物理型と論理型の分離により、同じストレージ表現でも異なる意味を持たせられる 論理型 物理型 説明 Date Int32 日付（Unix エポックからの日数） Timestamp Int64 タイムスタンプ（ミリ秒精度） RangeMap Map<Range, T> リニアリファレンシング情報の格納 Binary List<UInt8> バイナリデータ JSON String JSON 文字列 Geometry vec2 2D ジオメトリ GeometryZ vec3 3D ジオメトリ（高度付き） 型システム: 論理型 44
45. データ特性に応じた軽量圧縮を適用 データ型 エンコーディング 整数 Plain, RLE, Delta, SIMD-FastPFOR, Varint 浮動小数点 Plain, RLE, Dictionary, ALP 文字列 Plain, Dictionary, FSST Dictionary 真偽値 Boolean RLE エンコーディングの特徴 FastPFOR: Varint より小さい出力 & 高速デコード FSST: 文字列に特化した高速辞書圧縮 複数エンコーディングのカスケード（連鎖）が可能 Data Stream のエンコーディング方式 45
46. ジオメトリは Structure of Arrays（SoA） レイアウトで格納 ストリーム データ型 説明 GeometryType Byte ジオメトリタイプ（Point / LineString / Polygon） VertexBuffer Int32[] X, Y, Z 座標（インターリーブ形式） VertexOffsets UInt32[] 各地物の頂点開始位置（VertexBuffer 内のオフセット） NumParts UInt32 MultiLineString などの部分数 NumRings UInt32 Polygon の環（リング）数 NumTriangles UInt32 事前テセレーション済みの三角形数 IndexBuffer UInt32[] 三角形を構成する頂点インデックス配列 ジオメトリの表現 46
47. 全頂点を連続バッファに格納（MVT の相対座標コマンド列とは異なる） VertexBuffer （2D の場合）: [x1, y1, x2, y2, x3, y3, x4, y4, ...] └─ 地物1─┘ └───── 地物2─────┘ VertexBuffer （3D の場合）: [x1, y1, z1, x2, y2, z2, ...] └── 地物1──┘ └── 地物2──┘ 座標 整数座標（Int32）で格納 MVT 同様にタイル内ローカル座標系 3D 座標（高度 z）や m 座標もネイティブ対応 VertexBuffer の構造 47
48. MapLibre Tileでは ポリゴンの三角形分割をタイル生成時に完了させる 事前テセレーション IndexBuffer: 三角形を構成する頂点インデックスの配列（例: [0,1,2, 1,2,3, ...]） 48
49. MLT は Structure of Arrays（SoA・列指向） モデル MLT （列指向 / SoA ）: id 列: [id1, id2, id3, ...] ← 同じ型が連続 name 列: [name1, name2, name3, ...] class 列: [class1, class2, class3, ...] geom 列: [geom1, geom2, geom3, ...] 参考: 今までの MVT （行指向 / AoS ）: [id1][name1][class1][geom1] [id2][name2][class2][geom2] ... └────── Feature 1 ──────┘ └────── Feature 2 ──────┘ 列指向の効果 CPU キャッシュ効率向上（同じ型のデータが連続） SIMD 命令で複数要素を同時処理可能 特定列のみ読み込みでフィルタリング高速化 列指向のメモリ配置 49
50. ベンチマーク 50
51. 実世界の多様な特性を持つベースマップデータセット ID 名称 説明 OT1 OpenStreetMap OpenMapTiles スキーマ / Planetiler 0.6.0 / 最適化なし OT2 OSM 最適化版 OpenMapTiles スキーマ / Planetiler 0.8.3 / 高度に最適化 ST Swisstopo スイス国立測量局の地理空間基礎データセット OV Overture Maps AI 取得データを統合した新興の地理空間ソースフォーマット OT2 は MVT の制約を緩和するためのレイヤー特有の最適化を実装 ST は国家測量機関による信頼性の高いデータセット OV はネストされたプロパティを持つ新しいデータ構造 データセット 51
52. ブラウザ環境での性能を重視した JavaScript ベースのベンチマーク 測定環境 CPU: Intel Core i7-8665U（1.9 GHz）/ RAM: 32 GB / Windows 11 デコーダ実装 MVT: vector-tile-js ライブラリ v2.0.3（Mapbox 公式） MLT: TypeScript デコーダ（Simple Profile 対応） タイル選択方法 ユーザー操作をシミュレート: ズームレベル 0→18 で都市中心部へズームイン OT1 / OT2: ミュンヘン / OV: ロンドン / ST: チューリッヒ 全ズームレベルが均等に結果に寄与するよう調整 測定方法 52
53. 論文 Table 1 より — エンコード後のファイルサイズ（MB） データセット MLT (Adv) MLT (Simple) MVT 削減比 (Adv) OT1 15.7 18.1 45.5 2.9x OT2 13.8 16.6 21.7 1.6x ST 8.0 9.0 24.7 3.1x OV 97.5 127.7 241.1 2.5x MLT Advanced は MVT に対して 2.5〜3.1 倍小さい 大きなタイル単体では最大 6.7 倍の削減率 MLT（軽量エンコーディング）は Gzip 圧縮なしでも Gzip+MVT より小さい エンコード・圧縮性能 53
54. 論文 Table 2 より — 処理時間（ms） 処理 データセット MLT MVT 速度向上 デコード OT1 397 1212 3.1x デコード OT2 280 554 2.0x デコード ST 258 636 2.5x デコード OV 1248 3665 2.9x フィルタリング OT1 661 2845 4.4x フィルタリング OT2 32 117 3.7x フィルタリング: スタイルレイヤーにどの地物がレンダリングされるか決定する SIMD を利用していなくても優れたパフォーマンスを示している デコード・フィルタリング性能 54
55. 現状とまとめ 55
56. MLT は 「継続的に進化する仕様（Live Specification） 」 仕様は公開中: maplibre.org/maplibre-tile-spec/ 一部機能は EXPERIMENTAL（今後変更の可能性あり） 主要ツール・ライブラリへの統合が完了: ツール / ライブラリ MLT 対応状況 MapLibre Native Android 12.1.0 / iOS 6.2.0 以降でサポート MapLibre GL JS v5.12.0 以降でサポート Planetiler v0.10.0 以降で MLT タイル生成に対応 PMTiles MLT を格納可能（PMTiles v3 spec） Martin Tileserver v1.3.0 以降で MLT の検出・配信に対応 現状 56
57. MVT（Mapbox Vector Tile）は約10年前の設計 課題 内容 レコード指向 デコード時に GC プレッシャーが高い ランタイムテセレーション ポリゴン描画の CPU ボトルネック 重圧縮依存 Gzip が必要で CPU 負荷増加 貧弱な型システム 文字列・数値のみ、3D 非対応 これらの課題をゼロから解消するために MLT が設計された まとめ（前半）: MVT の課題 57
58. MLT（MapLibre Tile）の 3 つの技術的革新で課題を解決 革新 効果 数値 列指向ストレージ 圧縮効率・フィルタ速度向上 最大 3〜6x 圧縮 事前テセレーション GPU へ直接転送・描画高速化 デコード 2〜3.1x 高速 高度な型システム List / Struct / 3D 座標対応 フィルタ 3.7〜4.4x 高速 MLT 軽量エンコード単独で Gzip+MVT より小さい SIGSPATIAL '25 論文（Markus Tremmel / Roland Zink）で発表済み MapLibre GL JS / Native への統合進行中 地図レンダリングの次世代標準になる可能性を持つフォーマット まとめ（後半）: MLT の実現 58
59. 公式仕様・リポジトリ MapLibre Tile Spec Mapbox Vector Tiles Spec Mapbox Vector Tiles Standards 論文 Markus Tremmel, Roland Zink. "MapLibre Tile: A Next Generation Vector Tile Format." SIGSPATIAL '25, 2025. 参考リンク 59
60. FOSS4G 2026 Hiroshima 60
61. 世界最大のオープンソース GIS カンファレンスが広島にやってきます！ テーマ Bridging Geospatial Technology and Humanity 日程 8/30-31 ワークショップ 9/1-3 メインカンファレンス 9/4-5 コミュニティスプリント 会場 ワークショップ: RCC文化センター カンファレンス: 広島国際会議場 FOSS4G 2026 Hiroshima 開催決定！ 61
62. 参加登録開始！ チケット種別 価格（税抜） Local（日本在住の方向けチケット） ¥40,000 CfP（発表募集）締切 トラック 締切 Academic Track 2026年3月2日（間もなく！） General / Workshop 2026年3月16日 詳細は公式サイトへ: 2026.foss4g.org 参加登録 & CfP 受付中！ 62