
ogr2ogrで座標系を変換するには? — -t_srs と -a_srs の違いと、エラーを出さずに数メートルずれる条件
コマンドは1行です。
GISを立ち上げずに、手元の shp や GeoJSON をまとめて別の座標系にしたい。ogr2ogr ならターミナルの1行で終わります。では、その1行のどこに測地系が入るのでしょうか。
答えは -t_srs です。ただし——名前がよく似たオプションがもう1つあって、そちらは座標を1ミリも動かしません。 事故のほとんどはこの取り違えで起きています。
まず、最短の1行
JGD2011の緯度経度(EPSG:6668)で持っている GeoJSON を、平面直角座標系 第VII系(EPSG:6675)の Shapefile にする場合。
ogr2ogr -t_srs EPSG:6675 out.shp in.geojson
これだけです。出力形式は拡張子から推測されるので -f は省けます。逆に、明示するならこう。
ogr2ogr -f "ESRI Shapefile" -t_srs EPSG:6675 out.shp in.geojson
ここで -t_srs は2つのことを同時にやっています。座標値を計算し直し、かつ「出力はこのCRSだ」と書き込む。 変換と宣言がセットです。

3つのオプションの役割を分ける
日本のデータで使うのは、実質この3つです。
| オプション | 何をするか | 座標値は動くか |
|---|---|---|
-t_srs <CRS> |
このCRSへ変換し、出力CRSとして割り当てる | 動く |
-s_srs <CRS> |
入力側のCRSを上書きする(元データの宣言を無視する) | 単独では効かない |
-a_srs <CRS> |
出力にこのCRSを割り当てるだけ(再投影しない) | 動かない |
補足が2つあります。
-s_srs は単独では意味がありません。 公式ドキュメントに「このオプションは -t_srs と一緒に使って再投影するときにだけ効果がある」と明記されています。.prj が無い shp や、宣言が間違っている shp を正しく変換したいとき、-s_srs で入力の素性を教えてから -t_srs で飛ばす、という組み合わせで使います。
ogr2ogr -s_srs EPSG:4301 -t_srs EPSG:6668 out.geojson in.shp
-a_srs と -t_srs は排他です。 ogr2ogr の使用法(synopsis)でも [[-a_srs <srs_def>]|[-t_srs <srs_def>]] と、どちらか一方しか書けない形になっています。
「座標系を設定」したのに数値が変わらないのは、バグなのか
ここがいちばん引っかかるところなので、独立して書きます。
バグではありません。-a_srs は宣言であって、変換ではないからです。
たとえば第V系のつもりで持っていた X=0, Y=0 のデータに -a_srs EPSG:6673(第V系)を付けても、X=0, Y=0 のままです。そこへ -a_srs EPSG:6675(第VII系)を付け直すと、同じ X=0, Y=0 が、まったく別の場所を指す座標に化けます。 数値は1つも動いていないのに、地図上の位置だけが移動する。
これは QGIS の「レイヤCRSを設定」と同じ性格の操作です。使いどころは限られていて、
- 元データにCRSの宣言が無く、中身が何系かは分かっているので、正しい札を貼りたいとき
- 誤った
.prjが付いていて、座標値は正しいので、宣言だけ直したいとき
この2つ以外で -a_srs を選んでいるなら、たいてい -t_srs の書き間違いです。
冒頭で「1ミリも動かさない」と書いたのは、この意味です。
エラーを出さずに、数メートルずれる条件
旧日本測地系(EPSG:4301)や JGD2000(EPSG:4612)が混ざる案件では、もう1つ知っておくことがあります。
ogr2ogr の変換は PROJ が担当します。PROJ は測地系間の変換にグリッド(日本なら TKY2JGD 由来のもの)を使いますが、そのグリッドが手元に無いとき、PROJ は止まりません。 精度の落ちる別の方法——ヘルマート変換や、さらに大雑把な「ballpark(当たりをつける)」変換——に黙って切り替えます。
結果はどうなるか。コマンドは正常終了し、ファイルもできる。ただし座標が数メートルから、条件によってはそれ以上ずれている。 ログを注意して見ていなければ気づけません。
GDAL 3.11 以降には、この挙動を止めるオプションがあります。
ogr2ogr -ct_opt ONLY_BEST=YES -ct_opt ALLOW_BALLPARK=NO \
-s_srs EPSG:4301 -t_srs EPSG:6668 out.geojson in.shp
ONLY_BEST=YES— 最良の変換経路だけを使う。グリッドが無ければエラーで落ちるALLOW_BALLPARK=NO— 大雑把な変換への逃げ道を塞ぐ
「落ちてくれる」ほうが安全な場面は多いはずです。既定値は環境変数 PROJ_ONLY_BEST_DEFAULT や proj.ini でも設定できます。
なお ONLY_BEST は PROJ 9.2 より前のバージョンでは効きません。手元の PROJ のバージョンを先に確認してください。
緯度と経度が入れ替わるとき
GDAL 3.0 から、CRSを定義した機関が決めた軸順が既定で尊重されるようになりました。EPSG:4326 の権威定義は「緯度が先、経度が後」です。したがって EPSG:4326 や WGS84 という文字列から作ったCRSは、緯度・経度の順で扱われます。
いっぽう OGC:CRS84 は経度が先、緯度が後を強制する定義です。GeoJSON が採っているのはこちらの順序で、迷ったときは EPSG:4326 ではなく OGC:CRS84 と書くほうが曖昧さがありません。
自分で変換パイプラインを書く -ct オプションを使う場合は、さらに明示的な配慮が要ります。GDAL のドキュメントは「入力CRSが北→東の軸順なら、パイプラインの先頭に step proj=axisswap order=2,1 を入れること(出力側が北→東なら末尾に)」と指示しています。自動では入りません。
平面直角座標系のXとYが入れ替わる話とは原因が別なので、混同しないでください。
元期と今期を指定する
JGD2011やITRFのような動的CRSを扱うときは、GDAL 3.4 以降で座標のエポックを渡せます。
ogr2ogr -s_srs <入力の動的CRS> -s_coord_epoch 2020.5 \
-t_srs EPSG:6668 out.geojson in.geojson
-s_coord_epoch <epoch>— 入力側のエポック(-s_srsを使ったときだけ有効)-t_coord_epoch <epoch>— 出力側のエポック(-t_srsを使ったときだけ有効)
PROJ 9.4 より前は、この2つを同時に指定できませんでした(動的CRSどうしの変換に未対応だったため)。ここも手元のバージョン次第です。
結果を確認する
変換したあと、出力のCRSを見るのは ogrinfo です。
ogrinfo -so out.shp out
-so(summary only)を付けると、レイヤのCRSと範囲だけが出ます。ここで確認したいのは2点。
- 意図したCRSが書き込まれているか(
-a_srsと-t_srsの取り違えはここで出る) - 座標の範囲が想定どおりか — 平面直角座標系なら X が±数十万m、緯度経度なら 20〜46 と 122〜154 の範囲。桁が違えば単位か系番号の間違いです
CSVで数値そのものを見たいときは、ジオメトリを列に落とすオプションが要ります。
ogr2ogr -f CSV -lco GEOMETRY=AS_XY out.csv in.shp
CSVドライバは既定ではジオメトリを保存しないため、-lco GEOMETRY=AS_XY(3次元なら AS_XYZ)の指定が必要です。
まとめ
-t_srsが変換、-a_srsは宣言。 座標値が動かないのはバグではなく仕様。この2つは同時に書けない-s_srsは単独では効かない。-t_srsと組で、入力側の素性を上書きするときに使う- グリッドが無くても PROJ は止まらない。 精度の低い変換に黙って切り替わる。
-ct_opt ONLY_BEST=YES-ct_opt ALLOW_BALLPARK=NO(GDAL 3.11〜)で止められる - GDAL 3.0 以降、EPSG:4326 は緯度が先。 経度が先でよいなら
OGC:CRS84と書く。-ctを自分で書くならaxisswap order=2,1は自分で入れる - 動的CRSはエポックを渡せる(
-s_coord_epoch/-t_coord_epoch、GDAL 3.4〜) - 変換後は
ogrinfo -soでCRSと座標範囲を必ず見る
ogr2ogr が出した結果が正しいかどうかは、1点だけ別の実装に通して突き合わせるのがいちばん早い確認方法です。GeoConverter Pro は旧日本測地系・JGD2000/2011/2024 と平面直角19系の相互変換を、グリッドを内蔵した状態でオフラインで行えます。手元の1点を入れて、コマンドの出力と数値が合うかを見てください。

https://apps.apple.com/jp/app/geoconverter-pro/id6761740960
オプション名・既定の挙動は GDAL / PROJ のバージョンで変わります。本記事の記述は2026年8月時点の安定版ドキュメントに基づくものです。実行前に
ogr2ogr --helpとogrinfo --versionで手元の版を確認してください。
出典
- GDAL ドキュメント「ogr2ogr」 https://gdal.org/en/stable/programs/ogr2ogr.html
- GDAL ドキュメント「OGR Coordinate Reference Systems and Coordinate Transformation tutorial」 https://gdal.org/en/stable/tutorials/osr_api_tut.html
- GDAL ドキュメント「ogrinfo」 https://gdal.org/en/stable/programs/ogrinfo.html
- PROJ ドキュメント(glossary / ballpark transformation) https://proj.org/glossary.html
- 国土地理院「TKY2JGD」 https://www.gsi.go.jp/sokuchikijun/tky2jgd.html
次に確認する
- QGISの画面で同じ判断をするときの手順を確認する — 本記事のコマンドをGUIでやる場合のEPSGコードの決め方です
- PROJがグリッド無しで黙ってズレる条件を詳しく確認する — 本記事で1節にまとめたフォールバックを、実測で掘り下げた回です
- 緯度と経度のどちらを先に書くかが形式ごとに違う話を確認する — 軸順の落とし穴をデータ形式の側から見た回です
- Shapefileの.prjに書かれたWKTの読み方を確認する —
-s_srsで上書きする前に、元データが何を宣言しているかを読む回です - パラメータ変換とグリッド変換の違いを図で確認する(GeoPrism JP) — PROJ が「精度の落ちる方法」に切り替えるとき、何に切り替わっているのかが分かります
- 書籍でまとめて学ぶ: 『日本の測地系Q&A』第13章「座標データの落とし穴」(Kindle Unlimited対応)
入門から通しで読むなら: 『日本の測地系がわかる本』 — 旧日本測地系から JGD2024 まで、座標がズレる理由と実務での扱いを1冊にまとめました(Kindle Unlimited 対応)
開発者より: アプリ・Kindle本・オープンソースの一覧は GitHub: amru195704 にまとめています。
お願い
本記事の情報は参考目的で掲載しており、正確性・完全性を保証するものではありません。誤記・不正確な情報がございましたら、コメント欄よりご指摘いただければ、確認のうえ修正いたします。
コメントを残す