GeoJSONのエラー検証で壊れたデータを直す5手順

GeoJSONは、位置情報を扱う実務で使いやすい形式ですが、見た目は単純でも、少しの記述ミスや座標の扱い違いで読み込みエラー、表示崩れ、属性欠落、位置ずれが起こりやすいデータ形式です。特に「geojson 使い方」を調べながら現場資料、台帳、区域図、点検結果、境界確認用のデータを作成している場合、エラーの原因がファイル全体にあるのか、座標値にあるのか、属性にあるのかを切り分けられず、修正に時間を取られることがあります。

この記事では、GeoJSONの壊れたデータを安全に直すための実務的な流れを、5つの手順に分けて解説します。単にエラーを消すだけではなく、修正後に同じミスを繰り返さないための確認方法まで整理します。

目次

• GeoJSONのエラーは構文と地物の問題を分けて確認する

• 手順1としてファイル形式と文字コードを確認する

• 手順2として構造と必須要素の欠落を確認する

• 手順3として座標値とジオメトリの整合を確認する

• 手順4として属性情報とデータ型の乱れを確認する

• 手順5として修正後の再検証と運用ルールを固める

• まとめ

GeoJSONのエラーは構文と地物の問題を分けて確認する

GeoJSONのエラーを直すときに最初に意識したいのは、エラーには大きく分けて「ファイルとして読めない問題」と「読めるが地図データとして正しく扱えない問題」があるという点です。前者は、括弧の閉じ忘れ、カンマの過不足、引用符の欠落、不要な文字の混入などが原因で、そもそもデータを読み込めない状態です。後者は、GeoJSONとしては読み込めるものの、座標順序が逆になっている、面が閉じていない、属性名が揺れている、意図しない位置に表示されるといった状態です。

実務では、この2つを混ぜて考えると修正が遠回りになります。たとえば、地図上で対象区域が表示されないとき、すぐに座標値の誤りを疑いたくなりますが、実際にはFeatureCollectionの中にfeaturesが正しく入っていなかったり、各Featureのgeometryが空になっていたりすることがあります。逆に、ファイル自体は正常に開けるのに、現地とまったく違う場所へ表示される場合は、構文ではなく座標の順番や変換前データの座標系を疑う必要があります。

GeoJSONは、主にFeatureCollection、Feature、geometry、properties、coordinatesといった要素で構成されます。一般的な実務データでは、複数の地物をまとめるためにFeatureCollectionを使い、その中に複数のFeatureを並べます。各Featureには、図形を表すgeometryと、名称や番号、分類、調査日などを入れるpropertiesを持たせることが多いです。この基本構造が崩れると、読み込み時点でエラーになるか、読み込めても必要な情報が欠けた状態になります。

エラー検証の基本は、上から順に全部を眺めることではありません。まずJSONファイルとして成立しているかを確認し、次にGeoJSONとして必要な構造があるかを見ます。その後に、ジオメトリの種類ごとの座標ルールを確認し、最後に属性情報や運用上のばらつきを整えます。この順番を守るだけで、原因の切り分けがかなり楽になります。

また、GeoJSONはテキスト形式なので、表計算ソフトや変換ツール、業務システム、測量データ処理、地図編集ツールなどを経由する過程で、意図しない変換が入ることがあります。数値が文字列になったり、日本語の属性名が文字化けしたり、空欄がnullではなく空文字として出力されたりすることがあります。こうした変化は見た目だけでは判断しづらいため、検証の手順を決めておくことが重要です。

壊れたGeoJSONを直す目的は、単に「表示できる状態にする」ことだけではありません。現場や社内で使うデータであれば、どの地物が何を表しているか、属性値が後工程で使えるか、別の環境に渡しても同じように読めるかまで確認する必要があります。表示だけを優先して場当たり的に直すと、後で集計、検索、重ね合わせ、帳票化、共有の段階で別の不具合が出ることがあります。

そのため、GeoJSONの修正では、構文、構造、座標、属性、再検証の5段階で進めるのが安全です。次の章から、それぞれの手順を実務で確認しやすい形に整理します。

手順1としてファイル形式と文字コードを確認する

最初に確認するべきなのは、GeoJSONの中身ではなく、ファイルそのものが正しい形式で保存されているかです。GeoJSONはテキストデータですが、拡張子だけを.geojsonにしても中身が正しいとは限りません。別形式のデータを名前だけ変えて保存していたり、途中で余計な文字が入っていたり、文字コードの問題で日本語属性が壊れていたりすると、後の修正作業に進む前に読み込みで失敗します。

まず見るべき点は、ファイルの先頭と末尾です。GeoJSONは通常、全体がひとつのJSONオブジェクトとして表現されます。先頭に不要な説明文、見出し、コメント、出力ログ、不可視文字が入っていると、読み込み側が正しく解釈できないことがあります。特に、メール本文や文書からコピーして作ったデータでは、見えない文字や装飾由来の記号が混入することがあります。ファイルの最初が波括弧で始まり、最後が対応する波括弧で閉じているかを確認するだけでも、初期段階のエラーを見つけやすくなります。

次に、括弧、角括弧、カンマ、引用符の整合を確認します。GeoJSONでは、オブジェクトを波括弧で囲み、配列を角括弧で囲み、キーと文字列値を引用符で囲みます。複数の要素を並べるときはカンマを使いますが、最後の要素の後に余分なカンマを置くと、一般的なJSONとしては不正になります。表形式から手作業で変換したデータでは、最後のFeatureの後ろにカンマが残ることがあります。これだけでファイル全体が読めなくなるため、最初に確認しておきたい箇所です。

文字コードも重要です。日本語の地名、施設名、路線名、調査メモ、分類名などをpropertiesに入れる場合、文字化けが起こると地図表示はできても実務データとして使いにくくなります。文字化けした属性は後から元に戻せないこともあるため、修正前の元データを必ず残しておきます。特に、複数のソフトウェアやシステムを経由して出力した場合、文字コードの扱いが変わっている可能性があります。読み込み時に日本語が崩れている場合は、GeoJSONの構造を直す前に、元データ側の出力設定や保存形式を確認する方が安全です。

また、改行コードやインデントの有無はGeoJSONの意味そのものには大きく影響しませんが、実務で修正する場合は読みやすさに関わります。1行に圧縮されたGeoJSONは、コンピューターには読めても、人がエラー箇所を探すには不向きです。修正作業に入る前に、人が読める形に整形しておくと、括弧の対応、Featureごとの区切り、coordinatesの入れ子構造、propertiesの内容を確認しやすくなります。ただし、整形する前には元ファイルの控えを必ず保存しておきます。整形作業自体でデータが変化する可能性を完全には否定できないためです。

ファイルサイズにも注意が必要です。非常に大きなGeoJSONは、読み込みに時間がかかったり、途中で処理が止まったりすることがあります。この場合、データが壊れているのではなく、扱う環境の処理能力や表示方法に問題があることもあります。大きなデータを検証するときは、全体を一度に直そうとせず、代表的な数件を抜き出して同じ構造で検証する方法が有効です。小さなサンプルで問題が再現するなら構造や座標の問題を疑い、サンプルでは問題がなく全体だけで止まるなら、データ量や複雑なジオメトリの影響を疑います。

ここで大切なのは、いきなり座標や属性を触らないことです。ファイル形式が崩れたまま中身を修正すると、どの修正が効いたのか分からなくなります。まずは「GeoJSONとして読み取り可能なテキストファイルであること」を確認し、その後に構造や地物の検証へ進むことで、修正作業の迷子を防げます。

手順2として構造と必須要素の欠落を確認する

ファイルとして読めることを確認したら、次はGeoJSONとしての構造を確認します。実務で多く使われる形はFeatureCollectionです。全体のtypeがFeatureCollectionになっており、その中にfeaturesという配列があり、さらに各Featureが並ぶ構造です。ここが崩れていると、読み込み側が「地物の集合」として認識できなかったり、空のデータとして扱ったりすることがあります。

FeatureCollectionで確認したいのは、featuresが配列として存在しているか、featuresの中にFeatureが入っているか、各Featureにtype、geometry、propertiesがあるかという点です。geometryは図形の情報、propertiesは属性の情報です。propertiesが空のオブジェクトでもGeoJSONとして扱える場合はありますが、実務では地物番号、名称、区分、調査日、作成者、更新日などの情報が必要になることが多いため、空のまま運用してよいかは別途確認が必要です。

geometryのtypeには、Point、LineString、Polygon、MultiPoint、MultiLineString、MultiPolygon、GeometryCollectionなどがあります。これらの種類によってcoordinatesの入れ子構造が変わります。Pointであればひとつの座標、LineStringであれば座標の連続、Polygonであれば閉じた線の配列、MultiPolygonであれば複数の面の配列になります。よくあるエラーは、geometryのtypeとcoordinatesの構造が合っていないことです。たとえば、PolygonのつもりなのにLineStringのような座標列になっていると、読み込み時にエラーになるか、表示されても面として扱えません。

構造確認では、ひとつのFeatureだけを見て判断しないことも大切です。最初のFeatureは正常でも、途中のFeatureだけgeometryがnullになっていたり、propertiesが意図しない配列になっていたり、typeの文字が欠けていたりすることがあります。大量データでは、変換元の一部レコードだけに空欄や特殊文字があり、それが原因で一部のFeatureだけ壊れることがあります。表示上は「一部の地物が出ない」ように見えますが、実際には途中の構造不整合が原因で、その後のデータまで正しく読めなくなっている場合もあります。

geometryが空の場合の扱いも注意が必要です。GeoJSONのFeatureではgeometryにnullを入れられる場合がありますが、地図表示を目的とするデータでは問題になりやすいです。未測定、未設定、対象外などの理由でジオメトリを持たないレコードを扱う場合、空のgeometryを許容する運用にするのか、地図表示用のファイルからは除外するのか、別の属性で管理するのかを決めておく必要があります。修正時に無理やり仮の座標を入れると、後で誤った位置情報として扱われるおそれがあります。位置が分からない地物は、分からないことが分かる形で管理する方が安全です。

propertiesの構造も、後工程を考えると重要です。GeoJSONではpropertiesに任意の属性を入れられますが、属性名がFeatureごとにばらばらだと、検索や集計で不具合が出ます。あるFeatureではname、別のFeatureではName、さらに別のFeatureでは名称というように混在していると、見た目には似ていても別の項目として扱われます。エラー検証の段階で、属性名の統一も合わせて確認しておくと、後の運用が安定します。

また、GeoJSONのキー名は決められているものがあります。type、features、geometry、properties、coordinatesなどの基本キーを、全角文字や別表記に変えてしまうと、GeoJSONとして認識されません。日本語の属性名をproperties内で使うことは可能な場合がありますが、基本構造のキー名まで日本語化するのは避けます。特に自動変換や翻訳を挟んだデータでは、キー名が意図せず変わっていないか確認します。

構造修正のコツは、正常な最小サンプルと比較することです。壊れたファイル全体を見て悩むより、PointだけのFeature、LineStringだけのFeature、PolygonだけのFeatureといった小さな正常例と並べて、どこが違うかを見る方が早く原因にたどり着けます。実務では、社内でよく使う正常なGeoJSONのひな形を用意しておき、変換後のデータと見比べるだけでもミスを減らせます。

手順3として座標値とジオメトリの整合を確認する

構造が整っているのに表示位置がおかしい場合は、座標値とジオメトリの整合を確認します。GeoJSONで特に注意したいのは、座標の並び順です。一般的なGeoJSONでは、座標は経度、緯度の順で記述します。地図や測量の実務では緯度、経度の順で表現される資料も多いため、ここを取り違えると、まったく別の場所に表示されます。日本国内の経度緯度データであれば、経度はおおむね120台から150台付近、緯度は20台から40台付近に入ることが多いため、数値の並びを見れば逆転に気づける場合があります。

ただし、座標値の妥当性は地域や変換前データの前提によって変わります。標準的なGeoJSONとしてWeb地図や一般的なGISに渡す場合は経度緯度の座標を前提にするのが基本ですが、変換前の業務データには平面直角座標系や独自のローカル座標で管理されているものもあります。そのような数値を変換せずにGeoJSONへ入れると、期待した位置に出ないことがあります。座標の数値が数十万や数百万になっている場合、経度緯度ではなく別の座標系の値をそのまま入れていないか確認します。

Pointの場合は、座標の順番と数値範囲を確認するだけで原因が分かることが多いです。一方でLineStringやPolygonでは、座標の連続性も見なければなりません。LineStringでは、点の順番が実際の線の流れと合っているか、途中で極端に離れた座標が混じっていないかを確認します。ひとつだけ桁違いの座標が入ると、地図上では長い線が突然飛んだように表示されます。これは入力時の桁抜け、符号の誤り、座標変換の途中失敗、表の列ずれなどで起こります。

Polygonでは、面が閉じているかが重要です。Polygonの外周線は、最初の座標と最後の座標が同じである必要があります。閉じていない面は、読み込み側によって自動的に補正されることもありますが、すべての環境で同じように扱われるとは限りません。実務データとして安定させるには、最初と最後の座標を一致させ、面として明確に閉じた状態にしておく方が安全です。造成範囲、敷地範囲、調査区域、管理区域などの面データでは、この確認が特に重要です。

Polygonには、外周と内側の穴を表す構造があります。たとえば、区域の中に除外部分がある場合、外周と内側リングを分けて表現します。このとき、入れ子構造が乱れると、穴が外周として扱われたり、面全体が崩れたりすることがあります。実務では、穴を含む複雑な面データを作るときほど、変換後の表示確認だけでなく、座標配列の階層が正しいかを確認する必要があります。外周と内側リングの向きについても、利用するツールや後工程の仕様に合わせて確認しておくと安心です。

MultiPolygonやMultiLineStringでは、さらに入れ子が深くなります。複数の区域や複数の線をひとつのFeatureとして持たせる場合、各要素の区切りを間違えると、別々の図形がつながってしまったり、ひとつの図形として認識されなかったりします。壊れたデータを修正するときは、まず単独のPolygonやLineStringとして正常に表現できるかを確認し、その後で複数形の構造に戻すと安全です。

座標値の精度にも注意が必要です。桁数が多ければよいというものではありません。必要以上に細かい小数を持つと、ファイルサイズが大きくなり、修正時の見通しも悪くなります。一方で、丸めすぎると境界、施設位置、点検箇所、線形などの位置表現が粗くなります。どの程度の精度が必要かは用途によって異なりますが、現場確認用、概略表示用、設計照合用、台帳連携用では求められる精度が違うため、用途に応じて判断します。

座標を修正するときは、推測で値を書き換えないことが大切です。表示位置がずれているからといって、地図上で見た目が合うように手作業で座標を動かすと、元データとの整合が失われます。原因が経度緯度の逆転なのか、座標変換の不足なのか、変換条件の誤りなのか、元データの入力ミスなのかを切り分けてから修正します。特に境界や管理範囲に関わるデータでは、見た目の一致だけで判断せず、元資料や測量成果、管理台帳との照合を行う必要があります。

手順4として属性情報とデータ型の乱れを確認する

GeoJSONが地図上に正しく表示されても、propertiesの中身が乱れていると実務では使いにくいデータになります。属性情報は、地物の意味を伝えるための重要な部分です。点が表示されていても、それが調査点なのか、設備なのか、境界点なのか、危険箇所なのかが分からなければ、後工程で活用できません。エラー検証では、座標だけでなく属性も必ず確認します。

まず確認したいのは、属性名の統一です。同じ意味の項目に複数の名前が使われていないかを見ます。たとえば、id、ID、管理番号、番号のように似た項目が混在していると、集計や検索で漏れが出ます。人が画面で見るだけなら気づきにくいのですが、後から条件抽出や帳票作成を行うときに問題になります。属性名は、短く、意味が分かり、表記揺れが起こりにくいものに統一します。

次に、データ型の乱れを確認します。数値として扱いたい項目が文字列になっていたり、日付として扱いたい項目がばらばらの表記になっていたりすると、並べ替えや集計で想定外の結果になります。たとえば、面積、延長、高さ、点検回数などは、数値として扱うのか、文字列として扱うのかを決めておく必要があります。管理番号のように先頭のゼロを残したい項目は、数値にするとゼロが消えることがあるため、文字列として持つ方がよい場合もあります。

空欄の扱いも実務上の重要ポイントです。空欄をnullで表すのか、空文字で表すのか、未確認、対象外、不明のような文字で表すのかを決めておかないと、同じ意味の欠損が複数の形で混在します。後から「未確認の地物だけを抽出したい」となったとき、nullと空文字と不明が混ざっていると、条件を何度も作る必要があります。GeoJSONを長く運用するなら、欠損値の表現は早い段階で統一しておくべきです。

属性値に改行、カンマ、引用符、特殊記号が入っている場合も注意します。GeoJSON自体は文字列を扱えますが、別の形式へ変換したり、帳票へ出力したり、システムへ取り込んだりする段階で問題になることがあります。現場メモをそのままpropertiesに入れる場合、改行や記号が多いと後工程で扱いづらくなります。必要な情報を残しつつ、項目を分ける、表記ルールを決める、長文メモを別管理にするなどの整理が必要です。

分類項目の表記揺れもよくある問題です。たとえば、点検済、点検済み、確認済、済のように似た値が混在すると、地図上の色分けや条件抽出が安定しません。危険度、優先度、種別、状態、担当区分など、分類に使う項目は、入力候補を決めておくとデータ品質が上がります。GeoJSONは自由度が高い形式だからこそ、属性値の自由入力が増えると品質が落ちやすい点に注意します。

また、個人情報や公開に適さない情報がpropertiesに混入していないかも確認します。GeoJSONは共有しやすい形式であるため、地図データとして外部へ渡すときに、内部メモ、担当者名、連絡先、未公開の管理情報などが残っていると問題になることがあります。エラー検証というと構文や座標に目が行きがちですが、公開用、共有用、内部作業用で属性の範囲を分けることも重要です。

属性修正では、元データとの対応関係を失わないようにします。属性名を変えるときは、旧項目と新項目の対応を記録しておきます。値を置き換えるときも、どのルールで変換したかを残します。たとえば、空欄を未確認に統一した、全角数字を半角数字に揃えた、日付表記を統一した、分類名を標準表記に変更したといった内容を記録しておくと、後で問い合わせがあったときに説明できます。

GeoJSONの使い方に慣れていない段階では、「地図に出れば成功」と考えがちです。しかし、実務担当者が本当に困るのは、表示後に属性が使えない状態です。図形と属性がそろって初めて、検索、確認、共有、報告、更新に使えるデータになります。壊れたGeoJSONを直すときは、座標だけでなくpropertiesまで含めて、業務に耐える形へ整えることが大切です。

手順5として修正後の再検証と運用ルールを固める

エラー箇所を修正したら、最後に再検証を行います。ここで大切なのは、修正したファイルを一度開いて表示できたから終わりにしないことです。GeoJSONは、ある環境では表示できても、別の環境では属性が読めなかったり、面の扱いが違ったり、座標の解釈で差が出たりすることがあります。実務で使うデータであれば、利用する環境に合わせて複数の観点から確認します。

再検証では、まずファイル全体が読み込めるかを確認します。次に、Feature数が修正前後で意図せず変わっていないかを確認します。エラー修正の途中で一部のFeatureを削除してしまったり、重複してコピーしてしまったりすることがあります。特に大量データでは、見た目だけでは件数の変化に気づきにくいため、Feature数、分類ごとの件数、代表的な属性の件数を確認します。

次に、代表地点や代表区域を地図上で確認します。全件を目視するのは現実的でない場合でも、端部、中央部、複雑な形状、穴を含む面、長い線、属性が特殊な地物などを選んで確認すると、問題を見つけやすくなります。表示位置が妥当か、線が不自然に飛んでいないか、面の外周や穴が意図どおりに表現されているか、意図しない空白や重なりがないかを見ます。

属性については、検索や絞り込みを試すことが有効です。表示画面で属性が見えるだけでは不十分です。管理番号で検索できるか、分類で抽出できるか、状態ごとに分けられるか、日付や数値が想定通り扱えるかを確認します。後工程で使う予定の操作を軽く試しておくことで、属性名やデータ型の問題を早い段階で発見できます。

修正履歴の管理も重要です。壊れたGeoJSONを直す作業では、どこをどのように修正したかが後から分からなくなりがちです。ファイル名に修正日や版数を入れるだけでなく、修正内容を簡単に記録しておくと、再発防止につながります。たとえば、座標順序を修正した、Polygonの閉じ忘れを修正した、属性名を統一した、空欄表現を揃えた、といった記録です。細かいようですが、複数人でデータを扱う現場では、この記録が品質管理に効いてきます。

運用ルールとしては、元データ、変換条件、確認方法、命名規則、属性定義をそろえることが大切です。GeoJSONは便利な受け渡し形式ですが、元データの作り方がばらばらだと、毎回同じようなエラーが発生します。どの座標系のデータをどの条件で変換するのか、属性名は何を使うのか、空欄はどう表すのか、面は必ず閉じるのか、公開用データから除外する属性は何かを決めておくと、修正にかかる時間を減らせます。

また、エラーが起きたときの切り戻し手順も決めておきます。修正後のファイルだけを残して元データを消してしまうと、誤った修正に気づいたときに戻れません。元ファイル、作業用ファイル、公開用ファイルを分けるだけでも安全性が上がります。作業中に何度も上書き保存するのではなく、段階ごとに版を分けることで、どの段階で問題が入ったかを追いやすくなります。

壊れたGeoJSONを直す作業は、一度きりの救急対応で終わらせない方がよいです。エラーには必ず原因があります。変換時の設定不足なのか、入力ルールの不統一なのか、座標の前提が共有されていないのか、属性定義が曖昧なのかを見直すことで、次回以降のエラーを減らせます。特に、現場担当者、管理担当者、システム担当者、外部協力者が同じデータを扱う場合、GeoJSONの受け渡しルールを文書化しておくと、確認の手戻りが少なくなります。

再検証の最後には、実際の利用目的に照らして問題がないかを確認します。現場で見るためのデータなら、必要な地物が素早く確認できるかが重要です。台帳に連携するデータなら、属性の一貫性が重要です。区域を説明する資料なら、面の形状と境界の見え方が重要です。点検結果を共有するデータなら、点の位置と状態区分が重要です。目的によって見るべきポイントは変わるため、単にエラーが消えたかだけでなく、使えるデータになっているかを確認します。

まとめ

GeoJSONのエラー検証では、壊れた箇所を感覚で探すのではなく、順番を決めて切り分けることが大切です。最初にファイル形式と文字コードを確認し、次にFeatureCollectionやFeatureなどの基本構造を見ます。そのうえで、座標の順序、数値範囲、ジオメトリの入れ子、面の閉じ方を確認し、さらにpropertiesの属性名、データ型、空欄、分類表記まで整えます。最後に、修正後の再検証と運用ルールの見直しを行うことで、同じエラーの再発を防ぎやすくなります。

GeoJSONは、シンプルで扱いやすい一方、自由度が高いために表記揺れや構造崩れが起こりやすい形式です。特に実務では、地図に表示できるかどうかだけでなく、現地確認、資料作成、台帳管理、関係者共有、後工程の集計まで見据えて整える必要があります。構文だけを直して終わるのではなく、図形と属性の両方を確認し、元データとの関係を保ちながら修正することが安全です。

「geojson 使い方」を学びながらデータを整備する段階では、正常なひな形を用意し、壊れたデータと比較する方法が役立ちます。さらに、修正履歴を残し、座標や属性のルールを共有しておけば、担当者が変わっても品質を保ちやすくなります。GeoJSONは単なるファイル形式ではなく、位置情報を現場と管理業務の間でつなぐための共通形式です。エラー検証を丁寧に行うほど、地図データは安心して使える実務資料に近づきます。