Shapefileの.prjを読む — WKTで座標系を記述する

GISソフトでShapefile（.shp）を受け渡しするとき、同じフォルダに入っている.prjという小さなテキストファイルに気づいたことはないでしょうか。中身を開くと英語の記号がぎっしり並んだ1行の文字列で、パッと見ただけでは何が書いてあるのか分かりにくいものです。今回はこの.prjファイルの正体であるWKT（Well-Known Text）という記述形式を、GeoConverterPro（GCVP）の座標変換の視点から読み解きます。

Shapefileは実は複数ファイルの集合体

「Shapefile」と呼ばれていますが、実体は.shp単体ではなく、最低でも次の3ファイルがセットで1つの地理データを構成しています。

拡張子	役割
`.shp`	図形（点・線・面）の座標そのもの
`.shx`	`.shp`内の各図形へすばやくアクセスするための索引
`.dbf`	各図形に紐づく属性データ（名称・数値など）
`.prj`（任意）	座標系の定義（WKT形式のテキスト）

このうち.prjだけは仕様上「必須」ではありません。ESRI社の元々のShapefile仕様（1998年公開のテクニカル・ホワイトペーパー）には座標系の記述形式が含まれておらず、後から.prjとして補助的に追加された経緯があります。そのため、古いデータや簡易的なエクスポートでは.prjが欠落していることがあり、その場合は「座標の並びだけが分かって、どの測地系・座標系なのかはファイル単体では判定できない」という状態になります。これは前回扱ったGeoJSON・KML・GPXがWGS84固定という仕様とは対照的で、Shapefileは「座標系は毎回変わり得る・書いてあるとは限らない」形式です。

WKTの中身を分解する

.prjを実際にテキストエディタで開くと、次のような1行が書かれています（読みやすく改行して示します）。

PROJCS["JGD2011_Japan_Zone_9",
  GEOGCS["GCS_JGD_2011",
    DATUM["D_JGD_2011",
      SPHEROID["GRS_1980",6378137.0,298.257222101]],
    PRIMEM["Greenwich",0.0],
    UNIT["Degree",0.0174532925199433]],
  PROJECTION["Transverse_Mercator"],
  PARAMETER["False_Easting",0.0],
  PARAMETER["False_Northing",0.0],
  PARAMETER["Central_Meridian",139.8333333333333],
  PARAMETER["Scale_Factor",0.9999],
  PARAMETER["Latitude_Of_Origin",36.0],
  UNIT["Meter",1.0]]

構造を要素ごとに読むと、この1行が何を定義しているかが見えてきます。

要素	この例での値	意味
`PROJCS`	JGD2011_Japan_Zone_9	投影座標系全体の名前（平面直角座標系第9系）
`GEOGCS` / `DATUM`	JGD2011	元になる地理座標系・測地系
`SPHEROID`	GRS_1980（a=6378137.0, 1/f=298.257222101）	準拠楕円体の定数
`PROJECTION`	Transverse_Mercator	投影方式（ガウス・クリューゲル投影の系列）
`Central_Meridian`	139.8333…	中央子午線の経度（第9系の原点経度）
`Scale_Factor`	0.9999	中央子午線上の縮尺係数
`UNIT`（末尾）	Meter	座標値の単位はメートル

つまり.prjは、「どの測地系（DATUM）を基準に」「どんな楕円体（SPHEROID）で」「どの投影方式（PROJECTION）で」「どのパラメータ（原点・縮尺係数）で」座標を平面に落としたかを、人間にも読めるテキストで丸ごと記述したものです。日本の平面直角座標系（1〜19系）を使うShapefileでは、系ごとにCentral_MeridianとLatitude_Of_Originの値だけが変わり、他の骨格はほぼ共通というパターンが多く見られます。

平面直角座標系全19系の区分

EPSGコードとの関係

WKTの文字列は情報量が多い一方、人間が読み書きするには冗長です。そこで実務でよく使われるのが、同じ座標系定義に対応するEPSGコードという数値IDです。たとえば上記のJGD2011平面直角座標系第9系は、EPSG:6677という4桁のコード1つで参照できます。

多くのGISソフトは「EPSGコードを指定 → 内部でWKTに展開して.prjに書き出す」という流れで動いているため、実務上はWKTの中身を毎回手で書くことはほとんどありません。ただし、次のような場面ではWKTを直接読む必要が出てきます。

.prjが壊れている・空になっているデータを受け取り、内容を目視で復旧する
独自ツールやスクリプトでShapefileを生成し、.prjを自前で書き出す
「見慣れないDATUM名」が書かれたデータの座標系を特定する（例: 旧日本測地系のTokyo DatumがD_Tokyoとして残っているケース）

JGD2024とEPSGコードで見る日本の座標系対応表

「.prjが無い」「壊れている」ときの実務対応

.prjが欠落・破損しているShapefileを受け取った場合、座標の並びだけを見てもどの測地系・座標系かは断定できません。実務では次のような手がかりを組み合わせて推定することになります。

座標値の桁数・範囲（緯度経度の10進度なのか、平面直角座標系のメートル単位なのか）
発注元・作成元の慣習（測量業界では平面直角座標系、GIS/Web系ではWGS84緯度経度が多い）
既知の基準点・地物と座標を重ね合わせて、ズレの方向・量から測地系を絞り込む

最後の「重ね合わせて絞り込む」やり方は、測地系が書かれていない座標データの見分け方で扱った考え方と同じです。座標変換ツール側では「入力測地系はこれ」という前提を必ず明示的に選ぶ必要があるため、.prjが読めない・存在しないデータは、変換の前段階でこの見極め作業が欠かせません。

まとめ

Shapefileは.shp単体ではなく.shx・.dbf・（任意で）.prjの複数ファイルからなる形式
.prjはWKT（Well-Known Text）というテキスト形式で、測地系・楕円体・投影方式・原点・縮尺係数などを1行に記述している
同じ座標系定義はEPSGコードという数値IDでも参照でき、実務上はWKTを手書きする機会は少ないが、破損データの復旧や自作ツールでは直接読む必要が出てくる
.prjが欠落・破損している場合、座標の見た目や基準点との重ね合わせから測地系を推定する必要があり、変換作業の前段階として避けて通れない

出典

ESRI “ESRI Shapefile Technical Description”（1998年公開のホワイトペーパー） https://www.esri.com/
OGC “Well-known text representation of coordinate reference systems” 標準仕様 https://www.ogc.org/
EPSG Geodetic Parameter Dataset https://epsg.org/