インタラクティブマップ時代に向けた投影法の再考

先月、Mapbox GL JS v2.6をAdaptive Projectionsとともにリリースしました。これは、ユーザーエクスペリエンス、レンダリング品質、またはストリートレベルの精度を損なうことなく、インタラクティブな地図をグローバルスケールでより正確にするための新しい方法です。

Mapboxは、この機能をシームレスかつ自然に感じられるようにするために多くの検討を重ねてきました。これにより、お客様は1行のコードを追加するだけで、あらゆる種類の地図アプリでこの機能を採用できます。Mapboxがそれを行った理由と、その仕組みについて詳しく見ていきましょう。

地図投影法の紹介

画面や紙で見られる地図はすべて、特定の地図投影を使用しています。これは、地球を平面上に表現する方法です。これは、古代ギリシャ人が地球が球体であることを確立して以来、少なくとも数千年にわたって研究されてきたテーマです。しかし、確かなことが1つあります。完璧な投影法はなく、球体を平面にマッピングする方法はすべて、必然的に歪みにつながります（1777年のオイラーによる注目すべき数学的証明があります）。

すべての投影法は形状、サイズ、または距離を歪めるため、どれを選択するかはトレードオフの問題です。

• 一部の地図では、相対的なサイズを維持して、実際よりも大きく見えないようにする必要があります（たとえば、国地図にはAlbers projectionを使用し、世界地図にはEqual Earthを使用するなど）。ただし、これを実現するには、形状を歪める必要もあります。
• 一部の地図では、形状を維持する必要があります。これは、ナビゲーション（Mercator）や航空地図（Lambert Conformal Conic）にとって特に重要ですが、サイズが歪みます。
• 折衷投影法は、形状の歪みとサイズの歪みの両方をバランスさせようとします。形状の歪みもサイズの歪みも大きすぎないようにすることを目指し、「見た目が正しい」ものを目指しており、多くの場合、世界地図の視覚化に使用されます（Winkel tripel、Natural Earth）。
  

最も有名なトレードオフは、私たち全員が日常生活で経験するものであり、Web地図作成の黎明期に起こり、Webメルカトルが選択された投影法として採用されました。当時、インタラクティブな地図はストリートレベルのナビゲーションのために発明され、メルカトルはこれに最適です。線間の角度を保持し、形状の歪みを回避し、どの地点でも北が上になるようにします。

同時に、メルカトル図法は地球規模でサイズを大きく歪め、赤道から離れるほど形状を誇張します。そのため、インターネット時代に生きる多くの人々が、グリーンランドはアフリカと同じくらいの大きさだと考えていますが、実際には14倍も小さいのです:

インタラクティブ地図上の投影法

地図投影法は地図製作の基本的な概念の1つですが、インタラクティブマッピングで非メルカトル図法を採用することは非常に困難であることが証明されています。地図製作者やマッピング愛好家による多くの熱心なキャンペーンにもかかわらず、Webメルカトル図法が依然として主流です。

その理由の1つは、地図業界が投影法とともに、対応するタイリングスキームを採用したことです。これは、ズーム0でメルカトル図法の正方形タイルから始まり、後続のレベルごとに各タイルを4分割します。このシンプルで効率的な地図データ配信形式は、広く普及しました。

したがって、別の投影法を使用するには、すべてのデータを異なる投影法でタイルに再処理する必要がありますが、これは非常にコストがかかります。たとえば、Mapboxはそのベースマップスタイルのタイルをズーム16まで生成しますが、これは57億以上のタイルになります。データセットごとに可能なすべての投影法に対して個別のタイルセットを生成することは非現実的です。

ラスタ地図タイルの再投影は、テキストラベルが歪んだり、シャープな線やアイコンがぼやけたりするため、多くの場合選択肢になりません。

地図投影法をインタラクティブな地図に適用する際のもう1つの根本的な問題は、投影法が紙向けに設計されており、ユーザーが世界地図とストリートレベルの地図の間をズームできる場合にはうまく機能しないことです。グローバルスケールでうまく機能する投影法は、ズームインすると大きく歪み（モルワイデ図法で見たベイエリアの例を参照）、その逆もまた同様です（メルカトル図法）。

2012年にオレゴン州立大学のバーンハード・ジェニーがインタラクティブマップの地図投影を適合させるという注目すべき試みがありました。ただし、残念ながら概念実証にとどまりました。このアプローチでは、レンダリングフレームごとにジオメトリを再投影する必要がありました。これは、多くの場合、画面上に数百万のポイントを一度にレンダリングする必要がある最新のベクターレンダリング標準に拡張することが困難であり、既存のメルカトルタイルとの互換性を維持する必要があります。さらに、急激な投影の変化がある地図を操作すると、方向感覚を失う可能性があります。

これらの制限により、非メルカトル図法は通常のWebマップではほとんど見られず、主に専用のD3ベースの視覚化に限定されています。ベクターレンダリング技術の進歩は、より広範な採用への唯一の実行可能な道のように思われました。

Mapbox GL JSにおける投影法

MapboxがGL JSとそのベクターレンダリング技術の導入により地図業界を変えて以来、この問題に取り組む独自の立場にありました。おそらく、プロジェクトの8年の歴史の中で最もリクエストされた機能です。

これに取り組み始めたとき、私たちはそれを正しくやりたいと思いました。これは、代替投影法を非常に魅力的なものにし、広範な採用への障壁をなくすチャンスでした。そして、このような大規模で複雑な機能の特定の設計に一度コミットすると、後で変更することは難しいため、この一度の機会を大切にする必要がありました。私たちは次の指針となる原則に落ち着きました:

• 既存のソースおよびスタイルとの互換性により、誰でもMapboxの地図上で代替投影法をすぐに使い始めることができます。これには、Webメルカトルタイルをロードし、クライアント上でデータを再投影する必要がありました。
• ベクターフィーチャのレンダリングをシャープかつ正確に保つために、ラスタではなくベクターによる再投影を行います。
• ズームイン中に投影を動的に調整して、歪みを解消します。
• ズームとベアリングの意味を再定義し、異なる投影法への切り替えが直感的かつシームレスになるようにします。
• レンダリングパフォーマンスのオーバーヘッドがゼロであるため、代替投影法を使用した地図でも、通常の地図と同じように高速に感じられます。

投影法とズームレベル

投影法を設計するときに最初に尋ねた質問の1つは、些細なことのように思えます。「ズームレベルとはどういう意味ですか？」歴史的に、メルカトル図法の場合、ズームは、全世界を含む単一のタイルを持つマップの場合は0と定義され、1ずつ増分するごとにサイズが2倍になりました。

非メルカトル図法では、タイルもワールドも軸に沿った正方形ではなくなるため、同じ定義に頼ることはできません。しかし直感的には、ズーム値が地図上のフィーチャの縮尺を反映することを望んでいます。つまり、選択した図法に関係なく、特定の地図のズームと中心の設定により、地図がほぼ同じ領域をカバーし、形状のサイズが比較的同じになるようにします。これは、次の手順で実現できます。

1. 地図上の任意の領域を参照点として使用します（例：下の赤い四角）。
2. 再投影された座標でのサイズを計算します。
3. メルカトル座標でのサイズを計算します。
4. これらのサイズが一致するように、投影された地図の縮尺を調整します。

1つだけ注意点があります。どのポイントを基準にするかということです。地図表示の中心を使用すると、パンすると地図が目に見えてズームされ、奇妙に感じられます。また、地図上の固定点（世界の中心など）を使用すると、ユーザーがその点から離れるにつれて、サイズのずれが大きくなります。

最終的に、以下の方法を組み合わせたソリューションにたどり着きました。

• 低ズームレベルでは、固定点（投影の中心）を使用します。これにより、世界の形状は同じままになり、パン中に縮尺が変更されることはありません。
• 高ズームレベルでは、画面の中心を使用します。パンは比較的小さな距離に制限されているため、縮尺の変更は目立ちません。
• 中ズームレベルでは、両方を使用し、ユーザーが低ズームから高ズームに移動したり、戻ったりするときに、2つのアプローチをスムーズに移行します。
  

これにより、さまざまな投影法に合わせて地図をデザインし、最適なものを選択することが容易になります。

投影と回転

同様に、インタラクティブな地図を使用する場合、地図の向きについて、ある程度の先入観があります。メルカトル図法によって条件付けられているため、回転させない限り、地図が北を向いていることを直感的に期待します。また、特定の地図表示設定（中心、ズーム、ベアリング）は、投影法に関係なく同じ向きになることを期待します。

ズームと同様に、この直感に合うように地図を自動的に回転させます。

• 低ズームレベルでは、地図を、北が投影の中心から真上になるように配置します。これにより、地図はパンしても回転しません。
• 高ズームレベルでは、地図を、北が画面中央から真上になるように配置します。これにより、地球上のどの地点が表示されていても、メルカトル図法のように北が上になり、パン中の回転は目立ちません。
• 中ズームレベルでは、2つのアプローチをスムーズに移行します。
  

ズームイン時の歪みの修正

上記のズームとベアリングの調整を適用した後も、まだ問題が残っています。ズームインすると、地図が著しく歪んで見えることです。

これは、Winkel tripelのような非正角図法の自然な特性です。形状の相対的なサイズは保持されますが、子午線と平行線は互いに垂直ではないため、ズームインすると形状が歪んで見えます。これをどのように修正すればよいでしょうか。

十分にズームインすると、ビューは地球のほぼ平坦な部分を表します。したがって、形状またはサイズを歪めることの間で妥協する必要がないため、代替投影法はもはや必要ありません。地図をズームインすると、子午線と平行線を表す曲線がどのようにまっすぐになり、より高いズームレベルで直線に近づくかに注目してください。これらの線が垂直になるように地図を傾け直し、垂直方向と水平方向の距離が等しくなるように引き伸ばします。これにより、地図は正角になり、メルカトル図法とほぼ完全に一致します。

この斜めや伸縮はアフィン変換と呼ばれ、WebGLビューマトリックスを修正することでGPU上でリアルタイムに適用できます。これにより、タイルがロードされる際に一度座標再投影を適用し、ユーザーがズームする際にはパフォーマンスのオーバーヘッドなしにそれらの座標の表示を調整できます。また、ビューを不均一にねじったり歪めたりするより高度な変換よりも、地図の操作感がはるかに自然です。

以前の修正と同様の方法でこれを行います。低ズームレベルでは調整を行わず、ユーザーがズームインするとスムーズに完全な修正に移行し、両方の長所を生かします:‍

タイル読み込みの変更

回転、ピッチ、そして最近では3D地形機能により、どのタイルをロードするかを決定するコードは非常に複雑になっています。投影を使用すると、さらに複雑になります。タイルはもはや完全な正方形ではなく、使用される投影に応じてさまざまな形状になります。

さらに、同じズームレベルのタイルでも、再投影すると大きくなるものと小さくなるものがあるため、タイルのサイズに応じて同じビューで異なるズームレベルのタイルをフェッチするように、タイル読み込みロジックを調整しました。

ベクタジオメトリのリサンプリング

メルカトル図法から別の図法にベクタータイルデータを再投影する場合、新しい座標値を計算するだけでは十分ではありません。以前は直線だった線やポリゴンのセグメントが湾曲する可能性があるため、曲線に沿ってより多くの点を追加する必要があります。追加しすぎると、レンダリングパフォーマンスに影響します。少なすぎると、線が投影に一致しません。

適応型アルゴリズムでバランスを取ります。線分の中央に点を追加し、次に新しく作成された2つの線分の中央に点を追加し、各線分が十分な精度で曲線を近似するまで再帰的に続けます。これは、一般的なDouglas-Peuckerポリライン簡略化アルゴリズムと非常によく似ていますが、逆になっています。このアプローチにより、一般的な地図上でわずか2〜3％の追加ポイントで、再投影されたジオメトリを正確にレンダリングできます。

ラスタタイルの再投影

代替投影法で衛星レイヤーなどのラスタータイルをレンダリングするには、メルカトル図法画像をロードし、それを歪んだタイル形状にマッピングする必要があります。WebGLでそれを行うには、タイルを多数の小さな三角形に分割する必要があります。各三角形は、画像のごく一部を表します。一般に、三角形が少ないほど、レンダリングは高速になります。

2年前、MARTINIを発表しました。これは、ラスタハイトマップから3D地形メッシュをリアルタイムに生成するためのオープンソースライブラリであり、その仕組みを詳細に説明するインタラクティブな記事が付属しています。結果として、まったく同じアプローチを使用して、ラスタタイルを再投影するための三角形メッシュを生成できます。個々の三角形のエッジが地形をどの程度近似しているかを測定する代わりに（さらに分割するかどうかを決定するために）、エッジが再投影でどの程度湾曲するかを測定するだけです。

これにより、歪みの少ない領域ほど三角形が少なく、歪みの多い領域ほど三角形が多い三角形メッシュが生成されます。

Adaptive Projectionsを始めましょう

その結果、高速で美しく詳細なインタラクティブなMapboxの地図を、別の投影法で簡単に使用できるようになりました。お読みいただきありがとうございます。

こちらのデモで新機能を試したり、最小限のサンプルやドキュメントを確認したり、（コードまたはMapbox Studioを使用して）地図上で試用して、何か問題が発生した場合はお知らせください。また、Mapboxコミュニティが長年待ち望んでいた、もう1つの素晴らしい今後の機能にご期待ください:

ボーナス：NG集

このような複雑な機能の開発は決してスムーズに進みませんが、良い面としては、楽しむべき偶然の芸術がたくさんあります（私たちのチームには、これらを共有するための別の#lol-gl Slackチャンネルがあります）。

‍