GeoJSONを扱うときに、実務で意外とつまずきやすいのが座標順です。地図上に点を置く、線を引く、範囲を塗るといった処理そのものは単純に見えても、座標の並びを取り違えると、対象地点がまったく別の場所に表示されたり、図形が崩れたり、面の判定が期待どおりにならなかったりします。特に、普段の会話や資料では「緯度経度」と呼ぶことが多いため、GeoJSONの座標配列も緯度、経度の順だと思い込んでしまうケースがあります。しかし、GeoJSONでは座標の基本順序を正しく理解しておくことが重要です。 この記事では、geojsonで検索する実務担当者に向けて、座標順で迷わないための注意点を4つに絞り、現場で確認しやすい形で解説します。
目次
• GeoJSONの座標順は経度、緯度が基本
• 点、線、面で座標配列の階層を取り違えない
• 座標系と単位を混同しない
• 入出力時の確認ルールを決めてミスを防ぐ
• まとめ
GeoJSONの座標順は経度、緯度が基本
GeoJSONの座標順で最初に押さえるべき注意点は、基本の 並びが経度、緯度であるという点です。日本語では日常的に「緯度経度」と言う場面が多いため、北緯を先に、東経を後に書く感覚が自然に身についている人も少なくありません。しかし、GeoJSONの`coordinates`に入る位置の基本順序は、経度、緯度です。つまり、地図上の一点を表す場合、横方向の位置に相当する経度が先に来て、その後に縦方向の位置に相当する緯度が続きます。
この違いは、単なる表記上の差ではありません。経度と緯度を入れ替えると、地図上の位置が大きく変わります。たとえば日本国内の座標であれば、経度はおおむね120度台から150度台付近、緯度はおおむね20度台から40度台付近に入ることが多いです。これを逆にしてしまうと、緯度に130度台の値が入ることになり、通常の地理座標としては成立しにくい値になります。表示処理側で範囲外として扱われることもあれば、エラーにならず、何も表示されない、または想定外の場所に表示されるだけの場合もあります。そのため、表示されない原因が座標順にあると気づくまで時間がかかることがあります。
GeoJSONの座標順は、地図を座標平面として扱うときのx、yの考え方に近いと整理できます。一般的な平面座標では、xが横方向、yが縦方向です。経度は東西方向の位置を表し、緯度は南北方向の位置を表します。そのため、GeoJSONではxに相当する経度を先に、yに相当する緯度を後に書くと考えると理解しやすくなります。実務では「GeoJSONは緯度経度ではなく、経度、緯度の順」と覚えておくと、混乱を減らせます。
ただし、現場で扱うデータや画面上の表示では、必ずしもこの順序が明示されているとは限りません。帳票、点検記録、測量メモ、写真の位置情報、管理台帳などでは、項目名として緯度、経度の順に並んでいることがあります。そのデータをGeoJSONに変換するとき、項目の並びをそのまま配列に入れてしまうと、座標順が逆になります。人間が読みやすい順序と、GeoJSONが求める配列順序は別物だと考える必要があります。
特に注意したいのは、CSVや表形式のデータからGeoJSONを作成する場面です。列名が`lat`、`lon`、`latitude`、`longitude`などになっている場合、または日本語で「緯度」「経度」となっている場合、表の左から順に配列へ入れる処理をしてしまうと誤りが起きやすくなります。GeoJSONの`coordinates`を作るときは、元データの列順ではなく、必ず経度の値を先、緯度の値を後に配置する必要があります。変換処理を手作業で行う場合も、変換用の仕組みを使う場合も、こ の一点は最初に確認すべきです。
また、GeoJSONの座標配列には、高さに相当する3つ目の値を含められる場合があります。この場合も、基本は経度、緯度、その次に高さという順序で考えます。高さが入るからといって、緯度と経度の順序が変わるわけではありません。三次元的な位置を扱うときは、最初の2つの値が地図上の水平位置を決め、3つ目の値が高さ方向の情報になると整理しておくと安全です。ただし、実務で高さを扱う場合は、その高さがどの基準に対する値なのか、単位は何かを別途確認する必要があります。
座標順の確認では、数値の範囲を見ることも有効です。日本国内の地物を扱っているのに、最初の値が30台や40台、2つ目の値が130台や140台になっている場合は、緯度と経度が逆になっている可能性があります。もちろん地域によって値の範囲は変わるため、世界中のデータに同じ感覚を当てはめることはできません。それでも、対象地域が明確な業務では、想定される経度と緯度の範囲を事前に把握しておくことで、座標順の取り違えを早い段階で見つけやすくなります。
実務担当者がGeoJSONを扱うときは、まず「`coordinates`の中は経度、緯度」と確認するくらいでちょうどよいです。データ変換、表示確認、成果物の受け渡し、外部データの取り込みなど、どの工程でもこの原則が土台になります。座標順の誤りは、図形の見た目だけでなく、後工程の距離確認、面積確認、重なり判定、範囲検索などにも影響します。最初の一点の順序を軽く見ず、GeoJSONの基本仕様として確実に押さえておくことが重要です。
点、線、面で座標配列の階層を取り違えない
GeoJSONの座標順で迷わないための2つ目の注意点は、点、線、面によって`coordinates`の階層が変わることです。経度、緯度の順序を理解していても、配列の入れ子構造を取り違えると、正しいGeoJSONとして読み込めなかったり、意図した図形として表示されなかったりします。座標順の問題は単に1つの点の並びだけではなく、図形の種類ごとの配列構造と合わせて理解する必要があります。
点を表す場合は比較的単純です。1つの位置を示すだけなので、`coordinates`には経度、緯度の 組が入ります。高さを含める場合は、経度、緯度、高さのように値が続きます。点のデータで間違いやすいのは、緯度、経度の順にしてしまうことのほか、数値を文字列として扱ってしまうことです。GeoJSONでは座標値は数値として扱います。見た目では同じ数字に見えても、文字列になっていると後続の処理で不具合につながることがあります。
線を表す場合は、複数の点を順番に並べます。つまり、`coordinates`の中には、経度、緯度の組が複数入ります。このとき重要なのは、線は点の集合であるだけでなく、点の順番によって形が決まるということです。同じ点を使っていても、並び順が変われば線の通り方が変わります。道路、配管、境界線、移動軌跡などを扱う場合、点の順序は実務上の意味を持ちます。始点から終点へ向かう順なのか、現地で取得した順なのか、管理上の番号順なのかを整理しないままGeoJSONにすると、見た目の線が折り返したり、不要な交差が生じたりします。
面を表す場合は、さらに注意が必要です。面は外周線を閉じたものとして扱います。`coordinates`の中には、外周を構成する座標列が入り、必要に応じて内側の穴を表す座標列も入ります。ここで混乱しやすいのは、面の`coordinates`が点の列をそのまま1段で持つのではなく、輪郭線の配列をさらに入れ子にして持つ点です。単純な四角形であっても、面として扱う場合は、外周リングという単位を意識する必要があります。
面の外周では、最初の座標と最後の座標を一致させて閉じます。見た目では最後の線分を自動的に補ってくれそうに感じるかもしれませんが、GeoJSONとして扱うときは、閉じたリングとして座標列を用意するのが基本です。最初と最後が一致していない場合、読み込み側によって補完されることもありますが、常に期待どおりになるとは限りません。実務で成果物として扱うなら、外周リングが閉じているかを確認する方が安全です。
また、面では外周と内周の向きにも注意が必要です。GeoJSONでは外周と穴の輪郭について推奨される向きがあります。ただし、向きの扱いは表示や読み込みを行う処理によって見え方や許容範囲が異なることがあります。実務で重要なのは、表示されたから問題ないと判断しないことです。画面上で面が塗られていても、データとしての内外関係や穴の扱いが適切でないと、面積確認や重なり判定で違いが出る可能性があります。特に、敷地範囲、管理区域、施工範囲、立入制限範囲などの面データでは、リングの閉じ方と内外の扱 いを確認しておく必要があります。
複数の点、複数の線、複数の面をまとめて扱う種類では、配列の階層がさらに深くなります。ひとつの地物に複数の線が含まれる場合や、離れた複数の面をひとつの属性で管理する場合などです。このようなデータでは、座標の順序そのものは経度、緯度で変わりませんが、どの階層が1点を表し、どの階層が1本の線を表し、どの階層が1つの面を表すのかを見誤りやすくなります。階層を誤ると、データの意味が崩れるだけでなく、読み込みエラーの原因にもなります。
実務では、まず対象データが点なのか、線なのか、面なのかを明確にすることが大切です。点検写真の撮影位置なら点、道路中心線や境界線なら線、敷地範囲や作業範囲なら面というように、地物の種類を整理します。そのうえで、`coordinates`の構造がその種類に合っているかを確認します。点のつもりで座標列を複数入れていないか、線のつもりで面のような閉じた構造にしていないか、面のつもりなのに外周リングの階層が不足していないかを見ます。
座標配列の階層は、慣れないうちは複雑に感じます。しかし、基本は「点は1組、線は点の列、面は閉じた線の列」と考えると整理しやすくなります。複数形の種類は、そのまとまりがさらに並ぶだけです。座標値の順序と配列の階層を分けて考えれば、GeoJSONの構造は理解しやすくなります。座標順だけを直しても階層が間違っていれば正しく使えないため、変換時や受領時には必ず図形種類と階層構造を合わせて確認しましょう。
座標系と単位を混同しない
GeoJSONの座標順で迷わないための3つ目の注意点は、座標順と座標系を混同しないことです。経度、緯度の順に並んでいるからといって、すべての位置情報が正しく地図に重なるとは限りません。座標の順序が合っていても、座標系や単位が違えば、表示位置はずれます。実務では「順番は合っているのに場所がずれる」という問題が起きることがあり、その原因として座標系の違いが関係している場合があります。
GeoJSONで扱う経度と緯度は、度を単位とする地理座標として整理するのが基本です。一方、測量や設計、施工管理の現場では、メートル単位の平面直角座標や、独自の現場座標、図面上のローカル座標が使われることがあります。これらの座標は、見た目には同じように数値の組として表されますが、意味は大きく異なります。
たとえば、現場座標でxとyが数千や数万の値になっているデータを、そのままGeoJSONの経度、緯度として入れても、地球上の位置としては適切に解釈されません。経度や緯度は角度なので、値の範囲に自然な制約があります。経度はおおむねマイナス180度からプラス180度、緯度はマイナス90度からプラス90度の範囲で扱われます。これを大きく超える値が入っている場合、その値は経度や緯度ではなく、別の座標系の値である可能性があります。
現場で多い混乱は、「x、yの順」と「経度、緯度の順」を同じものとして扱ってしまうことです。GeoJSONの経度、緯度は、考え方としてはx、yに似ていますが、任意の平面座標のx、yをそのまま入れてよいという意味ではありません。座標順の理解と、座標系の変換は別の確認事項です。平面座標や現場座標をGeoJSONで地図表示したい場合は、対象の座標系から経度、緯度へ変換する工程が必要になることがあります。
また、図面データから取得した座標を扱う場合も注意が必要です。図面上の座標は、実世界の座標と対応している場合もあれば、単に図面内の作図単位で表されている場合もあります。原点位置、縮尺、回転、単位、座標軸の向きが整理されていなければ、GeoJSONに変換しても正しい地図位置にはなりません。図面上では正しく見える線や面でも、地図上では大きくずれることがあります。これはGeoJSONの座標順の問題ではなく、元データの座標基準の問題です。
高さ情報を含める場合も、単位と基準の確認が欠かせません。GeoJSONの座標配列に3つ目の値を入れる場合、その値が何を意味するのかを関係者間で共有しておく必要があります。標高として扱うのか、建物や構造物の高さとして扱うのか、地盤面からの相対高として扱うのかで、データの解釈は変わります。高さの単位がメートルなのか、別の単位なのかも確認が必要です。2次元の地図表示だけなら問題が見えなくても、3次元表示や断面確認に使うときにずれが表面化することがあります。
座標系の混同を防ぐには、データの中身だけでなく、データの出どころを 確認することが重要です。現地測量から作成されたものなのか、図面から抽出されたものなのか、写真の位置情報から作成されたものなのか、別の台帳から変換されたものなのかによって、注意すべき点が変わります。元データがどの座標系で管理されているか、変換済みなのか未変換なのか、変換時にどの基準を使ったのかを記録しておくと、後から原因調査をしやすくなります。
実務では、GeoJSONを受け取ったらまず表示して確認することが多いかもしれません。しかし、表示確認だけでは座標系の問題を見落とすことがあります。たまたま近い位置に表示されたように見えても、数メートルから数十メートルのずれが残っている場合があります。用地境界、設備位置、施工範囲、点検対象など、位置精度が業務判断に関わるデータでは、単に地図上に出たかどうかではなく、既知点や基準点、現地で確認できる目標物との整合を見ることが大切です。
座標系と単位の確認は、GeoJSONだけを見て完結しないことがあります。属性情報、作成手順、元データの説明、変換条件、業務上の前提を合わせて確認する必要があります。特に複数の担当者がデータをやり取りする場合、「座標は経度、緯度です」「単位は度です」「高さは含みません」「元の平面座標から変換済みです」といった情報を明記しておくと、取り違えを防ぎやすくなります。座標順の正しさは重要ですが、それだけで位置情報の正しさが保証されるわけではないと理解しておきましょう。
入出力時の確認ルールを決めてミスを防ぐ
GeoJSONの座標順で迷わないための4つ目の注意点は、入出力時の確認ルールをあらかじめ決めておくことです。座標順の知識があっても、作業のたびに担当者の記憶や勘に頼っていると、どこかでミスが混入します。実務では、元データの形式、変換方法、確認担当、納品形式が案件ごとに変わることがあります。そのため、GeoJSONを作成、編集、受領、納品する工程に、座標順を確認する手順を組み込むことが重要です。
まず決めておきたいのは、元データを取り込むときの列名確認です。表形式のデータからGeoJSONを作る場合、緯度と経度の列がどのような名前で並んでいるかを確認します。日本語の列名であれば「緯度」「経度」、英字であれば`lat`、`lon`など、表記が統一されていないことがあります。列名が似ている場合や省略表記 になっている場合は、数値の範囲も合わせて確認します。日本国内のデータであれば、経度と緯度の値の大まかな範囲から、列の取り違えに気づけることがあります。
次に、変換後のGeoJSONを確認する段階では、代表点をいくつか選んで位置を確認することが有効です。すべての点を目視で確認するのは現実的ではありませんが、始点、終点、範囲の四隅、代表的な施設や地点など、業務上意味のある位置を選んで確認すれば、座標順の誤りや大きな座標系の違いを発見しやすくなります。線や面の場合は、単に点があるかだけでなく、線のつながり方や面の閉じ方も確認します。
受領したGeoJSONを使う場合は、作成者がどの前提で座標を入れているかを確認することが重要です。GeoJSONだから必ず経度、緯度で正しく作られているとは限りません。人が作ったデータである以上、緯度、経度で入っている可能性もありますし、平面座標がそのまま入っている可能性もあります。受領時には、ファイルを開いて形式だけを見るのではなく、実際の座標値、対象地域、図形種類、属性情報を合わせて確認します。
確認ルールには、エラーが出た場合の切り分け方法も含めておくと便利です。GeoJSONが読み込めない、何も表示されない、遠く離れた場所に表示される、図形が極端に伸びる、面が塗られない、穴が反映されないといった症状は、それぞれ原因が異なります。座標順の逆転、配列階層の誤り、座標系の違い、リングの未閉合、数値形式の不備などを順番に確認できるようにしておくと、原因調査が早くなります。
実務で特に有効なのは、作業前に「このデータは何を表すのか」を言葉で整理することです。たとえば、点検写真の撮影地点を点で表すのか、現場巡回ルートを線で表すのか、施工範囲を面で表すのかによって、正しいGeoJSONの形が変わります。図形の種類が曖昧なまま座標だけを変換すると、あとで表示や集計に使うときに困ります。座標順だけでなく、地物の意味と図形形式をセットで確認することが大切です。
また、作成したGeoJSONには、属性情報として確認に役立つ項目を入れておくと運用しやすくなります。地点名、管理番号、取得日、作成元、確認状況などがあれば、地図上で表示したときに、どの座標が何を示しているか判断しやすくなります。座標だけのデータは一見シンプルですが、後から見たときに意味を読み取りにくく、誤った修正を招くことがあります。属性情報は座標順そのものを変えるものではありませんが、確認作業の質を上げるために役立ちます。
データを納品する側であれば、GeoJSONの前提を明記することも重要です。座標順は経度、緯度であること、座標系は地理座標であること、高さを含むかどうか、面のリングが閉じていること、作成元のデータ、変換日、確認方法などを簡単に記録しておくと、受け取る側が安心して使えます。納品後に座標がずれていると言われたときも、どの段階で問題が起きたかを追いやすくなります。
一方で、受け取る側も、GeoJSONという形式名だけで安全だと判断しないことが大切です。GeoJSONは位置情報を表すための便利な形式ですが、ファイル形式が正しいことと、業務上の位置が正しいことは別です。構文が正しくても、座標順が逆であれば位置は間違います。座標順が正しくても、元の座標系が違えば位置はずれます。表示できても、線や面の構造が意図どおりとは限りません。実務利用では、形式確認、位置確認、意味確認を分けて行う意識が必要です。
日常的な作業では、確認の観点を簡潔なルールとして共有しておくと効果的です。たとえば、GeoJSONの`coordinates`は経度、緯度の順で確認すること、点、線、面の階層を図形種類ごとに確認すること、値の範囲が対象地域と合っているか見ること、代表点を地図上で照合すること、受け渡し時に座標系と高さの有無を伝えることです。これらを担当者ごとの暗黙知にせず、作業手順として定着させると、座標順に関するミスを減らしやすくなります。
GeoJSONの取り扱いは、慣れれば難しいものではありません。しかし、座標順のような基本的な部分ほど、思い込みで処理してしまいやすいものです。特に、現場で得た位置情報を事務所で整理し、別の担当者が地図化し、さらに別の関係者が確認するような流れでは、途中で前提が抜け落ちることがあります。入出力のたびに同じ確認を繰り返せる仕組みを作ることが、実務での品質を安定させる近道です。
まとめ
GeoJSONの座 標順で迷わないためには、まず`coordinates`の基本が経度、緯度の順であることを確実に押さえる必要があります。日常的な言い方では「緯度経度」と表現することが多いため、その感覚のまま配列を作ると順序が逆になります。GeoJSONでは横方向に相当する経度を先に、縦方向に相当する緯度を後に置くと考えると理解しやすくなります。
次に、点、線、面で`coordinates`の階層が変わる点にも注意が必要です。点は1つの座標組、線は座標組の列、面は閉じたリングの列として整理します。座標値の順序が合っていても、配列の階層が図形種類に合っていなければ、正しく表示されないことがあります。面では外周が閉じているか、穴を含む場合に内外の扱いが適切かも確認します。
さらに、座標順と座標系を混同しないことも重要です。GeoJSONで扱う経度、緯度は度を単位とする地理座標ですが、測量や設計の現場ではメートル単位の平面座標や現場独自の座標が使われることがあります。x、yの順に似ているからといって、任意の平面座標をそのままGeoJSONの経度、緯度として使えるわけではありません。元データの座標系、単位、高さの基準を確認してから変換することが大切です。
最後に、入出力時の確認ルールを決めておくことで、座標順のミスを実務の中で防ぎやすくなります。元データの列名、数値の範囲、代表点の位置、図形種類、配列階層、座標系、属性情報を確認する流れを作っておけば、担当者が変わっても品質を保ちやすくなります。GeoJSONは便利な形式ですが、形式が正しいだけでは実務上の位置が正しいとは限りません。表示確認だけでなく、対象地域や業務目的に照らした確認が必要です。
現場で取得した位置情報をGeoJSONとして整理する場合、座標順の理解に加えて、取得時点から位置の意味を正しく残すことが大切です。点検写真、施工記録、現地確認結果などをあとから地図や図面上で活用したい場合は、取得、整理、共有までを一連の流れとして考えると、座標の取り違えや確認漏れを減らせます。特定の製品名やサービス名に依存せず、座標順、座標系、属性情報、確認手順をセットで管理することが、GeoJSONを安全に活用するための基本です。
LRTKで現場の測量精度・作業効率を飛躍的に向上
LRTKシリーズは、建設・土木・測量分野における高精度なGNSS測位を実現し、作業時間短縮や生産性の大幅な向上を可能にします。国土交通省が推進するi-Constructionにも対応しており、建設業界のデジタル化促進に最適なソリューションです。
LRTKの詳細については、下記のリンクよりご覧ください。
製品に関するご質問やお見積り、導入検討に関するご相談は、
こちらのお問い合わせフォームよりお気軽にご連絡ください。ぜひLRTKで、貴社の現場を次のステージへと進化させましょう。

