GeoJSONは、点、線、面などの地理空間情報をJSON形式で表現するためのデータ形式です。Web地図、現地調査、台帳管理、区域管理、設備管理、写真位置情報の整理など、さまざまな実務で使われます。その中でもFeatureCollectionは、複数の地物をまとめて扱う基本的な構成です。単独の点や線を表すだけなら比較的単純ですが、複数の地物をひとつのファイルやデータとして扱う場合は、FeatureCollectionの構造を正しく理解しておく必要があります。
FeatureCollectionは見た目には単なるJSONですが、type、features、geometry、propertiesなどの配置が崩れると、地図上に表示されない、属性が読み込まれない、座標の位置がずれる、後工程で加工しにくいといった問題が起きやすくなります。特に実務では、現場で取得した点の記録、境界線、調査範囲、設備位置、写真位置などをまとめて管理する場面が多く、最初の構成ミスが後の確認作業や修正作業を増やします。
この記事では、geojsonで検索してFeatureCollectionの作り方を確認している実務担当者に向けて、構成確認で見るべき5つのポイントを整理します。単に形式を覚えるだけでなく、現場や業務データとして安全に扱うために、どこを確認し、どのような考え方でデータを組み立てるべきかを解説します。
FeatureCollection全体の基本構造を確認する
GeoJSONのFeatureCollectionを作るときに最初に確認したいのは、データ全体の最上位構造です。FeatureCollectionは、複数のFeatureをまとめるための入れ物です。そのため、最上位のtypeにはFeatureCollectionを指定し、featuresという配列の中に個々のFeatureを並べる構成になります。この基本形が崩れていると、地図表示やデータ変換の段階で正しく読み込まれないことがあります。
実務では、GeoJSONを手作業で作る場合だけでなく、測量データ、現地調査データ、表計算データ、写真位置情報、設備台帳などを変換してGeoJSON化する場面があります。その際、出力されたファイルが一見JSONとして成立していても、GeoJSONとして正しい構成になっているとは限りません。JSONの文法として正しいことと、GeoJSONとして正しいことは別に考える必要があります。
FeatureCollectionの最上位には、typeとfeaturesを置きます。typeはこのデータ全体が何を表すかを示す項目です。ここがFeatureCollectionではなくFeatureになっていると、複数地物のまとまりとして扱う前提が崩れます。逆に、featuresが存在しない、featuresが配列になっていない、featuresの中にFeature以外の値が混ざっている場合も、読み込み側でエラーになったり、空のデータとして扱われたりすることがあります。
たとえば、点のデータを100件まとめて管理する場合、FeatureCollectionは100個の点を最上位に直接並べるのではなく、100個のFeatureをfeatures配列の中に持ちます。それぞれのFeatureがgeometryとpropertiesを持ち、geometryが位置や形状を表し、propertiesが名称や分類などの属性を表します。この階層を意識すると、どこに座標を書き、どこに属性を書くべきかが明確になります。
よくあるミスとして、features配列の外側にgeometryを書いてしまうケースがあります。単独のFeatureであればFeatureの直下にgeometryがありますが、FeatureCollectionでは最上位にgeometryを置くのではなく、features配列の各Featureの中にgeometryを置きます。FeatureCollectionはあくまで複数Featureの集合であり、地物そのものの形状を直接表すものではありません。
また、FeatureCollection全体に業務名や作成日などの情報を持たせたくなることがあります。このような全体メタ情報は、各地物のpropertiesとは扱いが異なるため、利用する環境でどう扱われるかを確認しておく必要があります。GeoJSONでは追加のメンバーを持たせられる場合がありますが、多くの地図表示や一般的な読み込み処理では、各Featureのpropertiesが主に利用されます。全体情報を独自項目として持たせる場合でも、読み込み側が無視する可能性があることを前提に設計するのが安全です。
FeatureCollectionを正しく作るうえでは、まず最上位の入れ物、次にFeature、さらにgeometryとpropertiesという階層を頭に入れることが大切です。構造を曖昧にしたままデータを増やすと、後からどの項目がどの地物に対応しているのか分かりにくくなります。特に、現地調査や施工管理、設備点検のように後から確認する人が変わる業務では、構造の分かりやすさがそのまま運用のしやすさにつながります。
さらに、FeatureCollectionの構成を確認するときは、文字コードや拡張子だけに安心しないことも重要です。拡張子がgeojsonになっていても、中身が正しいGeoJSONとは限りません。反対に、JSONとして保存されていても、構成がGeoJSONに沿っていれば利用できる場合があります。大切なのは、ファイル名ではなく中身の階層と項目がGeoJSONの考え方に沿っているかどうかです。
実務で安定して使うには、最初に最小構成のFeatureCollectionを作り、それが表示や変換で問題なく動くことを確認してから、属性や地物数を増やしていく流れが有効です。最初から多くの地物や複雑な属性を入れると、不具合が起きたときに原因を切り分けにくくなります。まずは全体構造、次にFeature単位、最後に属性や座標の詳細という順番で確認すると、修正作業を減らせます。
FeatureCollectionは、GeoJSONの中でも実務利用の中心になりやすい構成です。だからこそ、最上位のtypeとfeaturesの意味を正しく理解し、FeatureCollectionが何を持ち、何を持たないのかを整理しておくことが、データ品質を守る第一歩になります。
features配列にFeatureを正しく並べる
FeatureCollectionの中心になるのがfeatures配列です。features配列には、個々の地物を表すFeatureを並べます。点、線、面のいずれであっても、FeatureCollectionの中ではまずFeatureとして扱われ、そのFeatureの中にgeometryとpropertiesを持たせるのが基本です。この構成を守ることで、地図上の形状と業務上の属性を一体として管理できます。
features配列で重要なのは、配列の中身がすべてFeatureとして整っていることです。ひとつのFeatureには、typeとしてFeatureを指定し、geometryで形状を示し、propertiesで属性を示します。Featureごとに構造が揃っていないと、読み込み側によっては一部だけ表示されない、属性だけ欠落する、途中のFeatureから処理が止まるといった問題が起きることがあります。
たとえば、あるFeatureではpropertiesが空のオブジェクトなのに別のFeatureでは必要な属性が入っている、あるFeatureのgeometryは正しいが別のFeatureのgeometryがnullになっている、Featureのtypeが抜けている、といった状態は注意が必要です。GeoJSONの仕様上、propertiesやgeometryにnullを使える場面はありますが、実務データとしては、なぜ空なのか、後工程で問題がないかを確認しておく必要があります。
Featureを並べる順番については、地図表示だけを見ると大きな影響がない場合もあります。しかし、業務データとしては順番が意味を持つことがあります。たとえば、調査順、測点番号順、路線方向順、区域ごとのまとまりなどです。地図上では同じように表示されても、確認作業や帳票化、差分確認の段階では、並び順が整理されているほうが扱いやすくなります。
特に、現地調査で取得した点データをFeatureCollectionにする場合、Featureごとに識別できる属性を持たせておくことが重要です。地図上に点が表示されても、それがどの測点、どの写真、どの設備、どの確認項目に対応するのか分からなければ、実務では使いにくいデータになります。Featureは単なる座標の入れ物ではなく、位置と業務情報を結びつける単位として考える必要があります。
features配列に複数種類のgeometryを混在させることもあります。たとえば、同じFeatureCollectionの中に点の設備位置、線の調査ルート、面の作業範囲を入れるようなケースです。GeoJSONとしては複数のgeometry型を含められますが、実務運用では注意が必要です。読み込み先や処理方法によっては、同じ種類のgeometryだけを前提にしていることがあります。その場合、混在データは表示や集計で不具合の原因になります。
そのため、FeatureCollectionを作る段階で、ひとつのデータに何をまとめるのかを決めておくことが大切です。すべてをひとつにまとめれば管理が楽に見える一方で、用途が違う地物を混ぜすぎると、後で分類や抽出が難しくなります。設備点、調査範囲、作業ルートなど、目的が異なる情報は、別のFeatureCollectionとして分けるか、propertiesの分類項目で明確に区別できるようにしておくと扱いやすくなります。
また、features配列が空のFeatureCollectionを作る場合もあります。これは構造としては成り立ちますが、実務上は空である理由を明確にしておく必要があります。たとえば、該当地物なし、調査前の初期データ、抽出条件に一致する地物なしなど、空の意味によって後工程の扱いが変わります。単なる出力ミスなのか、意図した空データなのかが分からない状態は避けるべきです。
Featureごとのpropertiesの項目名を揃えることも、features配列の確認では大切です。あるFeatureではname、別のFeatureでは名称、さらに別のFeatureではtitleのように項目名がばらばらだと、地図表示や検索、ラベル表示、集計で扱いにくくなります。人が見れば意味を推測できても、処理する側は別項目として扱う可能性があります。実務では、項目名の表記ゆれを早い段階で統一しておくことが重要です。
features配列の確認は、単にカンマや括弧の位置を見る作業ではありません。各Featureが業務上の1単位として成立しているか、形状と属性が対応しているか、並び順や分類が後から見ても分かりやすいかを確認する作業です。GeoJSONの構文だけを満たしていても、実務データとして使いにくければ、修正や再確認の手間が発生します。
FeatureCollectionを正しく作るには、features配列を地物の一覧としてだけでなく、業務で確認する対象の一覧として設計することが大切です。どのFeatureが何を表し、どの属性で識別でき、どの順番や分類で管理するのかを決めておくことで、地図表示だけでなく、確認、共有、修正、保管まで安定して行いやすくなります。
geometryの型と座標構造を取り違えない
GeoJSONで最もミスが起きやすい部分のひとつがgeometryです。geometryは地物の形状を表す項目で、Point、LineString、Polygon、MultiPoint、MultiLineString、MultiPolygon、GeometryCollectionなどの型があります。FeatureCollectionでは、それぞれのFeatureの中にgeometryを持たせ、そのgeometryのtypeとcoordinatesで位置や形状を表します。ここを正しく作らないと、地図上に表示されなかったり、意図しない場所に表示されたりします。
まず重要なのは、geometryの型によってcoordinatesの階層が変わることです。Pointはひとつの座標を持ちますが、LineStringは複数の座標を順番に持ちます。Polygonは外周や穴を表すため、さらに階層が深くなります。MultiPolygonになると、複数のPolygonをまとめるため、さらに配列の入れ子が増えます。見た目はどれも座標の並びに見えますが、型に応じた配列構造を守らなければなりません。
実務で多いのは、PointとLineStringの座標構造を混同するミスです。点データであればcoordinatesはひとつの座標値の組ですが、線データでは座標値の組を複数並べます。点のつもりで複数座標を入れてしまったり、線のつもりで座標配列の階層をひとつ浅くしてしまったりすると、読み込み側が正しく解釈できません。エラーにならない場合でも、意図しない表示になることがあります。
Polygonでは、外周線を閉じる必要がある点にも注意します。面を表す場合、外周の最初の座標と最後の座標を一致させることで閉じた形状として扱います。これが抜けていると、面として扱えない、補正されて別形状になる、表示環境によって結果が変わるといった問題につながります。境界、敷地、作業範囲、規制区域などの面データを扱う場合は、外周の閉じ方を必ず確認したいところです。
Polygonでは、外周と内側の穴の区別も重要です。複数のリングを持つ場合、最初のリングが外周になり、その後のリングが穴を表します。座標の並べ方やリングの向きは、表示環境によって扱いに差が出ることもあるため、複雑な面データでは実際の表示結果を確認しておくと安全です。
座標の順番も重要です。GeoJSONでは、経度、緯度の順で座標を記述します。日本語の実務では緯度、経度の順で話すことが多いため、データ作成時に入れ替えてしまうミスが起こりやすくなります。経度と緯度が逆になると、日本国内の点がまったく別の場所に表示されたり、表示範囲外になったりします。地図に点が出ない場合、座標順の入れ替わりは最初に疑うべき項目です。
また、座標参照の考え方にも注意が必要です。GeoJSONでは、WGS 84の経度緯度を十進度で扱う前提が基本です。平面直角座標やローカル座標をそのまま入れると、一般的なWeb地図上では正しい位置に表示されません。測量や施工管理の現場では、ローカル座標、工事座標、平面直角座標などを扱うことがありますが、それらをGeoJSONとしてWeb地図に重ねる場合は、座標変換の前提を確認する必要があります。
高さ情報を含める場合も、取り扱いには注意が必要です。GeoJSONのcoordinatesには、経度、緯度に加えて高さに相当する値を3番目の要素として含められます。ただし、表示や解析で高さが必ず利用されるとは限りません。三次元的な管理をしたい場合でも、利用する環境が高さをどう扱うかを確認し、必要に応じてproperties側にも標高や高さの属性を持たせておくと、後工程で確認しやすくなります。
geometryがnullになるケースもあります。これは、属性情報だけを持つFeatureや、まだ位置が確定していないFeatureを扱う場合に使われることがあります。ただし、地図表示を目的とするデータでは、geometryがnullのFeatureは表示対象にならないことが多いです。実務では、geometryがnullでよいのか、位置情報の欠落なのか、未測定なのかを明確にしておく必要があります。
LineStringやPolygonでは、座標の順序が形状の意味に関わります。線であれば始点と終点、路線方向、調査の進行方向などに影響します。面であれば外周や内側の穴の扱いに関係します。単に座標が集まっていればよいのではなく、どの順番で並べるかが重要です。現場で取得した順番をそのまま使うのか、図面上の順番に並べ替えるのか、業務目的に合わせて決める必要があります。
geometryの型を選ぶときは、見た目だけで判断しないことも大切です。たとえば、複数の点をまとめたいからといってMultiPointにするのが常に適切とは限りません。それぞれの点に別々の属性を持たせたい場合は、PointのFeatureを複数作り、FeatureCollectionとしてまとめるほうが扱いやすいことがあります。MultiPointにすると、複数点がひとつのFeatureになるため、点ごとに異なる名称や状態を持たせにくくなります。
同じように、複数の区域をひとつのMultiPolygonとして扱うべきか、PolygonのFeatureを複数作るべきかも、業務上の意味で判断します。ひとつの管理対象が飛び地を持つならMultiPolygonが自然な場合があります。一方、別々の区域として管理するなら、PolygonのFeatureを分けたほうが検索や更新がしやすくなります。GeoJSONの型は、表示のためだけでなく、管理単位を表すものとして考えると判断しやすくなります。
geometryの確認では、型、座標の階層、座標順、閉じ方、座標参照、管理単位を総合的に見ることが必要です。FeatureCollection全体が正しくても、個々のgeometryに誤りがあれば、実務上は使えないデータになります。特に現地データをWeb地図や台帳に連携する場合は、最初に数件だけを表示して位置と形状を目視確認し、その後に全件を処理する流れが安全です。
GeoJSONはテキスト形式なので修正しやすい反面、座標構造の入れ子や順番のミスは見落としやすいです。geometryはFeatureCollectionの中で最も地図表示に直結する部分です。地物の種類に合った型を選び、coordinatesの階層を正しく作り、座標の前提を揃えることが、FeatureCollectionを正しく作るうえで欠かせない確認項目です。
propertiesに業務で使う属性を整理する
FeatureCollectionを実務で使う場合、geometryと同じくらい重要なのがpropertiesです。geometryが地物の位置や形状を表すのに対し、propertiesはその地物が何であるか、どのような状態か、どの業務に関係するかを表します。地図上に点や線や面が表示されても、propertiesが整理されていなければ、業務で使える情報にはなりにくいです。
propertiesには、名称、管理番号、分類、状態、確認日、担当区分、写真番号、備考など、業務に必要な属性を入れます。どの項目を入れるかは用途によって異なりますが、重要なのはFeatureごとに同じ考え方で項目をそろえることです。同じ意味の属性に複数の項目名を使うと、検索、集計、ラベル表示、条件抽出のときに扱いにくくなります。
たとえば、設備位置のGeoJSONを作る場合、設備名、管理番号、種別、点検状態、更新日などをpropertiesに入れることが考えられます。境界や区域のGeoJSONであれば、区域名、用途、管理区分、確認状況、作成根拠などが必要になるかもしれません。現地写真の位置を扱う場合は、写真番号、撮影方向、撮影日、対象物、メモなどが有効です。いずれの場合も、後で誰が見ても意味が分かる項目名にしておくことが大切です。
propertiesの値には、文字列、数値、真偽値、nullなどを使うことがあります。ただし、値の型がFeatureごとにばらつくと、処理時に問題が起きることがあります。あるFeatureでは管理番号が数値、別のFeatureでは文字列になっている場合、並べ替えや検索で意図しない結果になることがあります。番号に先頭ゼロが必要な場合や、数字に見えても識別子として扱いたい場合は、文字列として統一したほうが安全です。
日付の扱いも注意が必要です。確認日や作成日をpropertiesに入れる場合、表記ゆれがあると後で集計しにくくなります。年、月、日の順番や区切り記号を統一し、時刻やタイムゾーンが必要かどうかも事前に決めておくとよいです。現場メモとして人が読むだけなら多少のゆれが許容されることもありますが、後で抽出や並べ替えをするなら、機械的に処理しやすい表記が望まれます。
propertiesに入れる情報は、多ければよいわけではありません。不要な属性を大量に入れると、データが重くなり、確認もしにくくなります。また、個人情報や公開に適さない情報が混ざるリスクも高まります。GeoJSONは共有や公開に使われることも多いため、外部に出してよい情報か、内部管理に限る情報かを区別しておく必要があります。公開用と内部用でpropertiesの項目を分ける運用も有効です。
逆に、属性が少なすぎると、地図上では表示できても実務で判断できないデータになります。点が表示されているだけで、何の点か分からない、いつ確認したものか分からない、更新対象かどうか分からないという状態では、再確認の手間が発生します。FeatureCollectionを作る前に、そのデータを使って何を判断したいのかを考え、最低限必要なpropertiesを定義しておくことが重要です。
propertiesでは、分類項目の値も統一しておきたいところです。たとえば、状態を表す値として、正常、異常、要確認、未確認などを使う場合、表記ゆれや略称の混在を避けます。正常、問題なし、OKなどが混在すると、人が見る分には分かっても、条件抽出では別の値として扱われます。業務で使う分類は、入力前に選択肢を決めておくと品質を保ちやすくなります。
また、propertiesに長い文章を入れすぎると、地図表示の吹き出しや一覧表示で読みにくくなることがあります。備考欄は便利ですが、何でも入れる場所にすると、後で整理しにくくなります。重要な情報は専用項目として分け、補足だけを備考に入れる形にすると、検索や確認がしやすくなります。たとえば、点検結果、対応要否、写真番号、担当区分などは、備考にまとめず個別の属性にしたほうが扱いやすい場合があります。
geometryとpropertiesの対応関係も確認が必要です。座標はA地点なのにpropertiesはB地点の名称になっている、写真番号と位置がずれている、区域名と面形状が一致していないといったミスは、構文チェックでは見つかりにくい問題です。データ変換や結合を行った後は、数件を抽出して地図上の位置と属性の内容を目視確認することが大切です。
propertiesの項目名には、できるだけ分かりやすく、処理しやすい名前を使います。日本語項目名が使える場面もありますが、利用する環境によっては文字化けや扱いにくさが出ることがあります。英数字の項目名にして、表示名や凡例で日本語を使う方法もあります。どちらがよいかは運用環境によりますが、少なくとも同じデータ内で表記方針を混在させないことが大切です。
FeatureCollectionを長期的に使うなら、propertiesの設計を簡単なルールとして残しておくとよいです。どの項目が必須で、どの項目が任意か、値の型は何か、分類の選択肢は何か、空欄を許容するかなどを決めておくと、複数人でデータを作成しても品質を揃えやすくなります。GeoJSONは柔軟な形式ですが、柔軟であるほど運用ルールがないとばらつきやすくなります。
propertiesは、FeatureCollectionを業務データとして成立させるための要です。地図に表示するだけならgeometryが中心に見えますが、実際の確認、検索、報告、更新、引き継ぎではpropertiesの整理度が大きく影響します。どの属性を持たせるか、どう表記をそろえるか、どこまで共有するかを考えて作ることで、GeoJSONの活用範囲は大きく広がります。
作成後の検証と運用前チェックを行う
GeoJSONのFeatureCollectionは、作った時点で終わりではありません。実務で使う前に、構文、構造、座標、属性、表示結果を確認する必要があります。特に複数のデータを変換、結合、編集して作成したFeatureCollectionでは、見た目には問題がなさそうでも、一部のFeatureだけ構造が崩れていることがあります。運用前の検証を行うことで、後からの手戻りを減らせます。
まず確認したいのは、JSONとして文法が成立しているかどうかです。括弧の閉じ忘れ、カンマの不足や余分なカンマ、引用符の抜け、文字列の不整合などがあると、GeoJSONとして読み込む前にエラーになります。手作業で編集した場合はもちろん、別形式から変換した場合でも、途中で不要な文字や改行が混ざることがあります。最初に構文レベルの確認を行うことが基本です。
次に、GeoJSONとしての構造を確認します。最上位のtypeがFeatureCollectionになっているか、featuresが配列になっているか、各Featureにtype、geometry、propertiesがあるか、geometryのtypeとcoordinatesが対応しているかを見ます。JSONとして正しくても、GeoJSONの構造として誤っていれば、地図表示や変換処理では期待どおりに動きません。
座標の確認では、表示位置が実際の場所と合っているかを必ず見ます。特に、経度と緯度の順番が逆になっていないか、座標系の変換が必要なデータをそのまま入れていないか、日本国内のデータなのに海外や海上に表示されていないかを確認します。1件だけでは気づきにくい場合もあるため、範囲の端にある地物、中心付近の地物、代表的な地物をいくつか選んで確認するとよいです。
線や面のデータでは、形状の崩れも確認します。LineStringで点の順番が入れ替わっていると、線が折り返したり、不要な交差が出たりします。Polygonでは外周が閉じていない、座標順が不自然、穴の扱いが誤っているなどにより、面が想定と違う形で表示されることがあります。地図上で表示されたから問題なしと判断せず、業務上の境界や範囲と一致しているかを確認することが重要です。
propertiesについては、必須項目が入っているか、項目名が揃っているか、値の型や表記が統一されているかを確認します。たとえば、分類項目に表記ゆれがないか、日付形式が揃っているか、管理番号が欠落していないか、空欄が許容される項目かどうかを見ます。地図表示では気づきにくい属性ミスも、検索や一覧化の段階で問題になります。
データ量にも注意が必要です。Feature数が多いFeatureCollectionは、表示や読み込みに時間がかかることがあります。すべてをひとつのファイルにまとめるほうが管理しやすい場合もありますが、用途や範囲ごとに分割したほうが扱いやすい場合もあります。現地確認用、公開用、保管用、解析用など、目的に応じてデータの粒度を調整すると運用しやすくなります。
更新運用を考える場合は、Featureを一意に識別できる項目を用意することが大切です。地物の名称だけでは重複することがあり、位置だけでは変更時に追跡しにくいことがあります。共通して使うIDや管理番号を決めておくと、差分確認、修正履歴、再出力、外部データとの突合がしやすくなります。仕様上のidメンバーを使うのか、properties内の管理番号を使うのかは、利用環境と業務ルールに合わせて統一します。
共有前には、不要な情報が含まれていないかも確認します。GeoJSONはテキストとして中身を見られるため、propertiesに内部メモ、個人名、非公開の管理情報、不要なファイルパスなどが残っていると、そのまま外部に伝わってしまう可能性があります。公開や納品に使う場合は、表示に必要な属性と内部管理用の属性を分け、共有前に整理することが大切です。
ファイル名や管理方法も運用前チェックに含めると効果的です。FeatureCollectionの中身が正しくても、ファイル名で内容や作成日、対象範囲が分からないと、後から探し直す手間が増えます。更新版が複数ある場合は、どれが最新か分からなくなることもあります。データの内容、対象範囲、作成日、用途が分かる命名ルールを決めておくと、チーム内での共有がスムーズになります。
また、作成したFeatureCollectionを別の環境で読み込むことも確認しておくと安心です。作成時に使った環境では表示できても、別の地図表示環境や変換処理では一部の属性やgeometryが期待どおりに扱われないことがあります。特に、特殊な属性構造、深い入れ子、geometryの混在、大きなデータ量を含む場合は、実際の利用先で確認することが重要です。
検証では、全件を目視で確認するのが難しい場合もあります。その場合は、代表点だけでなく、異常が起きやすいデータを意識して確認します。座標値が空に近いもの、属性が空欄のもの、形状が複雑な面、複数部分に分かれる地物、範囲の端にある地物などを優先して見ると、問題を見つけやすくなります。単純なデータだけを確認しても、複雑なデータの不具合は残りやすいです。
FeatureCollectionの品質は、作成直後の一度の確認だけでなく、運用の中で保つものです。新しいFeatureを追加する、属性を更新する、座標を修正する、別形式に変換するたびに、構造や整合性が崩れる可能性があります。更新手順を決め、修正後に確認する項目を固定しておくことで、長期的に安定したGeoJSONデータを維持できます。
最後に、現場で取得した位置情報をFeatureCollectionとして活用する場合は、取得時点の精度や記録方法も重要になります。あとからGeoJSONの構造を整えても、元の位置情報や属性記録が曖昧だと、実務で使えるデータにはなりにくいです。現地での取得、属性入力、写真記録、データ整理までを一連の流れとして考えることで、FeatureCollectionの品質は大きく向上します。
まとめ
GeoJSONのFeatureCollectionを正しく作るには、最上位の構造、features配列、geometry、properties、作成後の検証を順番に確認することが大切です。FeatureCollectionは複数の地物をまとめる便利な形式ですが、自由度が高い分、構成の誤りや表記ゆれが入り込みやすい形式でもあります。見た目の地図表示だけで判断せず、業務データとして後から確認、検索、更新、共有できる状態になっているかを意識する必要があります。
最上位では、typeがFeatureCollectionになっているか、featuresが配列として正しく用意されているかを確認します。features配列では、各Featureが地物の1単位として成立しているか、geometryとpropertiesが対応しているかを見ます。geometryでは、型に応じたcoordinatesの階層、経度緯度の順番、面の閉じ方、座標参照の前提を確認します。propertiesでは、業務に必要な属性を過不足なく整理し、項目名や値の表記を揃えることが重要です。
また、作成後には構文チェックだけでなく、実際の表示、座標位置、属性の欠落、分類の表記ゆれ、共有前の不要情報の有無まで確認します。GeoJSONはテキスト形式で扱いやすい一方、少しの構造ミスが後工程に影響します。最初に確認項目を決め、データ作成と検証の流れを標準化しておくことで、地図表示だけでなく、現場管理、台帳整理、区域確認、点検記録などにも活用しやすくなります。
特に現地で取得した位置情報や写真記録をGeoJSONとして整理する場合は、取得時点から管理しやすい形にしておくことが重要です。現場での座標取得、写真とのひも付け、属性入力、後からの地図化までを一連の業務として考えると、FeatureCollectionの作成精度と運用効率が高まります。特定の製品やサービスに依存せず、座標の前提、属性の定義、共有範囲、検証手順を揃えておくことが、長く使えるGeoJSONデータを作るための基本になります。