GeoJSONを扱っていると、地物が想定外の場所に表示されたり、「座標が範囲外です」といったエラーが出たりすることがあります。形式としてはJSONとして成立していても、座標値の入力ルールが崩れていると、地図上では正しく扱えません。特に、経度と緯度の順番、度分秒と十進度の混在、測量座標や平面直角座標の取り違え、桁や符号の入力ミス、配列構造の崩れは、実務で見落とされやすいポイントです。
この記事では、geojsonで検索する実務担当者に向けて、GeoJSONの座標が範囲外になる時に見直したい入力ミスを5つに整理します。単なる構文確認だけでなく、現場で取得した座標や表計算データ、台帳データをGeoJSON化する際にどこを確認すべきかまで、公開前・納品前のチェックに使える形で解説します。
GeoJSONの座標範囲外エラーは形式ではなく意味の確認が重要
GeoJSONの座標が範囲外になる問題は、JSONの書き方だけを見ていても解決できないことが多いです。カンマや括弧の数が合っていて、FeatureやGeometryの構造が正しく見えていても、coordinatesに入っている数値の意味が間違っていれば、地図上では正しく表示されません。つまり、構文として正しいことと、地理座標として正しいことは別の確認項目です。
GeoJSONで一般的に使われる位置の座標は、経度、緯度の順で記録します。経度は地球の東西方向を示す値で、通常はマイナス180度からプラス180度の範囲に収まります。緯度は南北方向を示す値で、通常はマイナス90度からプラス90度の範囲に収まります。この前提から外れた値が入っていると、表示側や変換側で範囲外として扱われたり、地物が意図しない大陸や海上に飛んだりします。
実務では、座標値が手入力される場面だけでなく、表計算ファイルから変換する場面、測量成果を別形式から変換する場面、現場端末で取得した位置情報を取り込む場面などがあります。そのため、入力ミスの原因は一つではありません。列名が「緯度」「経度」となっているのに変換処理では逆順に読んでいる場合もあれば、平面直角座標のX、YをそのままGeoJSONの経度、緯度として入れてしまう場合もあります。
また、座標が範囲外になる問題は、エラーとして明確に表示される場合と、エラーは出ないが表示結果がおかしい場合に分かれます。前者はまだ気づきやすいですが、後者は厄介です。たとえば、日本国内の施設を示すはずの点が海外に表示されていても、画面を広域表示しなければ発見できないことがあります。線や面の場合は、ひとつの頂点だけが飛んでしまい、図形が極端に長い線として描かれることもあります。
そのため、GeoJSONを扱う時は、ファイルが読めるかどうかだけでなく、座標値の範囲、座標の順番、座標系、配列の構造、取得元データとの対応をまとめて確認する必要があります。特に、現場管理、点検、台帳整備、施工範囲の整理などで使うGeoJSONでは、少しの座標ミスが位置の誤認につながります。次の章から、範囲外の原因になりやすい入力ミスを具体的に見ていきます。
入力ミス1 経度と緯度の順番を逆にしている
GeoJSONで最も多い入力ミスの一つが、経度と緯度の順番を逆にしてしまうことです。多くの実務資料や表計算ファイルでは「緯度、経度」の順で列が並んでいることがあります。人が読む資料としては自然に見えますが、GeoJSONのcoordinatesでは基本的に「経度、緯度」の順で記録します。この違いを見落とすと、座標が範囲外になったり、まったく別の場所に表示されたりします。
たとえば、日本国内の地点であれば、緯度はおおむね20度台から40度台、経度はおおむね120度台から150度台に入ることが多いです。ところが、緯度と経度を逆にしてしまうと、緯度の位置に120以上の値が入ることになります。緯度は通常マイナス90度からプラス90度の範囲に収まるため、緯度として120や140といった値が入れば、範囲外として扱われます。
このミスは、CSVや表計算ファイルからGeoJSONを生成する時に特に起こりやすいです。列名が「lat」「lon」となっている場合、開発者や担当者が無意識にその順番のまま配列へ入れてしまうことがあります。また、日本語の列名で「緯度」「経度」と並んでいるデータを、何も考えずに左から順番にcoordinatesへ変換すると、GeoJSONとしては逆順になります。
確認の基本は、coordinatesの最初の値が経度になっているかを見ることです。日本国内のデータであれば、最初の値が120から150程度、二つ目の値が20から45程度になっているかを確認すると、初期チェックとして有効です。もちろん対象地域によって値の範囲は変わりますが、少なくとも二つ目の値が90を超えている場合は、緯度として成立しないため、順番の取り違えを疑うべきです。
線や面のデータでは、すべての頂点で同じ順番になっているかも重要です。先頭の数点だけ正しくても、途中で列の読み込み処理が変わったり、手作業で追加した頂点だけ緯度経度順になったりすると、図形が途中で大きく飛びます。LineStringでは線が不自然に長く伸び、Polygonでは面が大きくねじれた形になることがあります。
修正する時は、単に全体を機械的に入れ替える前に、元データの列定義を確認することが大切です。データの一部だけが逆順になっている可能性もあるためです。取得元の端末、手入力した表、外部から受け取った台帳、変換スクリプトのどこで順番が決まったのかを追うと、再発防止につながります。GeoJSONでは経度、緯度という順番を標準の確認項目として扱い、変換前の列名と変換後の配列順を必ず照合する運用にすると安全です。
入力ミス2 度分秒や測地系の前提を確認していない
座標が範囲外になる原因として、度分秒の表記を十進度に変換せず、そのまま入力してしまうケースがあります。GeoJSONのcoordinatesに入れる経度や緯度は、基本的には十進度の数値として扱います。たとえば「35度30分」のような表記は、人が読むには分かりやすいですが、そのまま数値配列に入れるものではありません。度、分、秒を一つの数値へ適切に変換しないと、想定と異なる場所になります。
度分秒の扱いで多いのは、35度30分を35.30のように入力してしまうミスです。一見すると小数表記に見えますが、十進度としての35.30度は35度18分に相当するため、元の35度30分とは一致しません。秒まで含む値では、ずれがさらに分かりにくくなります。範囲外エラーに直結しない場合でも、位置ずれの原因になるため、実務上は注意が必要です。
また、古い資料や過去の台帳から座標を取り込む場合、測地系の前提が現在使っているデータと異なることがあります。GeoJSONでは、一般的なWeb地図やGISで扱いやすい経度緯度として整えることが多く、異なる測地系の経緯度をそのまま扱うと表示位置にずれが出ます。多くの場合、緯度や経度の範囲そのものは極端に外れないため、範囲外エラーとしては見つからないこともあります。しかし、現地の構造物、道路、境界、点検対象物と重ねた時に位置が合わない原因になります。
この入力ミスを防ぐには、元データの座標表記が十進度なのか、度分秒なのかを最初に確認することが重要です。列名に「緯度」「経度」と書かれていても、中身が十進度とは限りません。値に度、分、秒を示す記号が含まれている場合や、桁の区切りが不自然な場合は、そのままGeoJSON化しないようにします。文字列として管理されている座標を数値化する時も、単純に記号を削除するだけでは正しい十進度になりません。
度分秒を十進度に直す場合は、度に分を60で割った値、秒を3600で割った値を加える考え方になります。南緯や西経を扱う場合は符号にも注意が必要です。国内業務では北緯と東経が中心になることが多いですが、海外データや広域データを扱う場合は、符号の扱いを誤ると半球が反対になります。
測地系については、元資料に記載された座標系、測地系、変換履歴を確認します。現場データ、既存台帳、設計データ、公開データを混在させる場合は、見た目の座標値が似ていても前提が異なることがあります。GeoJSONとして出力する前に、どの座標系へそろえるのかを決め、変換処理を記録しておくことが大切です。座標の値だけを見て判断せず、座標の由来まで確認することが、範囲外や位置ずれを防ぐ基本になります。
入力ミス3 平面直角座標やローカル座標を経緯度として扱っている
GeoJSONの座標が範囲外になる典型的な原因に、平面直角座標や現場独自のローカル座標を、経度と緯度のつもりで入れてしまうミスがあります。測量や建設分野では、メートル単位のX、Y座標で位置を管理することがよくあります。これらの座標は、地図上の経度、緯度とは値の意味が異なります。そのままcoordinatesに入れると、数千、数万、数十万といった値になり、経度や緯度の範囲を大きく超えてしまいます。
たとえば、現場で使っている座標値がX座標、Y座標として「-30000」「45000」のような値で管理されている場合、それは角度ではなく距離に基づく平面座標である可能性があります。GeoJSONの経緯度に入る値は度単位なので、経度が45000度、緯度が-30000度のような扱いになると、地球上の位置として成立しません。表示側が厳密であれば範囲外エラーになり、そうでなくても画面外や不明な位置に飛びます。
この問題は、測量成果、CAD由来の座標、施工管理用の図面座標、施設内のローカル座標をGeoJSON化する時に発生しやすいです。元データが地理座標なのか、平面座標なのかを確認せず、列名だけで「Xは経度、Yは緯度」と判断してしまうと誤変換になります。実務では「X」「Y」という表記がデータごとに異なる意味で使われるため、列名だけに頼るのは危険です。
平面直角座標をGeoJSONで扱いたい場合は、経緯度へ変換する処理が必要です。どの系番号なのか、原点はどこか、単位はメートルなのか、座標軸の向きはどう定義されているのかを確認し、適切な変換を行います。現場ローカル座標の場合は、公共座標や地理座標との対応点が必要になることもあります。対応点がないままGeoJSON化すると、地図上の正しい位置に置くことはできません。
また、CADや図面由来のデータでは、座標がミリメートル単位になっていることもあります。見た目にはX、Yの数値が整っていても、単位がメートルではなくミリメートルであれば、さらに大きな値になります。こうしたデータをそのまま経緯度として扱うと、座標範囲外になるだけでなく、変換後の図形サイズや位置関係も破綻します。
確認の際は、coordinatesに入っている値の桁を見ます。経度や緯度として使う値が数百、数千、数万になっている場合は、経緯度ではない可能性が高いです。日本国内の経度はおおむね3桁、緯度は2桁の十進度になることが多いため、桁が大きすぎるデータは平面座標やローカル座標の可能性を疑います。ただし、単純に桁を減らしたり小数点を移動したりしてはいけません。座標系を確認し、正しい変換手順を踏むことが必要です。
入力ミス4 符号、小数点、桁数の入力を誤っている
GeoJSONの座標が範囲外になる時は、符号、小数点、桁数の入力ミスもよく確認すべきです。座標値は小数を含むため、見た目では小さなミスに見えても、地図上では非常に大きな位置ずれになります。特に、マイナス記号の抜け、余分なマイナス記号、小数点の位置違い、桁区切りの混入、数字の貼り付けミスは、実務で起こりやすい問題です。
経度は東経をプラス、西経をマイナスとして扱うことが一般的です。緯度は北緯をプラス、南緯をマイナスとして扱います。国内の多くのデータでは経度も緯度もプラスになることが多いため、符号を意識しない運用になりがちです。しかし、海外データや南半球、西半球のデータを扱う場合、マイナス記号の有無は位置を大きく左右します。符号を落としてしまうと、地物が反対側の半球へ移動します。
小数点の位置ミスも深刻です。たとえば、139.7のつもりで1397と入力すれば、経度の範囲を大きく超えます。35.6のつもりで356と入力すれば、緯度として成立しません。表計算ファイルから変換する際に、小数点が削除されたり、文字列処理で桁が詰められたりすると、このような値になります。特に、外部データをコピーして貼り付ける時や、全角文字、区切り記号、余分な空白が混じっている時に注意が必要です。
桁区切りのカンマも確認ポイントです。JSONではカンマが配列の区切りとして使われるため、数値の中に桁区切りのカンマが入ると構文そのものが崩れます。たとえば、数値として「1,397」のような表記を含むデータを処理すると、意図しない複数の値として読まれる可能性があります。GeoJSONへ変換する前に、座標列には数値として不要な記号が入っていないかを確認します。
また、緯度や経度の末尾に不要な文字が残っている場合もあります。度を示す文字、単位、注記、全角スペース、改行などが含まれていると、変換処理によっては数値として正しく読めなかったり、途中までしか読まれなかったりします。エラーが出る場合は気づけますが、処理によっては一部だけを数値として採用してしまうことがあります。その結果、範囲内に見えても本来の値とは違う座標になる可能性があります。
符号、小数点、桁数の確認では、値の範囲チェックと同時に、対象地域として自然な値かどうかを見ることが重要です。日本国内のデータで、経度が13.9や1397になっている場合、緯度が356や3.56になっている場合は、桁や小数点の位置を疑います。範囲内に収まっていても、対象地域から大きく外れていれば入力ミスです。単に世界全体の経度緯度範囲だけで判定するのではなく、業務対象エリアの想定範囲を決めてチェックすると、見落としを減らせます。
入力ミス5 Geometryごとの座標配列の深さを間違えている
GeoJSONでは、点、線、面などのGeometryの種類によって、coordinatesの配列構造が異なります。座標値そのものが範囲内でも、配列の深さを間違えると、読み込みエラーになったり、意図した形状として扱われなかったりします。範囲外エラーと同時に出ることもあれば、表示結果が崩れる形で現れることもあります。
Pointは一つの座標を表すため、coordinatesには経度と緯度の組を入れます。LineStringは複数の座標を順に並べた線なので、座標の組を配列として並べます。Polygonは外周線や穴を表すため、さらに一段深い配列になります。MultiPoint、MultiLineString、MultiPolygonのように複数の地物をまとめる形式では、さらに配列が深くなります。この違いを理解せずに、すべて同じ形でcoordinatesを作ると、正しく読めません。
たとえば、Pointであるはずのデータに、LineStringのような座標列を入れてしまうと、点として扱うには値が多すぎます。反対に、LineStringに一つの座標だけを入れてしまうと、線として成立しません。Polygonでは、外周を閉じるために始点と終点の座標を一致させる必要があります。これを忘れると、面として不正なデータになることがあります。
配列の深さのミスは、表形式のデータから自動生成する時に起こりやすいです。点データだけを扱っていた処理を流用して線や面を作る場合、coordinatesの囲み方が不足することがあります。また、複数の面をまとめる時に、PolygonとMultiPolygonの構造を混同することもあります。見た目では括弧が多いだけに見えるため、手作業で修正していると対応関係を見失いやすくなります。
この問題を防ぐには、Geometryのtypeとcoordinatesの構造をセットで確認します。typeがPointなら座標一組、LineStringなら座標組の配列、Polygonなら線形リングの配列というように、型ごとの期待構造を決めて照合します。範囲チェックだけでは配列構造のミスは発見しにくいため、構文チェック、型チェック、座標値チェックを分けて行うことが重要です。
さらに、FeatureCollection全体でGeometryの種類が混在する場合は、各Featureごとにtypeを確認する必要があります。一つのファイル内に点、線、面が混在していること自体は珍しくありません。しかし、変換処理がすべてを同じ構造として出力していると、一部だけ不正になります。特定のFeatureだけ表示されない、特定の図形だけ範囲外になるといった場合は、配列の深さを疑うと原因に近づきやすくなります。
範囲外を防ぐための確認手順
GeoJSONの座標範囲外を防ぐには、問題が起きてから一つずつ勘で直すのではなく、確認手順を決めておくことが大切です。最初に見るべきなのは、coordinatesに入っている数値が経度、緯度の順になっているかどうかです。日本国内のデータであれば、経度らしい値と緯度らしい値の並びになっているかを確認するだけでも、多くの入力ミスを見つけられます。
次に、座標値の範囲を確認します。経度は通常マイナス180度からプラス180度、緯度はマイナス90度からプラス90度の範囲に収まります。この範囲を超えている値があれば、経緯度としては不正です。ただし、この世界範囲に収まっているだけでは十分ではありません。業務対象が日本国内の特定地域であれば、その地域として妥当な経度緯度の範囲を別に設定して確認する方が安全です。
続いて、元データの座標系を確認します。十進度の経緯度なのか、度分秒なのか、平面直角座標なのか、現場ローカル座標なのかを明確にします。ここが曖昧なままGeoJSON化すると、後工程で原因不明の位置ずれが発生します。外部から受け取ったデータでは、ファイル名や列名だけで判断せず、データ提供時の説明、図面注記、測量成果の記載、座標系に関するメモを確認します。
その後、Geometryのtypeとcoordinatesの配列構造を確認します。Point、LineString、Polygon、Multi系のGeometryでは必要な配列の深さが異なります。数値が正しくても構造が間違っていれば、地物としては正しく扱えません。特に面データでは、外周が閉じているか、穴を表す配列が意図どおりか、不要な空配列が混じっていないかを見ます。
最後に、実際に地図上で表示して確認します。範囲チェックや構文チェックを通過しても、現地の道路、建物、境界、点検対象物と重ねた時に位置が合わなければ、実務データとしては不十分です。全体表示で大きく飛んでいる点がないか、拡大表示で対象物と重なるか、線や面が不自然に伸びていないかを確認します。点数が多い場合は、代表点だけでなく外れ値を探す視点も必要です。
確認手順を標準化しておくと、担当者が変わっても品質を保ちやすくなります。たとえば、変換前データの座標系確認、列順の確認、範囲チェック、構造チェック、地図上での目視確認という流れを作っておけば、同じミスを繰り返しにくくなります。GeoJSONは軽量で扱いやすい形式ですが、座標の前提が崩れると利用価値が大きく下がります。入力時点での確認を丁寧に行うことが、後工程の手戻り削減につながります。
現場データをGeoJSON化する時に意識したい管理方法
現場で取得した座標をGeoJSON化する場合、座標値だけでなく、取得方法や確認履歴も合わせて管理することが重要です。点検結果、写真位置、施工箇所、補修範囲、設備位置などをGeoJSONとして整理する時、後から見直せる情報が不足していると、座標の正しさを判断しづらくなります。特に、複数人で取得したデータを統合する場合は、入力ルールの違いが範囲外や位置ずれの原因になります。
まず、現場で取得する段階で、経度と緯度の並び、座標系、単位、取得日時を記録しておくことが大切です。表計算ファイルに貼り付ける場合も、列名を明確にし、緯度、経度の順で保存しているのか、経度、緯度の順で保存しているのかを注記しておくと、変換時の取り違えを減らせます。列名だけでなく、サンプル値を確認できるようにしておくと、異常値の発見もしやすくなります。
次に、変換処理を手作業に依存しすぎないことも重要です。手作業で括弧やカンマを追加してGeoJSONを作ると、配列の深さや小数点、符号のミスが混入しやすくなります。可能であれば、決まった入力形式から決まった出力形式へ変換する手順を用意し、同じルールで繰り返し生成できるようにします。変換後には、座標範囲の自動チェックや、Geometry typeごとの構造チェックを組み合わせると効果的です。
また、外れ値を見つける仕組みも役立ちます。たとえば、対象エリアの外にある点、緯度が90を超える点、経度が180を超える点、周囲の点群から極端に離れた点を抽出できれば、公開前や納品前に多くのミスを発見できます。特に、写真位置や点検地点のように点数が多いデータでは、人の目だけで全件確認するのは現実的ではありません。範囲チェックと目視確認を組み合わせることで、効率よく品質を高められます。
現場データでは、後から座標を修正する場面もあります。その際、元の値を上書きしてしまうと、なぜ修正したのか分からなくなります。修正前の座標、修正後の座標、修正理由、確認者、確認日を残しておくと、後工程で説明しやすくなります。GeoJSONそのものにすべての履歴を入れる必要はありませんが、管理表や関連データとして残しておくと、トラブル時の確認がしやすくなります。
さらに、写真やメモと座標を紐づける場合は、位置だけでなく現地状況と照合できる情報が必要です。座標値が範囲内でも、写真の対象物と地図上の位置が合っていなければ、入力ミスの可能性があります。現場で撮影した写真、点検メモ、対象物番号、路線名、距離標、施設番号などを合わせて管理すると、座標の妥当性を複数の視点で確認できます。単にGeoJSONを作るだけでなく、後から使える位置情報として整えることが実務では重要です。
まとめ
GeoJSONの座標が範囲外になる時は、まず経度と緯度の順番を確認します。GeoJSONでは一般的に経度、緯度の順でcoordinatesに入れるため、表計算データや現場メモでよく使われる緯度、経度の並びをそのまま入れると、緯度に大きすぎる値が入り、範囲外になることがあります。日本国内のデータであれば、経度らしい値と緯度らしい値の並びになっているかを見るだけでも、多くの問題を発見できます。
次に、座標の表記と座標系を確認します。度分秒を十進度へ変換していない場合、見た目には近い数値でも実際の位置がずれます。古い資料や既存台帳では測地系が異なることもあります。平面直角座標や現場ローカル座標を経緯度として扱うと、値が数千、数万になり、経度や緯度の範囲を大きく超えます。座標値だけでなく、その座標がどの前提で作られたものかを確認することが欠かせません。
符号、小数点、桁数の入力ミスも見落とせません。小数点が抜けるだけで、緯度や経度は範囲外になります。マイナス記号の有無を誤ると、半球が反対になることもあります。桁区切りや不要な文字が混じっている場合は、数値として正しく読めない原因になります。世界全体の範囲に収まるかだけでなく、対象エリアとして自然な値かどうかを確認することが大切です。
さらに、Geometryごとのcoordinatesの配列構造も確認が必要です。Point、LineString、Polygon、Multi系のGeometryでは、必要な配列の深さが異なります。座標値が正しくても、構造が間違っていれば地物として正しく扱えません。特に線や面では、一部の頂点だけが飛んで図形が崩れることがあるため、範囲チェックと表示確認を組み合わせることが効果的です。
GeoJSONは、現場の位置情報を共有しやすい便利な形式です。一方で、入力時の小さなミスが、地図上では大きな位置ずれや範囲外エラーとして現れます。経度緯度の順番、座標表記、座標系、符号と桁、Geometry構造を順番に確認すれば、原因の多くは切り分けられます。現場で取得した位置情報をより確実に管理し、写真や点検記録と合わせて活用したい場合は、座標取得から記録、確認、共有までを一連の流れで扱える運用を整えることが重要です。