GeoJSONは、地図上の点、線、面などの地理空間データをJSON形式で表現するためのデータ形式です。現場の位置情報、設備管理、測量成果の共有、点検記録、区域データの整理などで使いやすい一方、座標データの前提を誤ると、地図上の位置がずれる、面が崩れる、距離や面積の解釈を間違える、別システムに渡したときに想定どおり表示できない、といった問題が起こります。
特に「geojson 使い方」を調べて実務に取り入れようとしている場合、ファイルの書き方だけでなく、座標の順番、座標参照系、精度、ジオメトリの種類、属性情報、運用時の確認方法まで含めて理解しておくことが重要です。この記事では、GeoJSONの座標データを正しく扱うために押さえておきたい6つの注意点を、現場データや管理データを扱う実務担当者向けに解説します。
GeoJSONは座標と属性を一体で扱う形式として理解する
GeoJSONを正しく使うためには、まず「座標だけのファイル」ではなく、「地図上の形状と、その形状に紐づく情報をまとめて扱う形式」として理解することが大切です。単に緯度や経度の数値を並べるだけではなく、その座標が何を表しているのか、どの種類の形状なのか、どの属性を持つ対象なのかを同時に記録できる点がGeoJSONの特徴です。
たとえば、現場内の点検箇所を記録する場合、座標だけが分かっていても、それがマンホールなのか、標識なのか、境界杭なのか、仮設物なのかが分からなければ、実務では使いにくくなります。GeoJSONでは、点の位置を示す座標とあわせて、名称、管理番号、点検日、状態、備考などの属性情報を持たせることができます。これにより、単なる位置情報ではなく、現場管理や維持管理に使えるデータとして扱いやすくなります。
GeoJSONの基本的な考え方は、地物を単位として扱うことです。地物とは、地図上で意味を持つ対象のことです。点検箇所、道路中心線、配管ルート、敷地境界、施工範囲、危険区域、写真撮影地点など、実務上管理したい対象は地物として考えられます。各地物には、形状を表す座標データと、意味を表す属性データがあります。この2つを分けて考えず、セットで管理することが、GeoJSONを実務に使う第一歩です。
GeoJSONでは、複数の地物をまとめた単位でファイルを作ることが一般的です。たとえば、現場内のすべての測点を1つのファイルにまとめる、道路沿いの設備を1つのファイルにまとめる、区域ごとの面データを1つのファイルにまとめる、といった使い方が考えられます。このとき、ファイル内の各地物が同じ種類の情報を持つようにしておくと、後から検索や集計がしやすくなります。
注意したいのは、GeoJSONは見た目の地図を保存するためのスタイル形式ではないという点です。色、線幅、ラベルの表示位置、画面上のデザインなどは、表示側のアプリケーションや地図サービスの設定で扱うことが多く、GeoJSONの中心は座標、形状、属性です。そのため、GeoJSONを作るときは「どう見せるか」よりも先に、「何をどの座標で、どの属性と一緒に管理するか」を整理する必要があります。
また、GeoJSONはJSONを基礎にしたテキスト形式であるため、人が読んで確認しやすい反面、構造が崩れると読み込みエラーが発生しやすい形式でもあります。カンマの抜け、括弧の不足、文字列の囲み忘れ、座標配列の階層ミスなど、わずかな記述ミスでも正しく処理できないことがあります。手作業で編集する場合は、座標値そのものだけでなく、ファイル構造が正しいかを確認する習慣が必要です。
実務では、GeoJSONを単独で完結する資料として見るのではなく、測量データ、設計図面、写真記録、点検台帳、施工管理資料などとつながる中間データとして扱う場面が多くなります。そのため、最初に用途を決めておくことが重要です。現地確認用なのか、台帳管理用なのか、関係者への共有用なのか、後工程で別の形式に変換する前提なのかによって、必要な属性や座標精度が変わります。
たとえば、現地で対象物を探すためのGeoJSONであれば、名称や管理番号、現地で見分けるためのメモが重要になります。施工範囲の確認に使う場合は、境界線や面の形状が正確であることが重要です。写真撮影地点を管理する場合は、撮影日時や撮影方向、対象物の種類などを属性に入れておくと、後から記録を追いやすくなります。
このように、GeoJSONは「座標を入れれば終わり」ではありません。座標、形状、属性、用途をそろえて初めて、実務で使えるデータになります。まずはGeoJSONを、地図上の対象を正しく管理するための器として理解し、座標データと属性情報を一体で設計することが大切です。
経度と緯度の順番を間違えない
GeoJSONの座標データで最も起こりやすいミスの一つが、経度と緯度の順番を逆にしてしまうことです。日常会話や多くの表記では「緯度・経度」という順番で言われることが多いため、つい緯度を先に書きたくなります。しかし、GeoJSONの位置配列では、地理座標を扱う場合に「経度、緯度」の順番で記述します。高さを含める場合も、標準的には「経度、緯度、高さ」の順に並びます。
この順番を間違えると、地図上の位置が大きくずれます。国内の座標であれば、緯度はおおむね20度台から40度台、経度はおおむね120度台から150度台に入ることが多いため、順番を逆にすると、まったく別の地域や海上に表示されることがあります。ファイル自体は構造として正しくても、座標値の順番が誤っていると、読み込みエラーではなく「意図しない場所に表示される」という形で問題が現れるため、発見が遅れることがあります。
特に、表計算形式のデータや測量成果の一覧からGeoJSONを作成する場合は注意が必要です。元データの列名が「緯度」「経度」の順で並んでいると、そのまま機械的に変換してしまい、GeoJSON側でも同じ順番にしてしまうことがあります。変換処理を行う前に、どの列が緯度で、どの列が経度かを明確にし、出力時には必ず経度を先に配置するルールを決めておくべきです。
また、座標値の単位にも注意が必要です。GeoJSONで標準的に使う経度・緯度は、度を単位とする小数表記です。度分秒のような表記をそのまま数値として入れると、正しい位置にはなりません。度、分、秒で管理されている座標を使う場合は、事前に小数の度へ変換する必要があります。見た目は似た数字でも、単位や表記方法が違えば意味は大きく変わります。
経度と緯度の順番を確認するには、まず代表点を一つ選び、地図上で表示して目視確認する方法が有効です。ファイル全体を変換してから確認するのではなく、最初に数点だけを取り出して、想定する場所に表示されるかを確認します。現場付近、自治体内、対象路線上、敷地内など、明らかに判断できる場所を基準にすると、順番の誤りに気づきやすくなります。
さらに、ファイル内で座標の順番が混在していないかも確認が必要です。一部のデータだけ手入力で修正したり、複数の元データを結合したりすると、ある地物は経度・緯度の順、別の地物は緯度・経度の順という混在が起こることがあります。全体の一部だけが遠く離れた場所に飛んでいる場合は、座標順、座標参照系、桁数、符号のいずれかに問題がある可能性があります。
高さを扱う場合も、順番の理解が重要です。GeoJSONでは3つ目の値として高さを入れることがありますが、標準的なGeoJSONではWGS 84楕円体を基準にしたメートル単位の高さとして扱われます。一方、実務データでは標高、楕円体高、現場基準の高さ、構造物の高さなどが混在することがあります。高さを含める場合は、属性情報や運用ルールの中で、高さの基準を明記しておくことが望ましいです。
実務でよくある失敗は、地図上の平面位置だけを確認して、高さの意味を確認しないまま使ってしまうことです。平面位置が正しくても、高さの基準が異なると、設計データや出来形データとの比較でずれが生じます。GeoJSONを3次元的な確認に使う場合は、経度・緯度の順番だけでなく、高さの扱いまで含めて確認する必要があります。
座標順のミスは、基本的なようでいて非常に多い問題です。GeoJSONを作成する前、変換する前、共有する前の各段階で、「座標は経度、緯度の順になっているか」を確認するだけでも、多くの位置ずれを防げます。ファイルの構造を覚えることよりも、まずは座標の並び順を徹底することが、GeoJSON活用の土台になります。
測地系と座標の前提をそろえる
GeoJSONの座標データを正しく扱ううえで、座標の順番と同じくらい重要なのが、測地系や座標参照系の前提をそろえることです。測地系とは、地球上の位置をどの基準で表すかという考え方です。見た目には同じような緯度・経度の数値でも、基準が異なれば、地図上の位置に差が出る場合があります。実務で複数のデータを重ね合わせるときは、この前提がそろっていないと、ずれの原因になります。
現在広く参照されるGeoJSON仕様では、座標参照系はWGS 84を用いた経度・緯度の地理座標が前提です。古い仕様や一部のソフトウェアでは、別の座標参照系を示す情報が付いたGeoJSON風のデータに出会うことがありますが、互換性を重視するなら、標準的なGeoJSONとして扱うデータはWGS 84の経度・緯度に変換しておくのが安全です。
一方で、測量や設計、施工の現場では、平面直角座標のようにメートル単位で扱う座標系が使われることがあります。設計図面や測量成果では、X座標、Y座標としてメートル単位の数値が使われていることも多く、そのままGeoJSONの座標欄に入れても、一般的なWeb地図やGISで正しい場所には表示できません。
ここで注意したいのは、「座標」と呼ばれるものが常に同じ意味ではないという点です。経度・緯度の座標、平面上のメートル座標、図面内のローカル座標、現場独自の基準点からの相対座標は、それぞれ前提が異なります。GeoJSONに変換する際には、元データがどの座標系で作られているかを確認し、必要に応じて適切な変換を行う必要があります。
たとえば、設計図面から取り出した座標値がメートル単位の平面座標である場合、そのままGeoJSONに入れても経度・緯度としては解釈できません。地図上に表示したい場合は、対象地域に合った座標変換を行い、経度・緯度の形式に変換する必要があります。逆に、GeoJSONの経度・緯度を設計図面や施工管理の座標に合わせたい場合は、図面側の座標系に変換して扱う必要があります。
また、同じ現場内のデータであっても、作成時期や提供元によって座標の前提が異なることがあります。古い資料、最新の測量成果、設計データ、台帳データ、現地で取得した位置情報を重ねる場合、それぞれがどの基準で作られているかを確認しなければなりません。わずかなずれであっても、境界、構造物、埋設物、設備位置などの確認では大きな問題になることがあります。
測地系の違いによるずれは、見た目だけでは原因を特定しにくいことがあります。全体が一定方向にずれている場合は、座標系や変換条件が合っていない可能性があります。一部だけがずれている場合は、元データの混在、個別編集、測定誤差、入力ミスなども疑う必要があります。重要なのは、ずれが見つかったときに、すぐにデータを手で動かして合わせるのではなく、まず座標の前提を確認することです。
GeoJSONを実務で扱う場合は、ファイルごとに座標の前提を記録しておくと安全です。どの測地系を前提にしているか、元データは何か、変換処理を行ったか、高さの基準は何か、作成日や更新日、担当者は誰か、といった情報を管理しておくと、後から確認しやすくなります。GeoJSONの属性情報にすべてを入れる方法もありますが、ファイル管理ルールや別の説明資料と組み合わせて運用する方法もあります。
特に、複数人で作業する場合や、外部にデータを渡す場合は、座標の前提を明示しないまま共有すると誤解が生じます。受け取った側が経度・緯度だと思って処理したが、実際は別の座標だったというケースでは、データの作り直しが必要になることもあります。共有時には、ファイル名や属性名だけに頼らず、座標系、単位、高さの扱いを説明できる状態にしておくことが重要です。
座標の前提をそろえることは、GeoJSONだけの問題ではありません。測量、設計、施工、維持管理、点検、報告の各工程をつなぐための基本です。GeoJSONは扱いやすい形式ですが、元データの前提を自動的に正してくれるわけではありません。だからこそ、変換前の確認、変換後の検証、共有時の説明をセットで運用する必要があります。
GeoJSONの使い方を覚えるときは、ファイルの書式やサンプルだけに注目しがちですが、実務では「その座標が何を基準にした数値なのか」を確認する力が欠かせません。座標系と測地系の前提をそろえることで、地図上の表示だけでなく、設計データや現場データとの整合性も高めることができます。
点・線・面のジオメトリ構造を正しく選ぶ
GeoJSONでは、点、線、面などの形状をジオメトリとして表します。座標値が正しくても、ジオメトリの種類を誤ると、意図した表示や処理ができません。実務でGeoJSONを使うときは、対象物の性質に合わせて、点で管理するのか、線で管理するのか、面で管理するのかを最初に決める必要があります。
点は、位置を一つの座標で表せる対象に向いています。測点、写真撮影位置、設備の中心位置、点検箇所、基準点、看板、照明、マンホール、境界標などが代表的です。点データは扱いやすく、属性情報との相性もよいため、現場記録や台帳管理でよく使われます。ただし、点は対象物の大きさや範囲を表すものではないため、広がりを持つ対象に点だけを使うと、後から解釈があいまいになります。
線は、連続した経路や境界を表す対象に向いています。道路中心線、配管ルート、ケーブルルート、フェンス、施工ライン、測線、河川の中心線などが例になります。線データでは、座標の並び順が意味を持つ場合があります。始点から終点への方向、上流から下流への方向、起点から終点への管理方向など、順番によって属性の解釈が変わることがあるため、座標列の順序を意識して作成する必要があります。
面は、範囲を表す対象に向いています。敷地、施工範囲、管理区域、立入禁止区域、舗装範囲、建物外形、土量計算の対象範囲などに使われます。面データでは、外周を構成する座標列が閉じている必要があります。つまり、最初の座標と最後の座標が同じであることが求められます。これが不足していると、面として正しく扱えなかったり、表示が崩れたりすることがあります。
面を扱う際には、外周と穴の違いにも注意が必要です。たとえば、区域の中に除外範囲がある場合、単純な外周だけでは正しく表現できません。面の内部に穴を持つ構造として扱う必要があります。GeoJSONのPolygonでは、最初のリングが外周を表し、その後のリングが内側の穴を表します。実務では、池、建物内の中庭、施工対象外の区画、通行不可部分など、外周の内側に別の意味を持つ範囲が存在することがあります。
Polygonでは、外周や穴の向きにも注意が必要です。標準仕様では、外周は反時計回り、内側の穴は時計回りという向きが定められています。ただし、古いデータや一部のツールでは向きが異なるデータも存在し、読み込み側が許容する場合もあります。面積計算や他形式への変換で問題が出ることがあるため、共有前に閉合、リングの順序、自己交差、向きの確認を行うと安全です。
複数の点、複数の線、複数の面を一つの地物として扱う場合もあります。たとえば、同じ管理番号を持つ複数の設備、分断された複数の路線、離れた複数の区域を一つの対象として管理したい場合です。ただし、複雑な構造にすると、扱う側のシステムや担当者にとって分かりにくくなることがあります。必要以上に複雑な構造にせず、実務で検索、編集、更新しやすい単位に分けることが大切です。
ジオメトリを選ぶときは、「地図上でどう見えるか」だけでなく、「後からどのように使うか」を考える必要があります。現地で対象物の位置を探すだけなら点で十分な場合がありますが、距離を測りたいなら線、範囲や面積を扱いたいなら面が必要になります。逆に、面として作るべきデータを点で代用すると、範囲確認や重なり判定ができなくなります。線で作るべきデータを面にしてしまうと、長さや経路の管理が難しくなることもあります。
現場データでは、点、線、面を組み合わせて管理することもあります。たとえば、施工範囲を面で表し、範囲内の写真撮影位置を点で表し、搬入経路を線で表すような構成です。このように役割ごとにジオメトリを分けると、表示や検索がしやすくなります。一方で、すべてを一つのファイルに詰め込みすぎると、更新時に混乱しやすくなります。用途ごと、対象ごと、更新頻度ごとにファイルを分けることも検討すべきです。
ジオメトリの構造を正しく選ぶことは、後工程の精度にも影響します。点を線に変換する、線を面に変換する、面から中心点を作るといった処理は可能ですが、元のデータが意図に合っていないと、変換後の結果も不自然になります。最初の段階で対象物の性質を見極め、適切なジオメトリを選ぶことが、GeoJSONの品質を左右します。
GeoJSONの構造は単純に見えますが、点、線、面の選択には実務上の判断が必要です。どの形状で管理すれば現場で使いやすいか、更新しやすいか、他のデータと重ねやすいかを考えながら設計することで、後から修正に追われるリスクを減らせます。
座標精度と丸め処理で位置ずれを起こさない
GeoJSONの座標データでは、数値の桁数や丸め処理にも注意が必要です。経度・緯度は小数で表されることが多く、小数点以下の桁数によって表現できる位置の細かさが変わります。桁数を減らしすぎると、地図上ではわずかな違いに見えても、現場では無視できない位置ずれになることがあります。特に、測量、施工、設備管理、境界確認のように位置精度が重要な用途では、安易な丸め処理は避けるべきです。
座標の小数点以下を何桁まで保持するかは、用途によって変わります。広域の概略表示であれば高い桁数は必要ないこともありますが、現場で対象物を探す、構造物の位置を確認する、設計データと重ねる、写真位置を管理する、といった用途では、十分な桁数を保持する必要があります。見た目を簡単にするために小数点以下を削ると、後から元の精度に戻すことはできません。
丸め処理で注意すべきなのは、表示上の丸めとデータ上の丸めを分けて考えることです。画面上や帳票上では見やすさのために桁数を減らして表示しても、元データとしては十分な桁数を保持するべきです。表示の都合で元ファイルそのものの座標を丸めてしまうと、次にそのデータを使う工程で精度不足が問題になります。実務では、保存用の座標と表示用の座標を区別する考え方が重要です。
また、座標変換を繰り返す場合にも注意が必要です。元データを別の座標系に変換し、さらに別形式へ変換し、そのたびに丸め処理が行われると、少しずつ誤差が積み重なることがあります。変換のたびに桁数を削るのではなく、可能な限り元データを保持し、必要な最終出力の段階で適切に整えることが望ましいです。
GeoJSONはテキスト形式であるため、ファイルサイズを小さくする目的で座標の桁数を削りたくなることがあります。大量の頂点を持つ線や面を含むデータでは、座標桁数がファイルサイズに影響します。しかし、ファイルサイズの削減を優先しすぎて精度を落とすと、地図上の形状が崩れたり、境界線がずれたり、面の重なりや隙間が発生したりすることがあります。軽量化が必要な場合でも、用途に必要な精度を確認してから行うべきです。
線や面のデータでは、点ごとの丸めが形状全体に影響します。直線に見える部分であっても、実際には複数の座標で構成されている場合があります。各座標を粗く丸めると、線が微妙に折れたり、面の外周が不自然になったりします。隣接する面同士で別々に丸め処理を行うと、本来ぴったり接しているはずの境界に隙間や重なりができることもあります。
面データの場合、丸め処理によって外周の始点と終点が一致しなくなる可能性にも注意が必要です。面を閉じるために同じ座標を使っていたとしても、処理の過程で一方だけが変更されると、面として不正な構造になることがあります。自動処理で座標を加工する場合は、加工後に面が正しく閉じているか、交差やねじれが発生していないかを確認することが重要です。
一方で、必要以上に細かい桁数を無条件に保持すればよいわけでもありません。取得方法や元データの精度以上に細かい桁を残しても、実際の精度が高くなるわけではありません。簡易的な位置取得で得られた座標に多くの小数桁が含まれていても、そのすべてが実用上の精度を意味するとは限りません。数値の桁数と測定精度は別物であることを理解する必要があります。
そのため、GeoJSONを作るときは、座標値の桁数だけでなく、取得方法、期待精度、使用目的を合わせて考える必要があります。高精度の測量成果を扱うのか、現地メモとしての概略位置を扱うのか、写真の撮影場所を目安として扱うのかによって、必要な精度は異なります。属性情報に取得方法や精度区分を持たせておくと、後からデータを使う人が判断しやすくなります。
実務では、精度に関するルールを事前に決めておくことが有効です。元データは丸めずに保存する、共有用データは用途に応じて桁数を調整する、座標変換後は代表点で位置確認を行う、面データは加工後に閉合を確認する、といった運用です。こうしたルールがないまま担当者ごとに処理すると、同じ種類のデータでも精度や形式がばらついてしまいます。
座標精度と丸め処理は、ファイルを開いた瞬間には目立たない問題です。しかし、現場で使う段階、他のデータと重ねる段階、距離や面積を確認する段階で影響が出ます。GeoJSONを信頼できるデータとして使うためには、数値の見た目だけでなく、桁数、変換、丸め、取得精度を一体で管理することが大切です。
属性情報とファイル運用のルールを決めておく
GeoJSONの実務利用では、座標データそのものと同じくらい、属性情報とファイル運用のルールが重要です。座標が正しくても、属性名がばらばらだったり、更新日が不明だったり、同じ対象が複数ファイルに重複していたりすると、現場管理や台帳管理では使いにくいデータになります。GeoJSONを一度作って終わりにするのではなく、継続的に更新、確認、共有する前提でルールを整える必要があります。
属性情報では、まず何を必須項目にするかを決めます。名称、管理番号、分類、状態、作成日、更新日、担当者、備考など、用途に応じて必要な項目は異なります。設備管理であれば管理番号や設備種別が重要になります。点検記録であれば点検日や判定結果が重要になります。施工範囲であれば工区名、施工段階、対象期間などが必要になる場合があります。
属性名は、できるだけ統一しておくことが大切です。同じ意味の項目に対して、あるファイルでは「名称」、別のファイルでは「名前」、さらに別のファイルでは「対象名」としていると、検索や集計の際に手間が増えます。人が読むだけなら意味が分かっても、機械的に処理する場合は別の項目として扱われます。最初に項目名のルールを決め、表記ゆれを減らすことが重要です。
属性値の入力ルールも必要です。たとえば、状態を表す項目に「良好」「正常」「問題なし」が混在していると、同じ意味でも集計しにくくなります。日付の書き方、分類名、空欄の扱い、未確認の場合の表記、数値と文字列の使い分けなどを決めておくと、データ品質が安定します。自由記述欄は便利ですが、重要な分類や判定を自由記述だけに頼ると、後から整理が難しくなります。
ファイル名の付け方も実務では重要です。GeoJSONファイルが増えると、どれが最新か、どの現場のものか、どの用途のものかが分かりにくくなります。現場名、対象、日付、版数、用途などを含めた命名ルールを決めておくと、関係者間で共有しやすくなります。ただし、ファイル名だけで情報を管理しようとすると限界があるため、属性情報や管理台帳と組み合わせて運用することが望ましいです。
更新ルールも欠かせません。GeoJSONは編集しやすい形式ですが、誰が、いつ、どの地物を更新したのかが分からないと、後から内容を検証できません。特に、現場で取得したデータを事務所で整理する場合や、複数人が同じファイルを扱う場合は、更新履歴の管理が重要です。最新版の管理、過去版の保管、承認済みデータと作業中データの区別を明確にしておく必要があります。
共有時には、ファイル単体ではなく、使い方の前提も一緒に伝えることが大切です。座標系、作成目的、対象範囲、更新日、属性項目の意味、注意点が共有されていなければ、受け取った側が誤った解釈をする可能性があります。たとえば、概略確認用のデータを正式な測量成果として扱ってしまうと、判断ミスにつながります。データの精度や用途を明示することは、トラブル防止にも役立ちます。
また、GeoJSONを別の形式に変換する場合は、属性が失われないかを確認する必要があります。変換先の形式によっては、長い項目名が短縮されたり、日本語の文字が正しく扱えなかったり、数値と文字列の型が変わったりすることがあります。変換後に座標だけを確認するのではなく、属性情報が想定どおり残っているかも確認するべきです。
文字コードにも注意が必要です。日本語の属性を含むGeoJSONでは、文字化けが起こると名称や備考が読めなくなります。関係者間で受け渡しを行う場合は、使用する文字の扱いを確認し、特殊な記号や機種依存文字を避けると安全です。特に、現場名や設備名に記号を多用すると、別環境での表示や検索に影響することがあります。
データ量が多くなる場合は、ファイルの分割方法も考える必要があります。すべての情報を一つのGeoJSONにまとめると、最初は管理しやすく見えますが、更新や読み込みに時間がかかることがあります。現場別、区域別、対象種別、更新頻度別に分けることで、必要なデータだけを扱いやすくなります。ただし、分けすぎると全体像が見えにくくなるため、運用しやすい単位を決めることが大切です。
品質確認の手順も決めておくと安心です。代表点が想定位置に表示されるか、座標順に誤りがないか、面が閉じているか、属性の必須項目が入っているか、重複する管理番号がないか、古いデータが混在していないか、といった確認を行います。これらを毎回担当者の経験に任せるのではなく、チェック項目として標準化しておくと、データ品質を保ちやすくなります。
GeoJSONは扱いやすい形式ですが、自由度が高いからこそ、組織や現場ごとのルールが必要です。座標、属性、ファイル名、更新履歴、共有方法、確認手順をそろえることで、単発の地図データではなく、継続的に使える位置情報データとして活用できます。
まとめ：GeoJSONは現場座標を活用する入口になる
GeoJSONは、座標データを地図上で扱いやすくする便利な形式です。しかし、正しく使うためには、単にファイルを作るだけでは不十分です。経度と緯度の順番、測地系や座標系の前提、点・線・面のジオメトリ構造、座標精度、丸め処理、属性情報、ファイル運用まで含めて考える必要があります。これらを押さえることで、GeoJSONは現場の位置情報を共有し、確認し、管理するための実用的なデータになります。
最初に注意すべきなのは、GeoJSONを座標だけの入れ物として見ないことです。座標は、対象物の意味や属性と結びついて初めて実務で使える情報になります。点検箇所、施工範囲、設備位置、写真撮影地点など、何を管理するための座標なのかを明確にし、必要な属性を整理することが大切です。
次に、経度と緯度の順番を間違えないことが基本です。GeoJSONでは経度、緯度の順で座標を扱います。日常的な「緯度・経度」という言い方に引っ張られて順番を逆にすると、地図上の位置が大きくずれる原因になります。高さを含める場合も、その高さが何を基準にしたものかを明確にしておく必要があります。
測地系や座標系の前提も重要です。設計図面や測量成果で使われるメートル単位の座標を、そのまま標準的なGeoJSONの経度・緯度として使うことはできません。元データの座標系を確認し、必要に応じて変換し、変換後には代表点で位置を確認することが大切です。複数のデータを重ねる場合は、それぞれの前提がそろっているかを必ず確認するべきです。
ジオメトリの選択では、点、線、面のどれで対象を表すべきかを考えます。位置だけを示すなら点、経路や線形を示すなら線、範囲を示すなら面が向いています。対象物の性質と後工程での使い方を考えずに形状を選ぶと、検索、集計、距離確認、面積確認などで不便が生じます。GeoJSONを作る段階で、使い方に合った構造にしておくことが重要です。
座標精度と丸め処理では、見やすさと実用精度を分けて考える必要があります。表示用に桁数を減らすことと、元データを丸めて保存することは別です。不要な桁を残しすぎる必要はありませんが、必要な精度まで削ってしまうと、後工程で位置ずれや形状崩れが起こります。座標の取得方法、期待精度、使用目的を踏まえて、適切に管理することが大切です。
属性情報とファイル運用では、項目名、入力ルール、ファイル名、更新履歴、共有時の説明、品質確認の手順を整える必要があります。GeoJSONは自由に作れる反面、ルールがないと担当者ごとに形式がばらつき、継続的な活用が難しくなります。現場で使えるデータにするためには、作成時だけでなく、更新と共有まで見据えた運用が欠かせません。
GeoJSONは、現場の座標データを扱うための入口として有用です。地図上で位置を確認するだけでなく、写真、点検記録、施工範囲、設備台帳、測量成果などと組み合わせることで、現場情報をより立体的に管理できます。一方で、精度や座標の前提を誤ると、便利なはずのデータが判断ミスの原因になることもあります。
現場で取得した位置情報をより正確に活用したい場合は、GeoJSONの作成ルールだけでなく、座標を取得する段階の精度にも目を向ける必要があります。高精度な位置取得、座標変換の検証、属性情報の整備、共有前の品質確認を組み合わせれば、GeoJSONは単なる地図データではなく、施工管理や維持管理に使える実務データになります。まずは小さな範囲でルールを決め、座標の前提を確認しながら運用を始めることが、安全なGeoJSON活用につながります。