GeoJSONを扱う実務では、地図に点を表示しただけなのに本来の場所から大きく外れる、線や面が海上に飛ぶ、対象地域とは別の国や地域に表示される、といった問題が起こることがあります。その代表的な原因の一つが、緯度と経度の順番を逆に扱っていることです。人が住所や位置情報を読むときは「緯度、経度」と表現する場面が多いため、データ作成時にもその順番で座標を入れてしまいがちです。しかし、通常のGeoJSONの座標配列では「経度、緯度」の順で記述します。この違いを理解しないまま変換や結合を行うと、見た目は正しい数値でも、地図上ではまったく違う位置に表示されることがあります。
この記事では、GeoJSONで緯度経度が逆になる主な原因と、実務で安全に修正するための4つの手順を解説します。単に座標を入れ替えるだけでなく、元データの座標系、値の範囲、ジオメトリの種類、bboxや高さ情報の扱い、変換後の検証まで確認することで、再発しにくい運用に整えることができます。
GeoJSONで緯度経度が逆になると何が起きるか
GeoJSONの緯度経度が逆になっていると、最も分かりやすい症状は地図上の表示位置が大きくずれることです。たとえば日本国内の地点データであれば、経度はおおむね120度台から150度台、緯度は20度台から40度台の範囲に入ることが多いです。この順番を逆にしてしまうと、本来は「経度139、緯度35」のように読むべき座標が、「経度35、緯度139」と解釈されます。緯度139度は通常の緯度範囲を超えるため、地図表示側で無効な座標として扱われたり、正常に描画されなかったりします。
一方で、地域によっては数値範囲だけではすぐに異常と判断できない場合もあります。経度と緯度の値がどちらも許容範囲に見える地域や、データ変換の途中で丸め処理が入っている場合は、明らかなエラーとして検出されず、別の場所に点が表示されることがあります。この場合、画面上では何らかの位置に表示されるため、担当者が「地図表示はできている」と誤認しやすくなります。特に大量の点群、境界線、設備台帳、道路施設、現地調査記録などを扱う場合、一部だけが逆転していても発見が遅れることがあります。
線データや面データでは、点データよりも影響が複雑になります。線の各頂点の座標順が逆になると、路線、配管、境界、調査ルートなどが本来の位置とはまったく異なる場所に描かれます。面データの場合は、区域や筆界、施工範囲、管理範囲が地図上で崩れたり、表示されなかったり、極端に大きな形状として扱われたりします。面の外周だけでなく穴を表す内側のリングにも座標配列が含まれるため、すべての階層を正しく処理しなければ修正漏れが起こります。
また、緯度経度の逆転は、単なる表示ミスにとどまりません。地物同士の重なり判定、近傍検索、距離計算、範囲検索、帳票出力、現地誘導など、座標を使う後続処理の結果にも影響します。たとえば、現場写真の撮影位置と設備台帳を結び付ける処理で座標が逆になっていると、正しい設備に写真を関連付けられません。施工管理や点検記録で位置情報を証跡として扱う場合は、位置の誤りがそのまま記録品質の低下につながります。
このような問題を避けるには、GeoJSONでは「座標が何を表しているか」だけでなく、「どの順番で並んでいるか」を明確に確認する必要があります。緯度経度の逆転は、慣れた担当者でも変換工程や受領データの確認不足で起こり得るため、初期チェックの仕組みに組み込んでおくことが重要です。
GeoJSONの座標順は緯度経度ではなく経度緯度
GeoJSONで最も重要な基本は、座標配列の順番が一般的な会話で使われる「緯度、経度」ではなく、「経度、緯度」であることです。GeoJSONのPointであれば、coordinatesには二つ以上の数値が配列として入ります。このとき先頭の値が経度、次の値が緯度です。高さや標高に相当する値を含める場合は、三つ目の値として扱う設計が一般的です。ただし、四つ目以降の値は仕様上の意味が曖昧になりやすいため、公開・交換用データでは安易に追加しないほうが安全です。
この順番は、地図や測量の実務でよく使う「X、Y」の考え方に近いものです。平面上の座標では横方向をX、縦方向をYとして扱います。経度は東西方向を表すためXに相当し、緯度は南北方向を表すためYに相当します。そのため、GeoJSONでは「X、Y」、つまり「経度、緯度」の順で座標を記述すると考えると理解しやすくなります。
混乱が起きやすいのは、位置情報を説明する文章や表計算データでは「緯度、経度」という順で列名が並んでいることが多いからです。現地調査アプリ、写真の位置情報、外部から受け取ったCSV、手入力の台帳などでは、列名が「lat」「lon」や「緯度」「経度」の順になっていることがあります。この並びをそのままGeoJSONのcoordinatesに入れてしまうと、GeoJSONとしては逆順の座標になってしまいます。
もう一つの混乱要因は、表示画面や入力フォームの見せ方です。人が確認しやすいように緯度を先に表示している画面でも、GeoJSONとして出力する座標配列では経度を先にする必要があります。画面表示の順番とGeoJSON出力の順番を同じにしてしまうと、意図せず逆転が発生します。つまり、ユーザー向け表示とデータ仕様を分けて考えることが必要です。
さらに、座標系に関する誤解も関係します。現在一般的に参照されるGeoJSON仕様では、座標参照系はWGS 84に基づく経度緯度の十進度が前提です。実務では平面直角座標、ローカル座標、工事用の任意座標、図面上の座標なども存在しますが、それらを外部共有用のGeoJSONとして扱う場合は、必要な座標系変換を行ったうえで、最終的なcoordinatesを経度、緯度の順に整える必要があります。関係者間の合意で独自の座標を扱う場合でも、仕様書やメタ情報で明確にしておかないと誤解を招きます。
したがって、GeoJSONの緯度経度問題を修正するときは、「GeoJSONでは経度、緯度」というルールだけを覚えるのではなく、元データがどの順番で、どの座標系で、どの単位で作られているかを合わせて確認することが重要です。この前提を押さえておくと、修正作業の判断ミスを大きく減らせます。
緯度経度が逆になる主な原因
GeoJSONで緯度経度が逆になる原因は一つではありません。最も多いのは、CSVや表計算データの列順をそのまま使ってしまうケースです。元データに「緯度」「経度」の順で列が並んでいると、変換処理を書く担当者は自然にその順番でcoordinatesを作ってしまいます。しかしGeoJSONでは経度、緯度の順であるため、この時点で逆転が発生します。列名が日本語ではなく略称で書かれている場合も注意が必要です。latは緯度、lonやlngは経度を表すことが多いため、latを先に入れるとGeoJSONでは逆になります。
次に多いのは、既存システムや外部データの仕様を十分に確認しないまま取り込むケースです。あるシステムでは画面表示上の順番が緯度、経度であっても、出力ファイルでは経度、緯度になっていることがあります。逆に、GeoJSONに似た形式であっても、独自仕様として緯度、経度の順で出力されているデータもあり得ます。ファイル拡張子や見た目だけで判断せず、実際の座標値と仕様を確認する必要があります。
手入力やコピー貼り付けも原因になります。住所検索や位置確認のために取得した座標を、担当者が台帳へ貼り付けるとき、表示されている順番のまま登録してしまうことがあります。登録画面の列名が曖昧だったり、入力例が不足していたりすると、担当者ごとに入力順がばらつきます。データ件数が少ないうちは目視で気付けても、運用が長くなると混在データが生まれやすくなります。
プログラム上の変数名と実際の中身が一致していないこともあります。たとえば、変数名ではlongitudeと書かれているのに、実際には緯度の列を代入している場合です。処理の途中で配列に変換し、さらに別の関数へ渡すような構成では、どの段階で順番が変わったのか追跡しづらくなります。特に、点だけを扱っていた処理を後から線や面に拡張した場合、座標配列の階層が増え、入れ替え処理の適用範囲が不明確になりがちです。
また、座標系の違いを緯度経度の逆転と誤解する場合もあります。地図上の位置がずれているからといって、必ずしも緯度経度が逆とは限りません。元データが平面直角座標であるにもかかわらず、緯度経度としてGeoJSONに入れている場合、数値の桁や範囲がまったく合わないことがあります。測地系が異なる、単位がメートルである、ローカルな基準点からの相対座標である、といった場合も位置ずれが起こります。このような問題に対して単純な緯度経度の入れ替えだけを行うと、かえって原因が見えにくくなります。
さらに、三次元座標を扱う場合には、高さや標高に相当する値を誤って緯度または経度として扱うミスもあります。GeoJSONのcoordinatesでは三つ目の値として高さを含めることがありますが、処理側が二次元前提で配列を扱っていると、三つ目の値を落としてしまったり、順番を崩したりする可能性があります。現地測量、点検、施工管理などで高さ情報も扱う場合は、二次元座標と三次元座標の処理を明確に分ける必要があります。
修正手順1：元データの座標列と範囲を確認する
緯度経度の逆転を修正する最初の手順は、元データの座標列と数値範囲を確認することです。いきなり全データを機械的に入れ替えるのではなく、まず代表的な数件を取り出し、どの列が緯度で、どの列が経度なのかを確認します。列名、入力仕様、サンプル地点、想定地域を照合しながら、データの意味を確定させます。
日本国内のデータであれば、緯度は多くの場合20度台から40度台、経度は120度台から150度台付近に収まります。もちろん離島や対象範囲による例外はありますが、この目安は初期チェックとして有効です。もし「緯度」と書かれた列に130台の値が入っており、「経度」と書かれた列に30台の値が入っているなら、列名が逆であるか、取り込み処理で入れ替わっている可能性があります。
ただし、数値範囲だけで判断しきれない場合もあります。対象地域が国外の場合、経度と緯度の値がどちらも自然に見えることがあります。また、元データが緯度経度ではなく平面座標である場合、値の桁が大きくなり、経度や緯度としては不自然になります。この場合は、緯度経度を入れ替える前に、そもそもGeoJSONへ入れるべき座標へ変換済みなのかを確認する必要があります。
確認時には、実在する基準点や現地で分かりやすい地点を使うと効果的です。たとえば、管理対象の入口、道路交差部、敷地角、設備の代表点など、地図上で目視確認しやすい地点を選びます。その地点の座標が元データ上でどの値になっているかを見れば、列順の誤りを発見しやすくなります。大量データの全件確認は難しくても、代表点の確認を行うだけで、変換処理全体の方向性を判断できます。
また、元データが複数の提供元から集まっている場合は、提供元ごとに座標列の意味を確認することが重要です。一つのファイル内では正しくても、別のファイルでは緯度経度の順番が違うことがあります。複数部署、協力会社、過去年度データ、現地調査データ、図面由来データを統合する場合、同じ列名でも中身の順番や座標系が異なる可能性があります。統合作業では、データ単位で確認済みかどうかを記録し、未確認データをそのまま混ぜない運用が必要です。
この段階で大切なのは、修正対象を明確にすることです。すでにGeoJSONとして正しい「経度、緯度」になっているデータまで入れ替えてしまうと、今度は正しいデータを壊してしまいます。問題があるのは元データなのか、変換スクリプトなのか、表示側の読み込み処理なのかを切り分けることが、正確な修正の出発点になります。
修正手順2：ジオメトリごとの座標階層を理解する
次の手順は、GeoJSONのジオメトリごとに座標配列の階層が異なることを理解することです。Pointであればcoordinatesは単純な座標配列です。しかし、LineStringやMultiPointでは複数の座標配列が並び、Polygonでは外周や内側のリングを表すためにさらに一段深い配列になります。MultiLineStringやMultiPolygonでは、さらに階層が深くなります。
点データだけを扱う場合、座標の入れ替えは比較的単純です。coordinatesの一つ目と二つ目を入れ替えればよいからです。しかし、線や面では、すべての頂点に対して同じ処理を行う必要があります。線の先頭点だけを修正しても、残りの頂点が逆のままでは形状は正しく表示されません。面の場合は、外周だけでなく内側のリングにも座標が含まれているため、処理漏れがあると形状が崩れます。
このため、修正処理を作るときは、GeoJSONの構造を見ながら階層に応じて座標をたどる必要があります。単純にファイル内のすべての配列の一番目と二番目を入れ替えるような処理は危険です。propertiesの中にも数値配列が入っている場合があり、それらは座標ではないかもしれません。属性値として保存された年月、番号、計測値、分類コードなどまで入れ替えてしまうと、位置情報以外のデータを破壊してしまいます。
安全な考え方は、geometryのcoordinatesだけを対象にすることです。FeatureCollectionであればfeaturesの中にFeatureが並び、それぞれのFeatureにgeometryがあります。geometryのtypeを見て、Point、LineString、Polygonなどの種類に応じてcoordinatesの階層を解釈します。このように対象範囲を明確にすることで、属性情報を誤って変更するリスクを下げられます。
また、GeometryCollectionのように、一つのgeometryの中に複数のgeometryが含まれる形式にも注意が必要です。GeometryCollectionではcoordinatesではなくgeometriesの配列に個別のgeometryが入ります。外部データや変換済みデータには含まれる可能性があるため、対応していないジオメトリが混じっている場合は、処理を止めるのか、警告を出すのか、未処理として記録するのかを決めておくと安全です。
bboxが含まれているGeoJSONにも注意が必要です。bboxは地物やコレクションの範囲を示す値で、座標と同じ軸順に従う必要があります。coordinatesだけを修正してbboxを古い値のまま残すと、表示範囲の自動調整や空間検索で不整合が出ることがあります。座標を修正した場合は、bboxを削除して再計算するか、修正後の座標に合わせて更新します。
座標に高さ情報が含まれる場合も、階層理解と同じくらい重要です。座標配列が「経度、緯度、高さ」の三要素で構成されている場合、緯度経度を入れ替えるとしても、高さは三つ目に残す必要があります。誤って高さを二つ目に移動したり、緯度を三つ目に押し出したりすると、三次元情報を扱う後続処理で問題になります。座標の入れ替えは一つ目と二つ目だけを対象にし、三つ目の値は原則として維持するという方針が分かりやすいです。
修正手順3：座標配列を安全に入れ替える
三つ目の手順は、確認した対象データに対して座標配列を安全に入れ替えることです。ここで重要なのは、すべてのデータに一律で入れ替えをかけるのではなく、「逆になっていることが確認できたデータ」だけを対象にすることです。正しいデータと逆転したデータが混在している場合は、まずデータを分けるか、判定条件を明確にしてから処理します。
Pointの場合は、coordinatesの先頭二つの値を入れ替えます。元の配列が「緯度、経度」になっているなら、GeoJSONとして正しい「経度、緯度」に並べ替えます。三つ目に高さがある場合は、そのまま後ろに残します。処理後の例としては、元の並びが「緯度、経度、高さ」であれば、修正後は「経度、緯度、高さ」になります。
LineStringでは、coordinates内に並ぶすべての頂点について同じ入れ替えを行います。線は複数の点をつないだものなので、どれか一つでも未修正の頂点が残ると線の形が不自然になります。道路、配管、ケーブル、境界線、移動軌跡などのデータでは、頂点数が多くなることがありますが、処理対象はすべての頂点です。修正後は、線が想定地域に沿って表示されるかを確認します。
Polygonでは、外周リングと内側リングのすべての頂点を対象にします。面データは、施工範囲、管理区域、土地の区画、調査範囲などで使われることが多く、位置がずれると影響が大きくなります。外周だけを入れ替えて内側リングを忘れると、穴の位置や形が崩れることがあります。面の構造を保ったまま、各座標配列の一つ目と二つ目だけを入れ替えることが必要です。
複数の地物を含むFeatureCollectionでは、各Featureを順に処理します。このとき、geometryがnullであるデータ、typeが想定外のデータ、coordinatesが欠けているデータが混じっている可能性も考慮します。実務データでは、未調査地点、削除予定データ、仮登録データなどが含まれていることがあります。こうしたデータを無理に処理すると、変換エラーや不完全なGeoJSONが発生します。処理できない地物はログや一覧に残し、後から個別確認できるようにするのが安全です。
手作業で修正する場合は、データ件数が少ないときに限るべきです。数件のサンプルや検証用データであれば、テキストとして開いて座標順を確認できます。しかし、本番データを手作業で大量に直すと、修正漏れや誤編集が起こりやすくなります。大量データでは、変換処理を作り、元ファイルを残したうえで修正版を別ファイルとして出力する方法が適しています。元データを上書きしないことで、問題が起きたときに差分確認ややり直しができます。
さらに、修正処理には変換前後の件数確認を含めるとよいです。Feature数が変わっていないか、geometryのtypeが変わっていないか、propertiesが維持されているかを確認します。bboxを持つデータでは、修正後の座標に合わせてbboxも再計算します。座標順を直すだけの作業で属性情報や地物数が変わっている場合、別の不具合が混入している可能性があります。座標修正は位置情報の変更であり、台帳情報や識別子を変える作業ではないため、不要な変更を避けることが大切です。
修正手順4：地図表示と数値チェックで検証する
四つ目の手順は、修正後のGeoJSONを地図表示と数値チェックの両方で検証することです。座標配列を入れ替えたからといって、必ず正しくなったとは限りません。元データの座標系が違っていた場合、列の意味を取り違えていた場合、一部だけ順番が違っていた場合など、修正後にも問題が残ることがあります。したがって、変換後の確認は必須です。
まず、地図上で代表点を確認します。対象地域の中心付近、範囲の端、特徴的な地点、現地で位置が分かる設備などを選び、修正後のGeoJSONが想定通りの場所に表示されるかを見ます。点データなら地点が正しい場所にあるか、線データなら道路や構造物の形に沿っているか、面データなら範囲が対象区域と重なるかを確認します。目視確認は単純ですが、緯度経度の逆転のような大きな誤りを発見するには非常に有効です。
次に、数値範囲を確認します。すべての座標について、経度が想定地域の範囲に入っているか、緯度が想定地域の範囲に入っているかを集計します。日本国内の特定エリアの業務であれば、都道府県や市区町村、工区、管理区域などに応じて、より狭い範囲を設定できます。想定範囲から外れた座標があれば、修正漏れ、元データ混在、入力ミス、座標系違いの可能性があります。
範囲チェックでは、最小値と最大値を見るだけでも多くの異常を検出できます。経度の最小値が30台、最大値が40台のようになっていれば、日本国内のデータとしては不自然です。緯度の最大値が130台になっている場合も明らかに異常です。さらに、平均値や中心点を確認すると、全体としてどこに集まっているかを把握できます。代表点は正しく見えても、一部の外れ値が残っていることがあるため、全件に対する数値チェックが重要です。
面データでは、形状の閉じ方や内外リングの扱いも確認します。緯度経度の入れ替え後に、面が閉じていない、極端に細長くなる、自己交差する、といった問題が出る場合があります。これは元データの頂点順や変換処理に別の問題がある可能性を示します。座標順の修正だけで解決しない場合は、元の図形作成工程や座標変換工程まで戻って確認します。
検証時には、修正前後のファイルを比較できるようにしておくと便利です。修正前はどこに表示され、修正後はどこに移動したのかを確認することで、入れ替え処理が意図通りだったか判断しやすくなります。ただし、修正前の位置が明らかに不正でも、修正後の位置が正しいとは限りません。必ず現地の基準点、既存図面、測量成果、管理台帳など、信頼できる情報と照合することが大切です。
最後に、検証結果を記録します。どのデータを、どの理由で、どの処理により修正したのかを残しておけば、後日同じ問題が発生したときに原因を追跡しやすくなります。特に、発注者提出資料、点検記録、施工管理データ、台帳更新データなどでは、修正履歴が重要になります。位置情報は一度誤った状態で共有されると後続作業に広がりやすいため、検証と記録をセットで行うことが望ましいです。
緯度経度の逆転を再発させない運用の考え方
GeoJSONの緯度経度逆転は、一度修正して終わりではなく、再発を防ぐ運用づくりが重要です。特に、現地調査、設計、施工、点検、台帳更新など、複数の工程で位置情報を扱う場合、どこか一つの工程で順番が曖昧になるだけで、再び逆転が発生します。担当者の注意だけに頼るのではなく、入力、変換、確認、共有の各段階にルールを組み込むことが大切です。
まず、列名を明確にします。「X」「Y」だけでは、経度緯度なのか平面座標なのか分からない場合があります。GeoJSON出力を前提にするなら、元データの列名に「経度」「緯度」や「longitude」「latitude」のように意味が分かる名前を付け、仕様書にも順番を明記します。さらに、GeoJSONのcoordinatesでは経度、緯度の順にすることを、変換仕様として書いておくと安全です。
次に、入力フォームや台帳の画面では、表示順と出力順を混同しない設計にします。人が入力しやすいように緯度、経度の順で表示すること自体は問題ありません。しかし、内部でGeoJSONを作るときには経度、緯度へ並べ替える必要があります。画面にGeoJSON出力時の順番を説明する、入力欄の例を示す、異常値を警告するなどの工夫で、入力ミスを減らせます。
変換処理には、自動チェックを組み込むことも有効です。GeoJSONを生成する前後で、経度と緯度の範囲を確認し、想定外の値があれば警告を出します。たとえば、対象地域が日本国内に限定される業務であれば、緯度や経度が大きく外れている座標を検出できます。すべての異常を自動判定することは難しくても、明らかな逆転や入力ミスは機械的に検出できます。
また、データ受領時のチェックリストを用意すると、外部データの取り込み時に役立ちます。受領したファイルについて、座標系、座標順、単位、対象範囲、サンプル地点、作成日、作成者、変換履歴を確認します。特に、同じ名称のファイル形式でも、提供元によって中身の仕様が異なることがあります。GeoJSONという名前が付いていても、必ずcoordinatesの順番や座標系の前提を確認することが大切です。
さらに、チーム内で用語を統一することも効果があります。「緯度経度」と言うと緯度が先だと感じる人が多いため、GeoJSONの文脈では「経度緯度」または「lon, lat」と表現するなど、意識的に順番が伝わる言い方を使うとよいです。会話、仕様書、画面表示、変換処理、ファイル名の説明で用語がばらばらだと、誤解が生まれやすくなります。
再発防止で最も避けたいのは、属人的な修正です。特定の担当者だけが「このデータは逆だから直しておく」と理解している状態では、担当変更やデータ追加のタイミングで問題が再発します。修正ルールを処理として残し、検証結果を記録し、次回以降も同じ手順で確認できるようにすることで、GeoJSONの品質を安定させることができます。
現地で取得する座標データとのつなげ方
GeoJSONの緯度経度逆転を防ぐうえで、現地で取得する座標データとのつなげ方も重要です。机上で作成した地図データや台帳データだけでなく、現場で取得した点、線、写真位置、出来形、設備位置などをGeoJSONとして扱う場面が増えています。このとき、現地取得データの座標順、座標系、高さ情報、取得精度を整理しておかないと、後工程で位置が合わない原因になります。
現地で取得した座標は、調査記録や施工管理の根拠として使われることがあります。たとえば、設備の位置を記録する、撮影地点を地図上に残す、施工範囲を面として管理する、点検結果を位置付きで共有する、といった用途です。これらをGeoJSON化する場合、現地で取得した値をそのまま使えるのか、変換が必要なのかを確認します。緯度経度で取得している場合でも、出力時にはGeoJSONの経度、緯度順に整える必要があります。
また、現場では高さ情報も重要になることがあります。地物の位置を二次元で見るだけでなく、標高、施工高さ、埋設深さ、構造物の上下関係などを合わせて扱う場合です。GeoJSONに高さ相当の値を含める場合は、三つ目の値として保持する設計が考えられます。ただし、高さの基準や単位が曖昧なままだと、別のデータと重ねたときに誤解が生じます。平面位置の緯度経度順だけでなく、高さ情報の意味も明確にしておくことが大切です。
現地取得データを台帳や地図システムへ渡すときは、出力形式の仕様を固定しておくと運用しやすくなります。たとえば、GeoJSONではcoordinatesを経度、緯度、高さの順にする、属性には地点名や管理番号、取得日時、作業区分を入れる、座標系や取得方法をメタ情報として残す、といったルールです。これにより、後から別の担当者がデータを見ても、どのように作られた位置情報なのか判断しやすくなります。
現場で位置を確認しながらデータ化する場合、画面上で正しく見えていることと、出力ファイルが正しいことの両方を確認する必要があります。画面表示用には内部で座標を変換しているが、出力時に別の順番になっているというケースもあり得ます。逆に、出力ファイルは正しいのに、読み込み側が緯度、経度として解釈してしまうこともあります。現地取得からGeoJSON出力、地図表示、共有までの流れを一連のものとして確認することが重要です。
このような現場とGeoJSONの接続を考える場合、高精度GNSS、測量機器、写真記録アプリ、点検システムなど、どの取得手段を使う場合でも、座標順と座標系の確認が土台になります。GeoJSONの経度、緯度順を正しく扱い、現地で取得した位置情報を台帳や地図に反映できれば、図面上の情報と現場の実測情報を結び付けやすくなります。位置情報の順番、座標系、精度、属性を整理しておくことが、現場データ活用の基本になります。
まとめ
GeoJSONの緯度経度が逆になる問題は、見た目には単純な入れ替えミスに見えますが、実務ではデータ品質や後続処理に大きく影響します。通常のGeoJSONのcoordinatesは経度、緯度の順であり、一般的な表現である緯度、経度とは順番が異なります。この違いを理解していないと、点が想定外の場所に表示され、線や面が崩れ、台帳や点検記録との連携にも支障が出ます。
修正では、まず元データの座標列と数値範囲を確認し、どのデータが逆転しているのかを見極めます。次に、Point、LineString、Polygonなどジオメトリごとの座標階層を理解し、geometryのcoordinatesだけを対象に安全に入れ替えます。bboxや高さ情報がある場合は、座標修正と整合するように扱います。その後、地図表示と数値チェックの両方で検証し、代表点や範囲、外れ値を確認します。修正前後の履歴を残すことで、後から原因を追跡しやすくなります。
再発を防ぐには、列名、入力画面、変換仕様、チェック処理、データ受領時の確認項目を整備することが重要です。特に、複数の部署や外部データを扱う場合は、座標順や座標系が混在しやすくなります。GeoJSONという形式だけで安心せず、coordinatesが経度、緯度の順になっているか、元データが正しい座標系であるかを確認する運用が必要です。
現場で取得した座標をGeoJSONとして活用する場合も、同じ考え方が欠かせません。緯度経度の順番を正しく扱い、必要に応じて高さ情報や属性情報も整理することで、地図表示、施工管理、点検記録、台帳更新へつなげやすくなります。現地の位置情報をより正確に活用したい場合は、取得機器やアプリの仕様に加えて、GeoJSON出力時の座標順、座標系、精度、属性の管理ルールを合わせて確認することが大切です。