GeoJSONを使って地物データを管理するとき、形状や属性の作り方に意識が向きやすい一方で、Feature IDの設計は後回しになりがちです。しかし、Feature IDは単なる通し番号ではありません。地図上の図形を一意に見つけるための目印になり、検索、更新、差分管理、外部データとの連携、履歴管理、画面表示の安定性に関わる重要な要素です。
「geojson 使い方」を調べて実務で扱い始める段階では、GeoJSONを読み込んで表示できることが最初の目標になります。しかし、運用が進むと、同じ地物を更新したい、特定の図形だけを差し替えたい、複数ファイルに分割したい、別の台帳や現地写真と結び付けたい、といった場面が増えていきます。そのときFeature IDが曖昧だと、画面上では同じように見えるデータでも、内部的には別物として扱われたり、逆に別の地物が同じものとして扱われたりする可能性があります。
この記事では、GeoJSONのFeature IDを設計するときに注意したい6つの観点を、実務担当者向けに整理します。特定のソフトウェアやサービスに依存しない考え方として、既存台帳、測量成果、点検記録、施設管理データ、現地調査データなどにGeoJSONを使う場面を想定しながら解説します。
Feature IDの役割を属性IDと混同しない
GeoJSONのFeature IDを考えるとき、まず整理したいのは、Featureそのものを識別するIDと、propertiesの中に入れる業務上の番号は必ずしも同じものではないという点です。GeoJSONでは、1つのFeatureが1つの地物を表し、そのFeatureに対してFeature直下のidを持たせることがあります。一方で、propertiesには施設番号、管理番号、路線名、地区名、点検番号、図面番号など、業務上必要な属性を入れることができます。どちらも「ID」のように見えるため、設計時に混同しやすい部分です。
Feature IDは、データを機械的に扱うための識別子として考えると分かりやすくなります。地図表示でクリックされたFeatureを特定する、更新時に同じFeatureを探す、差分データを適用する、関連データとひも付ける、といった処理で使うものです。これに対して、properties内の管理番号は、人が業務上確認するための番号である場合があります。台帳上の施設番号や現地で使っている呼称は重要ですが、名称変更、統合、分割、管理部署の変更などによって変わることもあります。
たとえば、ある点検対象をGeoJSONのFeatureとして管理する場合、propertiesには「施設名」「路線名」「点検年度」「管理区分」などを入れることがあります。このとき、施設名をそのままFeature IDにすると、名称変更があったときにIDまで変える必要が出ます。IDが変わると、過去の点検履歴や関連写真、コメント、差分更新の参照先がずれるおそれがあります。人に見せる名前と、内部で同じFeatureを追跡するためのIDは、役割を分けて設計することが大切です。
また、propertiesの中にidという属性を入れる場合にも注意が必要です。GeoJSONのFeature直下のidと、properties内のidは、構造上は別の場所にあります。読み込み側の処理によってはFeature直下のidを優先する場合もあれば、properties内の特定項目を識別子として扱う場合もあります。どちらを正式なFeature IDとして使うのかを決めずに運用すると、作成者ごとに参照する項目が変わり、同じデータを扱っているつもりでも結果が揃わなくなります。
実務では、Feature直下のidを機械処理用の安定した識別子とし、properties内には人が確認しやすい管理番号や表示名を入れる設計が扱いやすいです。ただし、既存の運用で台帳番号がすでに一意であり、将来も変更されにくい場合は、その台帳番号をFeature IDとして使う方法もあります。重要なのは、どの項目を正式な識別子とするかを明確にし、表示用の名称や説明用の属性と混ぜないことです。
変更されにくい識別子にして運用中の参照切れを防ぐ
Feature IDは、一度公開したり他のデータと連携したりすると、簡単には変えにくくなります。GeoJSONを一度だけ表示する用途であれば、連番を付けるだけでも大きな問題にならないことがあります。しかし、定期更新、点検履歴、現地写真、図面、報告書、外部台帳との連携を考えると、IDが変わることは参照切れの原因になります。Feature IDは「今の見た目」ではなく、「将来も同じ地物を指し続けられるか」という視点で設計する必要があります。
変更されやすい情報としては、地物の名称、担当部署、年度、工区、状態区分、点検結果などがあります。これらは業務上重要ですが、Feature IDに含めると、情報が更新されるたびにIDも変わる可能性があります。たとえば、点検年度をIDに含めると、年度が変わるたびに同じ施設でも別のFeature IDになってしまいます。過年度データを別Featureとして管理したい場合は別ですが、同一施設の継続管理が目的であれば、年度はproperties側で管理した方が自然です。
地物の統合や分割が起こる場合も注意が必要です。道路区間、管理区域、敷地境界、設備範囲などは、運用の途中で範囲が変わることがあります。1つのFeatureが2つに分かれる場合、元のIDをそのまま片方に残すのか、新しいIDを両方に付け直すのか、元IDとの対応関係を属性に残すのかを決めておかないと、履歴の追跡が難しくなります。逆に複数のFeatureが統合される場合も、どのIDを代表として残すのか、統合後に新しいIDを発行するのかを考えておく必要があります。
安定したFeature IDを作るには、地物そのものに紐づく固有性を重視します。既存台帳に長期運用されている不変に近い番号がある場合は、それを基礎にできます。台帳番号がない場合は、地物種別、管理範囲、発行順、内部の一意番号などを組み合わせて、後から意味が変わりにくいIDを作る方法があります。ただし、意味を詰め込みすぎると、分類変更のたびにIDを変えたくなるため、IDには最低限の識別性だけを持たせ、詳しい分類は属性で表現する方が安定します。
また、作業用の仮IDと正式IDを分けることも有効です。現地調査中やデータ整備中は、まだ台帳番号が確定していないことがあります。その段階で仮のFeature IDを配布してしまうと、後から正式番号に置き換えたときに参照関係が切れる可能性があります。仮IDを使う場合は、仮IDであることが分かる規則にし、正式化のタイミングで対応表を作成しておくと、更新時の混乱を減らせます。Feature IDは作成時だけでなく、運用中にどの程度変わらないかを重視して設計することが大切です。
文字列と数値の扱いを決めてシステム間の差を減らす
GeoJSONのFeature直下のidは、一般に文字列または数値として扱われます。どちらを採用する場合でも、運用ルールを最初に決めておくことが重要です。IDを数値で持たせると見た目は簡潔ですが、システム間の受け渡しや表計算、データベース、変換処理を挟むと、先頭ゼロの消失、型変換、丸め表示などが起こることがあります。実務では、施設番号や管理番号に先頭ゼロを含むことも多いため、IDを数値として扱うか文字列として扱うかを最初に決めておくことが重要です。
たとえば、「000123」という管理番号を数値として扱うと、「123」として保存される可能性があります。人が見るだけなら同じ番号のように感じるかもしれませんが、文字列として比較する処理では「000123」と「123」は別物です。既存台帳では「000123」が正式番号で、別のシステムでは「123」として読み込まれるような状態になると、結合処理で一致しなかったり、差分更新で同じFeatureを探せなかったりします。IDは見た目の番号ではなく、完全一致で照合される値として扱う必要があります。
大きな数値にも注意が必要です。非常に桁数の多い番号を数値として扱うと、処理環境によっては正確に保持できない場合があります。画面表示では同じように見えても、内部的に丸められて別の値になってしまうと、Feature IDとしての信頼性が損なわれます。そのため、長い番号、先頭ゼロを持つ番号、英字や記号を含む番号、外部台帳と完全一致させたい番号は、文字列として扱う方が安全です。
文字列IDにする場合は、使用する文字の範囲も決めておくと運用しやすくなります。日本語を含むIDも技術的には扱える場面がありますが、ファイル名、URL、外部連携、検索処理、文字コードの違いを考えると、英数字と一部の区切り記号に抑えた方がトラブルを減らせます。記号を使う場合も、空白、全角記号、見た目が似た文字、環境によって意味を持つ記号は避ける方が無難です。IDに人が読む説明を入れたい気持ちはありますが、説明はpropertiesに入れ、Feature IDは安定して比較しやすい値にする方が実務向きです。
また、大文字と小文字の扱いも決めておく必要があります。ある作業者が「A001」と入力し、別の作業者が「a001」と入力した場合、処理によっては別IDとして扱われます。人の目では同じように見える値でも、機械的には一致しないことがあります。IDの発行規則として、大文字に統一する、小文字に統一する、区切り記号を限定する、桁数を揃える、といったルールを定めておくと、後から大量の修正を行う手間を減らせます。
Feature IDを文字列に統一する場合でも、properties内に数値として扱うべき項目を入れることはできます。距離、面積、標高、点検回数、年度などは、必要に応じて数値型で管理できます。つまり、すべてを文字列にするという話ではなく、識別子として完全一致が求められる値は文字列として安定させ、計算や集計に使う値は別の属性として適切な型で持たせる、という整理が重要です。
重複と欠番を検出できる管理ルールを作る
Feature IDは、実務上は一意に扱える状態にしておくことが重要です。同じGeoJSON内で複数のFeatureが同じIDを持っていると、更新、選択、検索、スタイル適用、関連データの結合などで予期しない結果になることがあります。たとえば、あるIDを指定して1つのFeatureだけを更新するつもりが、同じIDを持つ別のFeatureにも影響する可能性があります。逆に、欠番や未設定のIDが混在していると、特定のFeatureだけ追跡できなくなります。
重複は、手作業でGeoJSONを作成したときだけでなく、複数のデータを結合したときにも発生します。別々の地区でそれぞれ「001」「002」「003」のような連番を使っている場合、1つのファイルに統合すると同じIDが複数出てくることがあります。地区ごとの中では一意でも、全体では一意ではないという状態です。このような場合は、地区コードや地物種別などを組み合わせるか、全体で一意になる内部IDを別途発行する必要があります。
欠番そのものは必ずしも問題ではありません。削除や統合の履歴を残す運用では、欠番が発生するのは自然です。むしろ、欠番を埋めるために過去のIDを再利用すると、古い履歴や外部参照と衝突する可能性があります。重要なのは、欠番があることではなく、欠番が意図したものか、誤ってIDを付け忘れたものかを判別できることです。削除済み、統合済み、未発番、仮登録などの状態を管理できるようにしておくと、データ品質を確認しやすくなります。
IDの重複や未設定を防ぐには、作業の最後に目視確認するだけでは不十分です。Feature数が少ないうちは人の目でも確認できますが、数百、数千、数万件になると、重複や空欄を見落としやすくなります。GeoJSONを作成する前段階の一覧表や台帳で、ID列の重複、空欄、余分な空白、全角半角の違い、不要な記号を確認する手順を入れると安全です。GeoJSONに変換した後も、Feature直下のidが想定どおりに入っているか、想定した形式になっているかを確認することが望ましいです。
複数人で編集する場合は、IDの発行権限も決めておく必要があります。各担当者が自由にIDを作ると、同じ番号を別のFeatureに使ってしまうことがあります。管理者が一括発行する、地区ごとに発行範囲を分ける、仮IDは作業者別の接頭辞を付ける、正式化時に重複チェックを必ず行うなど、運用ルールを決めておくと混乱を避けやすくなります。Feature IDはデータの中身だけでなく、作成や更新の業務フローと合わせて管理する必要があります。
また、IDの前後に入った空白にも注意が必要です。「A001」と「A001 」は、人の目ではほとんど同じに見えても、機械的には別の値として扱われる場合があります。表計算から変換したデータでは、意図しない空白や改行が入ることがあります。GeoJSONを使う前に、IDの前後空白を除去し、空文字を許可しない確認を行うだけでも、多くのトラブルを防げます。重複チェックは単に同じ文字列を探すだけでなく、表記揺れを含めて確認することが大切です。
分割配信や更新差分を前提にID体系を設計する
GeoJSONは扱いやすい形式ですが、データ量が増えると、1つのファイルにすべてを入れる運用が難しくなることがあります。地物数が多い、属性が多い、範囲が広い、更新頻度が高い、といった場合は、地区別、地物種別別、年度別、管理単位別などに分割することがあります。このとき、Feature IDの設計が分割後の扱いやすさに大きく影響します。
分割前のファイルでは一意だったIDでも、分割後に別ファイルと組み合わせて使うと衝突することがあります。特に、各ファイル内だけで連番を振っている場合は注意が必要です。たとえば、地区Aの001と地区Bの001が別々のファイルにあるうちは問題が見えにくいですが、同じ画面に重ねたり、検索対象を横断したり、統合して分析したりすると、同じIDが複数存在することになります。後から全体一意に直すには、関連データの修正も必要になるため、最初から全体で一意になる設計にしておく方が安全です。
更新差分を配布する場合も、Feature IDは重要です。全件を毎回配り直すのではなく、追加、更新、削除されたFeatureだけを反映したい場合、更新対象を特定する基準が必要になります。Feature IDが安定していれば、同じIDのFeatureを差し替える、存在しないIDを追加する、削除リストにあるIDを消す、といった処理を設計しやすくなります。逆に、更新のたびにIDが変わると、差分なのか新規なのか判別しにくくなります。
分割配信では、IDだけでなくファイルの分け方も考慮します。地物の位置が変わったとき、所属する地区や範囲が変わることがあります。もしファイル名やフォルダ構成に地区名を含め、Feature IDにも地区名を強く組み込んでいると、地区変更のたびにIDまで変えたくなるかもしれません。管理上の所属は変わる可能性があるため、IDに含める情報は慎重に選ぶ必要があります。所属情報は属性として持たせ、IDは地物の継続性を優先する考え方が有効です。
一方で、完全に意味のないランダムなIDだけにすると、人が確認しにくいという課題もあります。実務では、台帳番号や管理単位との対応が分かることも重要です。そのため、内部IDと表示用管理番号を分け、必要に応じて対応表や属性で結び付ける方法が現実的です。Feature IDは機械が安定して扱うためのキー、管理番号は人が業務上確認するための情報、という役割分担を意識すると、分割や更新にも強い構成になります。
また、削除の扱いも設計に含めるべきです。GeoJSON内に存在しないFeatureは単に未配信なのか、削除済みなのか、範囲外なのかが分からないことがあります。差分更新を行う場合は、削除対象のIDを別途管理する、状態属性で無効化を表す、更新履歴で削除日を持つなど、運用に合った方法を決めておく必要があります。Feature IDが安定していれば、削除や無効化の履歴も追いやすくなります。
複数のGeoJSONを組み合わせる場合は、IDの名前空間も意識します。道路、設備、区域、点検箇所など、異なる種類の地物を同じ画面で扱うとき、地物種別ごとに同じ番号が存在することがあります。Feature IDを全体で一意にするのか、地物種別とIDの組み合わせで一意にするのかを決めておかないと、検索や更新の条件が曖昧になります。長期的にデータを増やす予定がある場合は、将来追加される地物種別とも衝突しない設計にしておくと安心です。
表示名ではなく内部IDとして安全性と将来性を確保する
Feature IDは、画面に表示する名前ではなく、内部で同じFeatureを識別するための値として設計することが基本です。表示名をIDにすると、人には分かりやすい反面、表記変更、誤字修正、名称統一、管理区分変更の影響を受けやすくなります。特に日本語の名称は、全角半角、旧字体、スペース、記号、略称、正式名称の違いが発生しやすく、完全一致で扱うIDには向かない場合があります。
表示名には、業務上の分かりやすさが求められます。現地で呼ばれている名称、報告書に載せる名称、関係者が理解しやすい名称は、propertiesに入れて表示や検索に使うと便利です。一方で、Feature IDには、表記の分かりやすさよりも、変わりにくさ、重複しにくさ、処理しやすさが求められます。この2つを分けることで、名称を改善してもIDは維持でき、関連データの参照も保ちやすくなります。
安全性の観点では、個人情報や機密性の高い情報をFeature IDに含めないことも重要です。GeoJSONは地図表示やデータ連携のために共有されることがあり、IDは属性よりも目立たないように見えても、ファイル内には残ります。担当者名、所有者名、電話番号、個別の契約情報、内部事情を示す文字列などをIDに含めると、意図しない共有時に問題になる可能性があります。必要な情報は公開範囲を確認したうえで属性として管理し、IDには識別に必要な最小限の情報だけを持たせることが望ましいです。
将来性という点では、ID体系を最初から厳密に作り込みすぎないことも大切です。地物種別、地域、年度、管理者、状態、用途などをすべてIDに埋め込むと、一見整理されているように見えます。しかし、どれか1つの分類が変わっただけでIDを変更したくなるため、長期運用では不安定になります。IDは分類情報の保管場所ではなく、一意に識別するためのキーです。分類や状態は属性で管理し、必要に応じて検索や絞り込みに使う方が柔軟です。
ただし、まったく意味のないIDにすればよいというわけでもありません。現場で確認する人、台帳を管理する人、データ変換を行う人が、最低限の照合をしやすいことも重要です。そのため、実務では、短い接頭辞と一意番号を組み合わせる、既存台帳番号を文字列化する、地物種別を簡潔に示す記号を付けるなど、過度に意味を持たせすぎない範囲で人にも扱いやすいIDにする方法がよく合います。大切なのは、IDだけで全情報を表そうとしないことです。
また、Feature IDの変更が必要になった場合の手順も考えておくべきです。誤発番、重複、統合、分割、既存台帳との整合などにより、どうしてもIDを変更することがあります。その場合は、旧IDと新IDの対応を残し、関連する写真、点検記録、コメント、外部データ、過去ファイルをどの範囲まで更新するかを決める必要があります。IDを変更した事実が追えないと、過去データとのつながりが失われます。IDは変えない前提で設計しつつ、変える場合の記録方法も用意しておくと、運用の安全性が高まります。
GeoJSONの使い方を実務に広げるほど、Feature IDは単なるデータ項目ではなく、運用全体の基盤になります。初期段階では「地図に表示できればよい」と考えがちですが、更新、共有、分析、履歴管理まで考えると、IDの安定性が成果物の信頼性に直結します。表示名、属性、内部IDの役割を分け、将来の変更に耐えられる構造にしておくことが、長く使えるGeoJSONデータを作るうえで欠かせません。
まとめ：Feature IDを整えるとGeoJSONの使い方が安定する
GeoJSONのFeature IDは、地物を識別し、更新や連携を安定させるための重要な要素です。形状や属性の内容が正しくても、Feature IDが曖昧だと、同じ地物を継続的に追跡できなかったり、別の地物と取り違えたり、差分更新が難しくなったりします。特に、点検、測量、施設管理、現地調査のように、同じ対象を何度も扱う業務では、Feature IDの設計が後工程の効率に大きく影響します。
設計時には、まずFeature直下のidとproperties内の管理番号を混同しないことが大切です。人が見るための名称や業務上の番号と、機械的にFeatureを特定するためのIDは、役割が異なります。次に、名称や年度のような変わりやすい情報をIDに入れすぎず、長期的に変わりにくい識別子を選ぶことが重要です。さらに、文字列と数値の扱い、先頭ゼロ、大文字小文字、空白、記号のルールを決めておくことで、システム間の差や表記揺れによる不一致を減らせます。
また、Feature IDは作るだけでなく、重複や未設定を検出できる管理手順とセットで考える必要があります。複数人で作業する場合や、複数ファイルを統合する場合は、IDの発行範囲、仮IDの扱い、正式化の手順を決めておくと安全です。分割配信や更新差分を行う場合には、ファイル内だけでなく全体で一意になるか、削除や統合の履歴をどう扱うかも重要になります。
Feature IDは、見た目の分かりやすさだけで決めるものではありません。表示名は属性として管理し、IDは内部的に安定して使える値にすることで、名称変更や分類変更があってもデータのつながりを保ちやすくなります。個人情報や機密情報を含めない、意味を詰め込みすぎない、変更時の対応表を残すといった配慮も、実務で安心してGeoJSONを使うための基本です。
GeoJSONは、地図上に点、線、面を表示するだけでなく、現地で取得した情報や台帳データを結び付けるための実用的な形式です。Feature IDを丁寧に設計しておくと、現地調査結果の整理、点検履歴の更新、写真や測位データとの連携、複数年度の比較が進めやすくなります。これからGeoJSONを業務で活用する場合は、形状や属性の作成と同じくらい、Feature IDの設計に時間をかけることをおすすめします。
現地で取得した位置情報、写真記録、点検メモなどをGeoJSONなどの地図データと結び付けて活用したい場合は、取得から整理、共有までの流れを見据えておくことが大切です。Feature IDを安定させておけば、現地データと管理データの対応関係も保ちやすくなります。特定のツール名や製品名に依存せず、IDの発行ルール、属性設計、更新手順を先に整えることで、将来のデータ移行やシステム連携にも対応しやすくなります。