同僚からShapefileを受け取ってベースマップに重ねたら、建物が本来の位置から200メートルほどずれている。.prjファイルには "GCS_WGS_1984" とあるが、データは実際にはJGD2000で収集されていた。この不一致は数時間のデバッグを消費し、原因は一つに絞られる：EPSGコードの誤り。
EPSGコードは座標参照系（CRS）を表す数値の略称だ。EPSG:4326 と言えば、GISエンジニアなら誰でもWGS 84のことだと分かる——曖昧さなし、WKT文字列を解析する手間もなし。これを正しく理解することが、データのずれを防ぐ第一歩だ。
EPSGコードはどこから来たのか？
EPSGは欧州石油調査グループ（European Petroleum Survey Group）の略で、1985年に設立された。背景はこうだ：複数の石油会社が同じ海域でオフショア調査を行っていたが、各社が異なる座標系を使っていたため、データを統合できなかった。Elf AquitaineのチーフサーベイヤーJean-Patrick Girbigが、Agip、BP、Deminex、Shell、Statoil、Totalから大地測量の専門家を集めてこの問題を解決した。
最初の成果は標準化されたCRSデータベースで、1993年に500以上の定義を含む形で公開された。1995年、GeoTIFF v1.0規格がCRS識別子としてEPSGコードを採用し、EPSGは石油産業を飛び出してGIS全体に普及した。
2005年にEPSGワーキンググループはIOGP（国際石油・ガス生産者協会）の下で再編されたが、EPSGというブランド名は残った。現在EPSGデータセット（v12.053）には7,000以上のCRS定義、2,500の投影法、2,500の座標変換——合計2万件以上のエントリが含まれる。
EPSGコードとは正確には何か？
EPSGコードは4〜5桁の数値識別子（範囲1024〜32767）で、EPSGデータセット内のCRS、測地基準系（datum）、楕円体、または座標変換メソッドを一意に識別する。技術的な基盤はISO 19111規格だ。
標準的な表記
最も一般的な形式は authority:code：
EPSG:4326
OGCはURL形式も定義しており、Webサービスでよく使われる：
http://www.opengis.net/def/crs/EPSG/0/4326
EPSG定義の中身
各コードは完全なCRS定義に対応している：楕円体パラメータ（長半径、扁平率）、測地基準系、座標軸の方向と順序、単位（度またはメートル）、そして適用地理範囲。
最もよくあるミスは軸順序だ。EPSG:4326の標準定義は緯度が先（lat, lng）だが、多くのGISソフトウェアは実際に経度を先に渡す（lng, lat）。GeoJSONはlng, latを使い、LeafletのL.latLng()はlat, lngを期待する——混同した場合のバグは座標が明らかに入れ替わっているのではなく、地図上で点がランダムに散らばるように見える。
よく使われるEPSGコード
| EPSGコード | 名前 | タイプ | 単位 | 典型的な用途 |
|---|---|---|---|---|
| 4326 | WGS 84 | 地理座標系 | 度 | GPS・グローバルデータ交換 |
| 3857 | Web Mercator | 投影座標系 | メートル | ウェブ地図（Google Maps、OSM） |
| 6668 | JGD2011 | 地理座標系 | 度 | 日本国家基準（現行標準） |
| 4612 | JGD2000 | 地理座標系 | 度 | 日本国家基準（旧標準） |
| 6677 | JGD2011 / 平面直角IX系 | 投影座標系 | メートル | 東京・関東地方の測量 |
| 32654 | UTM Zone 54N | 投影座標系 | メートル | 日本（本州中部・東部） |
| 2154 | RGF93 / Lambert-93 | 投影座標系 | メートル | フランス |
| 27700 | OSGB 1936 | 投影座標系 | メートル | イギリス |
EPSG:4326 vs EPSG:3857——誰もが混同する二つのコード
EPSG:4326（WGS 84） は地理座標系で、緯度・経度（度）で位置を表す。GPSの生データはWGS 84だ。データ保存と交換の標準となっている。
EPSG:3857（Web Mercator） は投影座標系で、地球を平面に投影し、単位はメートル。Google Mapsが2005年のサービス開始時にこの投影を採用し、ほぼすべてのウェブ地図がこれに追随した。
EPSGは当初3857の登録を拒否した。理由：楕円体測地基準系に球面公式を適用しており、数学的に正確ではない。GoogleはそれでもリリースしてEPSGが折れて2009年にコードを登録した時点では、地球上のすべてのウェブ地図がすでに使っていた。普及している一方、3857は正確な面積・距離計測には適していない——標準メルカトルと比べて約0.33%のスケール誤差がある。
基本ルール：保存には4326、表示には3857。 KunYuの座標変換ツールで両者の変換が可能だ。
正しいEPSGコードを見つける方法
ケース1：CRS名が分かっている場合
"WGS 84" や "JGD2011" などの名前が分かっている場合は、EPSG Searchツールで直接検索できる。コード、名前、地域で8,000以上のEPSG定義を検索できる。
ケース2：場所は分かっているがCRSが分からない場合
特定のエリアに適した投影座標系が必要なら、EPSG Finderツールを使う——地図をクリックするかボックスを描くと、その地域をカバーするEPSGコードが一覧表示される。
ケース3：CRS情報なしでデータを受け取った場合
データに付属するメタデータファイルを確認する。ShapefileにはWKT形式のCRS定義を含む .prj ファイルがある（テキストエディタで開ける）。GeoTIFFは通常メタデータにEPSG情報を埋め込んでいる。GDALを使う場合：
# GeoTIFFのCRSを確認
gdalsrsinfo input.tif
# ShapefileのPRJファイルを読む
cat data.prj
GISソフトウェアでのEPSGコードの使い方
QGIS：プロジェクトプロパティ → CRSパネルでEPSGコードを指定してCRSを検索・切り替えできる。QGISのデフォルトはEPSG:4326。
GDAL/OGR：EPSGコードで目標CRSを直接指定：
# ShapefileをJGD2011からWGS 84に再投影
ogr2ogr -s_srs EPSG:6668 -t_srs EPSG:4326 output.shp input.shp
PROJ：オープンソースの座標変換エンジン。データベース（proj.db）にEPSG、IGNF、ESRIのCRS定義が統合されている。
コードでも同様にEPSGコードを使える：
// Proj4js (JavaScript)
import proj4 from "proj4";
proj4.defs("EPSG:4490", "+proj=longlat +ellps=GRS80 +no_defs");
const result = proj4("EPSG:4326", "EPSG:4490", [116.4074, 39.9042]);
# pyproj (Python)
from pyproj import Transformer
transformer = Transformer.from_crs("EPSG:4326", "EPSG:3857", always_xy=True)
x, y = transformer.transform(139.6917, 35.6895)
よくある質問
EPSG:4326とCRS:84の違いは？
どちらもWGS 84だが、軸順序が異なる。EPSG:4326の標準定義は緯度が先（lat, lng）だが、CRS:84は経度が先（lng, lat）。GeoJSONはlng, latを使うが、Leafletの L.latLng() はlat, lngを期待する——この混同はよくあるバグの原因だ。
データが数十〜数百メートルずれているのはなぜ？
最も多い原因はEPSGコードの誤り。日本では旧日本測地系（Tokyo Datum、EPSG:4301）とJGD2000/JGD2011の間に約450メートルの系統的なずれがある。このくらいのオフセットが見られたら、まず測地系の不一致を疑うべきだ。
EPSGコードは廃止されるか？
更新はされるが、削除や再割り当てはされない。IOGPの測地小委員会がEPSGデータセットを定期的に更新する。廃止されたコードはdeprecatedとしてマークされ、代替コードへのポインタが示される。
日本のEPSGコードは何を使えばいい？
現在の日本測地系はJGD2011（EPSG:6668）だ。2011年の東日本大震災後に地殻変動を考慮して改訂された。投影座標系は国土地理院の平面直角座標系（EPSG:6669〜6687）が一般的だ。古い東京測地系（EPSG:4301）のデータは現在の基準と最大数百メートルずれているため、そのままオーバーレイしてはいけない。
9割のケースに対応するルール
保存と交換には4326、ウェブ表示には3857。 迷ったら、EPSG Searchで名前から検索し、EPSG Finderで地図上の場所から検索できる。