GeoJSONの使い方を初心者向けに解説する7つの基本

GeoJSONは、地図上の点、線、面などの位置情報を扱うためのデータ形式です。名前のとおりJSONを基礎にしているため、人が読んでも構造を理解しやすく、システム間で地理空間データを受け渡すときにも使いやすい形式です。この記事では、「geojson 使い方」で調べている実務担当者に向けて、GeoJSONを扱う前に押さえておきたい基本を、できるだけ専門用語をかみ砕いて整理します。

目次

• GeoJSONとは何かを理解する

• GeoJSONで表せる地物の種類を知る

• 座標の並び順と座標参照の考え方を押さえる

• Featureとpropertiesの役割を分けて考える

• 点・線・面データの使い分けを理解する

• 実務でGeoJSONを作成・確認するときの注意点を押さえる

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

• まとめ

GeoJSONとは何かを理解する

GeoJSONは、地図上の位置や形状をJSON形式で表現するためのデータ形式です。通常のJSONが文字列、数値、配列、オブジェクトなどを組み合わせてデータを表すのに対し、GeoJSONでは地図上の点、線、面、複数の形状、属性情報などを一定のルールに沿って記述します。たとえば、建物の位置、道路の中心線、敷地境界、調査地点、点検箇所、工事範囲などをデータとして管理したい場合に利用できます。

初心者が最初に理解しておきたいのは、GeoJSONは地図そのものではなく、地図上に表示するための位置情報データであるという点です。背景地図や航空写真のような見た目を持つ画像データではなく、「この場所に点を置く」「この経路に線を引く」「この範囲を面として囲む」といった情報を、機械が読み取れる形で記述するためのものです。そのため、GeoJSONファイルを単体で開いても、文章や記号の集まりに見えることがあります。しかし、対応する地図表示環境や業務システムに読み込ませることで、点や線や面として視覚的に確認できるようになります。

GeoJSONが実務で使いやすい理由の一つは、構造が比較的シンプルであることです。専門的な地理情報システムで使われるデータ形式には、複数のファイルを組み合わせて扱うものや、座標系、属性定義、図形情報が分かれて管理されるものもあります。それらに比べると、GeoJSONは一つのファイル内に形状と属性をまとめやすく、メール添付、システム連携、データ確認、試験的な地図表示などに向いています。

一方で、GeoJSONは万能ではありません。大量の点群や非常に複雑な面形状をそのまま詰め込むと、ファイルサイズが大きくなり、表示や処理が重くなることがあります。また、座標の意味や精度、作成元データの品質を理解せずに使うと、地図上で位置がずれる、面が崩れる、意図しない場所に表示されるといった問題が起きます。つまり、GeoJSONの使い方を覚えるうえでは、書式だけでなく、地図データとして何を表しているのかを確認する姿勢が重要です。

実務担当者にとっては、GeoJSONをプログラムの専門家だけが扱う形式と考える必要はありません。点検結果を地図に重ねたい、現地調査地点を関係者に共有したい、台帳情報と位置情報を結び付けたい、工事範囲を簡単に可視化したいといった場面で、GeoJSONは実用的な選択肢になります。まずは「図形情報」と「属性情報」を一つのデータとして持てる形式だと理解すると、全体像をつかみやすくなります。

GeoJSONで表せる地物の種類を知る

GeoJSONでは、地図上にある対象物をいくつかの基本的な形状で表します。代表的なものは、点、線、面です。点は調査地点、標識、マンホール、設備、撮影地点、基準点など、一つの位置で表せるものに向いています。線は道路、河川、管路、境界線、歩行ルート、施工ラインなど、複数の座標をつないで表すものに向いています。面は敷地、建物外形、工区、区域、農地、災害範囲など、閉じた範囲として表現したいものに向いています。

GeoJSONでは、形状の種類をtypeという項目で示します。点であればPoint、線であればLineString、面であればPolygonのように記述します。複数の点をまとめて扱う場合はMultiPoint、複数の線をまとめる場合はMultiLineString、複数の面をまとめる場合はMultiPolygonという形があります。さらに、複数の地物をまとめたデータ全体をFeatureCollectionとして扱うことが多いです。

初心者が混乱しやすいのは、図形だけを表すGeometryと、実務上の対象物を表すFeatureの違いです。Geometryは、点や線や面といった形そのものを表します。Featureは、そのGeometryに名前、管理番号、分類、調査日、状態、担当者、備考などの属性を付けたものです。たとえば、あるマンホールの座標だけを示すなら点のGeometryですが、「管理番号Aのマンホールで、材質はコンクリート、点検日は何月何日、状態は良好」という情報まで含めるならFeatureとして扱うのが自然です。

GeoJSONの典型的な構造は、複数のFeatureをFeatureCollectionの中に入れる形です。これにより、一つのファイルに多数の地点や区域をまとめることができます。たとえば、現場内の危険箇所を複数登録したり、道路沿いの点検対象をまとめたり、複数の工区範囲を一括で共有したりできます。ファイルを受け取る側も、Featureごとに属性を読み取り、色分け、ラベル表示、検索、絞り込みなどを行いやすくなります。

実務では、どの形状を選ぶかによって後工程の扱いやすさが変わります。たとえば、道路を面として管理するのか、中心線として線で管理するのかによって、距離計算や範囲判定の意味が変わります。建物を点で代表位置だけ管理するのか、面として外形を管理するのかでも、活用できる場面は異なります。GeoJSONの使い方を学ぶときは、単にデータを作るだけでなく、そのデータを誰が何の目的で使うのかを考えて形状を選ぶことが大切です。

座標の並び順と座標参照の考え方を押さえる

GeoJSONで特に間違えやすいのが、座標の並び順です。GeoJSONでは、座標は原則として経度、緯度の順で記述します。地図や住所検索の感覚では緯度、経度の順で話すことも多いため、初心者はここで逆にしてしまいがちです。日本国内の位置を扱う場合、経度はおおむね120度台から150度台、緯度はおおむね20度台から40度台付近になります。もし値の順序を逆にすると、地図上で日本ではない場所に表示されたり、まったく見当違いの位置に点が出たりします。

たとえば、東京付近の座標を考えると、経度が約139度台、緯度が約35度台になります。GeoJSONではこの順で配列に入れるため、座標はおおむね[139.x, 35.x]のような並びになります。もし[35.x, 139.x]のように逆にすると、緯度として139度を指定することになり、通常の地理的な緯度の範囲を超えてしまいます。このような誤りは、地図表示環境によっては表示されなかったり、別の解釈で処理されたりするため、作成時点で必ず確認する必要があります。

また、高さを含める場合は、経度、緯度、高さの順で三つ目の値を加えることがあります。ただし、すべての表示環境や処理環境が高さを同じように扱うとは限りません。高さが楕円体高なのか標高なのか、現場で使う基準に対してどのような意味を持つのかを整理しておかないと、三次元的な確認をしたときにずれが生じる可能性があります。GeoJSONに高さを入れる場合は、propertiesの中に高さの基準や測定方法を補足しておくと、後からデータを確認する人にとって分かりやすくなります。

座標参照の考え方も重要です。現在広く使われるGeoJSONでは、WGS 84の経度緯度として扱われる前提で設計されていることが一般的です。平面直角座標や現場独自座標をそのまま入れると、表示環境によっては正しく地図上に重なりません。公共測量、設計、施工管理、設備管理などの実務では、さまざまな座標系が使われます。元データがどの座標系で作られているのかを確認し、必要に応じて経度緯度へ変換してからGeoJSON化することが大切です。

さらに、座標の精度についても注意が必要です。GeoJSONは数値を小数で記述できるため、見た目上は細かい位置まで表現できます。しかし、元の測位精度や図面精度が低ければ、小数点以下を増やしても実際の位置精度が上がるわけではありません。逆に、不要に桁数が多い座標を大量に含めると、ファイルサイズが大きくなり、処理が重くなることがあります。実務では、目的に必要な精度と、元データが持つ信頼性の両方を踏まえて座標を扱う必要があります。

GeoJSONを使い始めるときは、まず一つの点データを作り、地図上で正しい位置に表示されるか確認するのがおすすめです。点が正しい位置に出れば、座標の順序や大まかな座標系は合っている可能性が高くなります。そのうえで、線や面に広げていくと、問題の切り分けがしやすくなります。いきなり大量のデータを変換してから不具合に気付くと、原因が座標順なのか、座標系なのか、図形構造なのかを見分けるのに時間がかかります。

Featureとpropertiesの役割を分けて考える

GeoJSONを実務で活用するうえで、Featureとpropertiesの理解は欠かせません。Featureは、地図上に存在する一つの対象物を表す単位です。Featureの中には、形状を示すgeometryと、属性情報を格納するpropertiesがあります。geometryは「どこに、どのような形で存在するか」を表し、propertiesは「それが何で、どのような情報を持つか」を表します。この二つを分けて考えることで、GeoJSONの設計が整理しやすくなります。

たとえば、点検対象の設備をGeoJSONで管理する場合、geometryには設備の位置を点として入れます。一方、propertiesには設備番号、設備名、分類、点検日、点検結果、異常の有無、担当部署、備考などを入れます。道路の線データであれば、geometryには道路の形状を線として入れ、propertiesには路線名、区間番号、延長、管理者、舗装種別、点検状況などを入れます。工区の面データであれば、geometryには範囲を面として入れ、propertiesには工事名、工区名、施工予定期間、進捗、担当者などを入れることができます。

propertiesを設計するときに大切なのは、後で検索、集計、色分け、ラベル表示に使う項目を意識することです。単なる備考欄だけに情報を詰め込むと、人が読む分には分かっても、システムで分類したり、条件に応じて表示を変えたりするのが難しくなります。たとえば、点検結果を「問題なし」「要確認」「対応済み」のように決まった値で入れておくと、地図上で状態ごとに色分けしやすくなります。一方、毎回自由な文章で書いてしまうと、同じ意味でも表記ゆれが発生し、集計しにくくなります。

項目名の付け方にも注意が必要です。日本語の項目名を使うこと自体は可能ですが、他のシステムとの連携や長期的な管理を考えると、半角英数字の項目名にして、別途表示名を管理する方法もあります。たとえば、status、inspection_date、asset_idのような項目名にしておくと、データ連携時に扱いやすい場合があります。ただし、現場担当者が直接ファイルを読む運用では、日本語項目名のほうが分かりやすいこともあります。どちらが正解というより、利用者と運用環境に合わせて決めることが重要です。

propertiesには多くの情報を入れられるため、つい詳細な情報まで詰め込みたくなります。しかし、GeoJSONを軽く扱いたい場合や、外部共有する場合には、必要な項目だけに絞ることも大切です。個人情報、社外秘情報、契約情報、詳細な原価情報などを不用意にpropertiesへ入れると、ファイル共有時のリスクが高まります。地図表示に必要な情報、業務判断に必要な情報、共有相手に見せてもよい情報を切り分けて設計すると、安全に活用しやすくなります。

初心者向けの確認方法としては、まず一つのFeatureを文章で説明できるかを考えると分かりやすいです。「このFeatureは、現場Aの点検地点を表していて、位置はこの座標、属性として点検日と状態を持つ」というように説明できれば、geometryとpropertiesの役割が整理できています。逆に、形状と属性の境界があいまいなまま作成すると、後から項目追加やデータ統合を行うときに混乱しやすくなります。

点・線・面データの使い分けを理解する

GeoJSONの使い方を実務に落とし込むには、点、線、面の使い分けを理解する必要があります。同じ対象物でも、目的によって適した形状は変わります。たとえば、建物を管理する場合、所在地を示すだけなら代表点で十分なことがあります。しかし、建物の外形や敷地との関係、面積、隣接状況を確認したい場合は、面として管理したほうが適しています。道路についても、経路や延長を扱いたいなら線、道路区域として幅を含めて管理したいなら面が必要になることがあります。

点データの利点は、軽量で扱いやすいことです。現地調査地点、写真撮影位置、設備の代表位置、測定箇所、危険箇所などは、点として記録することで簡単に地図表示できます。点はデータ構造が単純なため、初心者がGeoJSONを学ぶ入口としても向いています。特に、現場で取得した座標を一覧化し、地図上に並べて確認するような用途では、点データから始めると理解しやすいです。

線データは、経路や連続した対象を表すのに向いています。道路中心線、配管ルート、水路、境界線、移動経路、施工ラインなどが代表例です。線データでは、座標の並び順が意味を持つ場合があります。たとえば、起点から終点に向かう方向、上流から下流に向かう方向、施工順序などを表したい場合、座標の順番を意識する必要があります。地図上では同じ線に見えても、データ上の向きが後工程の処理に影響することがあります。

面データは、範囲を表すのに向いています。敷地、建物、工区、浸水想定範囲、管理区域、立入禁止区域、土地利用区分などを表現できます。面では、座標列が閉じていることが重要です。Polygonの外周や内側の穴を表す座標列は、最初の座標と最後の座標を同じにする必要があります。また、面の外周と穴の扱いも注意が必要です。たとえば、大きな区域の中に除外したい範囲がある場合、単純な外周だけでは表現できないため、内部の穴を持つ面として扱う必要が出てきます。

実務でよくある失敗は、点で十分な用途に複雑な面を使ってしまうこと、または面で管理すべき対象を代表点だけで済ませてしまうことです。前者ではデータが重くなり、作成や修正の手間が増えます。後者では、範囲判定や面積計算、隣接確認ができず、後からデータを作り直すことになります。GeoJSONを作成する前に、「このデータで何を判断したいのか」「地図上で何を確認したいのか」「将来どのような分析に使う可能性があるのか」を整理しておくと、適切な形状を選びやすくなります。

また、点、線、面を一つのファイルに混在させることも可能ですが、初心者のうちは用途ごとに分けたほうが管理しやすい場合があります。たとえば、点検地点は点データ、点検ルートは線データ、点検対象区域は面データとして別々に管理すれば、それぞれの属性項目も整理しやすくなります。慣れてきたら、共通の管理番号や現場番号で関連付けることで、複数のGeoJSONを連携して活用できます。

実務でGeoJSONを作成・確認するときの注意点を押さえる

GeoJSONを実務で使うときは、作成したデータが正しい構造になっているか、地図上で意図した位置に表示されるか、属性情報が後工程で使いやすい形になっているかを確認する必要があります。ファイルとして保存できたからといって、必ずしも実務で使える品質になっているとは限りません。特に、複数の人や複数のシステムが関わる場合は、作成ルールと確認手順を決めておくことが重要です。

まず確認したいのは、JSONとしての構文が正しいかです。GeoJSONはJSONを基礎としているため、括弧の閉じ忘れ、カンマの付け忘れ、文字列の引用符の欠落などがあると、読み込み時にエラーになります。人が手で編集した場合や、表形式データから変換した場合に、このような構文ミスが発生しやすくなります。構文が正しいかを確認できる環境を使い、読み込み前にチェックする習慣を付けると、不要な手戻りを減らせます。

次に、GeoJSONとしての構造を確認します。FeatureCollectionの中にfeaturesがあり、その中にFeatureが並び、各Featureの中にgeometryとpropertiesがあるかを見ます。geometryにはtypeとcoordinatesが必要です。typeに指定した形状とcoordinatesの構造が合っていないと、地図上で表示できなかったり、表示結果がおかしくなったりします。Pointなら一つの座標、LineStringなら座標の配列、Polygonなら閉じた座標列をさらに配列として持つ、といった構造の違いを理解しておく必要があります。

位置確認では、まず代表的な数件を地図上で確認することが大切です。すべてのデータを一括で信じるのではなく、現場をよく知る人が見て、明らかにおかしな場所に表示されていないかを確認します。特に、座標の順序違い、座標系の変換漏れ、桁の欠落、単位の誤りは、見た目で気付きやすい場合があります。点が海上に出る、線が極端に長く伸びる、面が意図しない形で表示される、現場から大きく離れた場所に出るといった場合は、元データや変換処理を確認する必要があります。

属性情報の確認も重要です。管理番号が重複していないか、日付の形式が統一されているか、分類名に表記ゆれがないか、数値として扱いたい項目が文字列になっていないかなどを見ます。たとえば、同じ状態を「要確認」「要確認中」「確認要」などと別々に記録していると、後で状態別に集計したときに正しくまとまりません。現場入力では自由記述が便利な場面もありますが、集計や地図上の色分けに使う項目は、できるだけ選択式や定義済みの値に寄せると扱いやすくなります。

ファイルサイズにも注意が必要です。GeoJSONはテキスト形式で読みやすい反面、大量の座標を含むとサイズが大きくなりやすい特徴があります。細かすぎる境界線や不要な中間点を多く含む線、非常に複雑な面をそのまま保持すると、表示に時間がかかったり、共有しにくくなったりします。実務では、目的に応じて形状を簡略化する、対象範囲を分割する、必要な属性だけに絞るなどの工夫が必要になることがあります。

共有時には、データの意味を説明する情報も添えると親切です。GeoJSONファイルだけを渡されても、受け取った人は属性項目の意味、座標の基準、作成日、作成者、元データ、利用目的を判断できないことがあります。propertiesに必要なメタ情報を入れる方法もありますが、ファイル全体の説明として別途ルールを整理しておくと、組織内での再利用性が高まります。特に、測量成果、施工記録、台帳、点検結果などに関わるデータでは、いつ、誰が、どの方法で作成したかが後から重要になることがあります。

セキュリティ面では、GeoJSONに含まれる位置情報が外部に出ても問題ないかを確認する必要があります。設備位置、重要施設、工事中の区域、管理対象物の詳細な場所などは、公開範囲に注意が必要です。公開用データと内部管理用データを分ける、外部共有時には属性を削る、詳細な位置を丸めるなど、利用目的に応じた配慮が求められます。GeoJSONは扱いやすい形式だからこそ、簡単に共有できる一方で、情報管理の意識も必要です。

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

GeoJSONの使い方を覚える目的は、単にファイルを作ることではありません。実務で重要なのは、位置情報を業務の判断や共有に活かすことです。現地調査、測量、施工管理、設備管理、防災、維持管理などの現場では、場所に結び付いた情報が数多く発生します。それらを紙の図面、写真、表計算ファイル、口頭説明だけで管理していると、どこで何が起きているのかを関係者が共通理解しにくくなります。GeoJSONを使うことで、位置と属性を結び付け、地図上で確認できる形に整理しやすくなります。

たとえば、現場写真の撮影地点を点データにして、撮影日や写真番号をpropertiesに入れておけば、後から地図上で写真の位置を確認できます。補修が必要な箇所を点や線で記録し、状態や優先度を属性として持たせれば、対応順序の検討に役立ちます。施工範囲を面として表し、進捗や検査状況を属性として付ければ、関係者間で工区ごとの状況を共有しやすくなります。これらはすべて、GeoJSONの基本構造を理解していれば応用できる使い方です。

また、GeoJSONは台帳情報との相性も良い形式です。台帳には管理番号、名称、分類、設置日、点検履歴、補修履歴などが含まれますが、そこに位置情報が加わることで、地図上で検索したり、周辺状況と重ねて確認したりできます。たとえば、設備台帳の各設備に代表点の座標を持たせ、GeoJSONとして出力すれば、一覧表だけでは分からなかった分布や偏りを把握しやすくなります。逆に、地図上で選択した対象から台帳情報を確認する運用にもつなげられます。

施工や測量の分野では、GeoJSONを中間データとして活用する考え方もあります。設計図、現況測量、出来形確認、写真記録、点検結果など、さまざまなデータを位置情報で結び付けることで、関係者が同じ場所を基準に議論できます。ただし、精度が求められる業務では、GeoJSONに変換する前の座標系や測位方法、変換条件を慎重に確認する必要があります。地図上で見た目が合っているだけでは不十分で、業務上必要な精度を満たしているかを判断することが大切です。

初心者がGeoJSONを活用し始めるなら、まずは小さな業務から始めるとよいです。いきなり全社的な台帳や大規模な現場データをGeoJSON化するのではなく、一つの現場、一つの点検種別、一つの区域などに範囲を絞って試すと、データ項目や運用ルールの課題が見えやすくなります。たとえば、十数件の点検地点をGeoJSON化して、地図上で表示し、現場担当者に確認してもらうだけでも、座標の取り方、項目名、状態分類、共有方法について多くの気付きが得られます。

運用を広げる段階では、作成ルールを標準化することが重要です。座標はどの基準で扱うのか、項目名はどのように付けるのか、日付形式はどうするのか、状態区分は何種類にするのか、外部共有時に削除する項目は何か、といったルールを決めておくと、複数人で作成してもデータ品質を保ちやすくなります。GeoJSONは自由度が高い形式ですが、自由に作りすぎると統合や再利用が難しくなります。業務に合った最小限のルールを用意することが、長く使えるデータづくりにつながります。

さらに、現場で取得した位置情報をすぐに活用できる仕組みがあると、GeoJSONの価値は高まります。事務所に戻ってから手作業で座標を整理する運用では、入力ミスや時間差が発生しやすくなります。現地で取得した座標、写真、メモ、点検結果をできるだけ早く地図データとして確認できれば、記憶が新しいうちに修正でき、関係者への共有もスムーズになります。現場の位置情報をデジタル化する際には、GeoJSONのような扱いやすい形式を理解しておくことが、ツール選定や運用設計にも役立ちます。

まとめ

GeoJSONは、地図上の点、線、面と、それに付随する属性情報を扱うための分かりやすいデータ形式です。初心者にとっては、最初は記号や括弧が多く見えるかもしれませんが、基本は「どこにあるか」をgeometryで表し、「それが何か」をpropertiesで表す構造です。この考え方を押さえれば、点検地点、設備位置、施工範囲、調査ルート、管理区域など、さまざまな現場情報を地図上で扱えるようになります。

GeoJSONを使ううえで特に重要なのは、座標の並び順、座標系、形状の選び方、属性項目の設計、データ確認の手順です。経度と緯度を逆にしないこと、元データの座標系を確認すること、点・線・面を目的に応じて選ぶこと、propertiesを後から検索や集計に使える形で整理することが、実務での使いやすさを大きく左右します。ファイルとして正しく見えるだけでなく、現場の判断に使える品質になっているかを確認することが大切です。

また、GeoJSONは単独で完結するものではなく、現場業務や台帳管理、地図表示、データ共有と組み合わせて価値を発揮します。小さな範囲から試し、表示確認と運用改善を繰り返すことで、無理なく業務に取り入れられます。最初は一つの点データから始め、次に線や面、複数Feature、属性設計へと広げていくと、理解しながら実務に応用できます。

現場で取得した位置情報をより正確に残し、写真や点検結果、施工記録と結び付けて活用したい場合は、取得から共有までの流れを含めて考えることが重要です。GeoJSONの基本を理解しておくと、現地で得た座標データを地図や台帳に展開しやすくなり、関係者間の認識合わせにも役立ちます。特定の製品やサービスに依存せず、まずは座標の取得方法、データ形式、共有範囲、必要な精度を整理することで、自社の業務に合った位置情報活用を検討しやすくなります。