GeoJSONを扱う実務では、形状そのものは正しく表示されているのに、属性情報だけが想定どおりに読めないことがあります。数値として扱いたい面積や延長が文字列になっていたり、空欄が混ざった列だけ読み込み後に扱いが変わったり、同じ項目名なのに一部の地物だけ別の値の入り方をしていたりすると、検索、色分け、集計、ラベル表示、他形式への変換で不具合が起きやすくなります。本記事では、geojsonで検索する実務担当者に向けて、属性型が崩れる原因を整理し、公開・共有前に確認したいデータ整形の6手順を解説します。
GeoJSONの属性型が崩れるとは何か
GeoJSONは、位置情報を持つ地物と、その地物に紐づく属性情報をまとめて扱える形式です。座標や形状の情報だけでなく、名称、分類、面積、延長、管理番号、調査日、状態、メモなどをpropertiesの中に持たせることで、地図上の表示や検索、集計、フィルタリングに利用できます。実務では、現地調査の結果、台帳情報、設計関連の属性、点検記録、境界や施設の管理情報などをGeoJSONにまとめる場面があります。
属性型が崩れるとは、見た目には同じ項目に見えても、データとしては数値、文字列、真偽値、空値などが混ざり、利用側で意図しない扱いになる状態を指します。たとえば、ある地物の面積が数値の120.5として入っている一方で、別の地物では"120.5"のような文字列として入っている場合、画面上では同じように見えても、集計時には別物として扱われることがあります。また、延長の欄に「約30m」「30」「30.0」「未測定」が混在していると、数値として並べ替えたい場面で文字列として扱われたり、計算対象から外れたりすることがあります。
GeoJSON自体は、属性項目ごとに厳密な型定義を持つ表形式の規格ではありません。そのため、作成時に自由に値を入れられる反面、データ作成者が意識して整形しないと、読み込む側のソフトウェアやシステムによって属性の解釈が変わる場合があります。特に、表計算ソフトで編集したデータ、複数人が追記した調査データ、既存台帳から変換したデータ、複数の測量成果を結合したデータでは、属性の入り方にばらつきが出やすくなります。
属性型が崩れると、地図上の色分けが意図どおりにならない、数値範囲で抽出できない、ラベルに不要な小数や記号が表示される、日付順に並ばない、分類ごとの件数が合わない、別形式へ変換したときに一部の値が欠ける、といった問題につながります。形状のエラーに比べると発見が遅れやすく、納品前や公開後に気づくこともあります。
この問題を防ぐには、変換後のGeoJSONだけを見るのではなく、元データの段階から属性項目の意味、値の種類、空欄の扱い、単位、表記ゆれを整理することが重要です。以降では、現場や社内でGeoJSONを扱う際に確認しやすいよう、6つの手順に分けてデータ整形の考え方を説明します。
手順1として属性項目の用途を先に決める
最初に行うべきことは、属性項目を何のために使うのかを決めることです。GeoJSONのpropertiesには多くの情報を入れられますが、すべての項目を同じ厳密さで整える必要があるわけではありません。集計に使う項目、検索に使う項目、ラベル表示だけに使う項目、メモとして残す項目では、求められる型や整形ルールが変わります。用途を決めないまま整形を始めると、数値化すべき項目を文字列のまま残したり、逆に文字列として保持すべき管理番号から先頭のゼロが落ちたりする原因になります。
たとえば、面積、延長、高さ、数量、点検回数、優先度の点数などは、後から集計や比較を行う可能性が高い項目です。このような値は、単位を属性名や別項目で明確にし、値そのものには余計な文字を入れず、数値として扱える形にするのが基本です。一方、管理番号、施設番号、地番に相当する文字列、図面番号、分類コードなどは、数字だけで構成されていても計算対象ではないことがあります。この場合は、数値ではなく文字列として保持したほうが安全です。管理番号を数値として扱うと、先頭のゼロが消えたり、桁数の違いが見えなくなったりすることがあります。
用途を決める際は、項目名だけで判断しないことも大切です。たとえば「code」という項目名は、分類を表す文字列の場合もあれば、並び順を決める数値の場合もあります。「date」という項目名も、調査日、登録日、更新日、撮影日など、意味が異なれば必要な精度が変わります。年月日だけでよいのか、時刻まで必要なのか、現地の作業日を表すのか、データ更新日を表すのかを決めておかないと、後工程で混乱します。
属性項目の用途を決めたら、項目ごとに期待する型を簡単に書き出します。名称は文字列、面積は数値、調査日は日付を表す文字列、確認済みフラグは真偽を表す値、備考は文字列、というように、最低限の型ルールを作ります。この時点で、全員が同じ判断をできる程度に整理しておくことが重要です。複雑な仕様書を作る必要はありませんが、どの項目が集計対象で、どの項目が表示用で、どの項目が識別用なのかは明確にしておきます。
また、GeoJSONを外部に渡す場合は、受け取る側がどのように利用するかも確認しておく必要があります。地図で見るだけなのか、属性検索を行うのか、別の台帳に取り込むのか、現地確認の記録として蓄積するのかによって、必要な整形の粒度が変わります。特に、複数のシステムや複数の部署で同じGeoJSONを使う場合は、最初に用途を確認しておかないと、片方では便利な表記がもう片方では不具合の原因になることがあります。
この手順で大切なのは、データをきれいに見せることではなく、後で機械的に扱いやすい状態を定義することです。人が見て分かる表記と、処理に向いた値は必ずしも同じではありません。表示用に「約30m」と書きたい場合でも、集計用には30という数値を別項目で持たせるほうが扱いやすくなります。属性型の崩れを防ぐ第一歩は、項目ごとの役割を分け、処理用の値と説明用の値を混ぜないことです。
手順2として空欄と欠損値の扱いを統一する
次に確認したいのは、空欄と欠損値の扱いです。属性型が崩れる原因として多いのが、同じ意味の空欄に複数の表現が混ざることです。ある地物では値が入っていない状態を空欄で表し、別の地物では「未入力」「なし」「不明」「-」「0」などで表していると、読み込み側はそれぞれを異なる値として扱います。人間には似た意味に見えても、データとしては別の値です。
特に注意したいのは、0と未入力を混同しないことです。数値項目における0は、多くの場合、測定値や数量がゼロであることを意味します。一方、未入力は値が分からない、まだ測っていない、対象外である、といった状態を表します。たとえば、点検回数が0であることと、点検回数が未記録であることは意味が違います。面積が0であることと、面積が未計算であることも同じではありません。未入力をとりあえず0で埋めると、後から平均値や合計値を計算したときに結果が歪むことがあります。
GeoJSONでは、値がない状態を表す方法として、項目自体を持たせない方法、値にnullを入れる方法、空文字を入れる方法などが考えられます。どれが常に正解というより、利用先の処理に合わせて統一することが重要です。集計や変換を前提にする場合は、欠損を欠損として扱える形にそろえると、後から検出しやすくなります。空文字とnullが混ざると、欠損チェックの条件が増え、見落としが起きやすくなります。
文字列項目でも、空欄の扱いは統一が必要です。備考欄のように自由記述を許す項目であっても、「特になし」「なし」「無し」「該当なし」「-」が混在すると、検索や集計の際に不要な分類が増えます。備考がない場合は空にするのか、明示的に「該当なし」と書くのかを決め、同じルールで入力します。後から人が読む資料として必要な場合でも、機械処理に使う項目とは分けておくと安全です。
欠損値を整える際は、対象外、未調査、未入力、不明を同じ扱いにしないことも大切です。対象外は、その地物には項目の意味がない状態です。未調査は、調べれば値が入る可能性がある状態です。不明は、調査しても判断できなかった状態です。未入力は、作業上まだ入力されていない状態です。これらをすべて空欄にしてしまうと、後から作業状況や品質を確認できなくなります。必要に応じて、値そのものとは別に状態を表す項目を用意すると、属性型を保ったまま情報を残せます。
たとえば、延長の数値項目には数値または欠損だけを入れ、別の状態項目で「測定済み」「未測定」「対象外」などを管理する方法があります。こうすると、延長項目は数値として扱いやすくなり、状態は文字列の分類として扱えます。ひとつの項目に「30」「未測定」「対象外」を混ぜるよりも、後の集計や色分けが安定します。
空欄の統一は地味な作業ですが、属性型の崩れを防ぐうえでは効果があります。GeoJSONに変換する前の表データや中間データの段階で、欠損値の表現を洗い出し、同じ意味のものを同じ表現にそろえます。そのうえで、数値項目に文字列の欠損表現を入れない、文字列項目では表記ゆれを減らす、状態を表す必要がある場合は別項目に分ける、という方針を取ると、変換後の不具合を減らせます。
手順3として数値と文字列の混在を取り除く
属性型が崩れる場面で特に多いのが、数値と文字列の混在です。GeoJSONの見た目では、120と"120"の違いは分かりにくいかもしれません。しかし、前者は数値、後者は文字列です。地図表示では同じように見えても、範囲検索、合計、平均、大小比較、階級区分、色分けなどを行うと差が出ます。数値として扱いたい項目に文字列が混ざっていると、読み込み側で期待どおりに数値処理できない場合があります。
数値と文字列が混ざる原因はさまざまです。単位を値の中に入れてしまう、桁区切りの記号を入れる、全角数字と半角数字が混ざる、前後に空白が入る、概算を示す文字を付ける、未測定などの文字を同じ項目に入れる、といったケースが代表的です。たとえば、面積項目に「100」「100.0」「約100」「100平方メートル」「未入力」が混ざっていれば、その項目は安定した数値として扱いにくくなります。
整形の基本は、数値項目には数値だけを入れることです。単位は項目名に含めるか、別の単位項目で管理します。たとえば、area_sqmのように項目名で平方メートル相当の意味を示す、length_mのようにメートル相当の意味を示す、といった考え方です。日本語の項目名を使う場合でも、「面積_平方メートル」「延長_メートル」のように、値の単位が分かる名称にしておくと、値の中に単位を書かずに済みます。
概算や注記を残したい場合は、数値項目と注記項目を分けます。数値項目には100を入れ、別の項目に「概算」や「現地目測」などの情報を入れる形です。これにより、集計では100として扱えますし、表示時には注記も確認できます。値の中に「約100」と入れてしまうと、数値として計算しにくくなるだけでなく、後から「約」を取り除く処理が必要になります。
また、小数の扱いも統一しておきます。必要以上に小数桁が多い値が混ざると、ラベル表示が見づらくなったり、わずかな差を別値として扱ったりすることがあります。実務上必要な精度に合わせて丸め方を決め、元データと公開用データを分けることも検討します。ただし、丸めによって重要な精度が失われる場合があるため、測量成果や設計値の扱いでは、どの段階で丸めるかを明確にしておく必要があります。
文字列として保持すべき数字にも注意が必要です。管理番号、コード、地番に相当する項目、枝番、部屋番号、施設IDなどは、見た目が数字でも計算対象ではないことがあります。このような項目を数値に変換すると、先頭のゼロが消えたり、区切り記号が失われたり、長い番号が別の表記に変わったりする可能性があります。数値か文字列かを決める基準は、見た目ではなく用途です。足し算や大小比較をするなら数値、識別や分類に使うなら文字列、と考えると整理しやすくなります。
数値と文字列の混在を確認するには、項目ごとに値の種類を一覧し、想定外の文字が入っていないかを見ることが有効です。数字だけのはずの項目に、空白、単位、記号、漢字、かな、注記が混ざっていないかを確認します。特に、コピー貼り付けで作られたデータでは、見えない空白や全角記号が混ざることがあります。見た目では分からない差が、変換後の型崩れにつながるため、変換前に整理しておくことが重要です。
この手順では、すべてを数値に変換することが目的ではありません。数値として扱う項目は数値に、文字列として扱う項目は文字列に、役割ごとにそろえることが目的です。GeoJSONの属性は自由度が高いからこそ、項目ごとのルールを明確にし、混在を取り除くことで安定したデータになります。
手順4として日付やコード値を安定した形式にそろえる
日付やコード値も、属性型が崩れやすい項目です。日付は人が読むだけなら「2026年5月」「5/25」「令和表記」「調査済み」などでも意味が通じるかもしれません。しかし、GeoJSONを地図表示や検索、時系列管理に使う場合、日付形式がばらばらだと並べ替えや範囲抽出が不安定になります。日付として扱いたい項目には、一定の形式を決めて入力することが大切です。
年月日だけを管理する場合は、年、月、日が常に同じ順序で並ぶ形式にそろえると扱いやすくなります。月や日が一桁の場合でも、桁の表記をそろえておくと、文字列として並べた場合にも順序が崩れにくくなります。時刻まで必要な場合は、日付と時刻の区切り、時刻の桁、時間帯の扱いを決めておきます。現地調査の日時、データ作成日時、更新日時が混在する場合は、項目名で意味を分けることも必要です。
日付項目で避けたいのは、同じ項目に日付以外の状態を混ぜることです。たとえば、調査日に「未定」「不要」「確認中」などを入れると、その項目は純粋な日付として扱いにくくなります。この場合も、調査日は日付または欠損として保持し、調査状態を別項目で管理するほうが安定します。調査日が未定であることを記録したい場合は、状態項目に「未定」と入れ、日付項目は欠損にします。
コード値についても同様です。分類コード、施設種別、状態区分、優先度区分などは、表記ゆれが起きると集計結果が分かれます。たとえば、同じ状態を表す値として「完了」「済」「確認済」「OK」が混在すると、人間には近い意味に見えても、データ上は別分類になります。色分けや件数集計を行うと、同じ分類のはずの地物が別々に表示されることがあります。
コード値を安定させるには、入力できる値の一覧を先に決めることが有効です。分類項目なら、使用する分類名を決め、それ以外の表記を入れないようにします。状態項目なら、未着手、作業中、確認済み、対象外など、必要な状態を定義します。優先度であれば、高、中、低のような文字列にするのか、1、2、3のような数値にするのかを決めます。どちらを選ぶ場合でも、途中で混在させないことが重要です。
数値コードを使う場合は、コードの意味を別途管理する必要があります。たとえば、1が未確認、2が確認済み、3が対象外というように決めた場合、GeoJSONだけを見た人には意味が分かりにくいことがあります。表示用の分類名を別項目に持たせるか、データ仕様としてコード表を残すと、後から利用する人が迷いにくくなります。一方で、文字列の分類名を使う場合は、人が見て分かりやすい反面、表記ゆれが起きやすいため、入力時の統一が重要です。
日付やコード値は、地図上での見た目だけでは問題に気づきにくい項目です。すべての地物が表示されていても、日付順に並べると順序がおかしい、特定期間で抽出すると漏れがある、分類別の件数が想定より多い、といった形で後から問題が表面化します。GeoJSONを書き出した後ではなく、書き出す前のデータ整形段階で、日付形式とコード値をそろえることが重要です。
実務では、自由入力の項目が増えるほど表記ゆれが起こりやすくなります。現地で入力する場合は、入力しやすさを優先して短い表現を使うことがありますが、後で統合する段階で必ず整形が必要です。入力時点で選択式にできる項目は選択式にし、自由記述は備考や補足に限定すると、日付やコード値の崩れを減らしやすくなります。
手順5として地物ごとのproperties構造をそろえる
GeoJSONでは、各地物がpropertiesを持ち、その中に属性情報を格納します。属性型の崩れを防ぐには、値そのものだけでなく、地物ごとのproperties構造をそろえることも重要です。ある地物には面積、延長、状態、調査日が入っているのに、別の地物には一部の項目が存在しない、さらに別の地物には似た意味の別項目名がある、という状態では、読み込み側で安定して扱うことが難しくなります。
たとえば、ある地物では「名称」という項目を使い、別の地物では「name」という項目を使い、さらに別の地物では「施設名」という項目を使っていると、同じ意味の属性が複数の項目に分散します。表示設定や検索条件を作るときに、どの項目を使えばよいか分からなくなります。また、項目名の大文字と小文字、全角と半角、余分な空白の違いも、データ上は別の項目として扱われることがあります。
properties構造をそろえるためには、全地物に共通する属性項目を決めることが基本です。必ず入れる項目、条件によって入れる項目、任意で入れる項目を分け、同じ意味の項目には同じ名前を使います。値がない場合でも、欠損値として項目を持たせるのか、項目自体を省略するのかを決めておくと、後工程で扱いやすくなります。特に、同じデータセット内では、できるだけ項目の有無をそろえるほうが確認しやすくなります。
項目名の付け方にも注意が必要です。日本語の項目名は人が見て分かりやすい一方、連携先によっては扱いに注意が必要になる場合があります。英数字の項目名は処理しやすいことが多い一方、意味が伝わりにくくなることがあります。どちらを使う場合でも、途中で混在させないこと、同じ意味の項目を複数作らないこと、長すぎる名前や曖昧な名前を避けることが大切です。
また、入れ子の構造を使う場合にも注意が必要です。GeoJSONのpropertiesには、文字列や数値だけでなく、配列や入れ子の情報を持たせることもできます。しかし、地図表示や変換の工程によっては、入れ子の属性を想定どおりに扱えないことがあります。複雑な構造が必要な場合を除き、実務で共有する属性は平たい構造にしておくほうが扱いやすいことがあります。点検履歴や複数写真の情報などを詳しく持たせたい場合は、GeoJSON内にすべて詰め込むのではなく、外部の台帳や別ファイルと識別子で紐づける方法も検討できます。
地物の種類が複数ある場合は、共通項目と種別ごとの項目を分けて考えます。点、線、面の地物をひとつのGeoJSONにまとめる場合、面積は面の地物だけ、延長は線の地物だけに意味を持つことがあります。このような場合、すべての地物に同じ属性を持たせると空欄が多くなります。一方で、地物種別ごとに完全に別の構造にすると、共通検索がしにくくなります。まず地物種別、管理番号、名称、状態、調査日などの共通項目をそろえ、そのうえで種別固有の項目を追加すると整理しやすくなります。
複数のデータを結合するときは、properties構造の確認が特に重要です。別々に作成されたGeoJSONを結合すると、同じ意味の項目が別名で存在したり、数値と文字列が混ざったり、不要な作業用項目が残ったりすることがあります。結合前に項目名を対応付け、不要な項目を削除し、共通項目の型をそろえることで、結合後の崩れを防げます。
properties構造をそろえる作業は、見た目の地図表示だけでは確認しきれません。属性一覧として見たときに、列が過剰に増えていないか、似た名前の項目が重複していないか、特定の地物だけ項目構成が違っていないかを確認します。GeoJSONは柔軟な形式ですが、実務で安定して使うには、データセットとしての一貫性が欠かせません。
手順6として読み込み後の表示と集計で確認する
データ整形が終わったら、GeoJSONとして書き出した後に、実際の利用に近い形で確認します。元データの表では整って見えていても、GeoJSONに変換した段階で値の扱いが変わることがあります。また、読み込む環境によって属性の解釈や表示方法が異なる場合もあります。そのため、変換前の確認だけで終わらせず、変換後のGeoJSONを開き、属性表示、検索、色分け、集計、並べ替えを試すことが重要です。
まず確認したいのは、属性の値が想定どおりに表示されるかです。数値項目に単位や注記が混ざっていないか、管理番号の先頭のゼロが落ちていないか、日付がばらばらの表記になっていないか、空欄が想定どおりに扱われているかを見ます。ラベル表示を使う場合は、地図上に表示したときに余計な小数桁や不要な記号が出ていないかも確認します。
次に、数値項目で範囲抽出や並べ替えを行います。面積が大きい順に並べたときに、文字列として並んでいないかを確認します。文字列として並ぶと、数値の大小ではなく文字の順序で並ぶため、意図しない順番になることがあります。範囲条件を指定したときに対象が正しく抽出されるか、欠損や対象外の地物が混ざらないかも確認します。
分類項目では、分類別の件数を確認します。想定していた分類が数種類のはずなのに、表記ゆれによって細かく分かれていないかを見ます。「確認済み」と「確認済」、「対象外」と「対象なし」のような近い表現が別分類になっていれば、整形漏れの可能性があります。分類項目は、色分け表示に使うことが多いため、表記ゆれがあると凡例が増え、地図が分かりにくくなります。
日付項目では、期間で抽出したり、日付順に並べたりして確認します。年月日として見える値でも、形式がそろっていないと正しく並ばないことがあります。時刻を含む場合は、時刻の欠落や時間帯の扱いも確認します。調査日、作成日、更新日など複数の日付がある場合は、それぞれの意味に合った値が入っているかを見ます。
また、GeoJSONを別形式へ変換する予定がある場合は、変換後も確認します。ある環境では問題なく見えていても、別の環境に取り込むと、項目名が変わる、長い文字列が切れる、入れ子構造が展開されない、数値が文字列として扱われる、といったことがあります。納品や共有を前提にする場合は、受け渡し先で想定される利用方法に近い確認を行うと安全です。
確認時には、全件を目視するだけでなく、代表的な条件を作って検証します。数値が最大の地物、最小の地物、欠損している地物、分類ごとの代表地物、最近の日付と古い日付、特殊な文字を含む名称などを見ます。問題が起きやすい値を意識して確認すると、表面的な表示だけでは見つからない崩れを発見しやすくなります。
さらに、元データの件数とGeoJSONの地物数が一致しているかも確認します。属性整形の途中で行を削除したり、結合時に重複したりすると、型以前にデータ件数が変わることがあります。地物数、分類別件数、欠損件数、主要な数値の合計や最大最小を、元データと変換後で比較すると、変換ミスを見つけやすくなります。
この手順は、データ整形の最後の検査であると同時に、次回以降の改善材料を見つける工程でもあります。どの項目で崩れが起きたのか、どの入力表記が原因だったのか、どの確認で発見できたのかを記録しておくと、次のデータ作成時に同じ問題を減らせます。
まとめとして整形ルールを記録し再利用できる形にする
GeoJSONの属性型が崩れる問題は、単発の修正だけでは繰り返し起こりやすいものです。毎回、担当者が目視で直していると、作業者によって判断が変わり、別の表記ゆれが生まれることもあります。そのため、最後に重要なのは、今回行った整形ルールを記録し、次回も同じ手順で再利用できる形にすることです。
記録しておきたい内容は、項目名、項目の意味、想定する型、単位、欠損値の扱い、入力できる分類、日付形式、備考の使い方などです。特に、数値にする項目と文字列にする項目の判断は、後から見返せるようにしておくと便利です。管理番号のように数字だけに見える文字列は、担当者が変わると数値化されてしまうことがあります。なぜ文字列として扱うのかを残しておくことで、再発を防ぎやすくなります。
また、変換前の元データ、整形後の中間データ、最終的なGeoJSONを分けて管理することも有効です。最終データだけを残していると、どの段階で値の扱いが変わったのかを追跡しにくくなります。元データからどのような整形を行い、どの項目を削除し、どの項目を追加し、どの表記を統一したのかが分かる状態にしておくと、修正や再出力がしやすくなります。
現地調査を含む業務では、入力段階のルールも重要です。後から整形すればよいと考えて自由入力を増やしすぎると、作業量が大きくなります。分類や状態のように候補を決められる項目は、できるだけ入力値を限定し、備考欄にだけ自由記述を許す構成にすると、GeoJSON化した後の属性型が安定します。現地での入力しやすさと、後工程での扱いやすさの両方を考えて設計することが大切です。
GeoJSONは、位置情報と属性情報をひとつのデータとして共有しやすい形式です。しかし、自由に属性を持たせられるからこそ、項目設計と整形ルールが曖昧なままだと、型崩れが起きやすくなります。形状が正しくても、属性が安定していなければ、検索、集計、色分け、報告、引き継ぎの精度に影響します。
実務で確認すべき流れは、まず属性項目の用途を決め、空欄と欠損値を統一し、数値と文字列の混在を取り除き、日付やコード値を安定した形式にそろえ、地物ごとのproperties構造をそろえ、最後に読み込み後の表示と集計で確認することです。この6手順を毎回の作業に組み込むことで、GeoJSONの属性型が崩れるリスクを下げられます。
特に、現地で取得した位置情報や写真、点群、メモなどを後からGeoJSONや台帳に整理する場合は、最初の入力設計が重要になります。現場での記録がばらつくと、後工程で属性型をそろえる負担が増えます。位置情報と属性を現場で分かりやすく紐づけ、後から整理しやすい形で残すには、入力項目、単位、欠損値、分類名、日付形式を事前に決め、作成後の確認までを一連のルールとして運用することが有効です。