GeoJSONを使って地図データを扱おうとすると、最初につまずきやすいのがFeatureCollectionです。点の座標をひとつ置くだけなら何となく書けても、複数の地点、道路、区域、設備、調査結果をまとめて扱う段階になると、FeatureCollectionの理解が重要になります。この記事では、「geojson 使い方」で調べている実務担当者に向けて、FeatureCollectionを正しく読み書きするための要点を、現場で使う視点から解説します。
FeatureCollectionは複数のFeatureを束ねる入れ物
GeoJSONのFeatureCollectionは、複数の地物をひとつのまとまりとして扱うための形式です。地物とは、地図上に表したい対象のことです。たとえば、点検対象のマンホール、道路区間、建物の外形、工事範囲、調査地点、災害リスク区域などが地物にあたります。GeoJSONでは、こうした地物をFeatureという単位で表し、そのFeatureをまとめたものがFeatureCollectionです。
ここで注意したいのは、GeoJSONの最上位が必ずFeatureCollectionになるわけではないという点です。GeoJSONでは、Geometry、Feature、FeatureCollectionのいずれかを1つのGeoJSONオブジェクトとして表せます。そのため、1点だけを表すFeatureや、単独のPolygonだけでGeoJSONとして扱われることもあります。ただし、実務で複数の対象を一覧として扱う場合は、FeatureCollectionが外枠として使われることが多く、最初に覚えておく価値の高い基本形です。
現場で取得した複数の点データを地図に重ねたい、管理区域を一覧化したい、設備台帳を地図表示したい、線形のルート情報をまとめて共有したいといった場面では、多くの場合FeatureCollectionを使います。FeatureCollectionを理解しておくと、点、線、面が混在するデータでも、どこに地物の一覧があり、どこに形状や属性が入っているのかを追いやすくなります。
FeatureCollectionの最小構造はシンプルです。typeにFeatureCollectionを指定し、featuresにFeatureの配列を入れます。featuresは、地物を並べる箱のような役割を持ちます。中身が空の状態でもFeatureCollectionとしては成立しますが、実際に地図上へ表示したい対象がある場合は、featuresの中にFeatureを追加していきます。
json { "type": "FeatureCollection", "features": [] }
この形を見たときに重要なのは、FeatureCollection自体が座標を直接持つわけではないという点です。座標や形状は、featuresの中に入っている各Featureのgeometryに記述します。FeatureCollectionはあくまでFeatureの一覧を束ねる外枠であり、地図上の具体的な位置や形は各Featureが担当します。
また、FeatureCollectionの直下に、個々の地物のpropertiesやgeometryを置く形にはしないほうが安全です。地物ごとの名称、状態、分類、管理番号などは、各Featureのpropertiesに持たせます。FeatureCollection全体に関する説明や作成日などのメタ情報を扱いたい場合は、利用するシステムがその項目をどう読むかを確認し、GeoJSON本来のtype、features、geometry、propertiesの意味を変えないように設計します。
たとえば、10か所の調査地点をGeoJSONで表す場合、FeatureCollectionの中に10個のFeatureを入れます。1つ目のFeatureは調査地点A、2つ目のFeatureは調査地点Bというように、それぞれが自分のgeometryとpropertiesを持ちます。地図表示側はfeaturesを順番に読み取り、各Featureのgeometryを地図上に描画し、propertiesをポップアップや一覧表示、検索条件、ラベルなどに利用します。
この構造を理解しておくと、GeoJSONのエラー原因も見つけやすくなります。地図に何も表示されないとき、FeatureCollectionのtypeが間違っているのか、featuresが配列になっていないのか、featuresの中のFeatureが不正なのか、geometryの座標が間違っているのかを段階的に切り分けられます。FeatureCollectionを単なる形式として丸暗記するのではなく、「外枠」「地物の一覧」「各地物の形と属性を格納する入口」と捉えることが、GeoJSONを使いこなす第一歩です。
また、FeatureCollectionはデータ交換の単位としても便利です。地図表示、台帳連携、現地調査結果の共有、区域データの受け渡しなどでは、ひとつのファイルやひとつの通信レスポンスとしてFeatureCollectionを渡すことで、複数の地物をまとめて扱えます。これにより、点だけ、線だけ、面だけのデータに限らず、用途に応じて多様な地物を同じ形式で管理できます。
ただし、すべてをひとつのFeatureCollectionに詰め込めばよいわけではありません。対象の種類、更新頻度、利用目的が大きく異なるデータを無理にひとつにまとめると、後の管理が難しくなります。点検対象の設備、巡回ルート、工事区域、行政区域のように意味が異なるデータは、別々のFeatureCollectionとして管理したほうが扱いやすい場合があります。FeatureCollectionは便利な入れ物ですが、データ設計の単位として何をまとめ、何を分けるかを意識することが大切です。
Featureは地物、geometryは形、propertiesは属性を表す
FeatureCollectionを理解するうえで、次に重要なのがFeatureの中身です。Featureは、地図上に表示したいひとつの地物を表す単位です。ひとつの調査地点、ひとつの道路区間、ひとつの建物外形、ひとつの区域などが、それぞれFeatureになります。そしてFeatureの中には、type、geometry、propertiesが入ります。
typeは、そのオブジェクトがFeatureであることを示します。geometryは、地物の位置や形を示します。propertiesは、地物に付随する属性情報を示します。この分担を理解すると、GeoJSONを読むときも書くときも迷いにくくなります。地図上の形に関する情報はgeometryへ、名称や分類、管理番号、状態、調査日、担当区分などの情報はpropertiesへ入れる、という考え方です。
たとえば、ある調査地点を点として表す場合は、geometryにPointを指定し、coordinatesに経度と緯度を入れます。propertiesには、その地点の名前や状態などを入れます。
json { "type": "FeatureCollection", "features": [ { "type": "Feature", "geometry": { "type": "Point", "coordinates": [139.7671, 35.6812] }, "properties": { "name": "調査地点A", "status": "確認済み", "category": "設備点検" } } ] }
この例では、FeatureCollectionの中に1つのFeatureがあります。そのFeatureのgeometryは点を表し、propertiesには調査地点Aという名前や確認済みという状態が入っています。地図表示ではgeometryを使って点を描き、propertiesを使ってラベルや詳細情報を表示できます。
実務では、geometryとpropertiesを混同しないことが非常に重要です。たとえば、住所や施設名をpropertiesに入れるのは自然ですが、それだけでは地図上の位置は決まりません。地図上に表示するには、geometryに座標が必要です。逆に、geometryに座標だけが入っていてpropertiesが空に近い状態でも、地図上には表示できる場合があります。しかし、その点が何を意味するのか、人が判断しにくくなります。
GeoJSONの仕様上、FeatureのgeometryにはGeometryオブジェクトまたはnullを指定できます。propertiesにもJSONオブジェクトまたはnullを指定できます。ただし、地図上に表示するためのデータでは、有効なgeometryを持たせるのが基本です。位置が未確定の地物を一時的に管理したい場合にgeometryをnullにすることはあり得ますが、表示側や解析側がnull geometryに対応しているかを確認しておく必要があります。属性がない場合も、運用上はpropertiesを空のオブジェクトにしておくと扱いやすいことがあります。
geometryは地物の空間的な情報を担い、propertiesは業務上の意味を担います。点検業務なら、geometryは点検対象の位置を表し、propertiesは点検結果、点検日、異常の有無、管理番号などを表します。道路管理なら、geometryは路線の形を表し、propertiesは路線名、区間番号、舗装種別、補修状況などを表します。防災用途なら、geometryは危険区域や避難場所を表し、propertiesは区域名、リスク分類、指定日、備考などを表します。
Featureにはidを持たせることもあります。idはFeatureを一意に識別したい場合に便利です。GeoJSONのFeatureのidには文字列または数値を使えます。ただし、idを使うかproperties内に管理番号を入れるかは、利用する仕組みや運用方針によって変わります。重要なのは、同じFeatureを後から更新、照合、削除、集計できるように、安定した識別情報を持たせることです。表示するだけの一時的な地図であれば厳密な識別子が不要な場合もありますが、台帳や現場記録と連携するなら、識別情報の設計は避けて通れません。
また、propertiesには何でも入れられるからといって、無秩序に項目を増やすのは避けるべきです。似た意味の項目が複数ある、同じ項目に数値と文字列が混在する、日付の書き方がばらばらである、といった状態になると、後から検索や集計をするときに苦労します。FeatureCollectionは柔軟な形式ですが、実務データとして長く使うなら、propertiesの項目名、値の型、入力ルールをあらかじめ決めておくことが大切です。
Featureを正しく理解すると、GeoJSONは単なる座標ファイルではなく、空間情報と業務情報を結びつけるデータ形式だと見えてきます。FeatureCollectionは、そのFeatureを束ねることで、複数の現場情報を地図上で扱えるようにする仕組みです。GeoJSONの使い方を学ぶ際は、最初にこの「Featureは地物」「geometryは形」「propertiesは属性」という役割分担をしっかり押さえておきましょう。
coordinatesの順序とgeometry型を間違えない
GeoJSONで特にミスが起きやすいのがcoordinatesの順序です。多くの人は日常的に緯度、経度の順で位置を話すことが多いため、GeoJSONにも緯度、経度の順で書いてしまいがちです。しかし、RFC 7946に基づくGeoJSONでは、座標はWGS 84の経度、緯度の順で記述します。日本国内の地点であれば、経度はおおむね120台から150台、緯度はおおむね20台から50台に収まることが多いため、値を見て逆になっていないか確認できます。
たとえば、東京駅付近を点として表す場合、coordinatesはおおむね[139.7671, 35.6812]のようになります。これを[35.6812, 139.7671]と逆にすると、地図上では想定外の場所に飛んでしまい、表示されない、またはまったく違う地域に表示される原因になります。GeoJSONが壊れているわけではなく、座標順が間違っているだけというケースは実務でもよくあります。
coordinatesの構造は、geometryのtypeによって変わります。Pointはひとつの座標を持ちます。LineStringは2つ以上の座標を順番に並べ、線を表します。Polygonは面を表し、外周の座標列を閉じた形で持ちます。MultiPoint、MultiLineString、MultiPolygonのように、複数の点、複数の線、複数の面をひとつのgeometryとして表す型もあります。さらにGeometryCollectionという形もありますが、実務ではデータの扱いやすさを考え、まずはPoint、LineString、Polygonを正確に使い分けることが重要です。
Pointは、設備位置、観測地点、店舗、標識、点検箇所など、地図上の一点で表せる対象に向いています。LineStringは、道路中心線、巡回ルート、配管、河川、移動軌跡など、線として表したい対象に向いています。Polygonは、敷地、建物外形、工事範囲、管理区域、危険区域など、面として表したい対象に向いています。対象を点で表すべきか、線で表すべきか、面で表すべきかは、業務上の目的によって判断します。
たとえば、建物を地図上で探すだけなら代表点でも十分なことがあります。しかし建物の外形を使って面積を見たい、区域との重なりを判定したい、敷地境界に近いか確認したい場合はPolygonが必要になります。道路も同様に、単に位置を示すだけなら点でもよい場面がありますが、ルートとして扱うならLineStringが適しています。GeoJSONの使い方で大事なのは、表示できるかどうかだけでなく、その後に何をしたいかまで考えてgeometry型を選ぶことです。
Polygonでは、座標列の始点と終点を同じ値にして閉じる必要があります。面を表すには、外周がきちんと閉じた輪になっていなければなりません。GeoJSONのPolygonは、1つ以上のlinear ringの配列として表されます。linear ringは4つ以上の位置を持つ閉じたLineStringで、最初と最後の座標値は同一にします。穴のある面を表す場合は、最初の輪を外側の輪、2つ目以降を内側の輪として持たせます。
また、RFC 7946ではPolygonの輪の向きにも右手法則が示されています。外側の輪は反時計回り、穴は時計回りが基本です。ただし、既存データとの互換性のため、輪の向きだけを理由に多くの処理系がすぐ拒否するとは限りません。それでも、データを新しく作る場合は、閉じているか、座標の階層が正しいか、外側の輪と穴の順序が正しいかに加えて、輪の向きも確認しておくと安全です。
LineStringでは、座標の並び順が線の向きになります。道路や配管のように向きが重要でない場合もありますが、移動軌跡、巡回順、流れの方向などを表す場合は、座標の順序が意味を持ちます。単に点を集めれば線になるのではなく、どの順番で結ぶかによって形も意味も変わります。現地調査や移動記録からLineStringを作る場合は、取得時刻や記録順をもとに正しい順番で座標を並べる必要があります。
coordinatesには高さを含めることもできます。通常は経度、緯度の2要素ですが、必要に応じて3つ目の値として高さを持たせることがあります。RFC 7946では、3つ目の要素はWGS 84の参照楕円体に対するメートル単位の高さとして扱われます。ただし、高さの扱いは利用する表示環境や処理環境によって差が出やすいため、平面地図での表示だけを目的とするなら、まずは経度と緯度を正しく扱うことを優先したほうが安全です。高さを使う場合は、その値の基準、単位、取得方法をpropertiesや別資料で補足しておくと、後から誤解を防ぎやすくなります。
GeoJSONのcoordinatesで大切なのは、座標順、座標系、geometry型、配列の階層、点列の順序を一体として確認することです。地図上に表示されない、形が崩れる、意図しない場所に出るという問題の多くは、このどこかに原因があります。FeatureCollection全体を疑う前に、各Featureのgeometryをひとつずつ見直し、typeとcoordinatesが対応しているかを確認しましょう。
properties設計で検索・表示・集計の使いやすさが決まる
FeatureCollectionは、geometryだけでなくpropertiesの設計によって実務での使いやすさが大きく変わります。地図上に点や線や面を表示するだけなら、最低限geometryがあれば可能です。しかし、実際の業務では「未対応の点検箇所だけ表示したい」「工事中の区域を色分けしたい」「担当部署ごとに件数を集計したい」「特定の日付以降に更新されたデータだけ抽出したい」といった操作が必要になります。そのときに使われるのがpropertiesです。
propertiesは、Featureに関する属性情報を入れる場所です。項目名と値の組み合わせで表され、名称、分類、状態、管理番号、日付、担当、備考などを持たせられます。柔軟に書ける一方で、自由すぎるために設計が崩れやすい部分でもあります。最初に小さなサンプルだけで作ったpropertiesを、そのまま本番データに広げると、後から項目の不足や表記ゆれに悩まされることがあります。
たとえば、点検状態を表す項目に「完了」「確認済み」「済」「OK」が混在していると、人間には似た意味だと分かっても、機械的な検索や集計では別の値として扱われます。日付も「2026-05-26」「2026/5/26」「令和表記」「5月26日」のように混在すると、並べ替えや期間指定が難しくなります。数値であるべき項目に単位付きの文字列を入れると、合計や比較がしにくくなります。こうした問題は、地図表示の段階では気づきにくく、運用が進んでから表面化しやすいです。
propertiesを設計するときは、まず何に使う項目なのかを考えることが重要です。画面に表示するための項目なのか、検索に使う項目なのか、集計に使う項目なのか、外部の台帳と照合するための項目なのかによって、適切な名前や値の形式が変わります。表示用の名称は人が読みやすいことが大切ですが、検索や集計に使う分類値は表記を統一する必要があります。台帳連携に使う管理番号は、途中で変わらない安定した値であることが重要です。
項目名も慎重に決める必要があります。日本語の項目名でも扱える場合はありますが、複数の環境で利用する、外部の処理と連携する、長期的に運用する場合は、半角英数字を使った一貫した項目名にしておくと扱いやすくなります。たとえば、name、category、status、survey_date、asset_idのように、意味が分かりやすく、同じ規則で書かれた項目名にすると、後から処理を追加するときにも迷いにくくなります。ただし、組織内で日本語項目名を標準としている場合は、読みやすさや既存台帳との整合性を優先する判断もあり得ます。大切なのは、途中で揺れないことです。
propertiesには階層構造を持たせることもできますが、実務では単純な構造にしておくほうが扱いやすい場合が多いです。地図表示や簡単な検索、表形式での確認を前提にするなら、値は文字列、数値、真偽値、日付文字列などに整理しておくと便利です。複雑な入れ子構造を多用すると、表示側や変換処理で対応が必要になり、関係者がデータを確認しづらくなることがあります。
また、空欄や不明値の扱いも決めておくべきです。項目自体を省略するのか、nullを入れるのか、空文字にするのか、「不明」という文字列にするのかによって、後続処理の挙動が変わります。たとえば、未調査を表すのか、調査したが該当なしを表すのか、入力漏れなのかは区別できるほうが実務上は安全です。地図データは一度作って終わりではなく、現地確認、修正、承認、公開、更新といった流れの中で使われるため、状態を正しく表すproperties設計が重要になります。
色分けやアイコン変更にもpropertiesが使われます。地図表示では、statusが未対応なら目立つ色、完了なら落ち着いた色、重要度が高いなら大きな記号、分類が異なるなら別の線種というように、propertiesの値をもとに見た目を変えることができます。つまり、propertiesは単なる補足情報ではなく、地図を業務画面として機能させるための条件でもあります。
検索や集計を意識したproperties設計ができているFeatureCollectionは、後から活用範囲を広げやすくなります。最初は地図上で確認するだけだったデータを、次に一覧で管理し、さらに集計し、現場報告や進捗管理に使うことができます。逆に、propertiesが場当たり的だと、地図表示はできても、実務データとしての価値が伸びにくくなります。GeoJSONの使い方を学ぶときは、geometryの書き方だけでなく、propertiesをどう設計するかまで含めて考えることが大切です。
実務で壊れにくいFeatureCollectionを作る確認ポイント
FeatureCollectionを実務で使うときは、構造が正しいだけでなく、運用に耐えられるかを確認する必要があります。GeoJSONは人が読める形式なので、少量のデータであれば目視でも確認できます。しかし、数百件、数千件のFeatureを扱うようになると、手作業での確認には限界があります。最初から壊れにくい作り方を意識し、作成後に確認する習慣を持つことが重要です。
まず確認したいのは、JSONとして正しい形式になっているかです。括弧の閉じ忘れ、カンマの不足、余分なカンマ、引用符の不一致があると、GeoJSONとして読む前にJSONとして読み込めません。GeoJSONのエラーに見えても、実際にはJSON構文の問題であることがあります。特に手作業で編集した場合や、表形式のデータから変換した場合は、文字列内の記号や改行が原因で構文エラーになることがあります。
次に、FeatureCollectionとしての構造を確認します。最上位のtypeがFeatureCollectionになっているか、featuresが配列になっているか、featuresの中の各要素がFeatureになっているかを見ます。featuresの中にgeometryだけを直接入れてしまったり、Featureのtypeを省略したりすると、想定どおりに扱えない場合があります。GeoJSONは見た目が似ていても、階層の位置が違うだけで意味が変わるため、外枠から順に確認することが大切です。
各Featureについては、geometryが存在するか、geometryのtypeが有効か、coordinatesがtypeに合った構造になっているかを確認します。仕様上はgeometryがnullのFeatureもあり得ますが、地図上に表示する目的であれば、基本的には有効なgeometryが必要です。点として表示したいのにLineStringの構造になっている、Polygonなのに座標列が閉じていない、coordinatesの階層が足りないといった問題は、表示崩れや処理エラーの原因になります。
座標の範囲も確認しましょう。日本国内のデータであれば、経度と緯度がおおよそ想定範囲に入っているかを見るだけでも、緯度経度の逆転や桁の誤りに気づけます。測量や現地取得データを変換する場合、元の座標系がGeoJSONで想定するWGS 84の経度緯度と異なることもあります。その場合、単に数値を入れ替えるだけでは正しい位置になりません。元データの座標系、単位、変換方法を確認したうえでGeoJSON化する必要があります。
propertiesについては、必須項目が入っているか、値の型が揃っているか、分類値の表記ゆれがないかを確認します。たとえば、管理番号が空のFeatureがないか、statusに想定外の値が入っていないか、日付の形式が揃っているかを見ます。地図上に表示できるかどうかだけで確認を終えると、後から検索や集計を行う段階で問題が出ることがあります。FeatureCollectionを納品物や共有データとして扱うなら、propertiesの品質確認も欠かせません。
ファイルサイズにも注意が必要です。FeatureCollectionは複数の地物をまとめられる便利な形式ですが、非常に多くのFeatureや細かすぎる座標列を含むと、読み込みや表示が重くなることがあります。特にPolygonで細かな境界線をそのまま持たせる場合、座標点数が大きくなりやすいです。目的が概略表示であれば形状を適度に簡略化する、詳細表示が必要な範囲だけ別データに分ける、表示縮尺に応じてデータを切り替えるなどの工夫が必要になります。
更新運用も考えておく必要があります。FeatureCollectionを毎回全件作り直すのか、差分だけ更新するのか、現地で修正した内容をどのように反映するのかによって、データ設計は変わります。安定したasset_idやrecord_idのような識別項目があれば、既存データとの照合がしやすくなります。逆に、識別項目がないと、同じ地物が更新されたのか、新しく追加されたのか、削除されたのかを判断しにくくなります。
文字コードや改行も地味ですが重要です。日本語のpropertiesを含む場合、文字化けが起こると名称や備考が読めなくなります。複数の環境で受け渡す場合は、文字コードを統一し、特殊な記号や制御文字が混入しないように注意します。人が読むメモ欄に自由記述を許す場合でも、改行や引用符が変換時に問題を起こさないように処理する必要があります。
実務では、GeoJSONを作る人、確認する人、地図で使う人、現場で見る人が別々になることがあります。そのため、FeatureCollectionの中身だけでなく、項目定義や作成ルールを簡単に共有できる状態にしておくと運用が安定します。どのpropertiesが必須なのか、statusにはどの値が入るのか、日付はどの形式で書くのか、geometryは点なのか線なのか面なのかを関係者が理解できるようにしておくと、修正や追加のたびにデータ品質が崩れることを防げます。
壊れにくいFeatureCollectionを作るには、正しい構文、正しい構造、正しい座標、揃ったproperties、扱いやすいサイズ、更新しやすい識別情報のすべてを意識する必要があります。最初は少し手間に感じるかもしれませんが、この確認を習慣化すると、地図表示の不具合や集計ミス、現場との認識違いを大きく減らせます。GeoJSONを実務で使うなら、作成することと同じくらい、確認することが重要です。
まとめ：FeatureCollectionを現場データ活用の入口にする
GeoJSONのFeatureCollectionは、Featureをまとめて扱うための基本的な形式です。FeatureCollectionの中のfeaturesにFeatureを並べ、各Featureがgeometryとpropertiesを持つという構造を理解すれば、GeoJSONの読み書きはかなり見通しがよくなります。最初は括弧や配列の階層が複雑に見えるかもしれませんが、役割を分けて考えれば難しくありません。
FeatureCollectionは外枠、Featureは地物、geometryは形、propertiesは属性です。この関係を押さえるだけで、地図上に何が表示され、どの情報が詳細表示や検索に使われるのかを整理できます。点、線、面のどれで表すべきかを業務目的に合わせて選び、coordinatesを経度、緯度の順で正しく記述し、propertiesを検索や集計に使いやすい形で設計することが、実務で使えるGeoJSONにつながります。
特に、GeoJSONの使い方を調べている段階では、表示できることだけを目標にしがちです。しかし、業務で本当に必要になるのは、表示した後に活用できるデータです。未対応箇所を抽出する、区域別に集計する、現地調査の結果を更新する、別の台帳と照合する、関係者に分かりやすく共有する、といった場面では、geometryだけでなくpropertiesの設計と品質が効いてきます。
FeatureCollectionは、現場で集めた位置情報を単なる点の集まりで終わらせず、業務に使える地図データへ変える入口です。現地調査、設備管理、インフラ点検、工事管理、防災、まちづくり、施設管理など、位置と属性を結びつけたい場面では、FeatureCollectionの考え方が役立ちます。地図上に表示する対象が増えても、同じ構造で整理できるため、データの共有や再利用もしやすくなります。
これからGeoJSONを使い始めるなら、まずは小さなFeatureCollectionを自分で作り、Point、LineString、Polygonを試してみることをおすすめします。次に、propertiesへ業務で必要な項目を入れ、表示、検索、色分け、集計に使えるかを確認します。その過程で、座標順、座標系、geometry型、項目名、値の形式、更新方法の重要性が自然に理解できるはずです。
現場で取得した位置情報をGeoJSONとして活用したい場合は、取得から整理、共有までの流れを意識することが大切です。スマートフォン、GNSS機器、現場調査アプリ、既存台帳など、どの手段で位置情報を得る場合でも、最終的にFeatureCollectionとして扱いやすい形に整えられれば、表示、検索、共有、更新の流れを作りやすくなります。まずは小さく正しいGeoJSONを作り、業務に合わせてpropertiesと運用ルールを育てていきましょう。