GeoJSONの数値と文字列を正しく扱う4つの確認

GeoJSONを扱うとき、座標や属性を読み込めたように見えても、数値と文字列の扱いが曖昧なままだと、表示、検索、集計、変換、受け渡しの段階で思わぬ不具合が起きることがあります。特に「geojson 使い方」を調べている実務担当者にとっては、地図上に表示できるかどうかだけでなく、その後の属性検索、面積や延長の集計、外部データとの突合、現場記録との照合まで見据えてデータを整えることが重要です。この記事では、GeoJSONの数値と文字列を正しく扱うために、実務で確認したい4つの観点を解説します。

目次

• 数値と文字列の役割を先に決める

• GeoJSONのプロパティで型を崩さない

• 座標・ID・コードを混同しない

• 読み込み後の表示・検索・集計で確認する

• まとめ：型を意識したGeoJSON運用で手戻りを減らす

数値と文字列の役割を先に決める

GeoJSONを正しく使う第一歩は、データの中に入れる値を「数値として扱うもの」と「文字列として扱うもの」に分けることです。見た目だけで判断すると、どちらも同じように画面に表示されますが、内部での扱いは大きく異なります。数値は計算、比較、並べ替え、範囲判定に使いやすい形式です。一方、文字列は名称、分類、記号、管理番号、注記のように、人が読む情報や識別するための情報に向いています。この違いを最初に決めずに作業を進めると、後から集計できない、検索条件が合わない、ゼロ始まりの番号が消える、別データと結合できないといった問題につながります。

GeoJSONでは、地物ごとの属性情報は主にpropertiesに入ります。ここに入る値は、数値、文字列、真偽値、nullなどとして表現できます。たとえば、点検箇所の標高、延長、面積、勾配、数量、点数のように計算対象になる項目は、原則として数値として保持したほうが扱いやすくなります。反対に、路線名、地区名、施設名、判定区分、担当者名、備考、管理番号のように計算しない項目は、文字列として保持するのが自然です。どちらでも保存できるように見える項目ほど、運用前に扱い方を決めておく必要があります。

注意したいのは、数字に見えるからといって必ず数値にすべきではない点です。たとえば「0012」のような管理番号、「03」のような地区コード、「2026-05」のような年月、「1-2」のような区画番号は、数字を含んでいても計算対象ではありません。これらを数値として扱うと、先頭のゼロが落ちたり、記号が解釈できなかったり、別の形式に変わったりするおそれがあります。現場では、番号やコードを使って写真、帳票、図面、点検記録を突合することが多いため、見た目の数字に惑わされず、識別子として使うものは文字列にしておくほうが安全です。

一方で、距離や面積のように本来は数値である項目を文字列として入れてしまうと、後から集計しにくくなります。たとえば「12.5m」「約20」「10平方メートル」のように単位や言葉を混ぜた値は、人が読むだけなら便利ですが、機械的な計算には向きません。数値として扱いたい場合は、値には12.5や20や10のような数値だけを入れ、単位は項目名や別項目で管理すると扱いやすくなります。たとえば、延長をlength_m、面積をarea_m2のように分けておけば、後で何の単位の数値なのか判断しやすくなります。

実務では、GeoJSONを作る段階で「この項目は計算するのか」「この項目は検索するのか」「この項目は人が読むだけなのか」を整理しておくと、型の迷いが減ります。特に、現場で取得したデータを事務所で加工し、さらに別の担当者や別のシステムに渡す場合、作成者だけが意味を理解している状態では危険です。属性名だけで意味が伝わるようにし、数値項目には数値だけを入れ、文字列項目には表示や識別に必要な情報を入れるという基本を守ることが大切です。

また、欠損値の扱いも事前に決めておきたい確認点です。値が分からない場合に、空文字にするのか、nullにするのか、0にするのかで意味が変わります。0は「値がゼロである」ことを示す数値であり、「未入力」や「不明」とは違います。たとえば、補修数量が0なのか、まだ確認していないのかは、判断として大きな差があります。未確認の値を安易に0にすると、集計結果に影響するだけでなく、点検や施工管理の判断を誤らせる可能性があります。分からない値はnullや別の確認状況項目で表すなど、後から見ても意味が分かる形にしておくと安心です。

数値と文字列の役割を決める作業は、地味ですがGeoJSON運用の土台になります。地図に表示できた時点で安心してしまうと、後工程でデータの揺れが見つかることがあります。公開用、社内共有用、現場確認用、分析用など、用途によって必要な項目は変わりますが、どの用途でも型の考え方は共通です。計算する値は数値、識別や表示に使う値は文字列、未確認は未確認として分ける。この基本を最初に押さえておけば、GeoJSONの扱いはかなり安定します。

GeoJSONのプロパティで型を崩さない

GeoJSONの属性情報は、地物ごとのpropertiesに格納されます。このpropertiesに入れる値の型が途中で崩れると、読み込み時には問題が見えなくても、検索、色分け、ラベル表示、集計、書き出しの段階で不具合が出ることがあります。特に複数の地物をまとめたFeatureCollectionでは、同じ項目名を持つ値が地物ごとに違う型にならないよう注意が必要です。ある地物では数値、別の地物では文字列、さらに別の地物では空文字という状態になると、後から処理するときに判断が難しくなります。

たとえば、propertiesの中にstatusという項目がある場合、すべての地物で「未確認」「確認済」「要対応」のような文字列に統一されていれば、分類表示や検索がしやすくなります。しかし、一部だけ1や2のような数値になっていたり、別の地物では「済」「対応」など表記が異なっていたりすると、同じ意味の値を同じ条件で抽出できません。数値項目でも同じです。heightという項目を数値として扱うなら、すべての地物で数値としてそろえることが望ましいです。一部に「約5」「5m」「不明」のような文字列が混じると、数値としての比較や集計ができなくなる場合があります。

GeoJSONの作成では、手入力、表形式データからの変換、測量データや点検記録からの出力など、さまざまな経路があります。このとき、元データ側の列に混在した値があると、GeoJSON側にもそのまま持ち込まれやすくなります。表形式データでは、同じ列に数値と文字が混在していても一見すると違和感がありませんが、GeoJSONに変換した後は型の違いが処理結果に影響します。そのため、変換前の段階で列ごとに役割を決め、値の揺れを減らしておくことが重要です。

プロパティ名の付け方も、型を安定させるうえで大切です。たとえば、同じ「高さ」を表す項目でも、height、h、標高、高さなどが混在していると、同じ意味の項目を別々に扱うことになります。複数人で作業する場合は、項目名の一覧を先に作り、どの項目が数値で、どの項目が文字列で、どの項目が任意入力なのかを共有しておくとよいです。項目名は短すぎると意味が伝わりにくく、長すぎると扱いにくくなるため、実務では意味が分かる範囲で簡潔にするのが扱いやすいです。

数値項目では、小数点や丸めの扱いにも注意が必要です。GeoJSON自体は数値を保持できますが、元データの作成方法や読み込み先の処理によって、表示桁数や丸め方が変わることがあります。たとえば、現場で取得した座標や高さ、距離をそのまま細かい桁数で保存しても、画面表示では丸められる場合があります。逆に、表示上は丸められていても、内部には細かい値が残っている場合もあります。重要なのは、保存する値、表示する値、帳票に出す値の関係を混同しないことです。必要な精度を考えたうえで、元データの桁数と表示用の桁数を分けて考えると、説明しやすくなります。

文字列項目では、空白、全角半角、表記ゆれに注意します。たとえば「確認済」と「確認 済」、「A地区」と「Ａ地区」、「北側」と「北 側」のような違いは、人が見ると同じように見えても、データとしては別の値として扱われることがあります。分類や検索に使う項目ほど、入力ルールをそろえる必要があります。現場メモのように自由記述が必要な項目と、判定区分のように選択肢を固定したい項目を分けると、型と表記の両方を安定させやすくなります。

真偽値を使う場合も、文字列との違いを意識しておきたいところです。たとえば、is_checkedのような項目にtrueまたはfalseを入れると、確認済みかどうかを機械的に判定しやすくなります。ただし、実務では「未確認」「確認済」「対象外」「保留」のように二択では足りないこともあります。この場合は、無理に真偽値にせず、文字列の区分として管理したほうが現場の状態を正しく表せます。型は便利さだけで決めるのではなく、業務上の意味を正しく表せるかどうかで決めることが大切です。

nullの扱いも、プロパティの型を崩さないために整理しておきます。値がないことを表すnullは便利ですが、すべての読み込み先で同じように表示されるとは限りません。空欄として見える場合もあれば、文字として表示される場合もあります。そのため、重要な項目では、値そのものとは別に確認状況を示す項目を設ける方法もあります。たとえば、depthという数値項目と、depth_statusという文字列項目を分けておけば、深さの値が未測定なのか、対象外なのか、測定不能なのかを表現しやすくなります。

GeoJSONのプロパティで型を崩さないためには、作成時だけでなく、編集時や再出力時の確認も欠かせません。ある形式からGeoJSONに変換し、編集して、再び別の形式に出力する流れでは、途中で数値が文字列化されたり、文字列の先頭ゼロが消えたりすることがあります。特に、表形式の編集を挟む場合は、見た目の補正や自動変換が入ることがあるため、出力後のGeoJSONを確認する習慣を持つと安全です。作業の最後に、代表的な地物だけでなく、空欄を含む地物、最大値や最小値を持つ地物、コード番号を持つ地物を確認すると、型の崩れに気づきやすくなります。

座標・ID・コードを混同しない

GeoJSONで最も重要な数値の一つが座標です。geometryのcoordinatesに入る座標は、地物の位置や形状を表すための情報であり、propertiesに入る一般的な属性値とは役割が異なります。座標は地図上の位置を決めるための数値であり、表示、重ね合わせ、距離感、範囲判定に直接関わります。そのため、座標を文字列として扱ったり、属性情報と同じ感覚で加工したりすると、位置がずれる、表示されない、想定外の場所に出るといった問題が起きることがあります。

GeoJSONでは、座標の順序にも注意が必要です。標準的なGeoJSONでは、位置は経度、緯度の順で記述します。日常会話や一部の表記では緯度、経度の順に書かれることもあるため、ここを取り違えると、地物がまったく別の場所に表示されることがあります。座標が数値として正しく入っていても、順序が違えば正しい位置にはなりません。特に、現場で取得した位置情報を表形式で受け取り、GeoJSONに変換する場合は、列名と出力順序を必ず確認する必要があります。

座標と属性の数値も混同しないようにします。たとえば、標高、深さ、距離、面積、勾配などはpropertiesに入る属性値であり、geometryの座標とは別の意味を持ちます。標高を座標の三つ目の値として扱う場合もありますが、すべての利用環境で同じように解釈、表示、解析されるとは限りません。現場管理や点検記録で高さ情報を使う場合は、地図上の位置を表す座標と、業務属性としての高さを分けて管理したほうが、後工程での誤解を防ぎやすくなります。

IDやコードは、数字に見えても文字列として扱うべき代表例です。施設番号、点検番号、路線番号、地区コード、工区番号、写真番号、台帳番号などは、計算するための数値ではなく、対象を識別するための文字列です。これらを数値として扱うと、先頭のゼロが消える、長い番号が別の表記になる、枝番やハイフンを含められない、といった問題が起きます。実務では、番号が一文字違うだけで別の施設や別の写真を指すことがあります。そのため、IDやコードは「数字の形をした文字列」と考えるのが安全です。

また、連番と恒久的なIDも分けて考える必要があります。作業中に便宜的に振った1、2、3のような番号は、並べ替えや抽出のたびに意味が変わる可能性があります。一方、台帳や現場記録と突合するためのIDは、作業の途中で変えてはいけません。GeoJSONのpropertiesにidという項目を入れる場合、そのIDが一時的な番号なのか、管理上の正式な識別子なのかを明確にしておきます。名称が曖昧なままだと、後から別の担当者が誤って上書きしたり、別データとの結合に使ってしまったりすることがあります。

文字列として扱うコードには、桁数の意味が含まれていることもあります。たとえば、上位の地区を示す桁、施設種別を示す桁、年度を示す桁など、コードの中に意味を持たせている場合です。このようなコードを数値化すると、先頭ゼロが消えるだけでなく、桁数による判定ができなくなる場合があります。コードは、値そのものを計算するのではなく、文字の並びとして照合したり、先頭何桁かを取り出したりすることが多いため、文字列として保持するのが基本です。

日付や時刻も、数値と文字列の境界で迷いやすい項目です。日付は人が読める形式で保存したい一方、期間で検索したり、並べ替えたりすることもあります。GeoJSONのpropertiesに日付を入れる場合は、表記を統一しておくことが大切です。「2026/5/6」「2026-05-06」「令和8年5月6日」のように表記が混在すると、文字列として並べ替えたときに順序が崩れたり、検索条件を作りにくくなったりします。日付を文字列として扱う場合でも、一定の形式に統一しておくと後工程で扱いやすくなります。

数値として扱う項目でも、単位や基準を混同しないようにします。面積であれば平方メートルなのか、ヘクタールなのか、距離であればメートルなのか、キロメートルなのか、標高であればどの基準に基づく値なのかを確認します。GeoJSONの値そのものに単位の概念が自動的に付くわけではないため、属性名や別項目で単位が分かるようにしておく必要があります。単位が曖昧なまま数値だけを入れると、見た目は正しくても、集計や報告の段階で誤解が起きます。

座標、ID、コード、日付、単位は、GeoJSONの運用で特に混乱しやすい部分です。これらはすべて「数字を含む」ことが多いため、数値として一括で扱いたくなります。しかし、実際には、位置を表す数値、計算する数値、識別する文字列、分類する文字列、日付を表す文字列が混在しています。役割の違いを意識して項目を分けることで、GeoJSONは単なる表示用データではなく、現場情報を正しく受け渡すための実務データとして使いやすくなります。

読み込み後の表示・検索・集計で確認する

GeoJSONの数値と文字列を正しく扱えているかどうかは、ファイルを作った時点だけでは判断しきれません。実際に読み込み、表示し、検索し、集計してみることで、型の問題が見えてくることがあります。地図上に点や線や面が表示されるだけでは、属性の型まで正しく扱えているとは限りません。表示はできていても、色分け条件が効かない、数値の範囲検索ができない、ラベルが想定どおり出ない、集計値が合わないといったことが起きる場合があります。

まず確認したいのは、地図上の位置が正しく表示されているかです。座標の順序、座標系、桁数、geometryの種類に問題があると、対象物が想定と違う場所に表示されることがあります。GeoJSONの使い方に慣れていない段階では、表示されたこと自体を成功と考えがちですが、実務では「正しい場所に表示されたか」が重要です。現場で分かる目標物や既存図面、行政区域、道路、河川などと重ねて、大きなずれがないかを確認します。位置が合っていない場合、属性の型以前に座標の扱いを見直す必要があります。

次に、ラベル表示を確認します。施設名、管理番号、点検番号、地区名などをラベルとして表示したとき、先頭ゼロが消えていないか、文字化けしていないか、空欄が不自然に出ていないかを見ます。特に管理番号や写真番号は、現場写真や帳票との照合に使うことが多いため、ラベル表示で崩れがないか確認しやすい項目です。もし「001」が「1」になっている場合、その項目はどこかの段階で数値として扱われている可能性があります。

数値項目は、範囲検索や色分けで確認すると型の問題を見つけやすくなります。たとえば、延長が10以上の地物だけを抽出する、面積が一定以上の区域を色分けする、勾配の大きさで分類する、といった操作を行います。数値として正しく入っていれば、大小比較が自然にできます。しかし、値が文字列として入っていると、思った順序で並ばなかったり、条件に合うはずの地物が抽出されなかったりすることがあります。見た目の数字が同じでも、内部の型が違うと結果が変わるため、実際の操作で確かめることが大切です。

文字列項目は、完全一致検索や分類表示で確認します。地区名、判定区分、種別、担当区分などを使って抽出したとき、同じ意味の値が複数に分かれていないかを確認します。「要対応」と「要 対応」、「未確認」と「未 確認」、「A」と「Ａ」のような表記ゆれがあると、同じ条件では拾えません。自由記述のメモ欄は揺れがあっても問題ない場合がありますが、分類や検索に使う項目は表記を統一する必要があります。読み込み後の検索結果を見ながら、入力ルールの不備を見つけると改善しやすくなります。

集計も重要な確認です。数値項目の合計、平均、最大、最小、件数を確認すると、文字列混入や未入力の扱いに気づきやすくなります。たとえば、合計対象のはずなのに一部の値が集計に入っていない場合、その値が文字列になっている可能性があります。また、未確認を0として入力していると、平均値が実態より小さくなることがあります。集計結果を見るときは、数値だけでなく、その数値がどの地物から構成されているかを確認することが大切です。

書き出し後の再確認も忘れてはいけません。GeoJSONを読み込んで編集し、再度GeoJSONとして出力した場合、属性の型や表記が変わっていないか確認します。作業環境によっては、数値が文字列に変わる、空欄の扱いが変わる、項目名が変更される、不要な項目が追加されるといったことがあります。納品や共有に使うGeoJSONでは、最終出力ファイルを別の環境で読み直し、代表的な属性を確認するのが安全です。作業中の表示だけで判断せず、最終ファイルそのものを確認する習慣が手戻りを減らします。

複数人でGeoJSONを扱う場合は、確認結果を個人の記憶に頼らず、ルールとして残すことが大切です。たとえば、数値項目の一覧、文字列項目の一覧、IDとして扱う項目、未入力時の扱い、単位、日付形式、分類値の候補などを簡単にまとめておきます。大げさな仕様書でなくても、作業前に共有できる形にしておくと、担当者が変わっても品質を保ちやすくなります。GeoJSONは軽量で扱いやすい形式ですが、自由度が高い分、運用ルールがないとデータの揺れが増えやすい形式でもあります。

現場で取得した情報をGeoJSON化する場合は、入力時点の確認も効果的です。後から事務所で修正するより、現場で項目名、番号、分類、メモ、座標をできるだけそろえておくほうが、全体の手間は少なくなります。特に写真と位置情報を組み合わせる運用では、写真番号、撮影地点、対象物ID、点検区分の整合が重要です。ここで数値と文字列の扱いがぶれると、写真と地図を突合する段階で探し直しが発生します。現場入力の段階から、計算する値と識別する値を分けておくことが、GeoJSON運用の安定につながります。

確認作業では、正常なデータだけでなく、例外的なデータを見ることも大切です。最大値、最小値、空欄、ゼロ、先頭ゼロを持つコード、長い文字列、記号を含む番号、複数行になりそうな備考などを確認すると、型や表示の問題を見つけやすくなります。すべての地物を一つずつ確認するのは現実的でない場合でも、問題が出やすい値を含むサンプルを選んで確認すれば、公開前や共有前のリスクを下げられます。

読み込み後の確認は、GeoJSONの品質管理そのものです。ファイル形式として正しいことと、業務データとして使いやすいことは同じではありません。地図に表示できる、ラベルが出る、検索できる、集計できる、再出力しても崩れない。この一連の確認を通して、数値と文字列の扱いが実務に耐える状態かどうかを判断できます。

まとめ：型を意識したGeoJSON運用で手戻りを減らす

GeoJSONの数値と文字列を正しく扱うためには、最初に役割を決め、propertiesの型をそろえ、座標やIDやコードを混同せず、読み込み後の表示や検索や集計で確認することが重要です。GeoJSONは柔軟に属性を持たせられる便利な形式ですが、その柔軟さは同時に、データの揺れを生みやすい面もあります。何を数値として扱い、何を文字列として扱うのかを曖昧にしたまま作業すると、後から修正や確認に時間がかかります。

実務で特に注意したいのは、数字に見える値をすべて数値にしないことです。管理番号、地区コード、写真番号、台帳番号、工区番号のような識別子は、計算する値ではなく照合するための文字列です。先頭ゼロや枝番、ハイフン、桁数に意味がある場合も多いため、文字列として扱うのが安全です。一方、延長、面積、数量、標高、勾配のように集計や比較に使う値は、単位や注記を混ぜずに数値として持たせると扱いやすくなります。

また、値がない場合の扱いも、GeoJSON運用では重要です。未確認、対象外、測定不能、値がゼロである状態を同じように扱ってしまうと、集計や判断に影響します。値そのものと確認状況を分ける、分類値を統一する、必要に応じてnullを使うなど、後から見ても意味が分かる形にしておくことが大切です。特に点検、調査、施工管理、台帳整備のように後続作業がある業務では、データの意味が明確であることが品質につながります。

GeoJSONの使い方を身につけるうえでは、形式の理解だけでなく、現場から事務所、共有、確認、再利用までの流れを意識することが欠かせません。表示できるだけのGeoJSONではなく、検索できる、集計できる、突合できる、説明できるGeoJSONにすることで、実務での価値が高まります。そのためには、作成時のルール、変換時の確認、読み込み後の検証、出力後の再確認を一連の作業として組み込むことが効果的です。

現場で取得した位置情報や写真、点検メモを地図データとして扱う場面では、入力の段階から型を意識できる運用を整えることも有効です。位置、写真、属性、メモを後から無理に結び付けるのではなく、取得時点で整理しておけば、GeoJSON化した後の確認や共有がしやすくなります。現場情報を地図データとして活用したい場合は、利用するツールや記録方法を問わず、数値と文字列の役割をそろえ、後工程で検索、集計、照合しやすい形で管理することが大切です。