GeoJSONは、点・線・面といった地理空間情報をJSON形式で扱うためのデータ形式です。Featureとして扱う場合、位置や形状はgeometryに入り、その地物が何を表しているのか、どのような管理情報を持っているのかはpropertiesに入ります。つまり、GeoJSONを実務で使いやすくする鍵は、座標だけでなく属性情報propertiesをどう設計し、どう運用するかにあります。
「geojson 使い方」で調べている実務担当者は、地図に点や線を表示するだけでなく、現場名、施設名、管理番号、状態、点検日、担当区分、備考などを一緒に扱いたい場面が多いはずです。ところがpropertiesの設計が曖昧なままだと、後から検索できない、色分けできない、集計できない、別の担当者が意味を理解できないといった問題が起こりやすくなります。
この記事では、GeoJSONの属性情報propertiesを実務で活かすために、入力前に決めておきたい考え方、項目名の付け方、分類値のそろえ方、地図表示とのつなげ方、更新管理の注意点まで、6つのコツとして解説します。
propertiesは地物の意味を伝える情報として設計する
GeoJSONのFeatureでは、geometryが位置や形状を表し、propertiesがその地物の内容を表します。点であれば「どこにあるか」はgeometryで分かりますが、それが標識なのか、設備なのか、測点なのか、点検対象なのかはpropertiesを見なければ分かりません。線であっても、道路中心線なのか、境界線なのか、排水施設なのか、仮設ルートなのかは属性情報がなければ判断しにくくなります。面の場合も、敷地、区域、舗装範囲、管理区分、作業範囲など、意味づけはpropertiesによって補われます。
そのためpropertiesは、単なるメモ欄ではなく、地物の意味を伝えるための情報として設計することが大切です。現場で取得した座標を後から地図に表示するだけであれば、最小限の属性でも一見問題ないように見えます。しかし実務では、表示後に対象物を探したり、分類ごとに抽出したり、点検日で絞り込んだり、管理番号で照合したりする場面が出てきます。このときpropertiesが整っていないと、地図上には点が並んでいても、業務データとして使いにくい状態になります。
まず考えたいのは、そのGeoJSONを誰が、どの場面で、何の判断に使うのかという目的です。たとえば設備管理であれば、設備名称、管理番号、種別、設置場所、状態、点検日、担当部署などが重要になります。現地調査であれば、調査日、調査者、確認結果、写真番号、メモ、優先度などが役立ちます。工事や測量の確認用であれば、測点名、施工区分、設計値との関係、確認状況、修正要否などが必要になることがあります。目的によって必要なpropertiesは変わるため、何となく項目を増やすのではなく、利用場面から逆算して決めることが重要です。
また、propertiesに入れる情報は「人が読むための説明」と「機械的に処理するための値」の両方を意識すると扱いやすくなります。たとえば、地図上のポップアップに表示する名称は人が読む情報です。一方で、状態を「未確認」「確認済」「要対応」のように決めておくと、絞り込みや色分けに使いやすくなります。自由記述だけに頼ると柔軟ではありますが、集計や検索には向きません。逆にコードだけにすると、現場担当者が意味を把握しにくくなる場合があります。読みやすさと処理しやすさのバランスを取ることが、properties活用の第一歩です。
propertiesの設計では、最初から完璧な項目を作ろうとしすぎないことも大切です。実務では、運用してみて初めて必要になる項目があります。たとえば、最初は「状態」だけで足りると思っていても、後から「対応期限」や「確認者」が必要になる場合があります。そのため、初期設計では必須項目を絞りつつ、後から追加しても混乱しにくい命名ルールや入力ルールを整えておくと安心です。
一方で、何でもpropertiesに入れればよいわけではありません。長すぎる文章、形式がばらばらなメモ、担当者しか分からない略語、古い資料から転記しただけの未確認情報などを大量に入れると、かえって品質が下がります。propertiesは地物を説明するための情報であり、後から検索・表示・確認しやすい状態であることが重要です。位置情報と属性情報を組み合わせて初めて、GeoJSONは「点の集まり」から「業務に使える地図データ」になります。
属性名は短くても意味が通じる形に統一する
propertiesを活用するうえで、属性名の統一は非常に重要です。GeoJSONではFeatureのpropertiesに任意の項目を持たせられますが、自由に作れるからこそ、担当者ごとに名前がばらつきやすくなります。たとえば同じ意味の項目なのに「name」「名称」「施設名」「設備名」のように混在すると、後から検索や変換を行うときに手間が増えます。地図表示では一見問題なく見えても、集計や連携の段階で不整合が表面化します。
属性名は、短くても意味が通じる形に統一するのが基本です。長すぎる名前は読みづらく、入力時にも間違いやすくなります。一方で短すぎる略語は、別の担当者が見たときに意味が分からなくなることがあります。たとえば「nm」「dt」「st」のような略し方は、作成者本人には分かっても、引き継ぎ時に誤解を生みやすいです。実務では、名称を表すなら「name」、種別を表すなら「type」、状態を表すなら「status」、管理番号を表すなら「asset_id」や「management_id」のように、一定の考え方でそろえると扱いやすくなります。
管理番号を扱う場合は、GeoJSONのFeatureが持てるidと、properties内の管理IDを混同しないことも大切です。Featureのidを使う運用もありますが、システムや出力方法によって扱いが変わる場合があります。現場管理や台帳照合に使う番号は、properties内にasset_idなどの項目として持たせる方が、一覧化や属性編集の流れに乗せやすいことがあります。どちらを使うかは、利用するGIS、ビューア、変換ツール、管理台帳との関係を見て決めると安全です。
日本語の属性名を使うか、英数字の属性名を使うかも、事前に決めておきたい点です。日本語の属性名は現場担当者にとって直感的で分かりやすい反面、外部のシステムや別形式への変換で扱いに注意が必要になることがあります。英数字の属性名は連携や処理に向いていますが、意味が分かりにくくなる場合があります。どちらが絶対に正しいというより、運用環境と利用者に合わせて統一することが大切です。英数字の属性名を使う場合でも、別途項目定義を用意し、各属性が何を意味するかを明記しておくと混乱を防げます。
属性名では、表記ゆれも避ける必要があります。大文字と小文字の違い、単数形と複数形の違い、アンダースコアの有無、ローマ字表記の違いなどは、見た目以上にトラブルの原因になります。たとえば「inspection_date」と「inspected_date」が混在すると、同じ点検日を表しているのか、別の意味なのか判断しにくくなります。「管理番号」と「管理ID」も、現場によっては同じ意味で使われることがありますが、データ上では別項目として扱われてしまいます。最初に命名ルールを決め、既存データに追加するときもそのルールに合わせることが大切です。
属性名を決める際には、将来の利用も意識します。最初は地図上のポップアップ表示だけに使うつもりでも、後から帳票出力、一覧管理、絞り込み、更新履歴管理、外部データとの照合に使う可能性があります。そのとき、属性名が整理されていれば処理がしやすくなります。反対に、場当たり的な名前が増えていると、どの項目を基準にすべきか分からなくなります。特に複数人で作成・編集するGeoJSONでは、属性名のルールを共有しておくことが欠かせません。
実務では、属性名そのものだけでなく、項目定義の管理も重要です。項目定義には、属性名、意味、入力例、必須か任意か、入力形式、更新タイミングなどを整理しておくとよいです。これは大げさな仕様書である必要はなく、簡単な管理表でも十分です。大切なのは、propertiesを見たときに「この項目は何を表すのか」「どのように入力すればよいのか」が分かる状態にしておくことです。属性名が整っているGeoJSONは、担当者が変わっても扱いやすく、長く使えるデータになります。
分類・状態・日付は後から検索できる形で入力する
propertiesを実務で活かすには、分類、状態、日付の入力方法をそろえることが大切です。これらの項目は、地図上の表示や絞り込み、一覧化、進捗管理に使われることが多いためです。たとえば設備の種別、道路施設の区分、点検結果、対応状況、調査日、更新日などは、後から「特定の種別だけを表示したい」「未対応のものだけを確認したい」「一定期間内に調査したものを抽出したい」といった使い方につながります。
分類項目では、自由記述を避け、あらかじめ候補を決めておくことが重要です。たとえば同じ分類を表す場合でも、「照明」「道路照明」「照明灯」「街灯」のように入力がばらつくと、同じものとして集計しにくくなります。現場では意味が通じても、データとしては別の値として扱われることがあります。分類値は、必要以上に細かくしすぎず、業務で使う単位に合わせて決めるのが現実的です。細かすぎる分類は入力負担が増え、粗すぎる分類は後から使いにくくなります。
状態項目も同様です。「良好」「異常なし」「問題なし」「正常」のような表現が混在すると、確認済みなのか、異常がないのか、対応不要なのかが分かりにくくなります。状態を管理する場合は、「未確認」「確認済」「要対応」「対応中」「完了」のように、業務の流れに沿った値を決めておくと便利です。特に複数人で確認する場合、状態の意味が曖昧だと、作業の抜けや重複につながります。状態値は、見た人が次に何をすべきか判断できるように設計することが大切です。
日付は、propertiesの中でも形式のばらつきが起こりやすい項目です。年月日だけでよいのか、時刻まで必要なのか、和暦を使うのか西暦を使うのか、区切り文字をどうするのかを事前に決めておきます。日付を文字列として扱う場合でも、後から並べ替えや期間検索をしやすい形式にしておくと便利です。たとえば日付のみで足りるなら「2026-05-26」のように桁数をそろえた形式にしておくと、一覧で見たときにも比較しやすくなります。時刻やタイムゾーンが関係する運用では、利用するシステム側の扱いも確認しておく必要があります。
調査日、登録日、更新日、点検日など、似た項目が複数ある場合は、それぞれの意味も明確にしておきます。調査日は現地で確認した日、登録日はデータに追加した日、更新日は属性や形状を修正した日、点検日は維持管理上の点検日というように、名前と意味を対応させます。意味が曖昧なまま日付項目を増やすと、どの日付を基準に抽出すべきか分からなくなります。
また、分類・状態・日付は、地図表示の条件として使われることが多い項目です。状態が「要対応」のものだけを目立たせる、種別ごとに表示を切り替える、点検日が古いものを抽出するなど、propertiesを整えておくことで地図の使い勝手が大きく変わります。座標だけのGeoJSONでは、見えている点や面を眺めるだけになりがちですが、属性値が整っていれば、判断に必要な対象を素早く探せます。
入力値の統一には、現場での入力しやすさも関係します。理想的な分類を細かく作っても、入力者が迷うようでは品質が安定しません。たとえば「小破」「中破」「大破」のような区分を使う場合、どの状態がどの区分に当たるのかを現場で判断できる基準が必要です。基準がないまま分類値だけを用意すると、担当者ごとに判断が分かれてしまいます。propertiesはデータ形式の話であると同時に、現場判断をどう標準化するかという運用の話でもあります。
分類、状態、日付をきれいに入力することは、地味ですが効果の大きい作業です。後から手作業で修正するよりも、入力時点でルールをそろえる方が負担は少なくなります。GeoJSONを単発の確認用データで終わらせず、継続的な管理データとして使うなら、この3種類の属性は特に丁寧に設計しておきたい項目です。
地図表示に使う属性と管理用の属性を分けて考える
propertiesには多くの情報を入れられますが、すべての属性を同じ目的で使うわけではありません。実務では、地図表示に使う属性と、管理・検索・照合に使う属性を分けて考えると整理しやすくなります。地図表示に使う属性とは、画面上のラベル、色分け、ポップアップ、凡例、表示切り替えなどに関係する情報です。管理用の属性とは、管理番号、更新日、調査者、確認状況、内部区分、写真番号、帳票連携用の番号など、裏側の業務で使う情報です。
この区別をしないままpropertiesを作ると、地図上に表示したい情報が多すぎて見づらくなったり、逆に管理に必要な情報が不足したりします。たとえば現場確認用の地図では、地図上には「名称」「状態」「対応要否」程度が見えれば十分なことがあります。一方で、データ管理のためには、登録日、更新者、管理番号、関連資料番号などが必要になる場合があります。表示用と管理用を分けて考えることで、画面では見やすく、データとしては十分な情報を持つGeoJSONにできます。
ラベル表示に使う属性は、短く分かりやすい値にすることが大切です。長い文章をラベルにすると、地図上で重なったり、重要な位置が見えにくくなったりします。ラベルには名称や番号など、対象を識別できる最低限の情報を入れ、詳しい内容はポップアップや一覧で確認する設計にすると扱いやすくなります。特に点が密集するデータでは、ラベルに入れる情報を絞ることが見やすさに直結します。
色分けや線種、表示切り替えに使う属性は、値の種類を限定しておく必要があります。たとえば状態別に色分けするなら、状態値が統一されていないと期待どおりに表示できません。「要対応」と「要確認」と「対応必要」が混在していると、同じ意味の対象が別々に扱われてしまう可能性があります。地図表現に使う属性は、入力値のばらつきがそのまま表示の乱れにつながります。そのため、表示条件に使う属性ほど、事前のルール化が重要です。
一方で、管理用の属性は、地図上に常に表示する必要はありません。管理番号や内部コード、登録者、更新履歴に関する情報は、必要なときに参照できれば十分な場合があります。これらをすべて画面上に出すと、地図が情報過多になります。propertiesに入っている情報を「常に見せるもの」「クリック時に見せるもの」「検索や管理のために持っておくもの」に分けると、利用者にとって分かりやすい地図になります。
また、表示用の名称と正式な管理名を分けることもあります。正式名称が長い場合、地図上では略称を表示し、propertiesには正式名称も保持するという考え方です。ただし略称を使う場合は、その略称が誰にでも通じるかを確認する必要があります。部署内だけで通じる略語や、現場ごとに意味が変わる呼び方は、引き継ぎ時に混乱を招きます。表示の見やすさを優先しつつ、正式情報との対応が取れるようにしておくと安全です。
地図表示を意識したproperties設計では、利用者が地図を見て何を判断するのかを考えることが欠かせません。現地に向かう担当者が見る地図なのか、管理者が進捗を見る地図なのか、関係者に説明する地図なのかによって、必要な表示は変わります。同じGeoJSONでも、propertiesの使い方次第で、現場確認用にも、管理用にも、説明用にも活用できます。だからこそ、属性をただ詰め込むのではなく、表示と管理の役割を分けて設計することが重要です。
空欄・不明・備考の扱いを事前に決めておく
GeoJSONのpropertiesを運用していると、空欄や不明値、備考欄の問題が出てきます。現地で確認できなかった情報、資料上は存在するが未確認の情報、後で入力する予定の情報、対象外のため入力しない情報など、値が入っていない理由はさまざまです。これらをすべて空欄にしてしまうと、未確認なのか、該当なしなのか、入力漏れなのか判断できなくなります。
空欄の扱いは、最初に決めておくべき重要なルールです。たとえば、必須項目は原則として空欄にしない、確認できなかった場合は「不明」と入力する、該当しない場合は「対象外」と入力する、後で確認するものは状態項目で管理する、といった方針を決めておくと整理しやすくなります。空欄を許容する項目と許容しない項目を分けるだけでも、データ品質は大きく変わります。
不明値をどう表すかも統一が必要です。「不明」「未確認」「確認中」「なし」「空白」が混在すると、それぞれの意味が曖昧になります。特に「なし」と「不明」は区別した方がよい場面があります。「なし」は確認した結果存在しなかったことを示し、「不明」はまだ分からないことを示します。この違いを区別しないと、後から再確認すべき対象を見落とす可能性があります。propertiesでは、値がないこと自体にも意味があるため、その意味を表現できるルールが必要です。
JSONとしてはnullを使える場合もありますが、nullをどの意味で使うかは運用側で決めておく必要があります。未確認、対象外、入力予定、該当なしをすべてnullで表すと、後から判断できなくなります。利用するシステムによっては、空文字、null、項目自体が存在しない状態を別々に扱うこともあります。GeoJSONを別のツールへ渡す予定がある場合は、そのツールが空欄やnullをどう扱うかも確認しておくと安全です。
備考欄は便利ですが、使い方に注意が必要です。備考に何でも書けるようにすると、重要な情報が備考に埋もれてしまい、検索や集計で使いにくくなります。たとえば「要対応」「写真あり」「境界不明」「再確認必要」などの重要な判断を備考だけに書くと、後から抽出しづらくなります。業務判断に使う情報は、できるだけ独立した属性として持たせ、備考欄は補足説明に使うのが基本です。
一方で、備考欄を完全になくす必要はありません。現場では、決まった分類や状態だけでは表現しきれない情報があります。周囲の状況、確認時の注意点、資料との違い、次回確認時に見るべき点などは、備考として残しておくと役立ちます。ただし、備考に書く内容の粒度はある程度そろえた方がよいです。長すぎる文章や主観的な表現が増えると、読み手によって解釈が分かれます。事実、判断、依頼、感想が混ざらないように意識すると、備考の品質が安定します。
空欄や不明値の扱いは、データの信頼性にも関わります。地図上に表示された情報を見た人は、そこに入っている値をある程度信頼して判断します。もし空欄が多く、その理由が分からない場合、データ全体への信頼が下がります。逆に、未確認や対象外が明確に区別されていれば、利用者はどこまで確認済みで、どこに注意が必要かを判断できます。propertiesは情報を入れる場所であると同時に、情報の確からしさを伝える場所でもあります。
複数人で入力する場合は、空欄・不明・備考のルールを共有し、入力例を用意しておくと効果的です。特に現地調査では、時間が限られるため、担当者ごとに判断が分かれやすくなります。入力例があると、迷ったときに同じ基準で判断できます。後からGeoJSONを整形する作業を減らすためにも、空欄や備考のルールは軽視しない方がよいです。
更新履歴と現場運用を意識してpropertiesを育てる
GeoJSONは一度作って終わりではなく、現場の変化や点検結果に合わせて更新されることがあります。特に設備管理、道路施設管理、工事進捗管理、調査結果の整理などでは、同じ地物に対して状態や点検日、対応状況が変わっていきます。そのためpropertiesを設計するときは、初回入力だけでなく、更新しながら使うことを前提にしておくと実務に合いやすくなります。
更新を意識する場合、いつ、誰が、何を確認したのかが分かる属性を持たせると便利です。たとえば登録日、更新日、確認日、確認者、更新理由、対応状況などです。すべての業務で詳細な履歴が必要とは限りませんが、少なくとも最新の確認日や更新日が分かるだけでも、情報の鮮度を判断しやすくなります。地図上の位置が正しくても、属性が古いままだと、現場判断を誤る可能性があります。
ただし、GeoJSONのpropertiesだけで複雑な履歴管理をすべて行おうとすると、データが重くなり、扱いにくくなることがあります。履歴を詳細に残す必要がある場合は、GeoJSONには最新状態や参照番号を持たせ、詳細履歴は別の管理台帳で扱うという考え方もあります。GeoJSONは地図上で確認しやすい形式ですが、すべての業務情報を詰め込む器ではありません。地図で見るべき情報と、台帳で管理すべき情報を分けると、運用が安定します。
現場運用では、入力と更新のタイミングを決めておくことも重要です。現地で即時入力するのか、帰社後に整理して入力するのか、点検完了時に更新するのか、月次でまとめて更新するのかによって、propertiesに必要な項目や確認方法が変わります。即時入力を重視するなら、入力項目はできるだけ絞り、選択式で入力しやすい値を増やした方がよいです。後で整理する運用なら、現場メモや写真番号との対応を確実に残すことが大切です。
propertiesを育てるという考え方も大切です。最初から全項目を完璧に作り込むよりも、実際に使いながら、不要な項目を減らし、必要な項目を追加し、入力ルールを見直していく方が現実的なことがあります。ただし、途中で属性名や値の意味を変える場合は注意が必要です。既存データとの整合が崩れると、過去のGeoJSONと新しいGeoJSONを比較しにくくなります。項目を追加する場合は影響が小さいことが多いですが、既存項目の意味を変える場合は、関係者に共有し、必要に応じて過去データも整理する必要があります。
引き継ぎもproperties運用の重要なポイントです。作成者だけが意味を理解している属性が多いと、担当者が変わったときにデータが使えなくなります。項目定義、入力ルール、更新手順、確認方法を簡単に残しておくことで、GeoJSONは個人作業の成果物ではなく、組織で使える業務データになります。特に継続管理するデータでは、作成時点の便利さよりも、半年後、一年後に見ても意味が分かることが大切です。
また、更新時には座標と属性の関係にも注意が必要です。対象物の位置が変わったのか、属性だけが変わったのか、別の地物として追加すべきなのかを判断しなければなりません。たとえば設備を移設した場合、既存地物のgeometryを更新するのか、旧位置を履歴として残すのか、新しい地物として登録するのかは、業務ルールによって変わります。propertiesに「移設」「撤去」「新設」などの状態を持たせる場合も、地図上でどのように表示するかを合わせて決めておく必要があります。
GeoJSONのpropertiesは、最初の入力設計だけでなく、運用を通じて価値が高まります。地図を見れば対象の位置が分かり、propertiesを見れば状態や管理情報が分かり、必要に応じて次の行動につなげられる。この状態を目指すことで、GeoJSONは単なる交換用データではなく、現場と管理をつなぐ実務データになります。
まとめ
GeoJSONのpropertiesは、位置情報に意味を与えるための重要な要素です。geometryだけでは、点・線・面がどこにあるかは分かっても、それが何を示し、どのような状態で、誰がどのように管理すべき対象なのかまでは分かりません。propertiesを適切に設計することで、GeoJSONは地図表示だけでなく、検索、分類、点検、進捗管理、引き継ぎに使えるデータになります。
活用の第一歩は、propertiesを単なるメモ欄ではなく、地物の意味を伝える情報として考えることです。次に、属性名を統一し、分類・状態・日付を後から検索しやすい形で入力します。さらに、地図表示に使う属性と管理用の属性を分け、空欄や不明値、備考の扱いをあらかじめ決めておくことで、データの信頼性が高まります。更新履歴や現場運用まで意識すれば、GeoJSONは一度きりの確認資料ではなく、継続的に使える管理データとして育てられます。
実務では、最初から高度な仕組みを作る必要はありません。まずは、名称、種別、状態、日付、管理番号、備考といった基本項目を整理し、入力ルールをそろえることから始めるだけでも十分に効果があります。大切なのは、後から見た人が意味を理解でき、必要な対象を探せて、次の作業につなげられることです。propertiesの設計が整っているGeoJSONは、現場の情報共有をスムーズにし、地図データの活用範囲を広げてくれます。
現地で取得した位置情報をGeoJSONとして整理し、属性情報propertiesまで活用できる形にしたい場合は、取得、記録、確認、共有までの流れをできるだけ簡単にすることが大切です。使用するアプリやGIS、管理台帳、写真整理の方法を含めて運用ルールをそろえておけば、GeoJSONを現場業務に結びつけやすくなります。