GeoJSONの属性名を後悔しない命名ルール6選

GeoJSONは、点・線・面などの地物形状と、その地物に関する情報を一緒に扱えるデータ形式です。現場調査、用地管理、設備台帳、道路・河川・造成地の管理、防災点検、写真位置情報の整理など、実務ではさまざまな場面で使われます。ただし、形状データそのものと同じくらい後から問題になりやすいのが、propertiesに入れる属性名です。

属性名は一度決めると、地図表示、検索、集計、帳票出力、他システム連携、データ更新作業に影響します。最初は少人数で扱うだけでも、後から担当者が増えたり、別部署へ渡したり、別の形式に変換したりすると、あいまいな属性名が手戻りの原因になります。たとえばname、type、dateのような短すぎる名前は便利に見えますが、何の名称なのか、何の区分なのか、どの作業日のことなのかが分からなくなりがちです。

この記事では、geojsonで検索する実務担当者に向けて、GeoJSONの属性名を後悔しないための命名ルールを6つに整理して解説します。特定のソフトウェアやサービスに依存しない考え方として、長く使える属性設計の基本を押さえていきます。

目次

• 属性名は表示名ではなくデータの意味で決める

• 英数字と区切り文字を統一して扱いやすくする

• 略語を増やさず誰が見ても分かる名前にする

• 単位や基準日を属性名で誤解させない

• 分類値と自由記入欄を混在させない

• 将来の更新と連携を見据えて命名台帳を作る

属性名は表示名ではなくデータの意味で決める

GeoJSONの属性名を決めるとき、まず意識したいのは、属性名を画面に表示するラベルとして考えすぎないことです。地図上のポップアップや一覧画面に表示する名前は、利用するアプリケーションや表示設定で調整できる場合があります。一方で、GeoJSONのpropertiesに入れる属性名は、データを処理するときの識別子になります。そのため、見た目の分かりやすさだけでなく、データとして何を表しているのかが安定して伝わる名前にする必要があります。

たとえば、現地で確認した施設の名称を入れる属性に「名称」と付けること自体は分かりやすいように見えます。しかし、同じデータ内に所有者名、路線名、区域名、写真名、点検者名などが増えてくると、単に「名称」と書かれているだけでは何の名称なのかが不明確になります。データを受け取った人が文脈を知らない場合、画面上で見れば分かると思っていた情報が、集計や抽出の段階では判断できなくなることがあります。

属性名では、できるだけ対象と意味を組み合わせて表すことが大切です。施設名称であればfacility_name、調査地点名であればsurvey_point_name、管理区域名であればmanagement_area_nameのように、何に対する名前なのかを含めておくと、後から見返したときの迷いが減ります。日本語で運用する場合でも、「施設名」「調査地点名」「管理区域名」のように対象を含めた名称にしておくほうが安全です。

また、属性名は地物の種類と切り離して考える必要があります。GeoJSONでは、Featureのpropertiesに属性情報を持たせることができ、geometryにはPoint、LineString、Polygonなどの形状を入れられます。点データだけを扱っている段階ではpoint_nameという名前でも問題がないように見えますが、将来、同じデータ群に線や面を追加する可能性があるなら、pointという形状依存の言葉が邪魔になることがあります。形状ではなく業務上の対象に基づき、facility_name、boundary_name、route_name、photo_point_nameなどのように決めておくと、データ構造が変わっても意味が崩れにくくなります。

表示用の文言とデータ用の属性名を分ける考え方も重要です。画面では「現場名」「確認日」「管理番号」と表示したい場合でも、データ内部ではsite_name、inspection_date、management_idのように一定の規則で管理すると、検索や連携がしやすくなります。表示ラベルは利用者に優しく、属性名は処理に強くするという役割分担です。

属性名を表示名の感覚で決めてしまうと、後から「この項目は帳票ではこう呼ぶが、システム上は別の意味で使っている」といったねじれが発生することがあります。特に、複数の部署や協力会社が同じGeoJSONを扱う場合、見た目の呼び名よりも、データとしての定義が一致していることのほうが大切です。命名の最初の段階で「この属性は何を表すのか」「似た属性とどう違うのか」「将来も同じ意味で使えるか」を確認しておくと、後悔の少ない設計になります。

英数字と区切り文字を統一して扱いやすくする

GeoJSONのpropertiesのキー名は文字列として扱われるため、日本語を含むさまざまな文字を使うこと自体は可能です。しかし、実務で長く使うデータにするなら、属性名に使う文字の種類と区切り方を統一することが重要です。特に、データ変換、集計、検索、外部連携を考えると、半角英数字とアンダースコアを基本にした命名が扱いやすい場面が多くなります。

たとえば、施設IDを表す属性名があるとして、あるデータではfacility_id、別のデータではfacilityId、さらに別のデータではFacilityIDになっていると、人間には似た項目に見えても、機械的には別の属性として扱われます。大文字と小文字の違い、アンダースコアの有無、単語のつなぎ方の違いは、後からデータを統合するときに面倒なズレになります。最初にlower_snake_caseのような形式を採用するなら、すべての属性名を小文字英字とアンダースコアでそろえるなど、ルールを明確にしておくことが大切です。

日本語の属性名は、現場担当者にとって読みやすい利点があります。一方で、別の形式へ変換したり、簡易的なスクリプトで処理したり、外部システムへ渡したりする場合、文字コードや表記ゆれの影響を受けることがあります。日本語を使うことが必ず悪いわけではありませんが、長期的な連携や再利用を考えるなら、内部の属性名は英数字で統一し、別途表示名として日本語ラベルを管理する運用のほうが安定しやすくなります。

区切り文字の混在も避けたいポイントです。属性名にハイフン、スペース、括弧、記号を含めると、処理する環境によっては扱いにくくなることがあります。たとえばsurvey-date、survey date、survey(date)のような名前は、人間が見るだけなら意味を推測できますが、条件指定や変換作業では余計な注意が必要です。属性名はできるだけ単純な文字で構成し、survey_dateのように一貫した形にしておくと、後工程の作業が軽くなります。

先頭文字にも注意が必要です。属性名の先頭に数字を置くと、環境によっては扱いにくい場合があります。2026_statusのような名前ではなく、status_2026やinspection_statusのように、意味を表す単語から始めるほうが安全です。また、年月や年度を属性名に直接入れると、その年だけのデータには便利でも、毎年項目が増殖する原因になります。年度別の値を扱いたい場合は、属性名に年を埋め込むのではなく、survey_yearやfiscal_yearのような属性を別に持たせる設計も検討する価値があります。

英単語の表記もそろえる必要があります。inspectionとcheck、photoとimage、areaとzoneのように、似た意味の単語を気分で使い分けると、後から項目の違いを説明しにくくなります。点検はinspection、写真はphoto、区域はareaなど、業務内で標準語を決めておくと、属性名全体に統一感が出ます。特に複数人でGeoJSONを編集する場合、表記ルールがないと、同じ意味の属性が少しずつ違う名前で増えていきます。

属性名の扱いやすさは、作った直後よりも、半年後や一年後に効いてきます。データを開いたとき、どの属性も同じ規則で並んでいれば、初めて見る担当者でも構造を把握しやすくなります。逆に、文字種や区切り方がばらばらだと、内容を確認する前に名前の解読から始めなければなりません。GeoJSONの属性名は、見た目の自由度が高いからこそ、あえて制約を設けて統一することが実務上の安心につながります。

略語を増やさず誰が見ても分かる名前にする

属性名を短くしたいという気持ちは自然です。GeoJSONを手で確認したり、簡単な編集をしたりするとき、長い属性名は少し扱いにくく感じることがあります。しかし、短さを優先して略語を増やしすぎると、後から意味が分からなくなる危険があります。特に、担当者の間だけで通じる略語や、現場ごとに意味が変わる略語は、データの寿命を短くします。

たとえば、st、pt、cd、flg、cls、tmpのような略語は、作った本人には分かっていても、他の人には複数の意味に見えることがあります。stはstation、status、streetのいずれにも読めます。ptはpoint、photo、partのいずれにも見えます。cdはcodeのつもりかもしれませんし、created_dateを短くしたものかもしれません。略語が悪いのではなく、意味が一つに定まらない略語を説明なしで使うことが問題です。

実務のGeoJSONでは、属性名を読む人が必ずしもデータ作成者とは限りません。現場担当者、管理担当者、設計担当者、発注者側の確認者、システム担当者など、さまざまな立場の人が見る可能性があります。そのとき、属性名だけでおおよその意味が伝わることは大きな価値です。survey_date、inspection_result、photo_count、boundary_type、facility_statusのように、多少長くても意味が読める名前にしておくと、説明の手間を減らせます。

略語を使う場合は、業務内で定義済みのものに限定するのが安全です。たとえばidは識別子として広く使われるため、facility_idやphoto_idのように使っても誤解は少ないでしょう。latやlonのように緯度経度を表す略語も、位置情報の文脈では比較的理解されやすいものです。ただし、GeoJSONのgeometryの座標は一般に経度、緯度の順で扱われるため、properties側にlatやlonを別途持たせる場合は、代表点なのか撮影位置なのかなどの定義を明確にしておく必要があります。略語は便利な道具ですが、共有された定義があって初めて安全に使えます。

また、属性名に業界内の口頭表現をそのまま入れることにも注意が必要です。現場では「仮点」「本点」「済み」「未済」「NG」「要対応」などの言い方がよく使われますが、それをそのまま属性名にすると、何を管理する項目なのかが分かりにくくなる場合があります。たとえばdone_flagよりもinspection_completed、ng_reasonよりもinspection_issue_reasonのように、何の完了か、何の理由かが分かる名前にしたほうが、データの意味が安定します。

似た属性が並ぶ場合は、単語の順序もそろえると分かりやすくなります。inspection_date、inspection_user、inspection_result、inspection_noteのように、点検に関する項目をinspectionで始めると、一覧で見たときに関連項目がまとまりやすくなります。photo_date、photo_direction、photo_file_name、photo_commentのように写真関連の項目も同じ接頭語でそろえると、データの構造が自然に見えてきます。

短い属性名は一見すると効率的ですが、意味を思い出すために毎回確認が必要になるなら、結果的には非効率です。GeoJSONは人が読む場面と機械が処理する場面の両方があります。機械にとっては属性名が少し長くても大きな問題にならないことが多い一方、人間にとって意味不明な略語は大きな負担になります。後から見ても説明なしで理解できる名前を選ぶことが、後悔しない命名の基本です。

単位や基準日を属性名で誤解させない

GeoJSONのpropertiesには、距離、面積、高さ、幅、勾配、数量、日付、時刻など、さまざまな値を入れることがあります。このとき、属性名だけを見ても単位や基準が分からない項目は、後から誤解を招きやすくなります。特に、数値データは単位の違いがそのまま判断ミスにつながるため、命名段階で慎重に扱う必要があります。

たとえばlengthという属性名があった場合、それがメートルなのか、センチメートルなのか、地図上の計算距離なのか、現地で測った延長なのかが分かりません。areaも同じで、平方メートルなのか、ヘクタールなのか、図上面積なのか、登記上の面積なのか、設計上の面積なのかによって意味が変わります。単にwidth、height、depthと書くだけでは、どの基準で測った値なのかが曖昧になります。

単位を属性名に含める場合は、length_m、area_sqm、height_mのように、値の単位が分かる形にする方法があります。これにより、データを受け取った人が数値だけを見て誤った換算をするリスクを減らせます。ただし、単位を属性名に含める場合は、実際の値と必ず一致させなければなりません。途中で単位を変えたのに属性名をそのままにすると、かえって危険です。単位を変える必要がある場合は、変換後の属性を別名で作るか、データ全体の仕様を明確に更新する必要があります。

日付や時刻の属性も同じです。dateという名前だけでは、作成日なのか、調査日なのか、更新日なのか、確認日なのか、撮影日なのかが分かりません。created_date、survey_date、updated_date、inspection_date、photo_taken_dateのように、何の日付かを明確にすることが大切です。時刻まで扱う場合は、日時なのか日付だけなのかも区別しておくと安心です。たとえばinspection_datetimeとinspection_dateを分けて使うことで、時刻情報の有無が伝わりやすくなります。

基準日が重要なデータでは、属性名だけでなく定義も必要です。たとえばstatusという属性があったとして、その状態が調査時点の状態なのか、最新更新時点の状態なのか、承認時点の状態なのかによって意味が変わります。inspection_status、current_status、approval_statusのように具体化すれば、少なくとも属性名から用途を推測しやすくなります。さらに、データ説明の中で基準日や更新タイミングを決めておけば、複数回更新されるGeoJSONでも混乱を抑えられます。

座標や高さに関わる項目は特に注意が必要です。GeoJSONの形状部分に座標が入っている場合でも、properties側に代表点の緯度経度、標高、計測高さ、写真位置などを別途持たせることがあります。このとき、lat、lon、elevation_m、measured_height_mのように意味を分けておかないと、形状の座標と属性の座標が混同されることがあります。代表点なのか、撮影位置なのか、対象物の位置なのかを名前で区別することが重要です。

単位や基準が曖昧な属性名は、データの見た目を整えても本質的な不安が残ります。現場で使うGeoJSONは、正しい位置に表示されるだけでなく、属性値の意味が正しく伝わって初めて実務に使えます。数値と日付の属性名には、できるだけ単位、対象、基準を含め、誤った解釈が入りにくい名前を選ぶことが大切です。

分類値と自由記入欄を混在させない

GeoJSONの属性設計では、属性名だけでなく、その属性に入る値の性質も意識する必要があります。特に、分類値として使う項目と、自由記入のメモ欄として使う項目を混在させると、後から検索や集計が難しくなります。命名の段階で、どの属性が分類用で、どの属性が説明用なのかを分けておくことが重要です。

たとえば、点検結果を入れる属性としてinspection_resultを作ったとします。そこに「良好」「要確認」「補修予定」のような決まった分類を入れる運用なら、後から件数を集計したり、該当箇所だけを抽出したりしやすくなります。しかし同じ属性に「北側にひびあり」「雨天時に再確認」「担当者へ連絡済み」のような自由文も入れてしまうと、分類項目としての役割が崩れてしまいます。結果として、検索条件を作るたびに表記ゆれを確認しなければなりません。

このような場合は、inspection_resultとinspection_noteを分けるのが基本です。inspection_resultには決められた分類値だけを入れ、inspection_noteには補足説明を入れます。補修対応であればrepair_statusとrepair_note、写真確認であればphoto_statusとphoto_commentのように、状態や分類を表す属性と、説明や備考を表す属性を分けて命名します。この分離によって、データを機械的に扱う部分と、人間が読む部分の役割が明確になります。

分類値を扱う属性名には、type、category、status、result、rank、levelなどの単語がよく使われます。ただし、これらの単語も意味を混同しないように使い分ける必要があります。typeは種類、categoryは分類、statusは現在の状態、resultは判定結果、rankは順位や等級、levelは段階や水準を表すように、業務内で定義しておくと安定します。何となくtypeを多用すると、facility_type、inspection_type、damage_typeのような項目が増えたときに、それぞれの分類基準が分かりにくくなることがあります。

自由記入欄には、note、comment、description、remarksなどの単語が使われます。これらも混在させすぎると、どこに何を書くべきか分からなくなります。実務では、簡潔な補足はnote、画面表示用の説明はdescription、作業者のコメントはcommentのように使い分ける方法がありますが、そこまで細かく分けないなら、基本はnoteに統一するなど、シンプルなルールにしておくほうが運用しやすい場合もあります。

また、フラグ項目の命名にも注意が必要です。is_active、has_photo、requires_repairのように真偽が分かる名前にすると、値がtrueまたはfalseであることを想像しやすくなります。一方でactive、photo、repairのような名前だけでは、それが状態なのか、件数なのか、分類なのかが分かりません。真偽値として扱うならis、has、requiresなどを使い、分類値や文字列とは明確に区別することが望ましいです。

分類値と自由記入欄を分けておくと、後からデータ品質を確認しやすくなります。分類項目に想定外の値が入っていないか、未入力が多すぎないか、自由記入欄に本来分類すべき内容が混ざっていないかをチェックできるようになります。属性名は単なる見出しではなく、入力ルールを示すサインでもあります。分類するための属性なのか、説明するための属性なのかを名前で分かるようにしておくことが、使いやすいGeoJSONにつながります。

将来の更新と連携を見据えて命名台帳を作る

GeoJSONの属性名は、作成時点で完璧に見えても、運用が始まると変更したくなることがあります。新しい調査項目が増える、別の部署が使う、帳票出力が必要になる、外部の台帳と照合する、過年度データと統合するなど、実務では後から要件が広がることが珍しくありません。そのため、命名ルールは一度決めて終わりではなく、将来の更新と連携を見据えて管理する必要があります。

まず作っておきたいのが、属性名の命名台帳です。大げさな仕様書でなくても、属性名、表示名、意味、値の形式、単位、入力例、必須か任意か、更新タイミング、備考を整理した一覧があるだけで、運用の安定度は大きく変わります。GeoJSONファイルだけを見て判断するのではなく、属性の意味を説明する台帳を別に持つことで、担当者が変わっても同じルールを引き継ぎやすくなります。

命名台帳では、似た属性の違いを明確にしておくことが大切です。created_dateとsurvey_dateとupdated_dateの違い、facility_idとmanagement_idの違い、inspection_resultとinspection_statusの違いなど、名前だけでは迷いやすい項目を説明しておくと、入力ミスや解釈違いを減らせます。特に、id系の属性は外部台帳との連携に使われることが多いため、どのIDを正とするのか、誰が発番するのか、重複してよいのかを決めておく必要があります。

属性名の変更にもルールが必要です。運用中のGeoJSONで属性名を急に変えると、既存の表示設定、抽出条件、集計処理、帳票出力が動かなくなることがあります。たとえばfacility_nameをsite_nameに変更した場合、人間には似た意味に見えても、データ処理上は別の属性です。変更が必要な場合は、旧属性を一定期間残す、変換表を作る、バージョンを明記するなど、移行の手順を用意しておくと安全です。

将来追加する属性の余地も考えておきます。最初からすべての項目を詰め込む必要はありませんが、命名の型を決めておくと、後から項目が増えても統一感を保てます。点検関連はinspection_で始める、写真関連はphoto_で始める、補修関連はrepair_で始める、管理関連はmanagement_で始めるといった接頭語の設計は、拡張時に役立ちます。新しい属性を追加するときも、既存の型に沿って命名できるため、ばらばらな項目名になりにくくなります。

外部連携を考える場合は、相手側の項目名に引きずられすぎないことも大切です。別の台帳やシステムに合わせて属性名を決める場面はありますが、GeoJSON側の意味が崩れるほど無理に合わせると、内部運用が分かりにくくなります。連携先の項目名とGeoJSONの属性名が違う場合は、対応表を作って変換するほうが安全なこともあります。属性名はGeoJSON内での意味を優先し、連携は対応表で吸収するという考え方です。

また、空欄や未確認の扱いも命名台帳に含めておくと実務で助かります。未調査、該当なし、不明、確認中を同じ空欄で表してしまうと、後から状態を判別できなくなります。属性名そのものだけでなく、その属性にどのような値を許すのかを決めておくことで、データ品質を保ちやすくなります。必要に応じてstatusやnoteを分け、未確認であることを明示できる設計にしておくと、現場の途中経過も扱いやすくなります。

GeoJSONの属性名は、作業開始時には小さな決めごとのように見えます。しかし、データが増え、関係者が増え、更新回数が増えるほど、その影響は大きくなります。命名台帳を作り、変更履歴を残し、追加時のルールを守ることで、GeoJSONは一回限りの地図データではなく、継続して使える業務データになります。後悔しない命名とは、今の自分だけでなく、未来の担当者が迷わず使える状態を作ることです。

まとめ

GeoJSONの属性名は、地図上に表示される小さな項目名に見えますが、実務ではデータの使いやすさを左右する重要な設計要素です。形状が正しくても、propertiesの属性名があいまいであれば、検索、集計、更新、連携の段階で手戻りが発生します。逆に、属性名が整理されていれば、データを受け取った人が内容を理解しやすくなり、長期的な管理にも耐えやすくなります。

後悔しないためには、まず属性名を表示名ではなくデータの意味として考えることが大切です。何の名称なのか、何の日付なのか、何の状態なのかを明確にし、対象と意味を組み合わせた名前にします。次に、英数字や区切り文字のルールを統一し、処理しやすい形に整えます。さらに、略語を増やしすぎず、誰が見ても分かる名前を選ぶことで、担当者が変わっても意味が伝わるデータになります。

数値や日付を扱う属性では、単位や基準をあいまいにしないことも重要です。length_mやinspection_dateのように、値の意味を誤解しにくい名前にしておけば、後工程での判断ミスを減らせます。また、分類値と自由記入欄を分け、status、result、noteなどの役割を明確にすれば、検索や集計に強いGeoJSONになります。最後に、命名台帳を作って属性名、意味、値の形式、更新ルールを管理することで、将来の追加や連携にも対応しやすくなります。

GeoJSONは、単に地図に載せるためだけのファイルではありません。現場の情報を蓄積し、関係者間で共有し、判断や記録につなげるための業務データとして使われることがあります。属性名の命名を丁寧に設計しておくことは、現場調査や台帳管理の精度を支える土台になります。

現地で取得した位置情報、写真、点検結果をGeoJSONなどの地理空間データとして扱う場合は、取得後に属性名を整えるだけでなく、取得時点から項目の意味、単位、入力ルールをそろえておくことが大切です。属性名、表示名、値の形式、更新ルールをセットで管理しておけば、後から地図表示、集計、帳票作成、外部連携へ展開するときにも、無理の少ないデータ運用につながります。