GeoDiveExaでPROJを採用した話・その後 — 2年使って見えた守備範囲

2026年7月10日

アマグラマー

2024年7月に「GeoDiveExaで使用しているProj（座標変換ライブラリ）」という記事を書きました。GeoDiveExa（GDE）の座標変換に OSS の標準ライブラリ PROJ を採用した、という内容です。あれから2年ほど運用し、その間に JGD2024 への移行（2025年4月）や複数の地震補正パラメータの公開もありました。今回はその「続編」として、PROJ を実務アプリで使い続けて見えてきた守備範囲を振り返ります。

PROJ を選んだ判断は正しかった

まず結論として、GDE で PROJ を選んだこと自体は今でも正解だったと思っています。理由は前回書いたとおりで、EPSG コードを介した他ソフトとの互換性です。GDE で取得した座標を QGIS に持ち込む、逆に QGIS で作ったデータを現場で参照する——この往復が「EPSG:6668」のようなコード一つで齟齬なく成立するのは、世界標準基盤ならではの安心感です。

ただし、日本の静的な変換について PROJ が公式に同梱しているのは高さ（ジオイド）だけという点は、この2年で正しく捉え直したところです。ジオイド2011（jp_gsi_gsigeo2011.tif）を標準で同梱し、2025年4月にはジオイド2024（jp_gsi_jpgeo2024.tif）を使う変換もコミット、EPSG 側にも JGD2024 の鉛直系や平面直角座標系との複合座標系（19系まで）が登録されました。一方で、TKY2JGD（旧日本測地系→JGD2000）や PatchJGD といった緯度経度をシフトさせる水平方向のグリッドは、PROJ 本体にも公式 CDN にも同梱されていません。国土地理院の水平パラメータが独自の .par 形式で、PROJ 標準の NTv2（.gsb）や GeoTIFF ではないためです。使うには .par を .gsb に変換し +nadgrids=…gsb で読み込ませる、という開発者側の作り込みが要ります。「昔のものさしで測った座標を今のものさしに翻訳する」水平変換も、PROJ をそのまま入れただけでは動かない——これが正確な実態です。

グリッドが無いと、PROJ は「黙って近似」する

2年使って痛感したのは、グリッドが無くても PROJ はエラーを出さないという点です。JGD2011 や TOKYO を指定すると、EPSG コードが指す楕円体と投影法だけを使った処理に静かに落ち、「それらしい値」を返します。

同一測地系内（緯度経度 ↔ 平面直角）：楕円体（TOKYO＝ベッセル1841、JGD＝GRS80）は PROJ にハードコードされているので、投影はミリ以下で正確。ここは問題なし。
TOKYO → JGD：TKY2JGD グリッドが無いと、3/7 パラメータのヘルマート変換（全体の平行移動・回転だけの近似）にフォールバックし、局所的な歪みを無視して数メートル〜十数メートルずれる。
JGD2000 → JGD2011：両者は同じ GRS80 楕円体のため、PatchJGD グリッドが無いと シフト量ゼロ＝何もしない。地震の地殻変動がまるごと無視される。

RTK で 2cm を扱う GDE では、この「エラーにならず黙ってズレる」挙動は致命的です。EPSG コードの指定は「座標の器（楕円体＋投影法）を決めるタグ」であって、局所的な高精度シフトを自動でやってくれる魔法ではない——センチ級を守るには、.par→.gsb を用意して PROJ のパイプラインへ強制的に読ませる設計が要る、というのが2年の結論です。

2年ではっきりした「空白」

一方で、使い続けるうちに輪郭がはっきりしてきた空白があります。時間依存の補正です。

RTK-GNSS アプリである GDE が現場で受け取るのは「今期」＝いま現在の座標です。しかし台帳や図面は「元期」＝基準日に固定した座標で管理されています。この橋渡しをするのが、毎年パラメータが更新されるセミダイナミック補正と、2か月ごとに更新される定常時地殻変動補正（POS2JGD）。さらに2016年熊本、2024年能登・日向灘、2025年青森県東方沖と、大きな地震のたびに個別の地震補正パラメータが公開されてきました。

執筆時点（2026年7月）で、この層は PROJ の標準対応の外側にあります。TKY2JGD・PatchJGD・個別地震補正のような静的グリッドは、国土地理院のパラメータを自力で .gsb（NTv2）に変換すれば理論上は動かせますが、毎年・隔月で更新されるセミダイナミック／POS2JGD を EPSG レジストリの静的な登録体系に乗せるのは、そもそも構造的に難しい。これは PROJ の欠陥ではなく、世界標準の登録簿と、動き続ける日本列島の運用実態との間にあるギャップだと理解しています。

エコシステムとしての分担

そこで Geo アプリ群では、この空白を埋める日本特化の変換エンジン GeoCoreJP を整備しました。GeoConverterPro / GeoPrism JP の共通エンジンで、セミダイナミック・POS2JGD・個別地震補正（複数地震の発生順逐次適用を含む）を内蔵し、完全オフラインで動きます。C# 版もエコシステム共通ライブラリとして整備しており、静的変換と相互運用性は PROJ、時間依存補正は GeoCoreJP、という分担が現実的な着地点だと考えています。

PROJ と GeoCoreJP の対応範囲を項目ごとに突き合わせた詳細な比較表と、精度検証（全国73テストポイントで国土地理院公式ツールと残差ミリ単位の照合）については、GeoConverterPro ブログの本編記事にまとめました。

PROJで足りること・足りないこと — 日本特化エンジンGeoCoreJPを作った理由（GeoConverterProブログ）

「ライブラリを選ぶ」とは、そのライブラリが何をカバーし何をカバーしないかを知ることだ——2年前の採用記事の続編として、そんな教訓を残しておきます。