GeoJSONとJSONの違いを初心者向けに整理する5項目

GeoJSONは、地図上の点や線、範囲などを扱うために使われるデータ形式です。一方でJSONは、さまざまな情報をやり取りするための汎用的なデータ形式です。どちらも見た目は似ていますが、役割や使い方、データの読み方には違いがあります。実務で「geojson」と検索する方の多くは、地図データを扱う必要が出てきた段階で、JSONとの違いや座標の見方につまずきやすいです。この記事では、GeoJSONとJSONの違いを初心者向けに5つの項目で整理し、現場や業務で迷いやすいポイントを分かりやすく解説します。

目次

• GeoJSONとJSONの基本的な役割の違い

• GeoJSONが地図データを表現できる理由

• JSONとGeoJSONの構造で見る具体的な違い

• 実務でGeoJSONを扱うときに注意したい座標と属性

• GeoJSONを現場データ活用につなげる考え方

GeoJSONとJSONの基本的な役割の違い

JSONは、文字列、数値、真偽値、配列、オブジェクトなどを組み合わせて情報を表すための汎用的なデータ形式です。人が読んでも比較的分かりやすく、機械でも扱いやすいため、設定情報、顧客情報、商品情報、センサー値、アプリ間のデータ連携など、幅広い場面で使われます。JSONそのものは、特定の業界や用途に限定された形式ではありません。つまり、住所録にも使えますし、測定記録にも使えますし、機器の設定ファイルにも使えます。

一方、GeoJSONは、JSONの書き方をもとにしながら、地理空間情報を表すための決まりを追加した形式です。ここでいう地理空間情報とは、地図上の位置、線、範囲、複数の図形、図形に紐づく属性情報などを指します。たとえば、ある点検場所の位置、道路の中心線、敷地境界、調査範囲、設備の配置などをデータとして表すときにGeoJSONが使われます。

初心者が最初に押さえるべき違いは、JSONは「さまざまな情報を表せる汎用的な形式」であり、GeoJSONは「地図情報を表すための決まった形を持つJSON形式」だという点です。JSONは自由度が高い反面、どの項目に何を入れるかは作成者次第です。そのため、同じ位置情報を扱う場合でも、あるデータでは緯度を「lat」と書き、別のデータでは「latitude」と書き、さらに別のデータでは「y」と書くことがあります。これは柔軟で便利ですが、受け取る側が毎回項目名や意味を確認しなければならないという弱点にもなります。

GeoJSONでは、地図上の形を表すために「type」「geometry」「coordinates」「properties」などの基本的な項目が使われます。これにより、データを受け取る側は「この部分は図形の種類を示している」「この部分は座標を示している」「この部分は属性情報を示している」と判断しやすくなります。つまり、GeoJSONはJSONの一種と考えることができますが、単なるJSONではなく、地理空間情報を扱うためのルールを持ったJSONです。

実務では、この違いを理解していないと、GeoJSONファイルを開いたときに「JSONと同じように見えるのに、なぜ地図で表示できるのか」が分かりにくくなります。逆に、GeoJSONの考え方を理解しておくと、地図表示、現地調査、測量データ、設備管理、写真位置情報、点検記録などをつなげて考えやすくなります。

JSONは情報の整理に使える汎用形式であり、GeoJSONはその中でも地図に載せる情報を整理するための形式です。この関係を押さえておくと、両者の違いを無理なく理解できます。

GeoJSONが地図データを表現できる理由

GeoJSONが地図データとして使える理由は、地図上の形を表すための種類と、座標の並び方が決められているからです。JSONだけでは、座標らしき数値を入れることはできますが、それが点なのか、線なのか、面なのかまでは自動的には分かりません。GeoJSONでは、この問題を解決するために、図形の種類を「type」で示し、実際の座標を「coordinates」で表します。

たとえば、1つの地点を表す場合は、点を意味する種類を指定し、その座標を入れます。道路や配管ルートのように連続した線を表す場合は、複数の座標を順番に並べて線として扱います。敷地や区域のように面を表す場合は、範囲を囲むように座標を並べます。このように、GeoJSONでは、同じ座標でも図形の種類によって意味が変わります。

地図データでは、位置だけでなく形が重要です。点であれば「どこにあるか」が中心になりますが、線であれば「どこからどこまで続いているか」が重要になります。面であれば「どの範囲を囲っているか」が重要です。GeoJSONは、このような地図特有の考え方をJSONの中で表現できるようにした形式です。

GeoJSONでよく使われる図形には、Point、MultiPoint、LineString、MultiLineString、Polygon、MultiPolygon、GeometryCollectionなどがあります。また、図形と属性を組み合わせたFeature、複数のFeatureをまとめるFeatureCollectionもよく使われます。初心者の段階では、すべてを一度に覚える必要はありません。まずは、点は設備や写真位置、線は道路やルート、面は敷地や調査範囲を表すものだと考えると理解しやすくなります。

通常のJSONでも、次のように緯度経度を持つデータを書くことはできます。

`json { "name": "点検地点A", "latitude": 35.000000, "longitude": 139.000000 } `

このデータは人が見れば位置情報だと分かります。しかし、機械側から見ると、「latitude」と「longitude」という項目が必ず座標であるとは限りません。また、点として扱うのか、単なる数値として扱うのかも、別のルールや処理が必要になります。

GeoJSONでは、次のように図形の種類と座標を決まった形で表します。

`json { "type": "Feature", "geometry": { "type": "Point", "coordinates": [139.000000, 35.000000] }, "properties": { "name": "点検地点A" } } `

このように書かれていれば、これは「点の地図データ」であり、座標は「coordinates」に入っていて、名称などの属性は「properties」に入っていると判断できます。ここがGeoJSONの大きな特徴です。データの意味が形式によって整理されているため、地図表示や空間解析に使いやすくなります。

注意したいのは、GeoJSONの座標は原則として経度、緯度の順で書く点です。日本語の会話や住所情報では「緯度経度」と言うことが多いため、緯度を先に書きたくなります。しかしGeoJSONでは、座標配列の最初に経度、次に緯度を入れるのが基本です。この順番を間違えると、地図上でまったく違う場所に表示される原因になります。

GeoJSONが地図データとして扱えるのは、単に座標を持っているからではありません。点、線、面といった地図上の形を明確にし、座標の入り方を決め、属性情報と分けて管理できるからです。これにより、現地調査データ、設備位置、境界線、点検範囲などを地図上で扱いやすくなります。

JSONとGeoJSONの構造で見る具体的な違い

JSONとGeoJSONの違いを理解するには、構造の自由度に注目すると分かりやすいです。JSONは自由な形式で情報を記述できます。項目名も階層も、作成者が目的に合わせて決められます。たとえば、点検結果をJSONで表す場合、次のように書くことができます。

`json { "site": "調査地点A", "status": "確認済み", "lat": 35.000000, "lng": 139.000000, "memo": "異常なし" } `

この形式はシンプルで読みやすいですが、位置情報として扱うには、どの項目が緯度で、どの項目が経度なのかを事前に知っておく必要があります。さらに、「lat」と「lng」という項目名を別の形式に変えた場合、読み取る側の処理も変える必要があります。JSONでは、データの意味は項目名や仕様書、運用ルールに依存します。

GeoJSONでは、地図上に表示するための構造がより明確です。図形情報は「geometry」に入り、図形に関する種類は「type」に入り、座標は「coordinates」に入ります。名称、状態、メモ、管理番号などの業務情報は「properties」に入れます。この分け方があるため、地図として必要な情報と、業務上の補足情報を分離して扱いやすくなります。

たとえば、同じ点検地点をGeoJSONで表すと、次のようになります。

`json { "type": "Feature", "geometry": { "type": "Point", "coordinates": [139.000000, 35.000000] }, "properties": { "site": "調査地点A", "status": "確認済み", "memo": "異常なし" } } `

この構造では、「geometry」が地図上の形を示し、「properties」が業務情報を示しています。これにより、地図上には点として表示しながら、点を選んだときに点検結果やメモを確認する、といった使い方がしやすくなります。

複数の地点を扱う場合、GeoJSONでは「FeatureCollection」という形で複数の要素をまとめます。これにより、多数の点検地点や設備位置を1つのデータとして管理できます。

`json { "type": "FeatureCollection", "features": [ { "type": "Feature", "geometry": { "type": "Point", "coordinates": [139.000000, 35.000000] }, "properties": { "site": "調査地点A", "status": "確認済み" } }, { "type": "Feature", "geometry": { "type": "Point", "coordinates": [139.100000, 35.100000] }, "properties": { "site": "調査地点B", "status": "再確認" } } ] } `

JSONでも複数の地点を配列でまとめることはできます。しかし、その配列が地図上の要素の集合であることを示す標準的な決まりはありません。GeoJSONでは、「FeatureCollection」と「features」によって、複数の地物をまとめたデータであることが分かります。

この構造の違いは、データを受け渡すときに意味を持ちます。JSONだけで位置情報を管理している場合、受け取り側は「このJSONのどこに座標があるのか」「座標の順番はどうなっているのか」「これは点なのか線なのか面なのか」を確認する必要があります。GeoJSONであれば、一定のルールに沿って読み取れるため、データ連携時の認識違いを減らしやすくなります。

ただし、GeoJSONも万能ではありません。GeoJSON形式になっていても、座標が間違っていたり、属性名の付け方が現場で統一されていなかったりすれば、実務では混乱が起きます。GeoJSONは地図データの箱を整える形式であり、中身の正確性や運用ルールまで自動的に保証するものではありません。

JSONとGeoJSONの構造上の違いをまとめると、JSONは自由なデータ表現に向いており、GeoJSONは地図上の図形と属性を一定のルールで表すことに向いています。業務データを単に保存したいだけならJSONで足りる場合もありますが、地図表示や位置情報との連携を考えるならGeoJSONの形式にそろえる意味があります。

実務でGeoJSONを扱うときに注意したい座標と属性

実務でGeoJSONを扱うときに最も注意したいのは、座標の順番と座標参照の考え方です。GeoJSONでは、座標は原則として経度、緯度の順で記述します。ところが、現場や資料では「緯度、経度」の順で表現されることも多く、表計算データや写真情報から変換するときに順番を取り違えやすいです。このミスは見た目では分かりにくいものの、地図上では大きなズレとして現れます。

たとえば、日本国内の位置を表す場合、経度はおおむね東西方向の値、緯度は南北方向の値として扱われます。これを逆に入れると、想定した場所とはまったく異なる位置になります。GeoJSONを作成した後は、数値の形式だけでなく、実際に地図上で妥当な位置に表示されるかを確認することが大切です。

次に注意したいのは、高さ情報の扱いです。GeoJSONの座標には、経度と緯度に加えて高さに相当する値を含められます。ただし、高さの基準や意味はデータの作成方法や利用環境によって確認が必要です。現場の標高、機器が記録した高さ、設計上の高さ、補正後の高さなどは意味が異なります。高さを使う場合は、その値が何を基準にしたものかを属性情報や運用ルールで明確にしておく必要があります。

属性情報も、実務では非常に重要です。GeoJSONでは、図形そのものは「geometry」に入り、現場名、管理番号、点検結果、写真番号、測定日時、担当区分、異常の有無などは「properties」に入れるのが一般的です。このとき、属性名の付け方を場当たり的に決めると、後から検索や集計を行う際に困ります。

たとえば、同じ意味の項目に対して「status」「状態」「result」「判定」などが混在していると、データをまとめるときに変換作業が必要になります。また、日付の書き方が統一されていない場合や、管理番号の桁数がそろっていない場合も、照合ミスの原因になります。GeoJSONは地図上で表示できる形式ですが、業務データとして使うには属性情報の統一が欠かせません。

線や面のデータでは、座標の並び順にも注意が必要です。線は座標が並んだ順番に結ばれるため、順番が崩れると意図しない線になります。面では、範囲を囲むように座標を並べる必要があります。さらに、GeoJSONのPolygonでは外周や穴を座標の配列で表すため、点データよりも確認すべきことが増えます。初心者が最初にGeoJSONを扱う場合は、点データから始め、次に線、最後に面へ進むと理解しやすいです。

また、GeoJSONはテキスト形式なので、見た目では少しの記述ミスも気づきにくいことがあります。カンマの抜け、括弧の閉じ忘れ、文字列の引用符の不足、配列の階層間違いなどがあると、データとして読み込めない場合があります。JSONとして正しい文法であることと、GeoJSONとして正しい構造であることは分けて確認する必要があります。

さらに、ファイルの容量にも注意が必要です。点や線が少ないうちは問題になりにくいですが、広い範囲の境界データや細かい線形データを扱うと、GeoJSONファイルが大きくなることがあります。ファイルが大きくなると、読み込みや表示に時間がかかる場合があります。必要以上に細かい座標を含めない、用途に応じて範囲を分ける、属性項目を整理するなどの工夫が必要です。

実務でGeoJSONを扱う際は、形式が正しいかだけでなく、位置が正しいか、属性が使いやすいか、現場で意味が通じるかを確認することが大切です。地図に表示できたから完成ではなく、業務判断に使える状態になっているかまで確認することで、データの価値が高まります。

GeoJSONを現場データ活用につなげる考え方

GeoJSONとJSONの違いを理解する目的は、形式の知識を増やすことだけではありません。実務では、現場で取得した位置情報や点検結果を、後から見直しやすく、共有しやすく、判断に使いやすい形にすることが重要です。そのための形式として、GeoJSONは有効な選択肢になります。

たとえば、現地調査で取得した点検地点をGeoJSONとして整理しておけば、地図上で位置を確認しながら、各地点の状態やメモを確認できます。写真の位置情報、設備番号、点検結果、補修の要否などを属性として持たせれば、単なる点の集合ではなく、業務に使える地図データになります。JSONだけでも同じ情報を保存することはできますが、GeoJSONにすることで「地図上のどこにある情報か」を扱いやすくなります。

また、GeoJSONは担当者間の認識合わせにも役立ちます。現場では、住所や文章だけで場所を説明すると、細かな位置のずれが起きることがあります。特に、広い敷地、山間部、造成地、道路沿い、太陽光発電設備、仮設エリアなどでは、住所だけでは位置を特定しにくい場合があります。GeoJSONとして点や範囲を共有できれば、どの場所について話しているのかを明確にしやすくなります。

GeoJSONを使うときは、最初から複雑な仕組みを作る必要はありません。まずは、現場で管理したい対象を点として整理するだけでも十分です。設備位置、撮影地点、点検箇所、異常箇所、基準点、出入口、危険箇所など、地図上に置ける情報は多くあります。これらをGeoJSONとしてまとめることで、紙の図面や口頭説明だけでは見えにくかった情報を整理できます。

次の段階では、線や面の情報を加えると活用範囲が広がります。線であれば、道路、通路、ケーブルルート、排水経路、調査ルートなどを表せます。面であれば、敷地範囲、点検対象範囲、施工範囲、立入制限範囲、草刈り範囲などを表せます。点、線、面を組み合わせることで、現場の状況をより整理して把握できます。

ただし、GeoJSONを実務に活用するには、データ作成時のルール化が欠かせません。どの属性を必須にするのか、名称の付け方をどうするのか、座標の取得方法をどうするのか、更新履歴をどう残すのか、古いデータと新しいデータをどう区別するのかを決めておく必要があります。形式だけをGeoJSONにしても、運用ルールがなければデータの信頼性は高まりません。

初心者がGeoJSONを学ぶときは、まずJSONとの関係を理解し、次に点データの構造を確認し、その後に線や面へ進むのがよい流れです。いきなり複雑な境界データや大量の属性を扱うと、座標の階層やデータ構造で混乱しやすくなります。小さなデータで構造を確認し、実際に地図上で表示しながら理解することで、実務に応用しやすくなります。

GeoJSONは、専門的な地理情報のためだけの形式ではありません。現場で取得した位置付きの情報を、後から使える形に整えるための実用的な形式です。JSONとの違いを理解しておけば、単なるデータの保存ではなく、地図を軸にした情報整理へ発展させることができます。

まとめ

GeoJSONとJSONの違いを初心者向けに整理すると、JSONはさまざまな情報を表すための汎用的な形式であり、GeoJSONはそのJSONをもとに地図上の点、線、面、属性情報を扱えるようにした形式です。見た目はどちらも波括弧や配列を使うため似ていますが、役割は異なります。

JSONは自由度が高く、目的に合わせて項目名や構造を決められます。そのため、業務データや設定情報を柔軟に表せます。一方で、位置情報を地図データとして扱うには、項目の意味や座標の順番を別途決める必要があります。GeoJSONは、図形の種類、座標、属性情報を決まった構造で表すため、地図表示や位置情報の共有に向いています。

実務で特に注意したいのは、GeoJSONの座標順、属性名の統一、点・線・面の違い、データ量、現場での意味づけです。GeoJSONとして正しい形になっていても、座標の順番を間違えたり、属性がばらばらだったりすると、業務では使いにくいデータになります。形式の理解と同時に、運用ルールを整えることが大切です。

GeoJSONは、現地調査、設備管理、写真位置情報、点検記録、範囲管理など、位置と業務情報を結びつけたい場面で役立ちます。まずは小さな点データから始め、座標と属性の関係を確認しながら、線や面のデータへ広げていくと理解しやすくなります。

現場で取得した位置情報をより正確に扱い、地図データとして整理したい場合は、取得方法や補正方法まで含めて考えることが重要です。特定の製品やサービスに限定せず、利用する機器、アプリ、測位方法、データ変換手順を確認しながら、GeoJSONなどの位置情報データ活用へつなげると、記録、確認、共有までの流れを整理しやすくなります。