GeoJSONの書き方を7つの例で理解する入門ガイド

GeoJSONは、地図上の点、線、面などの位置情報をJSON形式で表現するためのデータ形式です。地図データを受け渡したい、現地調査の結果を整理したい、既存の座標データを地図上に表示したいといった場面でよく使われます。この記事では、GeoJSONの基本構造から、Point、LineString、Polygon、Feature、FeatureCollectionまで、実務で使いやすい7つの例を通して書き方を理解できるように解説します。

目次

• GeoJSONとは何か

• GeoJSONを書く前に押さえる基本ルール

• 例1 Pointで地点を表す

• 例2 LineStringで経路や境界線を表す

• 例3 Polygonで区域や敷地を表す

• 例4 MultiPointで複数地点をまとめる

• 例5 MultiLineStringで複数の線をまとめる

• 例6 Featureで属性情報を持たせる

• 例7 FeatureCollectionで実務データとしてまとめる

• GeoJSONを書くときによくあるミス

• 実務で使いやすいGeoJSONにする考え方

• まとめ

GeoJSONとは何か

GeoJSONは、位置情報を扱うためのJSONにもとづくデータ交換形式です。JSONはWebシステムや業務システムで広く使われる軽量なデータ形式であり、GeoJSONはその中で地理空間情報を表現するための決まりを定めたものです。通常のJSONでは、住所、名称、数値、状態などの情報を自由に書けますが、GeoJSONでは「これは点です」「これは線です」「これは面です」といった地図上の形状を、決まったキーと値の組み合わせで表します。

たとえば、現地で取得した設備の位置、道路の中心線、工事範囲、管理区域、点検対象の一覧などは、GeoJSONで表現できます。地図表示用のプログラムに渡すデータとして使われることもあれば、調査結果を別のシステムへ受け渡す中間データとして使われることもあります。データがテキスト形式なので、人が中身を確認しやすく、システム間連携にも向いています。

GeoJSONの基本は、geometryという地物の形状を表す部分です。geometryには、Point、LineString、Polygonなどの種類があります。Pointは一点、LineStringは複数の点をつないだ線、Polygonは閉じた面を表します。さらに、geometryだけでなく、propertiesという属性情報を組み合わせることで、地図上の形状に名前、種別、管理番号、状態、メモなどの業務情報を持たせることができます。

実務では、単に座標を並べるだけではなく、「この点は何を意味するのか」「この区域は何の範囲なのか」「この線はどの路線や区間を表すのか」を一緒に管理する必要があります。そのため、GeoJSONを理解するときは、座標の書き方だけでなく、geometry、properties、Feature、FeatureCollectionの関係まで押さえることが重要です。

GeoJSONを書く前に押さえる基本ルール

GeoJSONを書く前に、まずJSONとして正しい形式になっている必要があります。キーはダブルクォーテーションで囲み、文字列もダブルクォーテーションで囲みます。オブジェクトは波括弧で表し、配列は角括弧で表します。複数の値を並べるときはカンマで区切りますが、最後の要素の後ろに余分なカンマを置かないようにします。この基本が崩れると、GeoJSONとして扱う以前にJSONとして読み込めません。

GeoJSONで特に重要なのは、座標の順番です。標準的なGeoJSONでは、座標は経度、緯度の順で書きます。つまり、日本国内の地点であれば、おおむね「139前後の数値、35前後の数値」のような並びになります。緯度と経度を逆にすると、意図した場所とはまったく違う地点に表示されることがあります。日本のデータを扱っているのに海外や海上に表示される場合は、座標順が逆になっていないかを最初に確認するとよいです。

現在広く参照されるGeoJSONの仕様では、座標参照系はWGS 84で、経度・緯度の単位は10進度です。別の座標系で管理しているデータをそのままGeoJSONとして渡すと、受け取る側で正しく解釈されないことがあります。平面直角座標系などのデータを使う場合は、GeoJSONにする前に変換方針を確認しておきます。

GeoJSONのgeometryには、typeとcoordinatesが必要です。typeにはPoint、LineString、Polygonなどの形状種別を書きます。これらのtypeの値は大文字と小文字を区別します。coordinatesには、その形状を構成する座標を書きます。Pointであれば一つの座標、LineStringであれば座標の配列、Polygonであれば閉じた線を表す座標配列をさらに入れ子にして書きます。形状の種類によってcoordinatesの入れ子の深さが変わるため、ここを理解することがGeoJSON入門の大きなポイントです。

また、GeoJSONでは座標だけを直接書いたgeometryと、属性情報を含むFeatureを使い分けます。地図上に単純な形だけを渡すならgeometryだけでも表現できますが、実務では名称や管理番号などを一緒に扱うことが多いため、FeatureまたはFeatureCollectionを使う場面が一般的です。Featureは一つの地物を表し、FeatureCollectionは複数のFeatureをまとめたものです。

以降では、7つの例を使いながら、実際の書き方を順に見ていきます。最初は単純なgeometryから始め、最後に実務でよく使うFeatureCollectionまで進めます。

例1 Pointで地点を表す

Pointは、GeoJSONで最も基本的な形状です。一つの地点を表すときに使います。たとえば、設備の設置位置、建物の入口、点検箇所、観測地点、写真を撮影した位置などはPointで表現できます。Pointのcoordinatesには、一組の座標を入れます。

`json { "type": "Point", "coordinates": [139.767125, 35.681236] } `

この例では、typeにPointを指定し、coordinatesに経度と緯度を並べています。最初の139.767125が経度、次の35.681236が緯度です。GeoJSONを初めて書くときに間違いやすいのが、この座標順です。住所検索や表計算で扱うデータでは緯度、経度の順で表示されることもありますが、GeoJSONでは経度、緯度の順で書くと覚えておきます。

Pointは非常に単純ですが、実務でよく使われる形状です。たとえば、現地調査で取得したマンホール、標識、樹木、照明柱、境界標、撮影地点などを地図上に表示する場合、一つひとつの対象物をPointとして扱えます。ただし、Pointだけでは「それが何の地点なのか」は分かりません。形状だけを表すgeometryとしては正しいものの、業務データとしては情報が足りないことがあります。

そのため、実務ではPointをそのまま単体で管理するよりも、後で紹介するFeatureのgeometryとしてPointを入れ、propertiesに名称や管理番号を持たせる形が使いやすい場合が多いです。まずはPointの基本構造を理解し、そのうえで属性付きのFeatureに発展させると、GeoJSON全体の理解が進みやすくなります。

Pointには高さを表す3つ目の値を追加することもできます。標準的なGeoJSONでは、coordinatesを経度、緯度、高さの順で書きます。

`json { "type": "Point", "coordinates": [139.767125, 35.681236, 12.5] } `

この場合、12.5が高さに相当します。仕様上の高さはWGS 84楕円体からのメートル単位の高さとして扱われますが、実際に表示や解析で使われるかは利用するシステムによって異なります。高さを入れれば必ず三次元表示されるというわけではありません。実務で高さ情報を扱う場合は、propertiesにも標高、測定高、基準面などを明示しておくと、後工程での誤解を減らせます。

例2 LineStringで経路や境界線を表す

LineStringは、複数の座標を順番につないで線を表す形式です。道路、河川、配管、ケーブル、歩行経路、調査ルート、区域の境界線などを表すときに使います。Pointが一つの座標で表されるのに対して、LineStringでは座標を配列として複数並べます。

`json { "type": "LineString", "coordinates": [ [139.760000, 35.680000], [139.762000, 35.681000], [139.765000, 35.682000], [139.768000, 35.681500] ] } `

この例では、4つの座標を順番につないで一本の線を作っています。LineStringでは、座標の順番が線の方向を意味します。地図上で単に線として表示するだけなら方向を意識しないこともありますが、経路、進行方向、測線、区間管理などを扱う場合は、どちら向きに座標を並べるかが重要になります。

LineStringを書くときは、最低でも2つ以上の座標が必要です。1つの座標だけでは線にならないため、LineStringとしては不十分です。また、座標の間隔が粗すぎると、実際には曲がっている道路や境界が直線的に表現されてしまいます。逆に、点を細かく取りすぎるとデータ量が増え、表示や処理が重くなる場合があります。実務では、必要な精度とデータ量のバランスを考えて座標を用意します。

LineStringは、一本の連続した線を表すのに適しています。途中で完全に途切れる複数の線を一つのデータとして扱いたい場合は、後で紹介するMultiLineStringを使います。たとえば、一つの管理対象に複数の離れた線分が含まれる場合や、同じ路線名で複数区間をまとめたい場合には、LineStringだけでは表現しづらくなります。

LineStringでも、業務上は属性情報が重要です。線の種別、名称、管理者、延長、状態、調査日などをpropertiesに持たせることで、単なる線ではなく、意味のある業務データになります。線形データは現場管理、インフラ管理、点検計画などで使われることが多いため、GeoJSONでのLineStringの書き方は早い段階で習得しておきたい内容です。

例3 Polygonで区域や敷地を表す

Polygonは、閉じた面を表すGeoJSONの形状です。敷地、建物範囲、工事区域、調査範囲、管理区域、危険区域、利用範囲など、面として扱いたい地物に使います。PolygonのcoordinatesはLineStringよりも一段深い入れ子構造になります。

`json { "type": "Polygon", "coordinates": [ [ [139.760000, 35.680000], [139.768000, 35.680000], [139.768000, 35.685000], [139.760000, 35.685000], [139.760000, 35.680000] ] ] } `

この例では、四角形の区域を表しています。Polygonで最も重要なのは、最初の座標と最後の座標を同じにして閉じることです。上の例では、最初の座標が[139.760000, 35.680000]で、最後にも同じ座標を置いています。これにより、面の外周が閉じた形として表現されます。Polygonの外周や穴を表す線形リングは、閉じるための最後の座標を含めて4つ以上の座標が必要です。

Polygonのcoordinatesが二重の配列になっている理由は、外周と内側の穴を表現できるようにするためです。最初の配列が外周を表し、必要に応じて2つ目以降の配列で穴を表します。たとえば、区域の中に除外したい中庭や対象外エリアがある場合、外側の面と内側の穴を同じPolygon内で表現できます。

`json { "type": "Polygon", "coordinates": [ [ [139.760000, 35.680000], [139.770000, 35.680000], [139.770000, 35.690000], [139.760000, 35.690000], [139.760000, 35.680000] ], [ [139.763000, 35.683000], [139.763000, 35.687000], [139.767000, 35.687000], [139.767000, 35.683000], [139.763000, 35.683000] ] ] } `

この例では、最初の配列が外側の区域、2つ目の配列が内側の穴を表します。実務では、穴を持つPolygonは少し難しく感じるかもしれませんが、考え方は単純です。外周も内周も、どちらも閉じた線として座標を並べます。

Polygonを書くときは、自己交差にも注意が必要です。自己交差とは、面の外周線が途中で交差してしまう状態です。見た目には区域のように見えても、データとしては正しい面として扱えないことがあります。工事範囲や敷地境界を手作業で作成する場合、頂点の順番を間違えると自己交差が起きやすくなります。座標を並べるときは、外周を一方向にたどるように順序をそろえることが大切です。

標準的なGeoJSONでは、Polygonのリング方向にも決まりがあります。外周は反時計回り、穴は時計回りが基本です。ただし、古いデータや一部のツールでは異なる向きのPolygonを受け入れることもあります。互換性を高めるためには、作成後にGeoJSONの検証ツールやGISで確認し、閉じ忘れ、自己交差、リング方向の問題がないかを見ておくと安心です。

Polygonは面積計算や区域判定にも関係します。ある点が区域内にあるか、対象物が管理範囲に含まれるか、工事範囲と既存設備が重なるかといった処理では、Polygonの正しさが結果に直結します。見た目だけではなく、閉じていること、座標順が適切であること、不要な交差がないことを確認する習慣を持つと、後工程でのトラブルを減らせます。

例4 MultiPointで複数地点をまとめる

MultiPointは、複数の点を一つのgeometryとしてまとめる形式です。単独のPointが一つの地点を表すのに対して、MultiPointは複数地点の集合を表します。たとえば、同じ種類の観測点、同一案件の撮影地点、まとめて扱いたい複数の候補地点などを一つの形状として表現できます。

`json { "type": "MultiPoint", "coordinates": [ [139.760000, 35.680000], [139.765000, 35.682000], [139.770000, 35.684000] ] } `

この例では、3つの地点を一つのMultiPointとして表しています。coordinatesの中には、Pointと同じ形式の座標を複数並べます。LineStringと見た目が少し似ていますが、意味は異なります。LineStringは座標を順番につないで線を作りますが、MultiPointは座標同士を線でつなぎません。それぞれが独立した点として扱われます。

MultiPointを使うか、複数のPointをFeatureCollectionとして並べるかは、実務上の意味によって判断します。複数地点が一つの地物として扱われるならMultiPointが向いています。たとえば、一つの施設に複数の入口があり、それをまとめて施設入口群として扱いたい場合はMultiPointが候補になります。一方で、各地点に個別の名称、管理番号、点検結果、写真番号などを持たせたい場合は、それぞれを別々のFeatureにしたほうが扱いやすくなります。

実務では、MultiPointを使う場面はPointやFeatureCollectionほど多くないかもしれません。しかし、複数の座標をひとまとまりの形状として扱えることを知っておくと、データ設計の幅が広がります。特に、同一属性を持つ点群を軽量に表現したい場合には便利です。

ただし、後から個別地点ごとに状態を更新したり、地図上で個別に選択したり、帳票に個別出力したりする可能性があるなら、MultiPointではなく、PointのFeatureを複数作るほうが無難です。GeoJSONは書けることよりも、後工程でどう使うかが重要です。データを受け取る側がどの単位で検索、選択、更新、集計を行うのかを考えて形状を選びます。

例5 MultiLineStringで複数の線をまとめる

MultiLineStringは、複数のLineStringを一つのgeometryとしてまとめる形式です。連続していない複数の線分を同じ地物として扱いたいときに使います。たとえば、同じ管理路線に離れた区間がある場合、同じ種別の配管が複数区間に分かれている場合、または一つの調査対象に複数の測線が含まれる場合に利用できます。

`json { "type": "MultiLineString", "coordinates": [ [ [139.760000, 35.680000], [139.762000, 35.681000], [139.764000, 35.682000] ], [ [139.770000, 35.685000], [139.772000, 35.686000], [139.774000, 35.687000] ] ] } `

この例では、2本の線を一つのMultiLineStringとして表しています。coordinatesの中に、LineStringの座標配列が複数入っています。入れ子構造が増えるため、最初は少し読みにくく感じるかもしれませんが、一つひとつの内側の配列をLineStringとして見ると理解しやすくなります。

MultiLineStringを使うメリットは、同じ属性を持つ複数の線を一つの地物として表現できることです。たとえば、同じ管理番号を持つ路線が複数区間に分かれている場合、それらを一つのFeatureのgeometryとしてまとめることができます。propertiesには路線名や種別を一度だけ書けばよいため、データの重複を減らせます。

一方で、各線分を個別に管理したい場合は、MultiLineStringではなくLineStringのFeatureを複数作るほうが適しています。区間ごとに状態、施工日、点検結果、優先度などが異なるなら、同じ属性としてまとめてしまうと後で扱いにくくなります。GeoJSONの形状選択では、「見た目としてまとまっているか」よりも「業務上同じ単位として扱うか」を基準にすると判断しやすくなります。

MultiLineStringでは、線同士が接続していても、接続していなくても表現できます。ただし、完全に連続した一本の線として扱いたい場合はLineStringで十分です。途中で区切る必要があるのか、複数の線を同じ地物としてまとめる必要があるのかを考えて使い分けます。

例6 Featureで属性情報を持たせる

ここまで紹介したPoint、LineString、Polygon、MultiPoint、MultiLineStringは、主に形状を表すgeometryです。しかし、実務でGeoJSONを使う場合、形状だけでは不十分なことが多いです。地図上に点が表示されても、それが設備なのか、撮影地点なのか、点検箇所なのか分からなければ業務データとして使いにくくなります。そこで使うのがFeatureです。

Featureは、一つの地物を表す単位です。Featureには、geometryとpropertiesを持たせます。geometryにはPointやPolygonなどの形状を入れ、propertiesには名称、種別、管理番号、状態、メモなどの属性情報を入れます。なお、仕様上はgeometryやpropertiesにnullを使える場合もありますが、入門段階では「形状はgeometry、属性はproperties」と考えると理解しやすいです。

`json { "type": "Feature", "geometry": { "type": "Point", "coordinates": [139.767125, 35.681236] }, "properties": { "id": "P001", "name": "点検地点A", "category": "設備", "status": "確認済み", "survey_date": "2026-05-01" } } `

この例では、Pointの位置に対して、id、name、category、status、survey_dateという属性情報を持たせています。地図上に表示するだけでなく、一覧で検索したり、状態で絞り込んだり、クリック時に詳細情報を表示したりする場合、このpropertiesが重要になります。仕様上の識別子として扱いたい場合は、Feature直下のidメンバーを使う設計もあります。ここでは、業務属性として扱いやすい例としてproperties内にidを置いています。

propertiesには任意のキーと値を入れられます。文字列、数値、真偽値、nullなどを使えます。ただし、実務では自由に書けるからこそ、項目名の統一が重要です。あるFeatureではname、別のFeatureでは名称、さらに別のFeatureではtitleのように項目名がばらばらだと、後で集計や表示をするときに手間がかかります。英数字のキーに統一するのか、日本語のキーを使うのか、日付はどの形式にするのか、状態はどの語彙にするのかを事前に決めておくと扱いやすくなります。

PolygonをFeatureに入れる場合も考え方は同じです。

`json { "type": "Feature", "geometry": { "type": "Polygon", "coordinates": [ [ [139.760000, 35.680000], [139.768000, 35.680000], [139.768000, 35.685000], [139.760000, 35.685000], [139.760000, 35.680000] ] ] }, "properties": { "id": "A001", "name": "調査区域A", "category": "調査範囲", "priority": "高" } } `

この例では、調査区域をPolygonで表し、propertiesに区域名や優先度を持たせています。区域データでは、区域種別、対象期間、担当部署、備考などを入れることもあります。線データであれば、路線名、区間番号、延長、舗装種別、点検結果などが考えられます。

Featureを使うと、GeoJSONは単なる図形データから業務データとして扱いやすい形になります。地図表示、検索、フィルタリング、帳票出力、点検管理、進捗管理などにつなげやすくなるため、実務担当者がGeoJSONを書くならFeatureの理解は欠かせません。

例7 FeatureCollectionで実務データとしてまとめる

FeatureCollectionは、複数のFeatureをまとめるための形式です。実務でGeoJSONファイルとして扱う場合、FeatureCollectionの形にすると複数の点、線、面を一つのファイルにまとめやすくなります。

`json { "type": "FeatureCollection", "features": [ { "type": "Feature", "geometry": { "type": "Point", "coordinates": [139.767125, 35.681236] }, "properties": { "id": "P001", "name": "点検地点A", "category": "設備", "status": "確認済み" } }, { "type": "Feature", "geometry": { "type": "LineString", "coordinates": [ [139.760000, 35.680000], [139.762000, 35.681000], [139.765000, 35.682000] ] }, "properties": { "id": "L001", "name": "調査ルートA", "category": "経路", "status": "作業中" } }, { "type": "Feature", "geometry": { "type": "Polygon", "coordinates": [ [ [139.760000, 35.680000], [139.768000, 35.680000], [139.768000, 35.685000], [139.760000, 35.685000], [139.760000, 35.680000] ] ] }, "properties": { "id": "A001", "name": "調査区域A", "category": "範囲", "status": "予定" } } ] } `

この例では、Point、LineString、Polygonの3つのFeatureを一つのFeatureCollectionにまとめています。featuresにはFeatureの配列を入れます。それぞれのFeatureがgeometryとpropertiesを持っているため、地図上の形状と業務情報をセットで管理できます。

FeatureCollectionの利点は、複数種類の地物を一つのGeoJSONとして扱えることです。点検地点、調査ルート、調査範囲のように、形状の種類が違っていても同じfeatures配列に入れられます。地図表示側では、それぞれのgeometry typeに応じて点、線、面として描画できます。

ただし、すべてを一つのFeatureCollectionに詰め込めばよいわけではありません。データ量が大きくなりすぎる場合や、更新頻度が異なる場合、権限管理が異なる場合は、用途ごとにGeoJSONを分けたほうが扱いやすいことがあります。たとえば、設備点データ、路線データ、区域データを別ファイルにする設計もあります。逆に、小規模な現地調査結果を一括で共有したい場合は、一つのFeatureCollectionにまとめると便利です。

FeatureCollectionを実務で使うときは、propertiesの項目設計が特に重要になります。複数のFeatureをまとめるため、属性名がばらばらだと処理が複雑になります。点、線、面で共通する項目としてid、name、category、statusを持たせ、形状ごとに必要な項目を追加するように設計すると、後で扱いやすくなります。

また、idの重複にも注意します。地物を更新したり、別データと突き合わせたりする場合、idが一意でないと混乱が起きます。人が見て分かる名称と、システムで識別するidは分けて考えるとよいです。nameは表示用、idは管理用という役割にしておくと、名称変更が発生してもデータ連携への影響を抑えられます。外部システムと連携する場合は、properties内のidで管理するのか、Feature直下のidを使うのかも事前に決めておくと安全です。

GeoJSONを書くときによくあるミス

GeoJSONで起こりやすいミスは、経度と緯度の順番を逆にしてしまうことです。GeoJSONでは経度、緯度の順で座標を書きます。日本国内のデータであれば、経度はおおむね120から150程度、緯度は20から45程度に収まることが多いです。座標を見たときに、最初の値が35前後、次の値が139前後になっている場合は、順番が逆になっている可能性があります。

次によくあるのが、Polygonを閉じ忘れるミスです。Polygonでは、外周の最初の座標と最後の座標を同じにする必要があります。見た目上は最後の点から最初の点まで線が引かれているように表示される場合もありますが、データとして正しく扱えないことがあります。面データを作るときは、必ず始点と終点が一致しているか確認します。

JSONの構文ミスも頻繁に起きます。カンマの抜け、余分なカンマ、ダブルクォーテーションの不足、波括弧や角括弧の閉じ忘れなどです。GeoJSONは人が読める形式ですが、少しの記法ミスで読み込みに失敗します。特に入れ子が深いPolygonやFeatureCollectionでは、閉じ括弧の数が分かりにくくなります。整形された状態で確認し、インデントをそろえることが大切です。

typeの指定ミスにも注意が必要です。Point、LineString、Polygon、Feature、FeatureCollectionなどは決まった文字列として書きます。大文字と小文字も含めて正確に書く必要があります。たとえばpointやlinestringのように小文字だけで書くと、期待どおりに認識されない場合があります。

coordinatesの入れ子構造を間違えることもあります。Pointは一組の座標、LineStringは座標の配列、Polygonは線形リングの配列をさらに配列に入れた構造です。MultiPoint、MultiLineString、MultiPolygonになると、さらに入れ子が増えます。入れ子構造のミスは見た目では気づきにくいため、形状タイプごとに基本形を覚えておくとよいです。

propertiesに業務情報を入れるときは、値の表記ゆれにも注意します。たとえば、確認済み、確認済、済、完了のように同じ意味の状態が複数表記で混在すると、集計や絞り込みが難しくなります。GeoJSONそのものは自由な属性を許容しますが、実務データとして品質を保つには、入力ルールを決めることが重要です。

実務で使いやすいGeoJSONにする考え方

実務で使いやすいGeoJSONを作るには、まず利用目的を明確にすることが大切です。単に地図上に表示するだけなのか、検索や集計にも使うのか、現地で更新するのか、別のシステムに渡すのかによって、適切な構造は変わります。表示だけなら最小限のgeometryで足りる場合もありますが、管理や連携まで考えるならFeatureCollectionとして属性情報を整える必要があります。

次に、地物の単位を決めます。何を一つのFeatureとして扱うのかは、GeoJSON設計の重要な判断です。設備一つを一つのFeatureにするのか、同じ種類の設備群を一つのMultiPointにするのか、路線全体を一つのMultiLineStringにするのか、区間ごとにLineStringを分けるのかで、後の運用が大きく変わります。更新、検索、選択、集計をどの単位で行いたいかを基準にすると、実務に合った設計になります。

propertiesの項目は、必要十分な内容に絞ることも重要です。何でも入れられるからといって、関係の薄い情報まで詰め込むと、データが重くなり、管理も難しくなります。一方で、後から必要になる基本情報が不足していると、再調査や手戻りが発生します。id、name、category、status、date、noteなど、共通的に使う項目を決めたうえで、用途に応じた項目を追加するとよいです。

座標精度についても考える必要があります。小数点以下の桁数を多くすれば見かけ上は精密になりますが、元データの測位精度以上に細かい値を持たせても実務上の意味は限定的です。現地調査で取得した座標、図面から抽出した座標、手入力した座標では信頼性が異なります。必要であれば、propertiesに取得方法や精度区分を入れておくと、後でデータを評価しやすくなります。

ファイルを受け渡す場合は、文字コードや改行、整形状態にも気を配ります。GeoJSONはテキストファイルとして扱われるため、人がレビューしやすい形に整形されていると確認が楽になります。大量データでは圧縮や簡略化が必要になる場合もありますが、まずは正しい構造で読みやすく作ることが基本です。

また、GeoJSONは地図上の見た目だけでなく、業務フロー全体の中で使われるデータです。現地で取得し、事務所で確認し、関係者に共有し、必要に応じて更新し、最終成果として保管するという流れを考えると、単発で表示できるデータよりも、継続的に扱えるデータのほうが価値があります。属性名の統一、idの付与、日付形式の統一、状態管理のルール化は、後から効いてくる重要なポイントです。

作成後は、利用予定の地図ライブラリやGISで読み込み確認を行います。構文として正しいGeoJSONでも、表示スタイル、座標参照系の前提、第三座標の扱い、propertiesの表示方法などはツールによって差が出ることがあります。公開や共有の前に、実際の利用環境で点、線、面が意図した場所に表示されるかを確認しておくと安心です。

まとめ

GeoJSONは、地図上の位置や形状をJSON形式で表現できるデータ形式です。Pointは地点、LineStringは線、Polygonは面を表し、MultiPointやMultiLineStringを使えば複数の形状を一つにまとめられます。さらにFeatureを使うことで属性情報を持たせることができ、FeatureCollectionを使えば複数の地物を一つのGeoJSONとして管理できます。

GeoJSONを書くときは、経度、緯度の順番を守ること、geometry typeに応じたcoordinatesの入れ子構造を正しく書くこと、Polygonでは始点と終点を一致させることが基本です。これらを押さえるだけで、初歩的なエラーの多くを避けられます。加えて、実務ではpropertiesの設計が重要です。名称、管理番号、種別、状態、日付などを適切に持たせることで、GeoJSONは単なる地図表示用データではなく、現場管理や情報共有に使える業務データになります。

この記事で紹介した7つの例を理解すれば、GeoJSONの基本的な書き方を押さえられます。最初はPointやLineStringのような単純な形状から始め、次にPolygon、Feature、FeatureCollectionへと進めると、無理なく実務に応用できます。特に、現地調査や設備管理、工事範囲の共有、点検結果の整理では、GeoJSONを使えるようになることで、位置情報を扱う作業を効率化しやすくなります。

現場で取得した位置情報を業務データとして活用するには、正確な座標取得と、GeoJSONとして扱いやすいデータ整理を組み合わせることが重要です。公開前には、座標順、JSON構文、Polygonの閉じ方、propertiesの表記ゆれ、利用環境での表示結果を確認し、関係者が迷わず使えるGeoJSONに整えておきましょう。