GeoJSONを使い始めたときに混乱しやすいのが、「GeoJSONはJSONの一種なのか」「普通のJSONと何が違うのか」という点です。どちらも波括弧や角括弧を使ってデータを表すため、見た目はよく似ています。しかし、実務で地図表示、現地調査、道路・施設管理、点検記録、位置情報付きデータの共有を行う場合、この違いをあいまいにしたまま扱うと、座標の順序、属性の持たせ方、データの読み込み可否、地図上での位置ずれなどにつながることがあります。
この記事では、「geojson 使い方」を調べている実務担当者に向けて、JSONとGeoJSONの違いを5つのポイントで整理します。プログラム開発者だけでなく、測量成果、現地写真、設備台帳、点検結果、災害調査記録などを扱う人にも分かるように、データ構造と運用上の注意点を実務目線で解説します。
JSONは汎用データ形式でありGeoJSONは地理情報用の形式である
JSONは、文字列、数値、真偽値、配列、オブジェクトなどを組み合わせてデータを表現する汎用的な形式です。業務システムの設定情報、一覧データ、帳票の元データ、通信時の受け渡しデータなど、さまざまな場面で使われます。たとえば、点検者名、日付、施設番号、判定結果、備考欄のような情報を整理して保存するだけであれば、通常のJSONで十分に表現できます。
一方、GeoJSONはJSONの書き方を土台にしながら、地理情報を扱うための構造を定めた形式です。つまり、GeoJSONはJSONとまったく別の記法ではありません。JSONとして読める形を保ちながら、点、線、面といった地図上の形状を表すためのルールを追加したものと考えると理解しやすくなります。
通常のJSONでは、座標をどの項目名で持たせるか、緯度と経度をどちらの順番で書くか、複数の点をどう並べるか、属性情報をどこに入れるかを作成者が自由に決められます。この自由さは便利ですが、地図表示や他システムとの連携では弱点にもなります。受け取る側が「この数値は座標なのか」「どちらが緯度なのか」「線として扱うべきなのか、単なる数値の一覧なのか」を判断できないからです。
GeoJSONでは、このあいまいさを減らすために、地理情報として必要な要素の名前や階層が決められています。たとえば、データ全体が複数の地物を含む場合はFeatureCollection、個別の地物はFeature、位置や形状はgeometry、属性情報はpropertiesというように、役割ごとに入れる場所が整理されています。この構造に従うことで、地図を扱う一般的な処理系が「これは点のデータである」「これは線のデータである」「これは面のデータである」と判別しやすくなります。
実務では、JSONとGeoJSONの違いを「見た目が似ているかどうか」ではなく、「地図上の位置や形状を共通ルールで表せるかどうか」で考えることが重要です。単にデータを保存するだけならJSONでも足りますが、地図に重ねる、現地の位置を共有する、設備や調査地点を図面や地図と連携する、範囲や経路を表示する、といった用途ではGeoJSONの構造に合わせるほうが扱いやすくなります。
たとえば、ある点検結果をJSONで管理する場合、「場所」という項目に住所を入れるだけでも成立します。しかし、地図上で該当地点を表示したい場合は、住所だけでは位置が確定しないことがあります。表記ゆれ、地番と住居表示の違い、施設範囲の広さなどによって、同じ住所でも現地で確認したい場所がずれる場合があるためです。GeoJSONであれば、点の座標をgeometryとして持たせ、点検結果や管理番号をpropertiesに入れることで、位置と属性を一体で扱えます。
また、通常のJSONで座標を扱う場合、作成者が「lat」「lon」「x」「y」「latitude」「longitude」など自由に項目名を決められます。社内だけで使う小さなデータであれば問題にならないこともありますが、別部署、委託先、発注者、維持管理担当、解析担当などが同じデータを使う場合、項目名の違いが読み替えミスにつながります。GeoJSONの構造に合わせておけば、少なくとも地理形状を表す部分については共通の理解を持ちやすくなります。
JSONは自由度が高い形式であり、GeoJSONは地理情報を扱うために自由度を一定のルールで整理した形式です。どちらが優れているというより、目的が違います。業務情報を柔軟に持たせたい場合はJSONの考え方が役立ちます。地図上で点、線、面を正しく扱いたい場合はGeoJSONの考え方が役立ちます。この最初の違いを押さえておくと、GeoJSONの使い方を学ぶときに、なぜFeatureやgeometryといった決まった名前が必要なのかが理解しやすくなります。
GeoJSONでは地物の形をgeometryとして決められた型で表す
GeoJSONの大きな特徴は、地図上の形をgeometryとして明確に表すことです。JSONでは、座標の配列をどのように置いても文法上は成立します。しかし、GeoJSONでは、その座標の集まりが点なのか、線なのか、面なのかをtypeで示し、それに対応するcoordinatesを持たせます。
現地調査や台帳管理でよく登場する形状には、点、線、面があります。点は、標識、マンホール、電柱、調査地点、写真撮影位置、基準点のように、地図上の一点で表したい対象に向いています。線は、道路中心線、水路、配管、巡回経路、調査ルートのように、連続する位置を結んで表す対象に向いています。面は、敷地、区域、工区、浸水範囲、管理範囲、点検対象エリアのように、囲まれた範囲を表す対象に向いています。
通常のJSONでこれらを扱う場合、たとえば「points」という配列に座標を並べても、それが線を表すのか、複数の独立した点を表すのかは、データを読む側が仕様書や説明文を見なければ分かりません。GeoJSONでは、Point、LineString、Polygonのような型を使って、座標の意味を明示します。これにより、同じ数値の並びであっても、地図上でどのように描画すべきかを判断しやすくなります。
ここで重要なのは、GeoJSONでは「座標が入っていれば何でもよい」というわけではないことです。Pointであれば一つの座標、LineStringであれば複数の座標を順番に並べた線、Polygonであれば閉じた輪郭を表す座標列というように、型ごとに期待される構造があります。見た目はJSONの配列でも、その配列の深さや並び方には意味があります。
実務でよくあるミスは、点群のような複数地点データと、線や面のデータを混同することです。複数の調査地点をまとめて扱いたい場合、それぞれを独立したPointのFeatureとして持たせるのが自然です。一方、道路に沿った調査経路を表したい場合は、複数の座標をLineStringとして並べる考え方になります。見た目にはどちらも座標の集合ですが、地図上の意味は異なります。
また、面を扱う場合は、外周を囲む座標列が正しく閉じているかを確認する必要があります。Polygonの線形リングでは、最初の位置と最後の位置を同じにして閉じる必要があります。範囲を表しているつもりでも、始点と終点の扱いが不十分だったり、点の順序が乱れていたりすると、意図しない形で表示されることがあります。通常のJSONであれば単なる配列の不備として見過ごされやすい部分ですが、GeoJSONでは地図上の形状として解釈されるため、現地範囲や管理区域の誤認につながるおそれがあります。
GeoJSONのgeometryを理解するうえでは、地物という考え方も大切です。地物とは、地図上で位置や形を持つ対象のことです。設備、道路、敷地、調査地点、災害箇所、点検範囲など、現実世界の対象をデータとして扱う単位だと考えるとよいです。GeoJSONでは、その地物の形をgeometryで表し、その地物の説明や管理情報をpropertiesで表します。
JSONでは、位置情報と説明情報を同じ階層に自由に並べることができます。たとえば、管理番号、緯度、経度、点検日、判定、備考を同じオブジェクトの中に置くこともできます。人間が読むだけなら分かりやすい場合もありますが、地図に読み込ませる場合は、どれが形状でどれが属性なのかが分かりにくくなります。GeoJSONではgeometryとpropertiesを分けることで、地図表示に必要な部分と、台帳や検索に使う部分を整理できます。
この違いは、データの修正や検証にも影響します。通常のJSONでは、項目名や階層が案件ごとに変わることがあるため、チェック方法も個別対応になりがちです。GeoJSONでは、geometryのtypeとcoordinatesを中心に確認すれば、少なくとも位置や形状に関する基本的な検証を行いやすくなります。点のはずなのに線のような座標配列になっていないか、線のはずなのに座標が一つしかないか、面のはずなのに閉じた範囲になっていないか、といった確認がしやすくなります。
地図データを扱う実務では、形状の意味を曖昧にしないことが重要です。JSONは自由にデータを表せる便利な形式ですが、GeoJSONではその自由さの一部を地理情報向けの型に合わせることで、他の担当者や処理系が読み取りやすいデータになります。GeoJSONを使うときは、まず対象を点、線、面のどれとして扱うべきかを決め、そのうえでgeometryの型と座標配列を整えることが基本です。
GeoJSONでは属性情報をpropertiesに分けて管理する
GeoJSONとJSONの違いを理解するうえで、geometryと同じくらい重要なのがpropertiesです。propertiesは、地物に関する説明情報や業務情報を入れる場所です。たとえば、施設名、管理番号、点検日、調査者、写真番号、判定区分、路線名、工区名、備考などが該当します。地図上の形そのものではないけれど、現場管理や検索、集計、報告に必要な情報を入れる領域です。
通常のJSONでは、座標情報と属性情報を同じ階層に並べても問題ありません。しかしGeoJSONでは、地図上の形をgeometry、説明情報をpropertiesとして分けるのが基本です。この分け方を理解しておくと、データを地図表示に使うときだけでなく、あとから絞り込みや台帳連携を行うときにも扱いやすくなります。
たとえば、ある調査地点について、座標、地点名、異常の有無、写真ファイル名、確認日を持たせたいとします。GeoJSONでは、座標はgeometryに入れ、地点名や異常の有無などはpropertiesに入れます。こうすることで、地図表示の処理はgeometryを見ればよく、一覧表示や検索の処理はpropertiesを見ればよい、という役割分担ができます。これは小さなデータでは大きな差に見えないかもしれませんが、数百件、数千件の現地データを扱うときには効いてきます。
実務では、propertiesに入れる情報の粒度をそろえることも大切です。同じGeoJSONの中で、あるFeatureには「点検日」、別のFeatureには「確認日」、さらに別のFeatureには「調査年月日」という項目名を使ってしまうと、同じ意味の情報であっても集計や検索が難しくなります。JSONとしてはどれも正しい書き方ですが、運用データとしては扱いにくくなります。GeoJSONは形式としてpropertiesの中身まで業務ルール化してくれるわけではないため、現場や組織ごとに項目名のルールを決めておくことが重要です。
また、propertiesには業務上必要な情報を入れられるからこそ、位置情報と重複する項目の扱いには注意が必要です。たとえば、geometryに座標が入っているのに、propertiesにも緯度や経度を別項目として持たせるケースがあります。確認用や一覧表示用として必要な場合もありますが、両方の値が一致していないと、どちらが正しいのか判断できなくなります。特に、現地で修正した座標をgeometryだけ更新し、properties内の座標表示を更新し忘れると、地図上の位置と帳票上の数値が食い違うことがあります。
写真管理や現地調査では、propertiesに写真番号や撮影時刻、撮影方向、コメントなどを持たせることがあります。このときも、GeoJSONはあくまで位置と属性をまとめる形式であり、写真そのものを必ず中に埋め込む必要はありません。大量の写真データを直接入れようとすると、ファイルが大きくなり、読み込みや共有が重くなる場合があります。実務では、写真ファイル名、管理番号、保存先を示す識別情報などをpropertiesに持たせ、写真本体は別の仕組みで管理するほうが扱いやすいこともあります。
propertiesの設計では、後から何に使うかを想定することが重要です。地図に点を表示するだけなら、名称と分類があれば足りるかもしれません。しかし、点検結果の集計、未対応箇所の抽出、報告書作成、年度別管理、担当者別確認、現地写真との照合まで考えると、必要な項目は増えます。逆に、現場で入力しきれないほど項目を増やすと、空欄や表記ゆれが増え、データ品質が下がります。GeoJSONの使い方では、形式の正しさだけでなく、propertiesに何を入れるかという運用設計も欠かせません。
通常のJSONでは、業務に合わせて自由な階層を作れるため、複雑な情報を柔軟に表現できます。GeoJSONでもpropertiesの中に入れ子構造を持たせることはできますが、地図表示や一覧表示で扱うことを考えると、必要以上に複雑な構造は避けたほうが無難です。特に、複数の担当者が表計算形式に変換して確認したり、台帳データと突き合わせたりする場合は、単純で分かりやすい項目構成のほうがトラブルを減らせます。
属性情報の管理でよくあるもう一つの注意点は、数値と文字列の扱いです。管理番号や路線番号のように、見た目は数字でも先頭のゼロが意味を持つ項目は、数値として扱うと桁が変わることがあります。JSONでは数値と文字列を区別できますが、データ変換の過程で意図せず変わることがあります。GeoJSONのpropertiesに台帳番号や写真番号を入れる場合は、後工程での扱いも含めて型をそろえておく必要があります。
GeoJSONでは、地物の位置や形をgeometryに、業務上の説明をpropertiesに分けることで、地図表示と台帳管理をつなぎやすくなります。JSONの自由さをそのまま使うのではなく、地図データとしての読みやすさ、検索しやすさ、共有しやすさを意識して項目を整理することが、実務での使いやすさにつながります。
GeoJSONでは座標の順序と位置情報の扱いに注意が必要である
GeoJSONを使うときに最も注意したい点の一つが、座標の順序です。多くの現場資料や表計算データでは、緯度、経度の順に表記されることがあります。日常会話でも「緯度経度」という順番で呼ばれることが多いため、緯度を先、経度を後に置きたくなります。しかし、GeoJSONのcoordinatesでは、基本的に経度、緯度の順で座標を記述します。この順序を取り違えると、地図上でまったく違う場所に表示されることがあります。
日本国内のデータであれば、経度はおおむね三桁、緯度はおおむね二桁の数値になることが多いため、見た目で気づける場合もあります。しかし、自動変換や大量データ処理では、人が一件ずつ目視で確認できるとは限りません。座標の順序が逆になったままGeoJSONとして読み込まれると、海外や海上など、意図しない場所に点が飛ぶことがあります。地図上に何も表示されない、極端に縮尺を変えないと見つからない、範囲外のエラーになる、といった現象の原因になることもあります。
JSONでは、座標の順序は作成者が自由に決められます。latとlonという項目名を付ければ緯度と経度を明確に分けることもできます。ところが、GeoJSONではcoordinatesの配列内に数値を並べるため、項目名で緯度と経度を示すのではなく、順番そのものが意味を持ちます。ここが通常のJSONとの大きな違いです。
実務では、表計算で管理している緯度経度一覧をGeoJSONに変換する場面がよくあります。このとき、元データの列名が「緯度」「経度」の順で並んでいると、変換時にそのまま配列へ入れてしまい、GeoJSONとしては逆順になることがあります。変換処理を作る場合は、元の列順ではなく、GeoJSONのcoordinatesとして出力する順番を明確に指定する必要があります。
また、測量や設計で扱う平面直角座標系のような座標と、GeoJSONで一般的に使われる経度緯度の座標を混同しないことも重要です。GeoJSONでは、WGS84の経度緯度を前提に扱われることが多く、平面直角座標やローカル座標をそのまま入れても正しい地図位置になるとは限りません。現場で使う座標値には、緯度経度、平面座標、ローカル座標、図面上の座標など複数の種類があります。数値が座標らしく見えるからといって、そのままGeoJSONに入れれば正しく地図に載るとは限りません。
たとえば、工事現場のローカル座標でXとYを管理している場合、その数値を経度緯度のつもりでGeoJSONに入れても、地図上の正しい位置にはなりません。設計図面内では整合していても、地理座標としての位置を持っていない場合があるためです。地図上で表示するには、どの基準で作られた座標なのか、経度緯度へ変換済みなのか、変換条件は正しいのかを確認する必要があります。
高さ情報を扱う場合も注意が必要です。GeoJSONの座標には、経度、緯度に加えて高さに相当する値を含められる場合があります。ただし、すべての表示環境や処理が高さを同じように扱うとは限りません。高さを入れたつもりでも無視される場合や、二次元表示では見た目に反映されない場合があります。災害調査や施設点検で標高、路面高、構造物高さを管理したい場合は、geometry内の座標だけに頼るのではなく、propertiesにも測定条件や高さの種類を分かる形で持たせるなど、運用上の補足が必要になることがあります。
座標精度についても、GeoJSONとJSONの違いを意識する必要があります。JSONでは数値をそのまま持たせることができますが、実務では小数点以下の桁数、測位方法、補正の有無、入力時の丸め、変換時の丸めなどが精度に影響します。GeoJSONとして正しい構造であっても、元の座標が粗ければ現地位置とはずれます。逆に、必要以上に桁数だけ多くても、実際の測位精度が高いとは限りません。位置情報を扱うときは、データ形式の正しさと測位精度の妥当性を分けて考える必要があります。
GeoJSONの座標を確認するときは、地図上に表示できるかどうかだけでなく、現場で期待する位置にあるかを確認することが大切です。特に、道路、河川、境界、施設、災害箇所などのデータでは、数メートルのずれが判断に影響することがあります。地図上に点が出たから正しいと考えるのではなく、背景地図、台帳、現地写真、測量成果、調査メモなどと照合し、目的に対して許容できる位置かを確認する必要があります。
通常のJSONであれば、座標らしき数値を単なる属性として扱うこともできます。しかしGeoJSONでは、その数値が地図上の形状として解釈されます。だからこそ、座標の順序、座標の種類、変換条件、精度、表示時の解釈を慎重に確認する必要があります。GeoJSONの使い方でつまずく原因の多くは、文法エラーよりも、座標の意味を取り違えることにあります。
JSONとGeoJSONの違いを理解すると現地データ活用が安定する
JSONとGeoJSONの違いを理解すると、現地データの作成、共有、確認、修正の流れが安定します。特に、現場で取得した位置情報を後から地図や台帳で使う業務では、最初にどの形式で整理するかが後工程の手間に直結します。
通常のJSONは、柔軟なデータ受け渡しに向いています。入力フォームの結果、点検記録、機器設定、集計条件、帳票用データなど、地図表示を前提としない情報を扱う場合に便利です。項目名や階層を業務に合わせて設計しやすく、複雑な情報も表現できます。一方で、地図上の形状を他者と共有する場合は、項目の意味を別途説明しなければならないことがあります。
GeoJSONは、地理情報として共有することを前提にした形式です。点、線、面の形状を共通の構造で表し、属性情報をpropertiesにまとめるため、地図表示や空間的な確認に向いています。道路沿いの点検結果を地図に重ねる、災害調査で撮影地点を一覧化する、施設台帳に位置情報を付ける、範囲データを関係者に共有する、といった場面では、GeoJSONの構造が役立ちます。
この違いを理解していないと、データ作成時に中途半端な形式になりがちです。たとえば、JSONの中に座標らしき配列はあるものの、GeoJSONとして必要なtypeやgeometryがないため、地図に直接読み込めないということがあります。逆に、GeoJSONとして作ったつもりでも、属性情報がgeometry側に混ざっていたり、coordinatesの階層が合っていなかったりすると、処理でエラーになることがあります。
現場で扱いやすいGeoJSONを作るには、最初に利用目的を決めることが重要です。単に記録として残すだけなのか、地図に表示するのか、現地写真と結び付けるのか、設備台帳と連携するのか、報告書や検査資料に使うのかによって、必要なpropertiesや座標精度が変わります。GeoJSONは便利な形式ですが、目的を決めずに項目を増やすと、後から整理しにくいデータになります。
また、GeoJSONは共有しやすい形式である一方、個人情報や管理上注意が必要な情報を含める場合には配慮が必要です。位置情報は、それ自体が重要な情報になることがあります。個人宅に近い調査地点、設備の詳細位置、災害時の被害箇所、管理施設の位置などは、公開範囲や共有先を確認しなければなりません。JSONでも同じ注意は必要ですが、GeoJSONは地図上で位置が分かりやすくなるため、共有前の確認がより重要です。
データの更新管理にも違いが出ます。通常のJSONでは、業務項目の更新が中心になることが多いですが、GeoJSONでは位置や形状の更新も重要です。点検結果だけを更新したのか、位置も修正したのか、面の範囲を変えたのか、線の経路を直したのかが分かるようにしておかないと、過去データとの比較が難しくなります。propertiesに更新日や更新理由を持たせる、ファイル名や管理番号のルールをそろえる、変更前後のデータを区別するなど、運用上の工夫が必要です。
現地データでは、手入力、測位、写真撮影、図面からの変換、既存台帳からの取り込みなど、さまざまな経路で情報が集まります。そのため、GeoJSONとして整える前に、元データの性質を確認することが欠かせません。手入力の住所から座標化した点と、現地で取得した座標では、信頼性や使える用途が異なります。図面から変換した範囲と、現地測量で確認した範囲も同じではありません。GeoJSONの形式に入れると見た目は同じ地図データになりますが、元データの取得方法によって判断できる内容は変わります。
この点を補うために、propertiesには取得方法や確認状況を入れておくと便利です。たとえば、現地確認済み、机上整理、既存資料からの転記、概略位置、要再確認などの区分を持たせると、地図上で見たときに信頼度を判断しやすくなります。GeoJSONはgeometryで場所を示すだけでなく、propertiesを使って業務上の判断材料を添えることで、より実務向きのデータになります。
JSONとGeoJSONの違いを理解することは、単なる形式の知識ではありません。現場で集めた情報を、あとで誰が見ても分かる形に整えるための基礎です。GeoJSONを使えば、地図上の位置と業務情報を一体化できます。ただし、そのためには座標の順序、geometryの型、propertiesの設計、元データの精度、共有範囲を意識する必要があります。これらを押さえることで、現地データの再利用性が高まり、確認作業や手戻りを減らしやすくなります。
まとめ
GeoJSONとJSONは、見た目が似ているため混同されやすい形式です。JSONはさまざまなデータを自由に表現できる汎用形式であり、GeoJSONはそのJSONの書き方を使いながら、地図上の点、線、面を扱うための構造を定めた形式です。GeoJSONはJSONの一種として理解できますが、地理情報を扱うための約束事がある点が大きな違いです。
実務で重要なのは、GeoJSONを単なる座標入りJSONとして扱わないことです。地図上の形はgeometryに入れ、点、線、面などの型を明確にします。業務上の説明や台帳項目はpropertiesに入れ、位置情報と属性情報を分けて管理します。さらに、coordinatesでは座標の順序に注意し、経度と緯度の取り違え、座標系の混同、ローカル座標の誤用、変換時の丸めや精度の過信を避ける必要があります。
GeoJSONの使い方を安定させるには、データを作る前に目的を決めることが大切です。地図に表示するだけなのか、現地写真と結び付けるのか、点検台帳として使うのか、報告書や検査資料に活用するのかによって、必要な属性や精度は変わります。形式として正しいだけでなく、現場で判断に使える情報になっているかを確認することが、実務では欠かせません。
JSONは自由度が高く、GeoJSONは地理情報としての共通性を持っています。この違いを理解して使い分けることで、データの受け渡し、地図表示、現地確認、台帳連携がスムーズになります。特に、写真の撮影地点、点検箇所、災害調査位置、道路や施設の管理範囲などを扱う場合は、GeoJSONの考え方を取り入れることで、位置と記録を結び付けやすくなります。
現場で位置情報を扱うなら、データ形式の理解に加えて、取得した座標をどのように記録し、確認し、共有するかも重要です。紙のメモや表計算だけでは、撮影場所や確認地点の再現に手間がかかることがあります。位置情報付きの記録を現場から効率よく残すには、座標の取得方法、写真や台帳とのひも付け方、共有範囲、更新履歴をあらかじめ整理しておくことが大切です。こうした運用を整えることで、GeoJSONや地図データを現地確認、報告、維持管理に活用しやすくなります。