緯度と経度、どちらを先に書く？ — 形式ごとに違う「軸順序」の落とし穴

座標データを受け渡ししていて、測地系も単位も合っているのに点が全然違う場所に落ちることがあります。日本の現場なら、点が海の上や中国大陸のあたりに散らばる。この症状のかなりの割合は、測地系の取り違えではなく軸順序（axis order）の取り違えが原因です。

つまり「緯度・経度」の順で書かれたデータを「経度・緯度」の順で読んだ（またはその逆）というだけの話です。単純ですが、形式ごとに規定がばらばらなので、慣れていても踏みます。

測地系そのものの取り違えについては測地系が書いていない座標データの見分け方で扱いました。この記事は測地系は合っているのにズレるもう一つの原因、軸順序に絞って整理します。

形式ごとの規定を一覧にする

見てのとおり、GeoJSON・KML・Shapefile は「経度が先」、GPX は名前で区別、CSV は無法地帯、そして測量の平面直角座標系だけ X が北という構図です。

なぜ GeoJSON は「経度が先」なのか

GeoJSON の position は [経度, 緯度, （高度）] と仕様で定められています。これは数学やコンピュータグラフィックスの (x, y) の並びに合わせたもので、地図の東西方向を x、南北方向を y と見れば自然な順序です。

一方、人間が地理を語るときは「北緯35度、東経139度」のように緯度から言います。地図帳も測量成果表も緯度が先です。この人間の言語習慣と機械のデータ形式のねじれが、軸順序問題の根っこにあります。

GeoJSON・KML・GPX の座標系についてはGeoJSON・KML・GPXの座標系 — 「WGS84固定」の意味でも扱っています。あちらは「どの測地系か」、こちらは「どの順番か」という切り分けです。

いちばん厄介なのは WKT と EPSG:4326

.prj ファイルなどで使われる WKT には、座標系ごとに軸（AXIS）の定義を書ける仕組みがあります。そして EPSG の登録情報上、EPSG:4326（WGS84 の地理座標系）の軸順序は「緯度, 経度」 です。

ところが実務で流通しているデータやライブラリの多くは、EPSG:4326 を経度・緯度の順として扱ってきました。この食い違いが長年の混乱の種になっていて、ソフトによっては「EPSG:4326（軸順序を尊重）」と「CRS84（経度・緯度固定）」を別物として持っていたり、軸順序を無視するオプションを備えていたりします。

実務上の結論はシンプルです。

EPSG コードだけでは軸順序は決まらないと考え、必ず実データの数値で確かめる。

.prj / WKT そのものの読み方はShapefileの.prjを読む — WKTで座標系を記述するにまとめています。

測量の「X は北」を忘れない

日本の平面直角座標系では、X 軸が北方向（座標系原点を通る子午線）、Y 軸が東方向と定義されています。一般的な数学・GIS の「x = 東、y = 北」とはちょうど逆です。

そのため、測量成果の X, Y をそのまま GIS の x, y に流し込むと、原点を中心に鏡像・回転したような配置になります。数百 m のズレではなく、地図上で明らかに変な場所に出るので気づきやすい失敗ではありますが、CSV のヘッダが X,Y としか書かれていないと、受け取った側が判断できません。

平面直角座標系そのものの考え方は平面直角座標系を地図で学ぶ（GeoPrism JP）が入門になります。

数値レンジで見分ける

幸い、日本国内のデータであれば数値の範囲を見るだけでほぼ判別できます。

つまり十進度のデータなら、2つの数値のうち大きいほうが経度です。北緯35.6812 / 東経139.7671 のような東京の座標で、先頭が 139 なら経度が先、35 なら緯度が先。この判定はスクリプト1行でも書けます。

def guess_axis_order(a, b):
    """日本国内の十進度座標を想定した簡易判定"""
    if 20 <= a <= 46 and 122 <= b <= 154:
        return "緯度, 経度"
    if 122 <= a <= 154 and 20 <= b <= 46:
        return "経度, 緯度"
    return "判定不能（度以外・国外・平面直角座標の可能性）"

ただし両方が 20〜46 に収まる領域はないとはいえ、単位が度分秒（DMS）や度分（DM）で書かれていると数値の桁がまるごと変わります。表記のゆれについては度分秒（DMS）と十進度（DD）の相互変換を参照してください。

受け渡しのときに決めておくこと

CSV で座標をやりとりする場合、次の4点をファイルかメールに明記するだけで事故はほぼ防げます。

1. 測地系（例: JGD2024、旧日本測地系 など）
2. 座標の種類（緯度経度か、平面直角座標か。後者なら系番号）
3. 列の順序と単位（例: lat,lon 十進度6桁、X,Y メートル）
4. 高さの種類（標高か楕円体高か。取り違え防止のチェック）

CAD 図面のように、そもそも測地系情報を持てない形式もあります（DXFに測地系情報はない）。その場合は付随文書で伝えるしかありません。

CSV そのものを堅牢に読み書きする実装面の話はMAUIでCSV入出力を堅牢にする（GeoDiveExa）にまとめています。

GeoConverterPro での扱い

GeoConverterPro では、CSV 変換時にどの列が緯度でどの列が経度かを指定して読み込みます。ファイルの列順にアプリを合わせる形なので、「経度が先の CSV」でも列指定を入れ替えるだけで扱えます。

また、変換結果は使用した測地系・パラメータを含むテキストとして保存できるので、後から「どの向きでどう変換したか」を確認できます（変換の「根拠」をその場で残す）。

まとめ

• 軸順序の取り違えは、測地系が合っていてもデータを壊すもう一つの定番原因
• GeoJSON・KML・Shapefile は経度が先、GPX は属性名で区別、CSV は規定なし
• EPSG:4326 の登録上の軸順序は緯度・経度だが、実装は経度・緯度が多数派。EPSG コードだけを信用しない
• 測量の平面直角座標系は X = 北、Y = 東。GIS の x/y と逆
• 日本国内の十進度なら、大きいほうが経度という数値レンジ判定がほぼ使える

出典

• IETF RFC 7946「The GeoJSON Format」 https://datatracker.ietf.org/doc/html/rfc7946
• Google「KML Reference」 https://developers.google.com/kml/documentation/kmlreference
• Topografix「GPX 1.1 Schema Documentation」 https://www.topografix.com/GPX/1/1/
• 国土地理院「平面直角座標系（平成十四年国土交通省告示第九号）」 https://www.gsi.go.jp/LAW/heimencho.html
• EPSG Geodetic Parameter Dataset https://epsg.org/

関連記事（参考情報）

• 測地系が書いていない座標データの見分け方（GCVP）
• GeoJSON・KML・GPXの座標系 — 「WGS84固定」の意味（GCVP）
• Shapefileの.prjを読む — WKTで座標系を記述する（GCVP）
• 度分秒（DMS）と十進度（DD）の相互変換（GCVP）
• 平面直角座標系を地図で学ぶ — 「19系って何？」（GPRM）
• 緯度・経度「1度」は何メートル？ — 座標の桁数と距離感（GPRM）
• MAUIでCSV入出力を堅牢にする — 文字コード・BOM・改行の実務（GDE）

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

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

アプリを入手（App Store）：GeoConverterPro（座標変換）　｜　GeoPrism JP（測地系の可視化・学習）