AAE（Arc Algo Engine）は、オフラインで動作する自作の地理空間エンジンである。 地図そのものを公開地理データから直接生成し、商用の地図配信サービスにも API キーにも依存しない。 外部へ地図タイルを取りに行かないのは、公開されている地理データから手元で直接地図を描画しているためである。
形式の異なるデータを 1 つに畳み、1 枚の世界画像に焼き、球面を回し、対応表で引き直す。この 4 段階でできている。
| ① 形式を畳む | 海岸線・行政界・河川・地理院タイル——出所も構造もばらばらの公開地理データを、頂点列とリング境界だけを持つ 1 つの固定形式（前処理済みバイナリ）へ統一する。経度 ±180° の継ぎ目をまたぐ図形はこの段階で東西に分割しておく。 |
| ② 一枚に焼く | 統一したデータから、経度・緯度がそのまま画像の x, y に対応する 1 枚の世界画像（正距円筒図法：equirectangular）を、走査線塗りつぶしで生成する。極をまたぐポリゴンの処理もここで済ませる。 |
| ③ 球を回す | 地球の球面そのものを回転させ、指定した任意の地点を中心へ持ってくる（SRP＝球面回転投影）。 |
| ④ 引き直す | 出力画素ごとに「②で焼いた 1 枚のどこを見るか」を対応表（LUT）から逆引きする。投影処理は「出力画素 = 中間画像[LUT]」という 1 本の配列参照になる。 |
球面と平面のあいだに等長写像は存在しない（ガウスの驚異の定理）。どの投影法も、何かを保ち、何かを犠牲にする。
従来の方式は、多角形の頂点を平面へ投影してからポリゴンを塗る「順投影（forward）」である。だが中心を任意に動かせるようにすると、反子午線（±180°）や極をまたぐケースが頻発し、分割された線分を個別に閉じる処理が地図全体の整合性を壊してしまう。
開発当初に実際に出た症状は、「海と陸が反転する」「緯度 65° に水平の直線が走る」「30° に縦線、55° に斜め線が出る」といったもので、 一見すると互いに無関係なバグに見えた。だが原因はすべて1つだった。個別の実装ミスではなく、 「順投影でポリゴンを塗る」という方式そのものが抱える構造的な問題だったのである。
そこで順投影（forward）と逆投影（inverse）の役割を入れ替えた。あらかじめ正距円筒図法の1枚の中間画像に地図を焼き込んでおき、 出力画面の画素から元画像の座標を逆引きする——つまり、3DCG のテクスチャマッピングと同じ構造にしたのである。 これにより画素ごとの参照は完全に独立し、実行時の条件分岐は消える。
開発の最初の数か月は、描画の破綻と生成時間との戦いだった。対話的に動かし続けられる地図にするには、2つの条件を同時に満たす必要がある。 中心をどこへ動かしても描画が破綻しないことと、1フレームごとに作り直せるほど高速であることだ。 どちらか片方だけでは、「破綻した地図が高速に出る」か、「正しい静止画が紙芝居のように並ぶ」かのどちらかにしかならない。
| 時期 | 状態 |
|---|---|
| はじめ | 簡単にできると思っていた。1 枚作るのに数分かかり、角度を変えるとポリゴンが破綻した。順投影のまま、中心ごとに変わる継ぎ目と極の場合分けを追いかけていた。6 回作り直しても安定しなかった |
| 2026-02 末 | 「面積比の改善・横スクロール・大陸の向き」の 3 つは同時に満たせないと認め、球面回転（SRP）を本命にした |
| 2026-03 中旬 | 対応表（LUT）による逆引きの経路を 3 日で通した。投影が「表の差し替え」になり、破綻の問題は構造ごと消えた。この時点で 1 枚の合成は約 17 秒 |
| その後 | 残ったのは速度だけ。GPU 化・キャッシュ・高精細描画の分離と積み上げて、中心変更から表示まで 16.4 ms（1920 × 1080・RTX 4000 SFF Ada・中央値） |
対応表（LUT）を作り直せば、中心も投影法も切り替わる——すべて同じ 1 枚の中間画像から。
現在 20 種類の投影法を実装しており、中心と投影法は独立に選べる。エンジン側に図法ごとの条件分岐を持たず、各図法が申告する属性（背景面を持つか・既定の中心経度など）で処理を切り替える。新しい図法を足しても、既存の経路には一切触れない。
赤道が水平のまま。等角航路（破線）が直線になる。
同じ図法・同じ路線。球面を回してからメルカトル図法に通すと、マドリード周辺が最も歪みの小さい場所になる。
2 枚の違いは投影前の球面回転 R だけである。図法のコード自体はまったく同じものが走っている。 衛星画像: NASA Blue Marble
中間表現を挟む構造は、ベースマップの描画だけでなく、上に重ねる動的データの側にも同じように効く。
入力 N（データ源）と出力 M（図法・画像・動画・他システム）を直接結べば N × M 本の配線が要り、追加のたびに組み合わせが増える。 間に共通の中間表現を挟めば N + M 本に収まり、追加コストが「積」から「和」に下がる。 コンパイラの IR（中間表現）が複数の言語と複数の CPU をつなぐのと同じ構図である。
通信方式も中身も異なるデータ——航空機や船舶の位置報告、地上局の発信、軌道要素から計算した衛星の位置、 ファイアウォールのログに由来するサイバーイベント——は、すべて種別（kind）を付与して同じ 1 つのレコード型に正規化される。 現在は 5 軸を実装している（詳細は移動体・イベントを参照）。 新しい機器やプロトコルが来ても、種別を足して受信部を書くだけでよい。
エンジンの中核（基盤）は凍結し、その周りを差し替え可能にする。
| 系統 | 役割 | 差し替え |
|---|---|---|
| CORECore | 球面回転・LUT 逆投影・レイヤー合成・描画の基盤（＝中間表現の処理系） | 不可（凍結） |
| GEOGeographic | 地理データの前処理・構築（海岸線・地形・タイル → 固定形式） | 可 |
| PROJProjection | 投影法・視点制御（任意中心・20 図法） | 可 |
| RTTracks | 移動体の位置（航空機・船舶・地上局・衛星） | 可 |
| SECSecurity | サイバーイベント（ログ収集 → GeoIP による地理化 → 人の承認を経たファイアウォール制御） | 可 |
外部のタイルサーバーに問い合わせない。地図はすべて手元で焼く。
これは単なる利便性のためではなく、アーキテクチャから導かれる必然の帰結である。地図の中心を任意の場所へ滑らかに動かすには、 中心が移動するたびに画面の全画素を引き直す必要がある。その参照先が手元のメモリに無ければ、対話的な速度にはならない。 外部へタイルを取りに行かないのは、ネットワーク越しに取りに行けないほど高速に動かしたいからである。
ポリゴンの継ぎ目は、正距円筒図法（equirectangular）の経度 ±180° に一度だけ固定して焼き込む。そのため中心をどこへ動かしても、継ぎ目が暴れて破綻することはない。 その代わり、地図の最大解像度は「中間画像を焼いた時点」で決まる。極端に拡大すれば画像のピクセル（粒）が見える。 「任意の中心」と「対話的な描画速度」を得る代わりに、「無段階の拡大解像度」を手放す——AAE はその明確なトレードオフの上に成り立っている。 なお、手放したのは中間画像の解像度であって、幾何学的な位置関係ではない。どの地点が中心からどの方角・距離にあるかは、対応表（LUT）とベクタ投影が正確に保っている。
対応表（LUT）による逆引きは、出力画素ごとに完全に独立した演算である。
1 枚あたり数百万画素を、中心が変わるたびに全画素引き直す。CPU の逐次処理では、 マウス操作に合わせて地図を滑らかに動かす速度には届かない——つまり「任意の中心を対話的に動かす」という要件そのものが、GPU による並列演算を要求しているのである。
GPU 側の処理は 2 層でできている。
| 層 | 中身 | 使いどころ |
|---|---|---|
| 配列演算array ops | CuPy（NumPy と同じ記述方法で GPU 配列を操作） | 対応表（LUT）の生成、観測点を平面座標へ投影する計算 |
| 自前のカーネルcustom kernels | 手書きの CUDA C（十数本）。コンパイルと起動は CuPy が担う | 走査線の塗りつぶし、サンプリング（画素値の取得）、レイヤー合成、点と線の描画 |
分かれ目は処理の形にある。すべての画素や点に同じ数式を一律に適用する処理であれば、CuPy の配列演算で簡潔に書ける。 一方、走査線塗りつぶしや線分描画のように要素ごとにループ長や手順が変わる処理は配列演算に向かないため、 CUDA C で専用カーネルを書いて CuPy から呼び出している。他の複雑な CUDA 経路は使っていない。
技術的にできないからではない。中心を固定した静的タイルを 1 セット焼いて全員に配る方が、桁違いに安いからである。
イコールアース図法のような世界地図であっても、中心を固定すれば投影後の平面は 1 枚の静止画であり、z/x/y のタイルピラミッドに分割すること自体はできる。それにもかかわらず Web メルカトル（EPSG:3857）が基図のタイルに選ばれたのは、「等角（どのズームでも形が局所的に正しい）」「円筒（タイルの正方形格子が経緯線と揃う）」「ズーム間で自己相似」の 3 条件が揃い、どこまで拡大しても破綻しないタイルを作れる図法が他に無かったためである。
| 理由 | 中身 |
|---|---|
| タイルは「配信」の単位delivery, not rendering | 1 つのタイルピラミッドを一度焼けば、全世界のユーザーに同じ静的ファイルを CDN から安価に配れる。中心を変えられる地図は「操作する人ごとに別の絵」になるため、この大量配信モデルが成り立たない |
| 主用途はナビゲーションlocal navigation | 地図利用の大半は「今いる街の交差点で右に曲がる」。求められるのは局所の形が正しいこと（等角）と、「北が上」という共通の慣習であり、地球規模で距離や面積を正しく見たい人は少数に限られる |
| 格子が索引を兼ねるgrid as index | z/x/y は描画だけでなく、空間データの分割・検索・差分更新・キャッシュの鍵になっている。EPSG:3857 を前提にしたエコシステムが 20 年分積み上がっている |
| 端末の GPU 性能client GPU | 端末側で毎フレーム再投影するには、全データをベクタや生タイルで保持し、毎フレーム座標変換する計算力が要る。近年はズームアウト時に地球儀（球体）を表示したり、低ズーム時だけ図法を選べたりするサービスも登場したが、拡大すればすべて通常のメルカトル図法に戻る。 |