GeoJSONは、点・線・面などの地物情報を扱うときに便利なデータ形式です。座標だけでなく、各地物に名前、種別、管理番号、状態、日付、担当、備考などの属性を持たせられるため、現地調査、設備管理、台帳整備、地図表示、集計、空間分析など幅広い場面で使われます。
一方で、GeoJSONの使い方で意外とつまずきやすいのが、属性名の決め方です。属性名は一度決めると、入力画面、地図表示、検索条件、集計処理、外部データとの結合、納品データの説明資料などに影響します。最初は小さな違いに見えても、あとから修正しようとすると、関係する処理や関係者が増えていて直しにくいことがあります。
この記事では、GeoJSONの属性名を決める前に確認したい6つのルールを、実務担当者向けに整理します。単に名前を短くする、英語にする、日本語にするという話ではなく、後工程で迷わず使えるデータにするための考え方を中心に解説します。
属性名の意味を一目で判断できるようにする
GeoJSONの属性名を決めるときに最初に確認したいのは、その属性名だけを見て意味が判断できるかどうかです。GeoJSONでは、各地物の情報はpropertiesの中に格納されます。たとえば、点の地物に管理番号、施設種別、設置日、点検結果などを持たせる場合、それぞれの項目名が属性名になります。この属性名があいまいだと、データを開いた人が何を示しているのか判断できず、確認作業が増えます。
よくある失敗は、短さを優先しすぎた属性名です。たとえば、no、name、type、date、memoのような名前は一見わかりやすく見えますが、複数の目的でデータを使うようになると意味が広すぎます。noが現場番号なのか、施設番号なのか、調査番号なのか、図面上の通し番号なのかが判断できません。nameも、地物名、路線名、施設名、地点名、所有者名など複数の意味に読めます。typeも、施設区分、図形種別、点検区分、工種区分などに解釈できてしまいます。
属性名は、短くても意味が伝わることが大切です。たとえば、facility_id、survey_id、route_name、asset_type、inspection_dateのように、何の番号なのか、何の名称なのか、何の日付なのかがわかる名前にすると、後工程の判断がしやすくなります。日本語の属性名を使う場合でも、管理番号、調査番号、施設種別、点検日、確認結果のように、項目の役割が伝わる名前にすることが重要です。
特に実務では、GeoJSONを作成した人と利用する人が別になることがあります。現地で作ったデータを事務所で整理する、委託先が作ったデータを発注側が確認する、過年度データを別担当者が引き継ぐ、といった場面では、作成者の頭の中にある前提は共有されません。そのため、属性名だけで最低限の意味が伝わるようにしておくことが、データの使いやすさに直結します。
また、属性名には業務上の粒度も反映させる必要があります。たとえば、単にstatusとすると、工事の進捗なのか、施設の劣化状態なのか、点検の実施状況なのかがわかりません。progress_status、damage_status、inspection_statusのように、何の状態かを含めると、他の属性と並べたときにも混乱しにくくなります。属性名はデータの見出しであり、見出しがあいまいだと中身の理解も遅れます。
一方で、説明を詰め込みすぎた長すぎる属性名にも注意が必要です。長い属性名は、画面表示やデータ確認の際に扱いにくくなることがあります。大切なのは、必要な意味を含めつつ、繰り返し使っても負担にならない長さに整えることです。略語を使う場合は、関係者が同じ意味で理解できるものに限定し、独自の略し方を多用しないようにします。
GeoJSONの属性名は、単なる内部名ではありません。地図のポップアップ表示、一覧表、検索条件、集計項目、外部連携時の項目名として表に出ることがあります。あとから見た人が迷わない名前にしておけば、確認、修正、説明の負担を減らせます。属性名を決める前には、その名前を初めて見る人が、どの程度まで意味を理解できるかを必ず確認しておきましょう。
表記ゆれを防ぐ命名ルールを先に決める
次に重要なのは、属性名の表記ルールを先に決めておくことです。GeoJSONでは、properties内のキーとして属性名を設定できます。その自由度が高いぶん、担当者ごとに書き方が変わると、表記ゆれが発生しやすくなります。表記ゆれは見た目の問題だけでなく、検索、集計、変換、結合の失敗につながります。
たとえば、同じ意味の属性に対してfacility_id、facilityId、FacilityID、施設ID、施設番号が混在していると、同じ項目として扱うために変換作業が必要になります。人が見れば似た意味だと推測できますが、処理上は別の属性名として扱われます。GeoJSONの属性名はキー名として扱われるため、大文字と小文字、アンダースコアの有無、日本語と英語の違いなどが、そのまま別項目として残ります。
そのため、属性名を決める前に、英数字中心にするのか、日本語を使うのか、単語の区切りをどうするのか、大文字を使うのか、小文字に統一するのかを決めておく必要があります。実務で扱いやすい方法としては、小文字の英数字とアンダースコアを使い、単語を区切る形式があります。たとえば、facility_id、inspection_date、road_name、photo_countのような形です。この形式は、見た目で単語の区切りがわかりやすく、変換処理でも扱いやすいという利点があります。
ただし、必ず英語にしなければならないわけではありません。業務内で日本語項目名のほうが確認しやすい場合もあります。たとえば、点検結果、施設種別、管理番号、撮影日といった属性名は、現場担当者や確認者にとって直感的です。日本語を使う場合は、利用する環境で問題なく表示できるか、外部システムに渡す予定があるかを確認しておく必要があります。後工程で英数字の項目名が求められる場合は、最初から英数字名にしておくか、日本語名と英数字名の対応表を用意しておくと安全です。
命名ルールでは、使わない文字も決めておくとよいです。空白、記号、括弧、スラッシュ、単位記号などを属性名に含めると、環境によって扱いづらくなることがあります。たとえば、inspection dateのように空白を含む名前や、height(m)のように単位を括弧で入れた名前は、人が読むにはわかりやすいものの、処理や変換のときに余計な注意が必要になる場合があります。単位は属性名に無理に埋め込むより、説明資料やデータ仕様で管理したほうが安定します。どうしても属性名に単位を含める場合は、height_mのように決まった形式に統一すると扱いやすくなります。
また、同じ単語に複数の表記を使わないことも大切です。たとえば、number、num、no、idを気分で使い分けると、属性名全体の統一感がなくなります。番号を識別子として使うならid、通し番号ならseq、数量ならcountのように、意味に応じた使い分けを決めておくと混乱を防げます。日付もdate、time、datetimeを区別し、日だけなのか、時刻まで含むのかを明確にします。
属性名の表記ゆれは、データ量が少ないうちは大きな問題に見えません。しかし、データを複数の地区、年度、担当者、調査回に分けて扱うようになると、少しの表記違いが修正負担になります。最初に命名ルールを決め、既存データや入力様式にも反映しておくことで、GeoJSONを安定して運用しやすくなります。
図形情報と属性情報の役割を混同しない
GeoJSONでは、geometryに図形情報を持ち、propertiesに属性情報を持たせます。属性名を決める前には、この役割分担を意識する必要があります。位置や形そのものに関する情報と、地物の説明や管理に関する情報を混同すると、データの意味がわかりにくくなります。
たとえば、点の座標はgeometryに格納されます。それにもかかわらず、propertiesにlat、lon、x、yのような属性を追加する場合があります。これは、表示や検索、外部出力の都合で必要になることもありますが、常に必要とは限りません。geometryとpropertiesの両方に座標情報を持たせると、更新時に片方だけが変わり、値が食い違う可能性があります。座標を属性として持たせる場合は、表示用なのか、外部連携用なのか、測定値の記録なのかを明確にしておくことが大切です。
線や面の地物でも同じです。道路中心線、区域界、調査範囲、施設面などの形はgeometryで表現します。一方で、路線名、区域名、管理区分、面積区分、調査年度などはpropertiesで表現します。面積や延長を属性として持たせる場合は、それが図形から計算した値なのか、別資料から転記した値なのかを区別しておく必要があります。属性名をareaやlengthだけにすると、どの基準で算出した値なのかが曖昧になります。calculated_area、recorded_area、design_lengthのように、値の性格がわかる名前にすると誤解を減らせます。
特に注意したいのは、図形の種類と地物の種類を混同することです。GeoJSONのgeometryには、点、線、面などの図形種別があります。一方で、propertiesに入れるfacility_typeやasset_typeは、施設や対象物の種類を表します。ここでtypeという属性名だけを使うと、図形種別なのか、施設種別なのか、処理区分なのかがわからなくなります。GeoJSON全体の構造を理解していない人が見た場合、typeという言葉は既存の構造名とも重なりやすいため、独自属性として使うときは意味を補う名前にしたほうが安全です。
また、propertiesに入れる属性は、地物ごとの情報であることを意識します。データ全体の説明、作成者、作成日、座標に関する補足、調査仕様などは、各地物に重複して持たせるより、別の仕様書やメタ情報として管理したほうが適している場合があります。すべてをpropertiesに詰め込むと、各地物の属性が増えすぎて確認しづらくなります。属性名を決める段階で、その情報が地物ごとに異なるものなのか、データ全体に共通するものなのかを切り分けることが重要です。
現場データでは、写真番号、調査者、確認状況、補修要否、備考など、実務上必要な情報が多くなりがちです。だからこそ、図形で表現すべきこと、属性で表現すべきこと、別資料で管理すべきことを整理してから属性名を決める必要があります。属性名はデータ構造の設計そのものです。geometryとpropertiesの役割を分けて考えることで、後から見ても意味が崩れにくいGeoJSONになります。
値の種類と入力ルールを属性名とセットで考える
属性名を決めるときは、その属性に入る値の種類も同時に決める必要があります。名前だけを先に決めて、入力値のルールを後回しにすると、同じ属性の中に数字、文字列、空欄、記号、表記ゆれが混在しやすくなります。GeoJSONは柔軟に値を持てるため、管理側がルールを決めないと、入力者ごとの判断がそのままデータに残ります。
たとえば、inspection_dateという属性を作る場合、値をどの形式で入れるかを決めておく必要があります。ある地物では2026-05-26、別の地物では2026/5/26、さらに別の地物では5月26日と入力されていると、日付として並べ替えたり、期間で絞り込んだりするときに扱いづらくなります。属性名が同じでも、値の形式がそろっていなければ、実務上は使いにくいデータになります。
数値項目も同様です。height_m、width_m、depth_mのように単位を含めた属性名にする場合は、値は数値だけにするのか、単位付きの文字列にするのかを決めます。値に1.2、1.20、約1.2m、未測定などが混在すると、集計や比較に使いにくくなります。未測定や不明を表す必要がある場合は、空欄にするのか、別の確認状況属性を設けるのかを検討します。数値項目に文字を混ぜるより、measurement_statusのような属性を別に持たせたほうが処理しやすいことがあります。
分類項目では、選択肢の統一が重要です。たとえば、damage_levelという属性に、軽微、軽度、小、A、1などが混在すると、同じ意味でも別の値として扱われます。属性名を決める段階で、どの値を許可するか、表記をどう統一するかを決めておく必要があります。現場では入力のしやすさも重要なので、選択式にできる項目は自由入力を避ける設計にしたほうが、後工程の整理が楽になります。
真偽値を扱う項目にも注意が必要です。たとえば、補修が必要かどうかを表す属性としてrepair_requiredを作る場合、値をtrueまたはfalseにするのか、必要または不要にするのか、1または0にするのかを統一します。人が読むことを優先する場合と、処理で使うことを優先する場合で適した形式は変わります。どちらを選ぶにしても、同じ属性の中で複数の表現を混ぜないことが大切です。
備考欄のような自由記述項目も、属性名と役割を明確にしておく必要があります。memo、note、remarks、commentなど似た名前が複数あると、どこに何を書くべきか迷います。調査時のメモなのか、確認者のコメントなのか、修正理由なのか、納品時の補足なのかを分けたい場合は、field_note、review_comment、revision_noteのように役割別に属性名を設けると管理しやすくなります。逆に、自由記述項目を増やしすぎると入力が分散するため、必要な範囲に絞ることも重要です。
属性名は値の入れ物ですが、入れ物の名前だけではデータ品質は保てません。どの型の値を入れるか、空欄を許すか、単位をどう扱うか、選択肢をどう統一するかをセットで決めることで、GeoJSONを検索、集計、分析に使いやすくできます。属性名を決める前には、必ず入力例を複数作り、実際にその名前と値で運用できるかを確認しましょう。
検索・集計・結合で使いやすい名前にする
GeoJSONの属性は、地図上に表示するだけでなく、検索、絞り込み、集計、外部データとの結合にも使われます。そのため、属性名を決めるときは、作成時の見やすさだけでなく、後でどのように使うかを想定する必要があります。現場で作ったGeoJSONが、台帳、写真、点検結果、設計情報、報告資料とつながることは珍しくありません。
まず確認したいのは、結合キーになる属性です。たとえば、施設台帳とGeoJSONを結びつける場合、facility_idのような一意に識別できる属性が重要になります。属性名がidだけだと、どの台帳のIDなのか判断しにくくなります。asset_id、facility_id、survey_point_id、photo_idのように、結合対象がわかる名前にしておくと、複数データを扱うときに安全です。
結合キーでは、値の重複にも注意が必要です。属性名がわかりやすくても、同じ値が複数の地物に入っていると、一対一の結合ができない場合があります。連番を使う場合は、地区や年度が変わっても重複しない設計にするのか、別の属性と組み合わせて識別するのかを決める必要があります。属性名としてdistrict_id、survey_year、point_seqのように役割を分ける方法もありますが、結合作業でどの組み合わせを使うのかを明確にしておかなければなりません。
検索や絞り込みで使う属性は、名前から条件の意味が伝わることが重要です。たとえば、inspection_status、repair_required、priority_level、asset_type、area_nameのような属性は、検索条件として使う場面が多くなります。属性名があいまいだと、検索画面や集計設定で間違った項目を選びやすくなります。特に、statusやcategoryのような広い名前を複数の意味で使うと、後から見た人が判断に迷います。
集計で使う属性では、分類の粒度をそろえることも大切です。たとえば、施設種別をasset_typeに入れる場合、道路付属物、排水施設、標識、照明のような大分類にするのか、さらに細かい分類にするのかを決めておきます。属性名だけでは粒度まで表現しきれないため、必要に応じてasset_groupとasset_typeを分けるなど、属性設計を工夫します。すべてを一つの属性に詰め込むと、集計時に分類し直す手間が増えます。
日付や年度を使った集計では、属性名の使い分けが重要です。survey_date、inspection_date、created_date、updated_dateは、それぞれ意味が違います。現地調査をした日、点検を実施した日、データを作成した日、データを更新した日が混ざると、報告や履歴管理で誤解が生じます。日付属性を作るときは、何の日時なのかを属性名に含めることが基本です。
また、地図表示でラベルに使う属性も意識しておきましょう。画面上に表示する名称としてlabel_nameやdisplay_nameを用意する場合、正式名称とは別に短い表示名を持たせることがあります。正式名称をofficial_name、地図表示用の短縮名をdisplay_nameと分けておくと、表示と管理の目的を両立しやすくなります。これをnameだけで済ませると、正式名なのか表示用なのかがわからなくなることがあります。
GeoJSONは単体で完結するデータに見えますが、実務では他の資料やデータと一緒に使われます。属性名を決めるときは、地図で見る場面、一覧で確認する場面、条件で抽出する場面、別データと結合する場面を想定しましょう。後工程で使いやすい属性名にしておけば、データ整理のやり直しを減らせます。
運用中の変更に備えて説明できる属性名にする
GeoJSONの属性名は、最初に作った時点で完璧に決まるとは限りません。運用を始めると、追加したい項目が出てきたり、使わなくなった項目が見つかったり、別部署や別業務でも使いたくなったりします。だからこそ、属性名を決める段階で、変更に耐えられる設計にしておくことが大切です。
まず必要なのは、属性名と意味を説明できる状態にしておくことです。属性名の一覧、説明、値の例、入力ルール、必須か任意かを簡単にまとめておくと、引き継ぎや確認がしやすくなります。GeoJSONファイルだけを渡しても、属性名の意図までは伝わりません。たとえば、condition_rankという属性があっても、数値が大きいほど悪いのか良いのか、誰が判定したものなのか、いつの判定なのかは別途説明が必要です。
次に、将来追加される項目と衝突しにくい名前にしておくことも重要です。たとえば、dateという属性を先に作ってしまうと、後から調査日、更新日、確認日、撮影日を追加したくなったときに整理しにくくなります。最初からsurvey_dateやphoto_dateのように目的を含めた名前にしておけば、将来inspection_dateやupdated_dateを追加しても意味が衝突しにくくなります。
変更に備えるうえでは、属性名を安易に変更しないことも大切です。すでに地図表示、集計処理、入力様式、報告書作成に使われている属性名を変更すると、関連する設定が動かなくなることがあります。どうしても変更する場合は、旧属性名と新属性名の対応を記録し、移行期間を設けるなどの対応が必要です。属性名はデータの見た目だけでなく、処理の接点にもなっているため、名称変更は慎重に扱うべきです。
古い属性を残すか削除するかも、運用上の判断が必要です。使わなくなった属性を残し続けると、確認時に迷いが生じます。一方で、過去データとの比較に必要な場合は、すぐに削除できないこともあります。その場合は、属性名にoldやlegacyのような語を安易に付けるだけでなく、どの時点まで使っていた属性なのか、現在はどの属性を見るべきなのかを説明できるようにしておきます。
また、属性名は関係者間の合意にも関係します。現場担当者、事務所の整理担当者、管理者、発注者、外部協力者が同じGeoJSONを扱う場合、それぞれが理解しやすい名前にする必要があります。専門用語を使う場合は、関係者全員が同じ意味で理解しているかを確認します。業務内では当たり前の略語でも、別の担当者には伝わらないことがあります。属性名に略語を使うときは、説明資料で意味を補うことが前提になります。
運用中の変更に強い属性名とは、単に汎用的な名前ではありません。むしろ、何を表す項目かが明確で、追加や分割が必要になったときに判断しやすい名前です。最初に少し時間をかけて属性名を整理しておくことで、後からの修正、移行、説明が楽になります。GeoJSONを継続的に使う予定があるなら、属性名はその場限りで決めず、運用ルールの一部として管理しましょう。
まとめ
GeoJSONの属性名は、データの使いやすさを大きく左右します。座標や図形が正しくても、属性名があいまいだったり、表記ゆれが多かったり、値のルールが決まっていなかったりすると、検索、集計、確認、引き継ぎの場面で手戻りが発生します。反対に、属性名の意味、表記、値の形式、後工程での使い方を先に整理しておけば、GeoJSONを現場でも事務所でも扱いやすいデータにできます。
属性名を決める前には、まずその名前だけで意味が伝わるかを確認します。次に、英数字、日本語、アンダースコア、大文字小文字などの表記ルールを統一します。さらに、geometryとpropertiesの役割を分け、図形で表すべき情報と属性で管理すべき情報を混同しないようにします。属性に入る値の種類、日付形式、数値の単位、分類の選択肢、空欄の扱いも、属性名とセットで決めておく必要があります。
また、GeoJSONは単に地図に表示するだけでなく、台帳との結合、写真との紐づけ、点検結果の集計、条件検索、報告資料の作成にも使われます。結合キーになる属性、検索で使う属性、表示名として使う属性は、特にわかりやすく安定した名前にすることが重要です。運用中に項目を追加したり変更したりする可能性もあるため、属性名の意味や入力ルールを説明できる状態にしておくと、引き継ぎや修正がしやすくなります。
GeoJSONの使い方を実務に落とし込むとき、属性名の設計は地味ですが重要な作業です。現場で取得した位置情報を、あとから迷わず確認し、共有し、管理するためには、属性名のルールを最初にそろえておくことが欠かせません。現地で取得した点や写真、調査情報をよりスムーズに整理したい場合は、位置情報の取得方法、記録項目、共有先、更新手順までを含めて運用を整理すると、GeoJSONの属性設計を実務に結びつけやすくなります。