QGIS や GDAL、PostGIS の中で動いている座標変換ライブラリ PROJ。GIS に関わる方なら、意識せずとも毎日お世話になっているはずの、業界の事実上の標準基盤です。

実は私自身、以前開発した RTK-GNSS アプリ GeoDiveExa では PROJ（当時 9.1.1）を採用していました。QGIS など他ソフトとの座標互換性が取れるのは大きなメリットで、その判断は今でも正しかったと思っています。

それなのに、なぜ GeoConverterPro / GeoPrism JP では PROJ を使わず、日本特化の変換エンジン GeoCoreJP を自前で開発したのか。今回は「両方を実際に使った開発者」の立場から、PROJ と GeoCoreJP の守備範囲の違いを整理します。結論を先に言うと、この2つは競合ではなく、カバーしている層が違います。

PROJ とは — 世界標準の変換基盤

PROJ は OSGeo プロジェクトの一つで、MIT/X ライセンスのオープンソース。EPSG レジストリに登録された世界数千の座標参照系（CRS）を相互変換できる、C/C++ 製の汎用ライブラリです。QGIS・GDAL・PostGIS・GRASS など主要な GIS ソフトの内部で使われており、「EPSG コードを指定すれば変換できる」世界共通のインフラと言えます。

日本の測地系について、PROJ 本体および公式データセット（PROJ CDN）が公式に同梱しているのは、実は高さ（鉛直方向）のジオイドモデルだけです。

• ジオイド2011（GSIGEO2011）を同梱（jp_gsi_gsigeo2011.tif）
• ジオイド2024（JPGEO2024）も 2025 年 4 月に対応がコミットされ（jp_gsi_jpgeo2024.tif）、EPSG にも JGD2024 の鉛直系や平面直角座標系との複合座標系（19系まで）が登録されました

一方で、緯度経度をシフトさせる水平方向のグリッド（TKY2JGD や PatchJGD）は、PROJ 本体にも公式 CDN にも同梱されていません。理由ははっきりしていて、国土地理院が配布する水平パラメータは独自の .par 形式であり、PROJ が標準で対応する NTv2 形式（.gsb）や GeoTIFF（.tif）ではないためです。「高さの変換データは入っているが、緯度経度をずらす水平データは入っていない」——これが正確な実態です。

つまり「楕円体高から標高を出す」ジオイド変換は PROJ で世界標準の作法でできますが、「東京測地系の古い図面を JGD2000/JGD2011 に直す」水平変換は、PROJ をそのまま入れただけでは動きません。国土地理院の .par を有志の変換スクリプトで .gsb（NTv2）に変換し、データディレクトリに置いて +nadgrids=ファイル名.gsb で明示的に読ませる、という開発者側の作り込みが必要になります。

グリッドを渡さないと PROJ は「黙ってズレる」

ここで実務上いちばん怖いのは、グリッドが無くても PROJ はエラーを出さないことです。JGD2011 や TOKYO を指定すると、PROJ は EPSG コードが指す楕円体と投影法だけを使った処理に静かにフォールバックします。返ってくるのは「それらしい値」なので、間違いに気づきにくいのです。

• 同一測地系内（緯度経度 ↔ 平面直角座標）：楕円体の寸法（TOKYO＝ベッセル1841、JGD＝GRS80）は PROJ にハードコードされているので、投影計算はミリ以下で正確。ここは問題ありません。
• TOKYO → JGD：TKY2JGD のグリッドが無いと、PROJ は EPSG に登録された 3/7 パラメータのヘルマート変換（地球全体を平行移動・回転させるだけの近似）にフォールバックします。地域ごとの局所的な歪みを見ないため、数メートル〜十数メートルの誤差が出ます。エラーにならず値が返るのがやっかいな点です。
• JGD2000 → JGD2011：最も危険な挙動です。両者は同じ GRS80 楕円体なので、PatchJGD グリッドが無いと PROJ はシフト量ゼロ＝何も変換しない（差分0でそのまま素通り）。つまり地震による地殻変動が丸ごと無視されます。

RTK で 2cm 精度を狙うアプリでこれをやると致命的です。TOKYO からの変換は数メートルずれ、地震の地殻変動（PatchJGD）は完全に消える。EPSG コードの指定は「座標の器＝楕円体と投影法を決めるタグ」であって、局所的な高精度シフトを自動でやってくれる魔法のコマンドではない、ということです。センチメートル級を担保するには、前述のとおり .par を .gsb に変換して PROJ のパイプラインへ強制的に読ませる設計が不可欠になります。そして GeoCoreJP は、その「読ませるグリッドを揃える・複数地震を発生順に重ね掛けする・更新に追従する」部分を丸ごと引き受けています。

それでも空白が残る — 「時間」の層

水平グリッドを自前で .gsb 化して組み込んでも、まだ埋まらない層があります。日本の測量実務は元期の静的な変換だけでは回らないからです。

日本列島はプレート運動で毎年数センチ動き、GNSS 受信機が返すのは「今期」の座標です。これを台帳の「元期」に引き戻すのがセミダイナミック補正（毎年パラメータ更新）と定常時地殻変動補正 POS2JGD（2か月ごと更新）。さらに大きな地震のたびに、国土地理院は地震補正のパラメータを公開します（2016熊本・2024能登・2024日向灘・2025青森県東方沖…）。

執筆時点（2026年7月）で、この層は PROJ の空白地帯です。

※水平方向のグリッド（TKY2JGD・PatchJGD）は PROJ 本体にも公式 CDN にも同梱されていません。国土地理院の .par を有志のスクリプトで NTv2（.gsb）に変換し、+nadgrids=…gsb で読み込ませれば利用できますが、標準では提供されていません。PROJ が公式同梱しているのは高さ（ジオイド）だけです。

これは PROJ の欠陥ではありません。PROJ は EPSG レジストリという「静的な CRS の登録簿」を土台にした仕組みであり、毎年・2か月ごとに更新される時間依存のパラメータは、そもそもこの登録体系に乗りにくいのです。構造に由来する空白なので、当面埋まりにくいと私は見ています。

GeoCoreJP が埋めているもの

GeoCoreJP は、この空白＝「日本の測量実務で毎日使う部分」のために作った変換エンジンです。GeoConverterPro と GeoPrism JP の共通エンジンとして、次を担っています(GeoDiveExaにもC#版が組み込まれています）。

• 時間依存補正の内蔵：セミダイナミック・POS2JGD・個別地震補正を内蔵し、国土地理院の公表に直接追従して更新
• 複数地震の自動合成：一つの土地に複数の地震が効く場合（例：宮城県栗原市＝2008岩手・宮城内陸＋2011東北）、発生順に補正を自動で重ね掛け
• 完全オフライン：必要なパラメータをすべてアプリ内 DB に持つため、電波の届かない現場でも動作
• 品質の開示：補正メッシュの境界で 4 隅のデータが揃わない地点では、その事実を CCQ（座標変換クオリティー）という指標で利用者に明示

最後の点は設計思想の違いとして面白いところで、国土地理院のツールはデータのない地点を「対象地域外＝補正なし」とするのに対し、GeoCoreJP は連続性を優先して補正を続けつつ、扱いが異なることを隠さず伝える方針を取っています。どちらが正しいという話ではなく、現場アプリとしての判断です。

なお精度については、全国 73 のテストポイントで国土地理院の公式ツール（TKY2JGD・PatchJGD・SemiDynaEXE・POS2JGD）と突き合わせ、残差がミリ単位（多くは 1mm 未満）に収まることを確認しています。詳細は次の2本にまとめています。

• テストポイント設計を解説する — 地震補正・重複地震・境界域・47都道府県庁
• 全テストポイントを国土地理院の変換サイトと比較する — 精度の証明と検証の大変さ

使い分けの結論

GeoDiveExa で 当初PROJ を選んだのも、GeoConverterPro で GeoCoreJP を作ったのも、それぞれの守備範囲に合わせた選択でした。静的な変換と相互運用性は世界標準の PROJ に任せ、動き続ける日本列島との付き合い（時間依存の補正）は特化エンジンで引き受ける——併用も含めて、この分担が現実的だと思います。

「自分の座標が元期なのか今期なのか」「どの地震補正が効いている土地なのか」を手元で確かめたい方は、GeoConverterPro を試してみてください。変換詳細のトレースで、どの補正が一段ずつどれだけ効いたかまで読めます。

GeoConverterPro を App Store で見る

開発者より: アプリ・Kindle本・オープンソースの一覧は GitHub: amru195704 にまとめています。

お願い
本記事の情報は参考目的で掲載しており、正確性・完全性を保証するものではありません。誤記・不正確な情報がございましたら、コメント欄よりご指摘いただければ、確認のうえ修正いたします。