GeoJSONのCRS指定で混乱しない座標管理の基本5つ

GeoJSONを扱うとき、形状データそのものは正しく見えているのに、地図上に重ねた瞬間に位置がずれる、別の図面と合わない、緯度経度の順序が逆になっている、といった混乱が起きることがあります。その原因の多くは、CRSの理解不足や、座標系の扱いをデータ作成時に曖昧にしたまま運用していることにあります。GeoJSONは扱いやすい形式ですが、現行の標準では座標参照系に明確な前提があり、任意のCRSを自由にファイル内で指定して使い分ける形式ではありません。この記事では、GeoJSONでCRS指定に迷わないために、実務で押さえておきたい基本を5つに整理して解説します。

目次

• GeoJSONでは座標の前提を最初に確認する

• CRS指定に頼りすぎずデータの座標系を明示管理する

• 経度緯度の順序と高さ情報を取り違えない

• 変換前後の精度と基準点を記録する

• 現場利用まで見据えてGeoJSONを検証する

• まとめ

GeoJSONでは座標の前提を最初に確認する

GeoJSONを扱う実務担当者が最初に確認すべきことは、そのデータがどの座標の前提で作成されているかです。GeoJSONという形式名だけを見ると、地図上で使える汎用的なデータだと考えがちですが、実際には中に入っている座標値の意味を理解しなければ、正しく重ね合わせることはできません。特に、現行の標準に沿った経度、緯度の地理座標なのか、関係者間の合意に基づいて投影座標やローカル座標を便宜的に入れたデータなのかを確認しないまま読み込むと、画面上では表示されても、現地や図面との位置関係が大きくずれることがあります。

現在の標準的なGeoJSONでは、座標参照系はWGS 84に基づく地理座標で、座標配列は経度、緯度の順で扱うことが前提です。これは、日常会話でよく使う「緯度、経度」という順序とは逆に感じられるため、慣れていない担当者ほど取り違えやすい点です。たとえば、日本国内の地点であれば、経度はおおむね百数十度、緯度はおおむね数十度の値になります。座標配列の最初に数十度、次に百数十度が入っている場合は、順序が逆になっている可能性があります。このような単純な確認だけでも、読み込み時の大きな位置ずれを早い段階で発見できます。

また、GeoJSONのファイル内にCRSらしき記述があるかどうかだけで判断するのは危険です。古い仕様や独自仕様に基づいて作られたデータでは、crsというメンバーが含まれていることがあります。しかし、現行のGeoJSON標準では、旧仕様にあったCRS指定は使わない前提に整理されています。そのため、ファイルにcrsの記述があるから安心、記述がないから不明、という単純な見方ではなく、作成元、変換手順、座標値の範囲、利用目的を合わせて確認する必要があります。

実務では、GeoJSONを受け取った時点で、まず作成元に確認すべき情報を整理しておくと安全です。元データが測量成果なのか、設計図面から変換したものなのか、既存の台帳から抽出したものなのかによって、座標の信頼性や前提は変わります。測量成果であれば測地系や基準点の情報が重要になりますし、設計図面由来であればローカル座標や任意座標の可能性もあります。台帳由来であれば、過去に複数回の変換や編集を経ている場合もあり、表示できることと正しい位置を示すことは別問題として考えなければなりません。

特に注意したいのは、標準的なGeoJSONとして外部共有するデータと、現場内だけで使う便宜的なJSON形式の座標データを混同しないことです。実務現場では、投影座標やローカル座標をGeoJSONの形に入れてやり取りしているケースがあります。この場合、ファイルとしてはGeoJSONに似ていても、一般的な地図背景にそのまま重ねる用途では互換性に問題が出ることがあります。座標値がメートル単位のように見える場合や、経度緯度としてはあり得ない大きな数値が入っている場合は、地理座標ではなく投影座標や現場独自座標の可能性があります。

座標の前提確認では、データの見た目よりも数値そのものを見ることが大切です。地図画面で何となく表示されたから正しいと判断するのではなく、代表点の座標値を読み取り、想定する地域の範囲に入っているかを確認します。さらに、既知の地点、道路交差点、境界点、構造物の角など、現地で位置を確認しやすい点と比較すると、座標の取り違えを発見しやすくなります。GeoJSONのCRS指定で混乱しないためには、最初の段階で「この座標は何を基準にした数値なのか」を明確にする姿勢が欠かせません。

CRS指定に頼りすぎずデータの座標系を明示管理する

CRSとは、座標参照系を意味する考え方で、ある座標値がどの地球の形、どの基準、どの投影方法に基づいているかを説明するためのものです。地理情報の実務では、CRSが違えば同じ数値でも別の場所を指すことがあり、逆に同じ場所でもCRSが違えば座標値が変わることがあります。そのため、GeoJSONを扱うときにもCRSを意識することは重要です。ただし、GeoJSONファイルの中にCRS名を書いておけば十分だと考えると、かえって運用が不安定になります。

現行のGeoJSON標準では、座標参照系はWGS 84の経度、緯度であることが前提です。したがって、外部共有や汎用的な地図表示を目的にするGeoJSONでは、元データが平面直角座標系、Webメルカトル、CADのローカル座標、現場独自座標などで作られている場合、必要に応じて標準的な経度、緯度へ変換してから出力する考え方が安全です。関係者間で別の座標系を使う特別な取り決めがある場合でも、そのデータを一般的なGeoJSONとして扱えると誤解されないよう、用途と前提を明記しておく必要があります。

GeoJSONに限らず、地理空間データでは「ファイルを開けば分かる」という状態を期待しすぎないことが大切です。ファイル名、格納フォルダ、付随する説明文、データ管理台帳、変換履歴などを組み合わせて、どの座標系で作成され、どの用途に使えるデータなのかを残しておく必要があります。特に、複数の部署や協力会社が関わる業務では、同じGeoJSONという言葉を使っていても、片方は地図表示用の標準的なデータ、もう片方は設計図面から出力したローカル座標データを想定していることがあります。この認識違いが、後工程での大きな手戻りにつながります。

明示管理の基本は、データごとに最低限の属性情報を残すことです。作成日、作成者、元データの種類、元データの座標系、変換後の座標系、変換方法、検証に使った基準点、想定用途を記録しておくと、後から問題が起きたときに原因を追いやすくなります。たとえば、現場で位置が合わないと報告された場合でも、元データがローカル座標だったのか、変換時に経度緯度の順序を入れ替えたのか、高さを削除したのか、といった確認ができます。記録がなければ、見た目のずれだけを頼りに推測するしかなくなり、再変換や再測定が必要になることもあります。

CRSに関する混乱は、データを受け渡す場面で特に起こりやすくなります。作成者は自分の環境で正しく表示されることを確認していても、受け手側の環境では別の前提で読み込まれる場合があります。GeoJSONを共有するときは、単にファイルを渡すだけでなく、座標の前提を短く添える習慣を持つことが重要です。標準的なGeoJSONとして渡すなら、WGS 84に基づく経度、緯度の順であることを明記します。高さを含む場合は、座標配列の三つ目の値が何を意味するか、または高さを属性として別管理しているかを説明します。

また、CRS管理では、標準化と例外管理を分けて考える必要があります。すべてのデータを同じ座標系で管理できれば理想的ですが、実務では過去資料、設計図、測量成果、台帳、現場計測データが混在します。そのため、基本方針としてはGeoJSONの外部共有形式を統一しつつ、例外的に投影座標やローカル座標をGeoJSON風の形式で扱う場合は、ファイル名や説明で明確に区別します。例外データを通常データと同じ場所に置いたり、同じ命名規則で扱ったりすると、後から別の担当者が誤って地図表示用として利用する可能性があります。

座標系を明示管理することは、単なる整理整頓ではなく、品質管理の一部です。GeoJSONは軽量で扱いやすいため、試作や共有に使われやすい一方、簡単に複製、編集、変換できるため、どのデータが正であるか分からなくなりやすい形式でもあります。CRS指定の有無だけを見て判断するのではなく、データ管理の仕組みとして座標系を記録し、利用者が迷わない状態にしておくことが、実務での安定した運用につながります。

経度緯度の順序と高さ情報を取り違えない

GeoJSONで最も頻繁に起こる座標の混乱の一つが、経度と緯度の順序の取り違えです。一般的な会話や検索では「緯度経度」という表現がよく使われますが、GeoJSONの座標配列では経度、緯度の順で記述することが基本です。この違いを理解していないと、点、線、面の形状が本来とは別の場所に表示されたり、データ変換後に大きく位置がずれたりします。特に、表計算データや現場メモからGeoJSONを作成する場合は、元データの列名が「緯度」「経度」の順になっていることが多く、そのまま配列化すると誤ったGeoJSONになる可能性があります。

座標順序の確認では、まず数値の範囲を見ることが有効です。日本国内を対象にする場合、経度と緯度の値には大まかな傾向があります。もちろん地域によって差はありますが、経度と緯度を入れ替えた場合、対象地域から大きく外れることがほとんどです。そのため、代表的な座標を数点取り出し、想定する地域に含まれる値になっているかを確認します。点データであれば一つひとつの確認がしやすいですが、線や面のデータでは頂点数が多いため、外接範囲や中心点を確認すると効率的です。

線や面のGeoJSONでは、座標順序の誤りが形状の崩れとして現れることもあります。たとえば、道路中心線、敷地境界、配管ルート、構造物外形などを扱う場合、座標の順序が逆になると、地図上の位置だけでなく、形状の向きや長さの解釈にも影響します。見た目が何となく線や面に見える場合でも、実際にはまったく別の場所に表示されていることがあるため、背景地図や既知の基準点と重ねて確認することが必要です。特に、狭い範囲の現場データでは、少しのずれでも施工や点検の判断に影響するため、表示できたことだけで安心しないようにします。

高さ情報の扱いも注意が必要です。現行のGeoJSONでは、座標配列の三つ目の値は高さまたは標高に相当する値として扱えますが、標準に沿って解釈する場合はWGS 84の参照楕円体を基準にしたメートル単位の高さです。一般的な標高、ジオイド高、設計上の高さ、現場独自の基準高をそのまま三つ目の値として入れると、受け手側が標準的な高さとして解釈してしまう可能性があります。高さの意味が標準と異なる場合は、座標配列に入れるのではなく属性として持たせる、またはメタデータで明確に説明することが安全です。

高さ情報を含める場合は、二次元データとして使うのか、三次元データとして使うのかを最初に決めておくことが重要です。単に地図上に点や線を表示するだけであれば、高さを使わない運用でも問題ない場合があります。一方で、現場で高さを確認したり、三次元モデルや点群と重ねたりする場合は、高さ情報の基準を記録し、変換時に失われないように管理する必要があります。ファイル変換や簡易編集の過程で三つ目の値が削除されることもあるため、高さを重要情報として扱う場合は、変換後のGeoJSONを必ず確認します。

座標順序や高さ情報の取り違えを防ぐには、データ作成手順を標準化することが効果的です。たとえば、元データの列名を明確にし、GeoJSON出力時には経度、緯度、高さの順に変換することを手順書に書いておきます。人が手作業で列を入れ替える運用はミスが起きやすいため、可能な限り一定の処理で変換する方が安全です。ただし、自動変換であっても、入力データの列順や単位が変われば誤った結果になるため、変換後の検証は省略できません。

現場で使うGeoJSONでは、座標の小数点以下の扱いにも注意が必要です。表示上の見やすさを優先して桁数を丸めすぎると、位置精度が落ちることがあります。逆に、過剰な桁数を残していても、元データの精度がそれほど高くなければ意味がありません。重要なのは、必要な精度に対して十分な桁数を保ちつつ、元データの精度を超えるような過信をしないことです。座標値の桁数、測定方法、変換方法、利用目的を合わせて判断することで、GeoJSONをより安全に活用できます。

変換前後の精度と基準点を記録する

GeoJSONを実務で使う際には、元データをそのまま利用するだけでなく、別の座標系から変換して使う場面が多くあります。設計図面の座標を地図表示用に変換する、測量成果を共有用に変換する、既存台帳の座標を現場確認用に整えるなど、変換を伴う作業では、どのような処理を行ったかを記録しておくことが非常に重要です。CRS指定に関する混乱は、単に座標系の名前が分からないことだけでなく、過去にどのような変換が行われたか分からないことからも発生します。

変換前後の管理では、まず元データを保管することが基本です。変換後のGeoJSONだけが残っている状態では、位置ずれが見つかったときに原因を調べるのが難しくなります。元データの座標系、単位、測地系、作成時期、作成方法が分かる資料を残しておけば、変換処理の妥当性を後から確認できます。特に、複数回の変換を経たデータでは、最初の段階でどの座標系だったのかが分からなくなることがあります。中間ファイルをすべて残す必要はないとしても、少なくとも変換の起点となるデータと最終的なGeoJSONの関係は追跡できるようにしておくべきです。

基準点の記録も欠かせません。座標変換が正しく行われたかを確認するには、既知の位置を持つ点を使って検証する必要があります。現場内の基準点、公共座標が分かる点、構造物の角、道路や境界の明確な点など、変換前後で比較しやすい点を選びます。単に画面上で重なって見えるかどうかではなく、数値としてどの程度の差があるかを確認すると、精度管理がしやすくなります。検証に使った点を記録しておけば、後から別の担当者が同じ条件で再確認できます。

変換処理では、平面位置だけでなく高さの扱いも記録する必要があります。二次元の地図表示では高さを無視しても問題ない場合がありますが、現場で三次元的に確認する場合、高さをどのように変換したかが重要になります。たとえば、元データに高さが含まれていたがGeoJSON出力時に削除した、座標配列の三つ目として楕円体高を残した、設計高さを属性として残した、別の高さ基準に合わせた、といった処理内容を明記しておきます。高さ情報が座標配列に入っているのか、属性として管理されているのかも、利用者が混乱しやすい点です。

精度については、GeoJSONの形式そのものが精度を保証するわけではないことを理解しておく必要があります。GeoJSONは座標や属性を表現するためのデータ形式であり、その座標がどれだけ正確かは、元データの測定方法や変換方法に依存します。高精度な測量データから作成されたGeoJSONもあれば、概略図や手入力の座標から作成されたGeoJSONもあります。どちらも同じ形式で保存できるため、ファイルを見ただけでは精度の違いが分かりにくくなります。そのため、用途に応じた精度情報を別途管理することが重要です。

変換後のGeoJSONを確認する際には、対象範囲全体でずれ方を確認します。一点だけが合っていても、別の場所で回転や縮尺のずれが出ている場合があります。特に、ローカル座標や図面座標を地理座標へ合わせる場合、平行移動だけでなく、回転、縮尺、基準点の選び方が影響します。狭い範囲では目立たないずれも、対象範囲が広がると大きな差になることがあります。複数の基準点を使って、現場全体で整合しているかを確認することが望ましいです。

変換履歴を残すときは、専門的な文章を長く書く必要はありません。重要なのは、後から見た人が同じ処理を再現できる程度に情報を残すことです。元データの名称、変換日、変換者、変換前の座標系、変換後の座標系、使用した基準点、確認結果、注意事項を簡潔にまとめておくだけでも、実務上の価値は大きくなります。反対に、変換済みという言葉だけでは、どのように変換したのか分からず、品質確認に使えません。

GeoJSONは軽量で共有しやすいため、現場や関係者に素早く渡せる利点があります。しかし、共有しやすいからこそ、変換前後の情報が切り離されやすくなります。ファイルだけが一人歩きすると、後から座標の意味が分からなくなり、同じ場所のデータなのに異なる結果として扱われることがあります。CRS指定で混乱しないためには、変換処理を一度きりの作業として終わらせるのではなく、記録と検証を含めた座標管理の工程として扱うことが大切です。

現場利用まで見据えてGeoJSONを検証する

GeoJSONの座標管理は、机上でファイルを正しく作るだけでは完結しません。実務で本当に重要なのは、そのGeoJSONをどの場面で使い、現場でどの程度信頼できる情報として扱うかです。地図画面で見たときには問題がないように見えても、現地で確認すると道路端、境界、構造物、埋設物の位置と合わないことがあります。これは、CRSの取り違えだけでなく、元データの精度、変換方法、地図背景のずれ、測位環境、現場の基準点の取り方など、複数の要因が重なって起こります。

現場利用を前提にする場合、GeoJSONの検証は段階的に行うことが有効です。まず、データ作成直後に座標値の範囲や形式を確認します。次に、既存の地図や図面と重ね、対象物の位置関係が大きく外れていないかを確認します。さらに、現場で既知点と照合し、必要な精度に収まっているかを確認します。このように、数値確認、画面確認、現地確認を分けて考えることで、どの段階で問題が発生しているのかを特定しやすくなります。

GeoJSONの検証では、属性情報も重要です。点、線、面の形状が正しい位置にあっても、属性名や対象物の名称、管理番号、種別、日付などが誤っていれば、現場では使いにくいデータになります。座標系の確認に集中しすぎると、属性の整合性が後回しになることがありますが、実務では座標と属性がそろって初めて意味のあるデータになります。特に、維持管理や点検で使うGeoJSONでは、現地で対象物を識別できる情報が入っているかを確認する必要があります。

面データを扱う場合は、ポリゴンの閉じ方や穴の扱いにも注意が必要です。敷地、区域、構造物範囲、施工範囲などをGeoJSONで表す場合、外周線が正しく閉じていない、穴として扱うべき内周線が区別されていない、隣接する面との境界が重複している、わずかな隙間がある、といった問題が起こることがあります。これらはCRS指定とは別の問題に見えますが、座標変換や編集の過程で発生することもあります。現場で面積や範囲確認に使う場合は、見た目だけでなく、図形として正しいかを検証します。

線データでは、ルートの連続性や分岐点の整合性を確認します。道路、配管、ケーブル、排水経路、点検ルートなどのデータでは、線が途中で切れていたり、同じ場所に見える点がわずかにずれて接続していなかったりすることがあります。地図表示では気づきにくい小さな不整合も、経路検索、延長集計、現地ナビゲーションの場面では問題になります。GeoJSONを単なる表示用として使うのか、解析や誘導にも使うのかによって、必要な検証の深さは変わります。

現場確認では、測位精度との関係も考える必要があります。GeoJSONの座標が高精度でも、現地で使う端末や測位方法の精度が低ければ、表示位置と実際の位置に差が出ます。逆に、現地測位が高精度でも、GeoJSONの元データが概略であれば、正確な誘導には使えません。座標管理では、データ精度と現地測位精度の両方を見て、用途に合っているかを判断します。概略的な場所を確認する用途と、施工位置や境界付近を確認する用途では、必要な精度が大きく異なります。

GeoJSONを現場で使う前には、利用者が誤解しない表現に整えることも大切です。ファイル名やレイヤー名に、用途や座標の前提が分かる言葉を入れると、誤利用を防ぎやすくなります。確認用、共有用、変換済み、概略、三次元確認用など、データの性質が分かる表現を使うと判断しやすくなります。ただし、曖昧な言葉だけでは不十分な場合もあります。特に、正式な施工判断や管理台帳に使うデータでは、どの版が正であるか、誰が承認したか、いつ更新されたかを明確にしておく必要があります。

GeoJSONの検証は、一度行えば終わりではありません。現場で修正が入ったり、設計変更があったり、測量成果が更新されたりすれば、再度確認が必要になります。古いGeoJSONが残ったまま新しいデータと混在すると、どちらを使うべきか分からなくなります。更新管理の仕組みを作り、不要な旧版を誤って使わないようにすることが、座標管理の安定につながります。CRS指定の理解に加えて、現場でどのデータが使われるのかまで見据えることで、GeoJSONはより実務に強い形式になります。

まとめ

GeoJSONのCRS指定で混乱しないためには、ファイルの中に何が書かれているかだけでなく、座標値がどの前提で作成され、どの用途で使われるのかを一貫して管理することが重要です。GeoJSONは便利で扱いやすい形式ですが、現行の標準ではWGS 84に基づく経度、緯度の座標を前提としており、旧仕様のcrsメンバーや独自の投影座標を前提にすると、受け手の環境で誤解される可能性があります。座標系、経度緯度の順序、高さ情報、変換履歴、精度、現場での検証を曖昧にしたまま使うと、表示のずれや判断ミスにつながります。

まず、GeoJSONを受け取ったら、座標が標準的な経度、緯度の地理座標なのか、投影座標やローカル座標を便宜的に入れたデータなのかを確認します。次に、CRS指定の有無だけに頼らず、作成元、変換方法、利用目的を明示して管理します。さらに、経度緯度の順序や高さの意味を取り違えないようにし、変換前後の精度と基準点を記録します。最後に、画面上の表示だけでなく、現場で既知点や対象物と照合し、実際の利用に耐えるかを確認します。この流れを押さえることで、GeoJSONを安心して共有し、後工程でも使いやすいデータとして活用できます。

座標管理は、専門担当者だけの作業ではありません。GeoJSONを作る人、受け取る人、現場で見る人、台帳に反映する人が、それぞれ同じ前提を共有して初めて、データは正しく機能します。特に、現地確認や出来形管理、維持管理、設備位置の確認など、現場の判断に座標を使う業務では、データの見やすさだけでなく、位置の信頼性が重要になります。GeoJSONを単なる地図表示用ファイルとして扱うのではなく、現場と設計、管理情報をつなぐ座標データとして管理することが、実務の品質向上につながります。

現場でGeoJSONや座標データをより直感的に扱いたい場合は、机上で作成したデータを現地でどう確認し、どのように更新し、どの版を正として共有するかまで考えることが重要です。図面、点群、現地測位、台帳情報を組み合わせる場合でも、最初の土台になるのは座標の前提を明確にすることです。標準に沿ったデータと、現場内だけで使う例外的なデータを分けて管理することで、GeoJSONは地図表示だけでなく、設計、施工、維持管理をつなぐ実務的な情報基盤として活用しやすくなります。