GeoJSONのpropertiesを活用する実例と設計のコツ5つ

GeoJSONを実務で扱うとき、形状を表すgeometryに意識が向きがちですが、運用で効いてくることが多いのはpropertiesの設計です。点、線、面などの位置情報だけでは、地物が何を意味するのか、どの工程で使うのか、どの属性で絞り込むのか、どの時点の記録なのかが分かりません。propertiesを適切に持たせることで、地図表示、検索、色分け、点検記録、帳票化、外部データ連携まで一貫して扱いやすくなります。この記事では、geojsonで検索する実務担当者に向けて、propertiesを活用する具体例と、後から困らない設計のコツを5つに分けて解説します。

目次

• propertiesは地物の意味を伝える属性欄として設計する

• 表示用と管理用の情報を分けて考える

• 現場点検や設備管理でpropertiesを活用する

• 検索・色分け・集計に使いやすい値に整える

• 長く運用できるproperties設計にする

propertiesは地物の意味を伝える属性欄として設計する

GeoJSONは、位置や形状を表すための形式として使われます。点であれば座標、線であれば折れ線、面であれば範囲を表すことができます。ただし、geometryだけを見ても、その地物が何を示しているのかは分かりません。現場で撮影した写真の位置なのか、道路附属物の位置なのか、調査範囲の境界なのか、危険箇所の記録なのかは、座標だけでは判断できないからです。

そこで重要になるのがpropertiesです。GeoJSONのFeatureにはgeometryとpropertiesを持たせることができ、propertiesにはそのFeatureに関する属性情報を入れます。たとえば、地物名、種別、管理番号、状態、確認日、担当区分、備考などを持たせることで、地図上の図形に業務上の意味を与えられます。GeoJSONを単なる座標データとして扱うか、実務で使える管理データとして扱うかは、propertiesの設計で大きく変わります。

たとえば、道路沿いの点検対象をGeoJSONで管理する場合、点の座標だけを保存しても、後から見た人はそれが標識なのか、照明柱なのか、排水ますなのか判断できません。propertiesにtypeとして「標識」、nameとして「案内標識」、statusとして「要確認」、checked_atとして確認日を入れておけば、地図上で表示するだけでなく、未確認箇所だけを抽出したり、種別ごとに色を変えたりできます。

propertiesを設計するときは、まず「この地物を見た人が何を判断したいか」を考えることが大切です。地図画面に名称を出したいだけならnameがあれば足りるかもしれません。しかし、点検対象として管理するなら、管理番号、点検日、状態、対応優先度、担当者区分なども必要になります。さらに、後で集計するなら、自由入力の文章だけでなく、分類しやすいコードや定型値も必要です。

GeoJSONのpropertiesは自由度が高く、任意のキーと値を入れられます。この自由度は便利ですが、同時に設計が乱れやすい原因にもなります。同じ意味の項目にname、Name、名称、labelなど複数のキーが混在すると、表示や検索の処理が複雑になります。また、あるFeatureではstatusが「完了」、別のFeatureでは「確認済」、さらに別のFeatureでは「OK」となっていると、同じ状態を表しているつもりでも、集計上は別の値として扱われることがあります。

そのため、propertiesは思いつきで追加するのではなく、地物の種類ごとに必要な項目を整理してから使うのが安全です。最低限の設計として、表示名として使うname、分類に使うtype、状態を示すstatus、更新や確認の時点を示すdate系の項目を検討するとよいです。地物を一意に識別する値は、GeoJSONのFeatureが持てるidメンバーとして管理する方法もありますし、台帳連携用のasset_idやmanagement_idとしてpropertiesに持たせる方法もあります。重要なのは、業務目的に対して必要な項目が過不足なく入っており、同じ意味の値が同じ形式で入っていることです。

実務では、propertiesを人間が読むためだけのメモ欄にしてしまうケースがあります。備考欄に「北側の古い標識。少し傾きあり。次回確認」とまとめて書くと、画面上で読むには便利です。しかし、後で「傾きあり」の対象だけを抽出したい場合や、「次回確認」が必要なものだけを一覧化したい場合には扱いづらくなります。文章として残す情報と、検索や集計に使う情報は分けて持たせる方が実務向きです。

propertiesの活用は、地図を見やすくするためだけではありません。調査記録を引き継ぐ、現場と事務所で同じ情報を参照する、将来の更新作業に備える、他の形式へ変換する、といった場面でも効いてきます。GeoJSONを一度作って終わりにするのではなく、更新しながら使うデータとして考えるなら、propertiesは最初から業務データの一部として設計しておくべきです。

表示用と管理用の情報を分けて考える

GeoJSONのpropertiesでよくある失敗は、地図に表示するための項目と、管理のために必要な項目が混ざってしまうことです。地図画面では短い名称や色分け用の分類が重要ですが、管理台帳では正式名称、管理番号、点検履歴、状態区分、対応予定などが必要になります。両者を区別せずに設計すると、表示には長すぎる値が入ったり、逆に管理には情報が不足したりします。

表示用のpropertiesは、地図上で瞬時に判断できることを重視します。たとえばlabelには短い表示名を入れ、categoryには色分けに使う大分類を入れ、priorityには強調表示に使う優先度を入れるといった考え方です。地図画面では一度に多くの地物が表示されるため、propertiesの値が長すぎると見づらくなります。表示用の名称は短く、分類は分かりやすく、状態は一目で判断できる値にしておくと扱いやすくなります。

一方、管理用のpropertiesは、地物を安定して追跡できることを重視します。管理番号、台帳番号、調査番号、更新日、確認者区分、資料番号などは、画面上で常に表示しなくても、データ管理上は重要です。特に、同じ名称の地物が複数ある場合や、点検のたびに状態が変わる場合は、表示名だけでは履歴を追えません。propertiesに台帳と対応する識別子を持たせておくことで、後から更新や照合を行いやすくなります。

たとえば、現場写真の撮影地点をGeoJSONで管理する場合、表示用には「写真番号」「撮影方向」「確認状態」があれば十分に見えるかもしれません。しかし、管理用には撮影日時、撮影者区分、対象工種、関連する測点、ファイル名、写真の保存先を示す内部参照情報などが必要になることがあります。表示用の情報だけで作ると、現場では便利でも、整理や納品前確認の段階で情報不足になりやすいです。

propertiesの設計では、画面に出す項目と裏側で持つ項目を分けて考えると整理しやすくなります。たとえばdisplay_nameは地図ラベル用、official_nameは正式名称用、categoryは表示色用、asset_typeは管理分類用というように、用途を明確に分けます。名称が似た項目を増やしすぎるのは避けるべきですが、用途が違う情報を無理に一つの項目へ押し込むと、かえって運用しにくくなります。

また、表示用の値は変わる可能性がありますが、管理用の識別子はできるだけ変えない方が安全です。地図上のラベルは分かりやすさのために修正されることがあります。略称から正式名に変えることもありますし、現場での呼び方に合わせて変えることもあります。しかし、idや管理番号まで変えてしまうと、過去の記録や外部データとの紐付けが切れるおそれがあります。propertiesの中でも、変更してよい項目と固定すべき項目を意識しておくことが大切です。

実務では、ひとつのGeoJSONを複数の用途で使い回すことがあります。現場確認用の地図、社内共有用の地図、報告資料用の地図、点検台帳との照合などです。このとき、propertiesが表示専用に偏っていると、管理や照合に使いにくくなります。逆に管理項目ばかりで表示に必要な短いラベルがないと、地図画面が分かりにくくなります。最初から複数の利用場面を想定し、必要な項目を役割ごとに分けておくと、後工程での手戻りを減らせます。

propertiesに入れる値は、利用する人の立場でも見直す必要があります。現場担当者は「どこを確認すればよいか」「優先度は高いか」「前回の状態はどうだったか」を知りたいことが多いです。管理担当者は「台帳と一致するか」「更新日はいつか」「未対応件数はいくつか」を重視します。報告書を作る人は「分類ごとの件数」「位置図に出す名称」「説明に使える備考」を求めます。これらをすべて一つの自由記述欄で済ませるのではなく、propertiesの項目として整理しておくことで、同じGeoJSONを多目的に使いやすくなります。

現場点検や設備管理でpropertiesを活用する

propertiesの実例として分かりやすいのが、現場点検や設備管理です。GeoJSONは、点、線、面の地物を扱えるため、点検対象の位置、管理路線、調査範囲、危険箇所、施工範囲などを表すのに向いています。そこにpropertiesを加えることで、地図上の図形を点検記録や管理情報として扱えるようになります。

点のFeatureでは、標識、照明、ます、境界標、写真撮影位置、異常発見箇所などを管理できます。propertiesには、対象種別、管理番号、状態、確認日、対応方針、備考などを入れると実務で使いやすくなります。たとえばstatusに「未確認」「確認済」「要対応」「対応済」のような状態を持たせておけば、地図上で色分けしたり、要対応だけを抽出したりできます。priorityに優先度を持たせれば、巡回順序や対応計画にも使えます。

線のFeatureでは、道路区間、河川沿いの確認区間、配線経路、通行ルート、調査動線などを表せます。propertiesには、区間名、延長、管理区分、通行可否、調査状況、起終点の説明などを持たせると便利です。線データは、単に位置を示すだけでなく、区間ごとの状態管理に使われることが多いため、どの区間が対象で、どの区間が完了しているかをpropertiesで明確にしておくと、進捗管理にもつながります。

面のFeatureでは、調査範囲、施工範囲、危険区域、土地利用区分、立入制限範囲などを扱えます。propertiesには、範囲名、用途、面積区分、確認状況、制限内容、対象期間などを持たせることがあります。面データは見た目の印象が強いため、地図上で範囲を表示するだけで分かった気になりがちです。しかし、実際にはその範囲が何のための範囲なのか、いつ時点の情報なのか、どの資料に基づくのかをpropertiesで補う必要があります。

現場点検のGeoJSONでは、状態の更新が頻繁に起こります。最初は「未確認」だったものが、現地確認後に「確認済」になり、異常があれば「要対応」になり、補修後に「対応済」になるといった流れです。このような運用では、statusだけでなく、checked_at、updated_at、noteなどの項目を持たせておくと、いつの確認で状態が変わったのかを追いやすくなります。ただし、個人名の扱いには組織のルールや公開範囲への配慮が必要です。外部共有するGeoJSONでは、個人を直接特定する情報を入れず、担当部署や担当区分などに置き換える方が安全な場合があります。

設備管理では、propertiesの設計が台帳との連携に直結します。台帳側に管理番号があるなら、GeoJSON側にも同じ番号を持たせることで、地図と台帳を照合しやすくなります。逆に、GeoJSON側だけで独自の番号を振ってしまうと、後から台帳と突き合わせるときに手間が増えます。すでに運用中の台帳や既存資料がある場合は、propertiesを新しく考える前に、既存の管理項目と対応関係を確認することが重要です。

写真やメモとの連携でもpropertiesは役立ちます。たとえば、撮影地点を点データとして保存し、propertiesにphoto_id、photo_date、direction、target_type、commentなどを持たせると、写真整理の起点になります。ここで重要なのは、写真そのものをGeoJSONに無理に詰め込むのではなく、写真を識別するための情報や関連付けのための値を持たせることです。GeoJSONは地図データとして扱いやすい形式ですが、大量の画像データを直接含める用途には向きません。位置と属性を結び付ける役割としてpropertiesを使う方が、データの見通しがよくなります。

現場で使うGeoJSONは、通信環境や端末性能、表示する地物数の影響も受けます。propertiesに大量の文章や不要な項目を詰め込みすぎると、データサイズが大きくなり、表示や読み込みに影響することがあります。すべての情報をpropertiesに入れるのではなく、地図上で必要な情報、検索や集計に必要な情報、外部データと結び付けるための情報に絞って設計することが大切です。詳細な記録は別の台帳やデータベースで管理し、GeoJSONには参照用の識別子を持たせる考え方も有効です。

検索・色分け・集計に使いやすい値に整える

propertiesを実務で活用するうえで、値の整え方は非常に重要です。同じ項目を持っていても、値の書き方がばらばらだと検索や集計に使いにくくなります。たとえばstatusに「要対応」「要 対応」「対応必要」「修繕必要」「NG」が混在していると、人間が読めば似た意味だと分かっても、機械的には別の値として扱われます。地図上で要対応だけを色分けしたいときや、件数を集計したいときに、条件設定が複雑になります。

検索や色分けに使う項目は、できるだけ定型値にするのが基本です。statusであれば「未確認」「確認済」「要対応」「対応済」のように、使う値をあらかじめ決めておきます。typeであれば「標識」「照明」「排水」「境界」など、分類の粒度を決めます。priorityであれば「高」「中」「低」や数値の1、2、3など、並べ替えや絞り込みに使いやすい形式を選びます。自由入力は備考欄に残し、分類や状態は定型値で管理するのが実務向きです。

色分けを前提にする場合は、分類の粒度を細かくしすぎないことも大切です。typeが細かすぎると、表示色や凡例が増えすぎて、地図が読みづらくなります。たとえば設備種別を細分化しすぎると、色の違いが多くなり、現場で直感的に判断しにくくなります。地図表示では大分類を使い、詳細分類は別項目として持たせると整理しやすくなります。categoryを表示用の大分類、detail_typeを詳細な管理分類として分けるような考え方です。

日付の形式も統一しておく必要があります。確認日や更新日をpropertiesに入れる場合、あるFeatureでは「2026/5/1」、別のFeatureでは「2026-05-01」、さらに別のFeatureでは「5月1日」といった形式が混在すると、並べ替えや期間抽出が難しくなります。実務では、人間が読みやすい表記よりも、処理しやすく誤解が少ない形式を優先した方が安全です。年月日を一定の形式に統一し、時刻まで必要な場合はタイムゾーンを含めるかどうかもルール化しておきます。

数値をpropertiesに入れる場合も、単位をどう扱うかを決めておく必要があります。たとえば延長、面積、高さ、幅、距離などを入れる場合、値に「m」や「平方メートル」といった文字を混ぜると、数値として集計しにくくなります。数値は数値として入れ、単位は項目名や別項目で分かるようにする方が扱いやすいです。length_mのように項目名で単位を示す方法もあります。ただし、組織内の命名規則がある場合は、それに合わせることが重要です。

真偽値の扱いにも注意が必要です。たとえば、確認済みかどうかを表す項目に「はい」「有」「済」「true」「1」が混在すると、条件分岐が複雑になります。GeoJSONのpropertiesでは文字列、数値、真偽値、配列、オブジェクト、nullなどJSONで扱える値を使えますが、同じ項目では同じ型に揃えるのが基本です。is_checkedを真偽値として使うなら、すべてのFeatureで同じ考え方にします。statusのような状態項目と、is_checkedのような真偽値項目を併用する場合は、意味が重複しないように注意します。

検索性を高めるためには、名称や備考に頼りすぎないことも大切です。たとえばnameに「北側標識 要補修」と入れておけば、人間には分かりやすいかもしれません。しかし、名称の中に状態を混ぜてしまうと、状態が変わったときに名称も修正する必要があります。さらに、名称検索と状態検索が混ざり、データの意味が不安定になります。nameは地物名、statusは状態、noteは補足説明というように、情報の置き場所を分けることで、更新や検索が安定します。

集計を意識する場合は、空欄や未設定の扱いも決めておきます。propertiesに項目が存在しないFeatureと、項目はあるが値が空のFeatureと、値が「不明」のFeatureでは意味が異なります。未調査なのか、該当しないのか、入力漏れなのかが分からないと、集計結果の信頼性が下がります。実務では、未確認、該当なし、不明などを区別して扱う必要がある場面があります。すべてを空欄で済ませず、必要に応じて定型値として表現すると、後で判断しやすくなります。

propertiesは、地図表示のための飾りではなく、検索条件や集計軸になります。最初に地図で見えることだけを優先すると、後から一覧化、抽出、件数確認、状態管理をしたいときに困ります。特に、複数人で入力するデータでは、値のルールがないとすぐに表記ゆれが発生します。入力前に項目名、値の候補、日付形式、数値単位、空欄の扱いを決めておくことが、properties活用の土台になります。

長く運用できるproperties設計にする

GeoJSONのpropertiesは、作成した時点だけでなく、更新、共有、変換、引き継ぎまで見据えて設計することが重要です。短期的な地図作成であれば、必要な項目をその場で入れるだけでも使えます。しかし、点検管理、設備管理、工事記録、調査成果のように継続利用するデータでは、後から見ても意味が分かり、別の担当者が更新しても破綻しにくい設計が必要です。

長く運用するための第一のコツは、項目名を分かりやすく安定させることです。propertiesのキー名は自由に決められますが、自由だからこそルールが必要です。短すぎる略称は作成者以外に意味が伝わりにくく、長すぎる項目名は扱いにくくなります。たとえばstだけではstatusなのかstreetなのか分かりません。逆に、現場確認状態区分名のように長くしすぎると、処理や確認のたびに負担になります。英数字で統一するのか、日本語キーを使うのかも含め、組織や案件内で一貫させることが大切です。

第二のコツは、後から増える項目を想定しておくことです。最初はnameとtypeだけで足りると思っていても、運用が進むとstatus、priority、checked_at、source、noteなどを追加したくなることがあります。項目追加自体は問題ではありませんが、既存データとの整合が取れなくなると運用が崩れます。新しい項目を追加するときは、既存Featureにも同じ項目を入れるのか、未設定を許容するのか、過去データをどこまで更新するのかを決めておく必要があります。

第三のコツは、データの由来を残すことです。GeoJSONは複数の資料や現地確認結果をもとに作られることがあります。propertiesにsourceやsurvey_dateのような情報を持たせておくと、そのFeatureが何に基づく情報なのかを追いやすくなります。特に、設計資料、現況確認、過年度資料、現地調査が混在する場合、由来が分からないデータは判断に使いにくくなります。ただし、出典情報や内部資料名を外部公開データに含めてよいかは、共有範囲に応じて確認が必要です。

第四のコツは、公開用と内部用を分けることです。内部管理では必要なpropertiesでも、外部共有や公開には適さない情報があります。個人を特定できる情報、内部の連絡先、非公開の管理番号、詳細な脆弱箇所、契約や権利に関わる情報などは、共有先によっては削除や置き換えが必要です。GeoJSONはテキスト形式で中身を確認しやすいため、意図せずpropertiesに不要な情報を残したまま渡してしまうリスクもあります。共有前には、geometryだけでなくpropertiesの中身も確認することが欠かせません。

第五のコツは、他形式への変換を意識することです。GeoJSONは扱いやすい形式ですが、実務では表計算形式、台帳形式、別の地理空間データ形式、報告用資料などへ変換することがあります。このとき、propertiesの項目名や値が整理されていれば、変換後も意味を保ちやすくなります。逆に、ひとつの項目に複数の意味が混ざっていたり、値の表記がばらばらだったりすると、変換後に手作業で修正することになります。GeoJSONを最終成果ではなく、中間データや連携データとして使う場合ほど、propertiesの整備が重要です。

長期運用では、propertiesの設計内容を別途メモとして残すことも有効です。どの項目が何を意味するのか、どの値を使うのか、空欄は何を意味するのか、更新時に変更してよい項目はどれかを整理しておくと、担当者が変わっても運用を続けやすくなります。GeoJSONファイルだけを渡されても、項目の意味が分からなければ正しく使えません。簡単な項目定義を用意しておくことは、データ品質を守るための実務的な対策です。

また、propertiesの肥大化にも注意が必要です。便利だからといって、将来使うかもしれない項目を大量に入れると、データが重くなり、確認もしづらくなります。項目が多いほど入力漏れや表記ゆれも増えます。長く使うデータほど、必要な項目を絞り、役割が重複する項目を減らし、使われていない項目を見直すことが大切です。propertiesは多ければよいのではなく、判断、検索、表示、連携に必要な情報が適切な形で入っていることが重要です。

GeoJSONのproperties設計は、最初に完璧を目指すよりも、業務で使いながら改善できる形にしておく方が現実的です。ただし、id、type、status、dateのような基本項目は後から変える影響が大きいため、初期段階で慎重に決める必要があります。地物の種類、利用場面、共有範囲、更新頻度を整理し、変えてよい項目と固定する項目を分けておくと、運用中の混乱を抑えられます。

まとめると、GeoJSONのpropertiesは、地図上の図形に業務上の意味を与えるための重要な設計領域です。propertiesをうまく活用すれば、地物の名称を表示するだけでなく、状態管理、点検記録、色分け、検索、集計、台帳連携まで実務に必要な処理を進めやすくなります。逆に、propertiesを場当たり的に作ると、表記ゆれ、項目不足、情報過多、共有時のリスクが発生しやすくなります。

GeoJSONを実務で使うなら、まず地物を識別する情報、表示に使う情報、検索や集計に使う情報、更新や引き継ぎに必要な情報を分けて考えることが大切です。そのうえで、項目名、値の候補、日付や数値の形式、公開範囲を整理しておくと、現場でも事務所でも扱いやすいデータになります。特に、スマートフォンで取得した位置情報や現地確認記録をGeoJSONとして活用する場合は、propertiesの設計がそのまま後工程の効率に影響します。

現場で取得した位置情報を、ただの点データで終わらせず、確認日、対象種別、状態、備考などのpropertiesと組み合わせて活用したい場合は、位置取得、属性入力、写真や台帳との関連付け、共有前の情報確認までの流れをあらかじめ整えておくことが重要です。特定のツール名や製品名に依存せず、GeoJSONの標準的な構造と業務上の項目定義を分けて考えることで、後から別のGIS、台帳、報告資料へ展開しやすいデータになります。