MapKitでヒートマップを描く — オーバーレイ実装の勘所

⚠ 本記事は、「ヒートマップの読み方」で紹介したGeoPrism JPのヒートマップ機能の実装版です。前回は「補正量やジオイド差分を色で見る」という使い方を説明しましたが、今回は「その色付き地図を、iOSアプリの中でどう描画しているか」という実装側の勘所をまとめます。

GeoPrism JPのヒートマップ表示例

要件 — 全国グリッドを色で・ズームしても軽く

ヒートマップ機能に求められる要件は、大きく2つです。

全国規模のグリッドデータ（緯度経度メッシュごとの補正量・ジオイド差分）を、地図上に色分けして重ねて表示する
ユーザーが地図を拡大・縮小・スクロールしても、描画がカクつかず軽快に動作する

MapKitは背景地図の描画自体は最適化されていますが、「全国規模の格子データを色付きで重ねる」部分は、標準のピンやポリラインとは違うアプローチが必要になります。

MKOverlay / MKOverlayRendererの基礎

MapKitでカスタムの地図表現をする基本パターンは、MKOverlayプロトコルに準拠したデータモデルと、実際の描画を担当するMKOverlayRenderer（またはそのサブクラス）を組み合わせる構成です。

MKOverlay：オーバーレイが地図上のどの範囲（境界矩形）に存在するかを表すデータ側の役割
MKOverlayRenderer：MKMapViewから描画リクエストを受け取り、実際にCore Graphicsで色や図形を描く役割

ヒートマップのように「タイル状に敷き詰められた色付きの矩形（あるいは円）の集合」を描く場合、素朴には各メッシュを個別のMKPolygonとして大量に追加する方法も考えられますが、メッシュ数が多くなるほど描画・ヒットテストの負荷が増えるため、後述するタイル単位でのオーバーレイ描画（MKTileOverlay系のアプローチ）と組み合わせる設計が現実的です。

グリッドデータ→色への変換（カラースケール設計・凡例）

数値データを色に変換する部分は、見た目の分かりやすさに直結する設計要素です。

カラースケールの選定：値が小さいほど寒色（青系）、大きいほど暖色（赤・オレンジ系）に近づく連続的なグラデーションを基本にしています。単純な線形補間ではなく、実際のデータ分布（多くの地点は小さい値に偏り、一部の地点だけ極端に大きい）に応じて、色の変化がなだらかになるようスケールを調整する工夫が必要です
凡例の表示：色だけでは絶対値が伝わらないため、画面の一部に「この色は何cm・何mに相当するか」を示す凡例を常時表示します
透明度：背景地図の地形や道路情報を完全に隠さないよう、色付きレイヤーには適度な透明度を持たせています

性能対策（タイル化・間引き・キャッシュ）

全国規模のデータをそのまま毎フレーム描画すると、特に低ズームレベル（広域表示）で描画コストが跳ね上がります。実務上は次のような対策を組み合わせます。

タイル化：地理院タイルと同じXYZタイル方式の考え方で、ヒートマップ画像もあらかじめタイル単位に分割・事前レンダリングしておき、表示中の範囲に必要なタイルだけを描画する
ズームレベルに応じた間引き：広域表示では細かいメッシュを間引いて粗い解像度で表示し、拡大するにつれて詳細なメッシュへ切り替える（いわゆるLOD＝Level of Detailの考え方）
描画結果のキャッシュ：一度計算・描画した色付きタイルはキャッシュしておき、同じ範囲を再表示する際の再計算を避ける

これらはいずれも、.NET MAUI側で地図タイルを重ねる実装でも共通する考え方で、プラットフォームが変わってもタイルベースの最適化という発想自体は同じです。

色覚多様性への配慮

赤緑の組み合わせだけで「大きい・小さい」を表現すると、色覚特性によっては違いが分かりにくくなる場合があります。ヒートマップの配色では、明度（暗い→明るい）の変化も同時に持たせることで、色の識別だけに頼らずに大小関係が伝わるようにする配慮が一般的に推奨されています。凡例に数値を併記しているのも、この配慮の一環です。