GeoJSONをExcelで扱う時に困りやすい整形手順5つ

GeoJSONは、点・線・面などの地図上の形状と、それにひも付く属性情報をまとめて扱えるデータ形式です。一方で、Excelなどの表計算ソフトで開いて確認しようとすると、座標が長い文字列のように見えたり、propertiesの中身が一つのセルに詰まったり、文字化けや桁落ちが起きたりして、思ったより扱いにくいと感じる場面があります。特に実務では、地図表示そのものよりも、地番、設備番号、点検日、管理区分、担当者メモなどを一覧で確認したい場面が多く、GeoJSONをそのまま表に変換するだけでは使いやすいデータにならないことがあります。

この記事では、geojsonで検索する実務担当者に向けて、表計算ソフトでGeoJSONを扱う前後に困りやすい整形手順を5つに分けて解説します。単にファイルを開く方法ではなく、後から検索、並べ替え、チェック、共有をしやすくするために、どの順番で整えると混乱を減らせるかを重視します。

目次

• GeoJSONの構造を表に変換する前に確認する

• propertiesを列として展開し属性情報を読みやすくする

• coordinatesを用途に合わせて分解し座標の扱いを決める

• 文字コードと数値形式を確認して表示崩れを防ぐ

• 表計算後にGeoJSONへ戻す前提で編集ルールを整える

• まとめ

GeoJSONの構造を表に変換する前に確認する

GeoJSONを表計算ソフトで扱うときに最初につまずきやすいのは、GeoJSONが最初から表形式で作られているわけではないという点です。通常の台帳データであれば、1行が1件のデータ、1列が1つの項目として整理されています。しかしGeoJSONでは、地物ごとの情報がFeatureという単位に入り、その中に形状を表すgeometryと、属性情報を表すpropertiesが分かれて入っています。さらに複数のFeatureをまとめる場合はFeatureCollectionというまとまりになります。この階層構造を理解しないまま表に変換すると、どこを1行にすればよいのか、どの項目を列にすればよいのかが曖昧になり、後工程で修正に時間がかかります。

表計算ソフトで扱いやすい形にするには、まず1行を何に対応させるかを決めることが重要です。多くの場合は、1つのFeatureを1行として扱うのが自然です。たとえば設備点のGeoJSONであれば、1つの設備を1行にします。道路中心線や配管ルートのGeoJSONであれば、1本の線形を1行にします。筆界や管理区域のような面データであれば、1つの区域を1行にします。このように、地図上で1つの対象として管理したい単位と、表計算上の1行を合わせておくと、後から属性確認や修正履歴の管理がしやすくなります。

一方で、geometryの中には座標が複数入ることがあります。点であれば座標は基本的に1組ですが、線であれば折れ点の数だけ座標が並び、面であれば外周や穴の座標が配列として入ります。これを無理にすべて列へ展開しようとすると、列数が大きく増えたり、地物ごとに座標数が違って表が崩れたりします。表計算ソフトは一覧確認や属性編集には向いていますが、複雑な形状編集には向かない場面もあります。そのため、表に出すべき情報と、GeoJSON側に保持したままにする情報を分けて考える必要があります。

整形前には、対象のGeoJSONが点、線、面のどれを中心にしたデータなのかを確認します。混在している場合は、点だけ、線だけ、面だけに分けて扱うか、geometryの種類を示す列を作っておくと便利です。たとえば、同じファイルの中に設備点と管理区域が混在していると、座標の数や意味が大きく異なります。そのまま一つの表にすると、点では経度と緯度を列にできても、面では外周座標全体をどう扱うかで迷いやすくなります。混在データは便利に見えますが、表計算での点検作業ではかえって見通しが悪くなることがあります。

また、GeoJSONの中に不要な情報がどれだけ含まれているかも確認しておきます。地図表示用に使われていたスタイル指定、表示ラベル、内部処理用の識別子、空の項目などが残っている場合、表に展開したときに列が増えすぎて、肝心の属性情報が見つけにくくなります。削除してよい項目かどうかを判断できない場合は、元データを別に保管したうえで、作業用の複製ファイルを整形します。実務では、元データ、整形用データ、共有用データを混在させないことが、後戻りを防ぐ基本になります。

表に変換する前の段階で確認したいのは、Featureの件数、geometryの種類、propertiesの項目数、座標の桁数、文字化けの有無、空欄の多い項目の有無です。これらを先に把握しておくと、変換後に「なぜ行数が合わないのか」「なぜ列が増えすぎたのか」「なぜ座標が読みにくいのか」といった問題を切り分けやすくなります。GeoJSONを表計算ソフトで扱う作業は、開いてから考えるより、構造を見てから整えるほうが安全です。

propertiesを列として展開し属性情報を読みやすくする

GeoJSONを表計算で扱う目的の多くは、geometryそのものを細かく編集することではなく、propertiesに入っている属性情報を確認・修正・整理することです。propertiesには、名称、番号、分類、住所、管理者、点検結果、更新日、備考など、実務上確認したい情報が入ります。表計算ソフトで扱うなら、このpropertiesを列として展開し、1項目1列の状態にすることが重要です。

困りやすいのは、properties全体が一つのセルに文字列として入ってしまうケースです。この状態でも中身を読むことはできますが、並べ替え、絞り込み、重複確認、空欄チェックなどがしにくくなります。たとえば管理区分ごとに件数を見たい場合や、点検日が未入力の地物だけを抽出したい場合、一つのセルに複数項目が詰まっていると作業効率が落ちます。表計算で使うのであれば、属性項目を列として分ける整形が欠かせません。

列へ展開するときは、項目名をそのまま列名にするだけでなく、実務で見て意味が分かる名前になっているかを確認します。GeoJSONの作成過程によっては、短い英字、略称、内部処理用の名前が列名になっていることがあります。作業者が内容を理解していれば問題ないように見えますが、別の担当者が確認すると意味が伝わらないことがあります。公開資料や共有用の一覧にする場合は、列名の対応表を作るか、作業用の表では分かりやすい名称を併記すると扱いやすくなります。

ただし、列名を変更するときには注意が必要です。表計算で見やすくするために列名を変えると、再びGeoJSONへ戻すときに元のproperties名と対応しなくなることがあります。地図表示側や読み込み側が特定の項目名を参照している場合、列名の変更によってラベル表示や分類表示が意図どおり動かなくなる可能性があります。そのため、元の項目名を残す列と、表示用に分かりやすくした列を分ける方法もあります。作業の目的が閲覧用なのか、再利用用なのかによって、列名をどこまで変更してよいかを判断します。

属性情報を整える際には、空欄、表記ゆれ、不要な空白、全角半角の混在にも注意します。たとえば同じ管理区分でも、「未確認」「未 確認」「未確認　」のように見た目が似た値が混在していると、集計時には別の値として扱われることがあります。住所や地番、設備名、備考などは人が入力することが多く、表記ゆれが起きやすい項目です。GeoJSONを地図で見るだけなら気づきにくい小さな違いも、表計算で集計すると大きな差になります。

日付の扱いも整形時の重要なポイントです。propertiesに日付が入っている場合、表計算ソフト側で自動的に日付形式として解釈されることがあります。便利な場面もありますが、元の文字列と表示が変わることがあり、月日だけに見えたり、区切り記号が変わったりする場合があります。点検日、取得日、更新日など、後で証跡として確認する可能性がある項目は、元の値を残したまま作業用の列で整えると安心です。勝手に変換された値をそのまま上書きすると、元データとの照合が難しくなることがあります。

IDや管理番号も慎重に扱います。先頭にゼロが付く番号や、長い数字だけの識別子は、表計算ソフト上で数値として扱われると、先頭のゼロが消えたり、指数表示のように見えたりすることがあります。これは見た目だけの問題ではなく、別データとの照合に失敗する原因になります。管理番号、地物ID、設備番号、地番の枝番のように、計算に使わない番号は文字列として扱うのが安全です。

propertiesを列に展開した後は、属性項目の役割を整理します。地図表示に使う項目、検索に使う項目、管理台帳として必要な項目、作業中だけ使う項目を分けて考えると、表が読みやすくなります。すべての列を同じ重要度で並べるのではなく、現場や確認作業でよく見る項目を左側へ寄せ、内部処理用の項目や備考類は後ろへ配置すると、確認作業の負担が減ります。整形とは単に列を分けることではなく、実務で見やすい順番へ並べ直すことでもあります。

coordinatesを用途に合わせて分解し座標の扱いを決める

GeoJSONのcoordinatesは、表計算ソフトで最も扱いに迷いやすい部分です。点データであれば比較的単純で、経度と緯度を別々の列に分ければ一覧として確認しやすくなります。しかし線や面のデータでは、coordinatesの中に複数の座標が入るため、すべてを表の列に展開するのは現実的でない場合があります。ここで大切なのは、座標を何のために表で扱うのかを先に決めることです。

点データの場合は、経度列と緯度列を分けるだけで、位置の確認、並べ替え、空欄確認がしやすくなります。高さや標高に相当する値が座標に含まれている場合は、それを別列として扱うこともあります。ただし、GeoJSONの標準的な座標順序は経度、緯度の順であり、必要に応じて高さなどの値が続きます。表にするときに緯度、経度の順へ入れ替えてしまうと、後から混乱しやすくなります。日本語の実務では緯度経度という言い方に慣れているため、列の見出しを作るときに順番を誤らないよう注意が必要です。

線データの場合、coordinatesには線を構成する折れ点が順番に入ります。この順番は形状を再現するうえで重要です。表計算で扱うために折れ点を並べ替えたり、不要そうに見える座標を削除したりすると、線の形状が変わる可能性があります。距離やルートの確認のために始点と終点だけを見たい場合は、すべての座標を列に展開するのではなく、始点経度、始点緯度、終点経度、終点緯度のように代表値として切り出す方法があります。全折れ点を確認したい場合は、1つのFeatureを1行にする表とは別に、折れ点番号付きの座標一覧を作るほうが扱いやすいこともあります。

面データの場合はさらに慎重な整形が必要です。面は外周の座標列によって囲まれた範囲として表現されます。場合によっては内側に穴を持つ形状もあります。表計算ソフトで面の座標を平面的に眺めても、形の向きや閉じ方、外周と内周の関係までは直感的に分かりにくいものです。そのため、面データを表で扱う場合は、座標列そのものを編集対象にするより、面の識別子、名称、面積に関する属性、管理区分などのpropertiesを中心に整えるほうが安全です。座標を編集する必要がある場合は、表計算だけで完結させず、地図上で形状を確認できる環境と組み合わせることが望ましいです。

座標を分解するときに注意したいのは、桁数を不用意に丸めないことです。見やすさを優先して小数点以下を短く表示すると、実際の値まで丸められたのか、表示だけが丸められたのかが分かりにくくなることがあります。座標はわずかな差でも地図上の位置に影響します。特に現地確認、設備管理、境界付近の確認、施工記録の整理などで使う場合は、座標の丸めが後から問題になる可能性があります。表計算上では表示桁数を調整するだけにとどめ、元の値を保持する運用が安全です。

また、座標参照系の扱いにも注意が必要です。現在一般的に扱われるGeoJSONでは経度緯度の座標が使われる前提ですが、実務データの作成過程では、別の座標系から変換されたものや、独自の前提で作られたデータが混在することもあります。表計算ソフト上で座標の数値だけを見ると、どの座標系の値なのか判断しにくい場合があります。経度緯度であれば日本周辺では経度が緯度より大きい値になることが多いため、明らかな入れ替わりに気づける場合もありますが、目視だけで正しいと断定するのは危険です。データの作成条件や受領時の説明を確認し、座標参照系や単位をメモとして残しておくと、後の利用者にも伝わりやすくなります。

coordinatesをそのまま1セルに残すか、代表点だけを列にするか、全座標を別表に分けるかは、作業目的によって変わります。属性確認が中心なら、coordinatesは元の文字列として保持し、点データだけ経度緯度列を追加する程度で十分なことがあります。位置の概略確認をしたい場合は、中心点や代表点を別列に持たせる方法もあります。形状編集が目的なら、表計算ソフトだけで完了させるより、形状を確認できる地図環境で編集し、表計算側では属性管理に専念するほうが安全です。

文字コードと数値形式を確認して表示崩れを防ぐ

GeoJSONを表計算ソフトに取り込むとき、内容自体は正しいのに、表示が崩れてしまうことがあります。代表的なのが文字化け、日付の自動変換、長い番号の表示崩れ、座標の丸め、改行や記号によるセル分割の乱れです。これらは一見すると小さな問題に見えますが、実務では確認漏れや誤った修正につながることがあります。整形作業では、データをきれいに見せるだけでなく、元の意味が変わっていないかを確認する姿勢が必要です。

文字化けは、名称や住所、備考など日本語を含む項目で起こりやすい問題です。ファイルを開いた直後に一部の文字が不自然な記号に変わっていたり、地名や人名が読めなくなっていたりする場合は、取り込み時の文字コード設定が合っていない可能性があります。文字化けした状態で保存してしまうと、元の文字に戻せなくなる場合があります。まず元ファイルを残し、取り込み設定を変えながら正しく読める方法を確認することが大切です。

数値形式の自動変換もよくある落とし穴です。表計算ソフトは便利な反面、入力値を自動的に数値や日付として解釈することがあります。たとえば管理番号が数値と判断されると、先頭のゼロが消えることがあります。長いIDが指数のような表示になったり、日付らしい文字列が別の形式に置き換わったりすることもあります。GeoJSONのpropertiesに入っている値は、人にとっては番号や記号であっても、表計算ソフト側では計算対象の数値と見なされることがあります。この差を理解していないと、見た目を整えたつもりでデータの意味を壊してしまいます。

座標値についても同じです。経度や緯度は小数点以下の桁数を持つ数値として扱われますが、表示幅が狭いと丸められて見えることがあります。表示だけが丸められているなら問題は小さいですが、保存時や別形式への書き出し時に桁数が失われると、位置精度に影響します。特に、表計算ソフト上で小数点以下の表示桁数を変更した後、別形式で保存する場合は注意が必要です。元のGeoJSONと整形後の値を比較し、座標が意図せず短くなっていないか確認します。

セル内の改行や区切り記号も、取り込み時の崩れにつながります。propertiesの備考欄に改行、カンマ、引用符に相当する記号などが含まれている場合、表形式へ変換した際に列がずれたり、1件のデータが複数行に分かれたりすることがあります。見た目の行数がGeoJSONのFeature数と合わない場合は、こうした文字が影響している可能性があります。整形後には、元のFeature数と表の行数が一致しているかを確認し、途中で分割や結合が起きていないかを見ます。

空欄の扱いも実務では重要です。GeoJSONのpropertiesには、項目が存在しない場合と、項目はあるが値が空の場合があります。表計算ソフト上ではどちらも空欄に見えることがありますが、再びGeoJSONへ戻す場合には意味が変わることがあります。ある地物だけ項目が存在しないのか、すべての地物に項目はあるが未入力なのかは、データ管理上の意味が異なります。入力漏れを確認したい場合は、単に空欄を埋めるだけでなく、その項目が必要な項目なのか、任意項目なのかを確認してから編集する必要があります。

表示崩れを防ぐには、取り込み直後に全体を見て、行数、列数、見出し、代表的な値を確認する習慣が役立ちます。すぐに編集を始めるのではなく、まず元データと照合する確認用の時間を取ります。たとえば、先頭の数件、中間の数件、末尾の数件を見て、属性名や座標が意図した列に入っているかを確認します。件数が多い場合でも、代表的なサンプルを複数箇所で見ることで、取り込み時の大きなミスに気づきやすくなります。

もう一つ大切なのは、表計算ソフトで保存する形式を意識することです。作業中の形式と、受け渡し用の形式と、GeoJSONへ戻すための形式は同じとは限りません。作業中は計算式や表示設定を使えても、書き出し時には失われる情報があります。逆に、表計算で便利な装飾や結合セルは、データ変換には向きません。GeoJSONへ戻す可能性がある表では、見た目の装飾よりも、1行1地物、1列1項目という単純な構造を優先するほうが安全です。

表計算後にGeoJSONへ戻す前提で編集ルールを整える

GeoJSONを表計算ソフトで扱う作業には、大きく分けて二つの目的があります。一つは、GeoJSONの中身を一覧で確認することです。もう一つは、表計算ソフトで属性を修正し、その結果を再びGeoJSONとして利用することです。前者であれば多少の表示調整で済むこともありますが、後者では編集ルールをきちんと決めておかないと、元のGeoJSONへ戻すときに不整合が起きます。

まず決めたいのは、編集してよい列と編集してはいけない列です。propertiesの中でも、名称や備考、点検結果のように人が更新する列は編集対象になります。一方で、地物ID、座標、geometryの種類、元ファイルの識別情報などは、安易に変更するとデータの対応関係が崩れます。表計算ソフトではどのセルも簡単に編集できるため、作業者が意図せず重要な列を変更してしまうことがあります。編集対象外の列は色分けや説明行で管理したくなることもありますが、GeoJSONへ戻す前提の作業表では、装飾に頼りすぎず、列名や別シート相当の管理で明確に区別することが大切です。

次に、1行を削除してよいかどうかを決めます。表計算上では不要に見える行でも、GeoJSONでは地図上の1つの地物に対応している可能性があります。行を削除すると、その地物自体が失われることになります。不要データを除外したい場合でも、すぐ削除するのではなく、除外フラグや確認状況の列を作り、後から判断できるようにしておく方法があります。削除は最終判断として扱い、作業中は元データに戻れる状態を保つほうが安全です。

並べ替えを行う場合も注意が必要です。1行1Featureの表であれば、行全体を正しく並べ替える限り、属性の対応関係は保たれます。しかし、一部の列だけを選択して並べ替えると、IDと属性、座標と名称の対応がずれる危険があります。これは表計算作業で起きやすく、発見が遅れると修正が難しい問題です。並べ替えや絞り込みを行う前には、必ず表全体を対象にする運用を徹底します。作業前に通し番号や元のFeature番号を持たせておくと、後から元の順番に戻したり、対応関係を確認したりしやすくなります。

値の入力ルールもそろえる必要があります。たとえば点検結果に「良好」「要確認」「対象外」と入れる運用であれば、別表記を増やさないようにします。「要確認」と「確認要」や「再確認」が混在すると、後で分類表示や集計を行うときに分かれた値として扱われます。自由記述が必要な備考欄と、選択肢をそろえる分類欄を分けると、データの再利用性が上がります。GeoJSONは地図表示にも使われるため、分類値がそろっていると、色分けやラベル表示の条件にも使いやすくなります。

改行や特殊な記号の入力にも気を配ります。備考欄に長文を入れること自体は可能ですが、改行や区切り記号が多いと、別形式へ書き出すときに崩れやすくなります。現場メモをそのまま入れる場合でも、後工程で処理しやすいように、改行を避ける、不要な記号を使わない、表記を一定にするなどのルールを決めておくと安心です。人が読むための文章と、データとして再利用するための値は、同じセルに詰め込みすぎないほうが扱いやすくなります。

GeoJSONへ戻す前には、元データとの照合を行います。Feature数が変わっていないか、編集対象外のIDが変わっていないか、geometryが欠落していないか、propertiesの列名が変わっていないかを確認します。特に、表計算ソフトで属性だけを編集したつもりでも、保存や変換の過程で文字列の形式が変わることがあります。変換後のGeoJSONを地図上で読み込み、表示位置、件数、ラベル、分類が想定通りかを確認するところまでを一連の作業と考える必要があります。

作業履歴の残し方も大切です。誰が、いつ、どの列を、どの目的で編集したのかが分からないと、後から不具合が見つかったときに原因を追いにくくなります。大げさな管理でなくても、作業日、作業者、編集対象、元ファイル名、変換後ファイル名を記録しておくと、再確認がしやすくなります。GeoJSONは軽量で扱いやすい形式ですが、だからこそ複製や編集が簡単にできてしまいます。似た名前のファイルが増えると、どれが最新で、どれが元データなのか分からなくなるため、ファイル名や保管場所のルールも整えておくと安心です。

まとめ

GeoJSONをExcelで扱う時に困りやすい整形作業は、単にファイルを開けるかどうかではなく、GeoJSONの階層構造を表計算に合う形へどう落とし込むかにあります。GeoJSONは地図上の形状と属性を一緒に持てる便利な形式ですが、そのまま表として読むには複雑な部分があります。特に、Feature、geometry、properties、coordinatesの関係を理解せずに変換すると、列が増えすぎたり、座標が読みにくくなったり、属性情報の対応関係が分からなくなったりします。

最初の手順としては、1つのFeatureを1行として扱うのか、点・線・面を分けるのか、coordinatesをどこまで表に出すのかを決めることが重要です。次に、propertiesを列として展開し、名称、番号、分類、日付、備考などを一覧で確認しやすくします。このとき、列名の変更、表記ゆれ、空欄、日付や番号の自動変換には注意が必要です。見やすくするための整形が、元データの意味を変えてしまっては本末転倒です。

coordinatesについては、点データなら経度と緯度を分けるだけで扱いやすくなりますが、線や面ではすべての座標を表に展開することが必ずしも適切とは限りません。始点・終点・代表点だけを切り出すのか、全座標を別の一覧にするのか、元のgeometryを保持したまま属性だけを編集するのかを、作業目的に応じて選びます。座標の順序、桁数、座標参照系の前提を誤ると、地図上の位置に影響するため、表計算上の見た目だけで判断しないことが大切です。

また、文字コード、数値形式、長いID、先頭ゼロ、セル内改行など、表計算ソフト特有の自動処理にも注意が必要です。便利な自動変換が、GeoJSONの実務データでは思わぬ崩れにつながることがあります。取り込み直後に件数、列数、代表値を確認し、元ファイルと照合する習慣を持つだけでも、後工程の手戻りを減らしやすくなります。

最終的にGeoJSONへ戻す可能性がある場合は、編集してよい列、変更してはいけない列、削除の扱い、並べ替えの方法、入力値のルールを先に決めておく必要があります。表計算ソフトは一覧確認や属性整理には便利ですが、地図上の形状確認や位置精度の確認まで単独で担うものではありません。GeoJSONを安全に整形するには、表で見やすくする作業と、地図データとして正しく使える状態を保つ作業を分けて考えることが大切です。

現場で取得した位置情報や点検記録を後からGeoJSONや台帳として活用したい場合は、最初の記録段階で属性名、座標、写真、メモの入力ルールをそろえておくと、表計算での整形負担を減らせます。受領データを加工する場合も、元ファイルを保管し、作業用ファイルを分け、変換後に地図上で確認する流れを決めておくことで、Excelでの一覧整理とGeoJSONとしての再利用を両立しやすくなります。