GeoJSONのバリデーションで見つかる不備と対策7選

GeoJSONは、位置情報を扱う現場で広く使われるデータ形式です。地物の形状、属性、座標をひとつのデータとして表現できるため、地図表示、現地調査、設備管理、測量成果の共有、点検記録、エリア分析など、さまざまな業務で利用されています。一方で、GeoJSONは人が読める形式で扱いやすい反面、少しの記述ミスや座標の不整合が、表示崩れ、読み込み失敗、検索精度の低下、面積計算の誤差、後工程でのデータ破損につながることがあります。

GeoJSONのバリデーションは、単に「ファイルが開けるか」を確認する作業ではありません。JSONとして正しいか、GeoJSONとして仕様に沿った構造になっているか、座標の順序と座標参照系の前提が合っているか、ポリゴンが閉じているか、属性が業務要件に合っているか、不要なデータが混ざっていないかを確認し、実務で安心して使える状態に整えるための重要な工程です。この記事では、GeoJSONのバリデーションでよく見つかる不備を7つに整理し、それぞれの原因と対策を実務目線で解説します。

目次

• GeoJSONのバリデーションが重要な理由

• 不備1：JSON構文エラーで読み込めない

• 不備2：GeoJSONの基本構造が仕様に合っていない

• 不備3：座標の順序や値が間違っている

• 不備4：ポリゴンが閉じていない、リング構造が不正

• 不備5：ジオメトリ種別と座標配列の階層が一致していない

• 不備6：属性情報の欠落、型違い、命名ゆれがある

• 不備7：データ量、精度、重複が実運用に合っていない

• GeoJSONバリデーションを業務フローに組み込むポイント

• まとめ：正しいGeoJSONは現場データ活用の土台になる

GeoJSONのバリデーションが重要な理由

GeoJSONは、位置情報データを扱ううえで便利な形式です。点を表すPoint、線を表すLineString、面を表すPolygon、複数形状をまとめるMultiPoint、MultiLineString、MultiPolygon、さらに属性情報を持つFeature、複数のFeatureをまとめるFeatureCollectionなどを使い、地物と属性を一体で管理できます。テキスト形式であるため内容を確認しやすく、システム間の受け渡しにも向いています。

ただし、GeoJSONは柔軟に書けるからこそ、不備が混入しやすい形式でもあります。たとえば、標準的なGeoJSONでは座標を経度、緯度の順で扱いますが、測位や帳票の現場では緯度、経度の順で表記される場面も多く、入力や変換の過程で順序が逆になることがあります。ポリゴンの始点と終点が一致していなければ、面として正しく扱えない場合があります。属性名がファイルごとに揺れていると、検索や集計の処理で意図した結果が得られません。

特に実務では、GeoJSONが単体で完結することはあまりありません。現地で取得したデータを地図上に表示し、台帳と結び付け、距離や面積を計算し、他の空間データと重ね合わせ、社内外の関係者へ共有するという流れの中で使われます。最初の段階で小さな不備を放置すると、後工程で原因特定に時間がかかり、修正コストが大きくなります。

GeoJSONのバリデーションでは、まずJSONとして正しく読めるかを確認し、そのうえでGeoJSONとして仕様に合っているかを確認します。さらに実務では、座標参照系の前提、属性の必須項目、データ量、精度、重複、運用ルールへの適合まで見る必要があります。つまり、バリデーションは技術的な形式チェックであると同時に、業務データの品質管理でもあります。

GeoJSONで検索する実務担当者の多くは、「地図に表示されない」「読み込み時にエラーが出る」「座標がずれる」「ポリゴンが壊れる」「変換後のデータがおかしい」といった課題を抱えています。これらの多くは、バリデーションで事前に発見できます。ここからは、よく見つかる7つの不備と、それぞれの対策を具体的に見ていきます。

不備1：JSON構文エラーで読み込めない

GeoJSONは、名前の通りJSONを土台にした形式です。そのため、GeoJSONとしての妥当性を確認する前に、まずJSONとして正しい構文になっている必要があります。JSON構文エラーがあると、地図表示システムや変換処理に渡す以前に、ファイルそのものを読み込めません。

よくある構文エラーには、括弧の閉じ忘れ、カンマの付け忘れ、余分なカンマ、ダブルクォーテーションの不足、キー名や文字列の囲み忘れがあります。特に手作業でGeoJSONを編集した場合や、別形式から変換した後に一部だけ修正した場合に起こりやすい不備です。人間の目では一見正しく見えても、1文字の欠落で全体が無効になることがあります。

たとえば、FeatureCollectionの中に複数のFeatureを並べる場合、それぞれのFeatureの間にはカンマが必要です。一方で、配列やオブジェクトの最後の要素の後ろに余分なカンマを置くと、標準的なJSONとしては不正になります。また、属性値に引用符を含む文字列を入れる場合、適切にエスケープされていないと構文エラーになります。外部連携や公開を前提にする場合は、コメント付きJSONや独自拡張ではなく、厳密なJSONとして確認するのが安全です。

この不備の厄介な点は、エラーの発生箇所と実際の原因箇所がずれることです。読み込みエラーの表示では「この行でエラー」と示されても、実際にはその前の行でカンマが抜けていたり、さらに前の階層で括弧が閉じられていなかったりします。ファイルが大きいほど、目視で原因を探すのは困難です。

対策としては、GeoJSONを編集する前に、まずJSON構文を検査できる環境で確認することが基本です。構文チェックにより、括弧、カンマ、文字列、配列、オブジェクトの整合性を機械的に確認できます。手作業で編集する場合は、インデントを整え、階層構造を見やすくしておくことも重要です。1行に圧縮されたGeoJSONは転送効率の面では便利ですが、修正作業には向いていません。

業務フローでは、GeoJSONを受領した直後、変換した直後、納品前の3段階で構文チェックを行うと効果的です。受領時に構文エラーを発見できれば、後続作業に入る前に差し戻せます。変換後に確認すれば、変換処理の不具合や文字コード由来の問題を早期に見つけられます。納品前に確認すれば、最終成果物として最低限読み込める状態であることを担保できます。

また、構文チェックだけで安心しないことも大切です。JSONとして正しくても、GeoJSONとして正しいとは限りません。たとえば、typeの値が誤っていたり、coordinatesの階層が不足していたりしても、JSON構文としては成立してしまいます。JSONオブジェクト内の同じキー名が重複している場合も、処理系によって扱いが分かれることがあるため避けるべきです。最初の確認はJSON構文、その次にGeoJSON仕様、その次に業務要件という順番で段階的に確認するのが実務的です。

不備2：GeoJSONの基本構造が仕様に合っていない

JSONとして読み込めても、GeoJSONの基本構造が仕様に合っていなければ、地理空間データとして正しく扱えません。GeoJSONでは、オブジェクトのtypeに何を指定するか、その中にどの要素を持たせるかが重要です。FeatureCollectionであればfeaturesを持ち、Featureであればgeometryとpropertiesを持ち、GeometryCollection以外のgeometryにはPointやPolygonなどのジオメトリ種別とcoordinatesが必要になります。

よく見つかる不備として、typeの値が誤っているケースがあります。大文字小文字が違う、余分な空白が入っている、独自の種別名を入れている、FeatureとGeometryを混同しているといった問題です。GeoJSONのtype値は決められた文字列として扱われるため、ここが間違っていると、後続の処理は正しくデータを解釈できません。

また、FeatureCollectionであるにもかかわらずfeaturesが配列になっていないケースもあります。本来は複数または0件以上のFeatureを配列として格納しますが、単一のFeatureオブジェクトを直接入れてしまったり、featuresではなくfeatureのような別名にしてしまったりすることがあります。人間には意味が通じても、機械処理では別のキー名は別物として扱われます。

Feature内のgeometryとpropertiesの扱いにも注意が必要です。geometryには位置や形状の情報を入れ、propertiesには名称、管理番号、種別、状態、備考などの属性を入れます。GeoJSONの仕様上、geometryは未位置付けのFeatureとしてnullになり得ます。propertiesもJSONオブジェクトまたはnullを取り得ます。ただし実務データでは、geometryやpropertiesをnullのまま許容するのか、エラーとして除外するのかを業務ルールで決める必要があります。

座標をproperties側に入れてしまったり、属性情報をgeometry側に混ぜてしまったりすると、GeoJSONとしての意味が崩れます。表示だけなら偶然動くこともありますが、検索、抽出、変換、空間演算で問題が出やすくなります。管理IDのようにFeature全体を識別する値は、propertiesに入れる運用もありますが、共通識別子として扱う場合はFeature直下のidを使う設計も検討できます。

対策としては、GeoJSONのトップレベルが何であるべきかを明確にすることです。複数の地物を扱う一般的な業務データでは、FeatureCollectionを基本形にすると扱いやすくなります。そのうえで、各Featureにはgeometryとpropertiesを持たせ、geometry内のtypeとcoordinates、またはGeometryCollectionの場合はgeometriesを確認します。単一のジオメトリだけを扱う場合でも、将来の属性追加や複数件対応を見越してFeatureCollectionに統一する運用は有効です。

バリデーションでは、typeの値、必須キーの有無、featuresの配列構造、geometryとpropertiesの存在、coordinatesまたはgeometriesの有無を確認します。さらに、propertiesを空オブジェクトとして入れるのか、nullを許容するのか、必須属性を定義するのかを運用ルールとして決めます。構造が統一されていれば、後工程の読み込み処理や変換処理を単純化でき、システム間連携のトラブルも減らせます。

GeoJSONの基本構造は、一度ルール化すれば大きな効果があります。現場ごと、案件ごと、担当者ごとに書き方が違う状態では、バリデーション結果も安定しません。標準テンプレートを用意し、受け入れ可能な構造を明文化しておくことで、データ品質を継続的に保ちやすくなります。

不備3：座標の順序や値が間違っている

GeoJSONのバリデーションで非常に多い不備が、座標の順序や値に関する問題です。標準的なGeoJSONのcoordinatesでは、WGS 84を前提に、経度、緯度の順で座標を記述します。ところが、地図や測位の現場では緯度、経度の順で表記される場面も多いため、入力や変換の過程で順序が逆になることがあります。

座標の順序が逆になると、データは見かけ上「数値としては正しい」ため、単純な構文チェックでは検出できないことがあります。しかし地図上では、本来の場所から大きく離れた位置に表示されます。日本国内のデータであれば、経度はおおむね120度台から150度台、緯度は20度台から40度台に収まることが多いため、値の範囲を確認すれば異常に気づける場合があります。たとえば、経度の位置に35程度、緯度の位置に139程度が入っていると、順序が逆である可能性が高くなります。

ただし、値の範囲だけで機械的に判断できないケースもあります。地域によっては数値範囲が近くなる場合があり、また海外データでは前提が変わります。そのため、バリデーションでは、対象地域の想定範囲をあらかじめ定義しておくことが重要です。日本国内の特定エリアを扱う業務であれば、都道府県、市区町村、工区、敷地範囲などに応じた外接範囲を設定し、そこから大きく外れる座標を警告対象にできます。

座標参照系の混同も重要な不備です。現在広く参照されるGeoJSON仕様では、座標参照系はWGS 84、単位は十進度を前提とします。旧仕様由来のcrs指定や、平面直角座標系、Webメルカトル、測量ソフトの内部座標などを変換せずに入れると、数値としては成立していても、標準的なGeoJSONとしては誤解される可能性があります。関係者間で別の座標参照系を使う合意がある場合でも、外部連携や公開用のデータでは、変換条件と座標参照系の扱いを明示することが大切です。

座標値そのものの不備もよくあります。経度が180を超えている、緯度が90を超えている、文字列として座標が入っている、nullや空文字が混ざっている、数値の桁が欠けている、といった問題です。特に表計算データからGeoJSONへ変換する場合、数値が文字列として扱われたり、小数点以下が丸められたりすることがあります。座標の桁数が不足すると、地図上の位置が数メートルから数百メートル単位でずれることもあります。

高さや標高など、3つ目の値を含む座標にも注意が必要です。GeoJSONでは、位置の3つ目の要素としてWGS 84楕円体を基準にした高さを入れられます。一方で、実務データでは標高、楕円体高、独自の高さ、時刻、線形参照値などが混在していることがあります。3つ目の値を使う場合は、その意味と単位をデータ仕様として明確にし、2次元座標と3次元座標が同じファイル内で混在しても処理側が問題なく扱えるか確認します。4つ目以降の値は解釈が不明確になりやすいため、標準的なGeoJSONとして共有する場合は避けるのが安全です。

対策としては、まず座標順序を経度、緯度に統一することです。入力元が緯度、経度の順である場合は、変換時に明示的に入れ替える処理を行い、変換後にサンプル地点を地図上で確認します。次に、座標値の範囲チェックを行います。経度は原則としてマイナス180から180、緯度はマイナス90から90の範囲にあるかを確認し、さらに業務対象エリアの範囲内に収まっているかを確認します。

加えて、座標の数値型を確認することも重要です。見た目が数字でも、文字列として格納されていると、空間処理や計算で不具合が出ることがあります。バリデーションでは、coordinates内の各位置要素が数値であること、不要な空文字や単位付き文字列が混ざっていないことを確認します。座標の丸めについても、表示用と保存用を分け、元データの精度を必要以上に落とさない運用が望ましいです。

座標の不備は、見落とすと現場判断に直結します。設備位置、境界線、調査地点、施工範囲などのデータでは、数メートルの差が業務上大きな意味を持つことがあります。GeoJSONのバリデーションでは、構文や構造だけでなく、座標が現実の場所として妥当かを確認する視点が欠かせません。

不備4：ポリゴンが閉じていない、リング構造が不正

GeoJSONで面を表すPolygonやMultiPolygonでは、リング構造の正しさが重要です。ポリゴンは、座標列によって境界を表し、最初の座標と最後の座標が同じである必要があります。これを「閉じている」と表現します。始点と終点が一致していないポリゴンは、面として正しく扱えないことがあります。

ポリゴンの閉じ忘れは、線データから面データを作成した場合や、手作業で座標を編集した場合によく発生します。見た目にはほぼ閉じているように見えても、最後の座標が最初の座標と完全には一致していないことがあります。たとえば、小数点以下のわずかな差があるだけでも、データとしては別の点として扱われます。その結果、面積計算ができない、塗りつぶし表示が乱れる、空間演算に失敗する、といった問題につながります。

Polygonの線形リングは、閉じたLineStringであり、4つ以上の位置を持つ必要があります。三角形であっても、3点だけでは閉じたリングにならないため、最後に始点と同じ座標をもう一度入れる必要があります。バリデーションでは、単に最初と最後が近いかではなく、同じ値として記録されているかを確認します。

ポリゴンには外側の境界と内側の穴を表すリングがあります。coordinatesの最初のリングは外周を表し、続くリングは穴を表します。この階層や順序が崩れていると、穴として扱うべき部分が外側の面になったり、逆に面として必要な部分が抜けたりします。たとえば、敷地の中に除外区域があるデータや、建物外形に中庭があるデータでは、リングの扱いを誤ると業務上の判断を誤る可能性があります。

リングの向きも注意点です。GeoJSONでは、右手則として外周は反時計回り、内周の穴は時計回りにする考え方が示されています。一方で、互換性のため、処理系はリングの向きだけを理由にPolygonを拒否しないことが推奨されています。そのため、バリデーションでは「読み込み可否」だけでなく、他形式への変換や別システム連携で誤解されにくい向きに整える観点も重要です。

自己交差も重要な不備です。ポリゴンの境界線が自分自身と交差している場合、見た目には図形として成立しているようでも、面としては不正な形状になることがあります。いわゆるリボン状に交差した面や、8の字のような面は、面積計算や内外判定で問題を起こしやすいです。特に現地で取得した点列をそのまま面にした場合、点の順序が乱れて自己交差が発生することがあります。

対策としては、PolygonとMultiPolygonに対して、まず各リングの始点と終点が一致しているかを確認します。一致していない場合は、単純に始点を末尾に追加すれば解決するケースもありますが、それだけで十分とは限りません。点の並び順が誤っている場合は、閉じても自己交差が残る可能性があります。そのため、閉合チェックとあわせて、座標数、自己交差、リング数、穴の位置関係、リング方向も確認する必要があります。

また、線データからポリゴンを生成する場合は、変換前に線が連結しているか、端点が一致しているかを確認します。微小な隙間がある線を無理に面化すると、不正なポリゴンが作られることがあります。現場で取得した境界点からポリゴンを作る場合は、点の取得順序を統一し、外周を一筆書きのように記録する運用にすると、不備を減らせます。

ポリゴンの不備は、地図上で見ただけでは発見しにくいことがあります。表示システムによっては、不正なポリゴンでもそれらしく描画してしまう場合があります。しかし、面積集計、重なり判定、範囲検索、他形式への変換では問題が顕在化します。GeoJSONを業務で使う場合、ポリゴンのリング構造は必ずバリデーション対象に含めるべき項目です。

不備5：ジオメトリ種別と座標配列の階層が一致していない

GeoJSONでは、ジオメトリ種別ごとにcoordinatesの配列階層が決まっています。Pointであれば単一の位置、LineStringであれば位置の配列、Polygonであれば線形リングの配列、MultiPolygonであればPolygon座標配列の配列というように、形状の種類に応じて入れ子の深さが変わります。この階層が一致していないと、データを正しく解釈できません。

たとえば、Pointであるにもかかわらずcoordinatesが複数点の配列になっている場合、処理側はどの点を代表点として扱うべきか判断できません。LineStringなのに座標点が1つしかない場合、線として成立しません。Polygonなのにリング配列ではなく座標列が直接入っている場合、面の外周として解釈できないことがあります。MultiPolygonではさらに階層が深くなるため、変換時や手作業編集時に配列の括弧が不足したり、逆に過剰になったりしがちです。

この不備は、見た目では発見しづらいものの、バリデーションでは比較的検出しやすい項目です。typeとcoordinatesの構造を対応させて確認すれば、ジオメトリ種別に対して期待される配列階層になっているかを判断できます。しかし、単に階層が合っているだけでは不十分です。LineStringには2点以上が必要であり、Polygonのリングには少なくとも閉じた線を構成できるだけの座標数が必要です。Multi系のジオメトリでは、空配列や要素数不足をどう扱うかも運用上確認する必要があります。

GeometryCollectionを使う場合も注意が必要です。GeometryCollectionはcoordinatesではなくgeometriesを持ち、複数の異なるジオメトリをまとめられる構造です。便利な一方で、実務上は処理側の対応に差が出やすい形式です。点、線、面が混在したデータをひとつのFeatureとして扱える一方で、表示や変換、集計の段階で想定外の扱いになることがあります。業務要件として本当にGeometryCollectionが必要なのか、Featureを分けて表現した方がよいのかを検討することが大切です。

また、ひとつのFeatureCollection内に複数のジオメトリ種別が混在している場合も、運用上の確認が必要です。GeoJSONとしては混在できますが、業務システムや分析処理では、点データだけ、線データだけ、面データだけを前提にしていることがあります。たとえば、設備台帳の位置情報としてPointを想定しているデータにPolygonが混ざると、取り込みエラーや処理スキップが発生する可能性があります。

対策としては、データセット単位で許容するジオメトリ種別を定義することです。調査地点データならPoint、道路や管路ならLineStringまたはMultiLineString、区域や敷地ならPolygonまたはMultiPolygonというように、目的に応じた種別を決めます。そのうえで、Featureごとにgeometry.typeを確認し、想定外の種別が含まれていないかを検査します。

coordinatesの階層については、ジオメトリ種別ごとに検査ルールを分けます。Pointなら数値2つ、必要に応じて3つの位置配列、LineStringなら2点以上の位置配列、Polygonなら1つ以上の閉じたリング配列、MultiPolygonならPolygon座標配列を含む階層構造として確認します。GeometryCollectionでは、geometries配列内の各Geometryについて同じ検査を再帰的に行います。空のcoordinatesやnullが含まれている場合は、業務上許容するのか、エラーとして修正するのかを明確にします。

ジオメトリ種別と座標階層の不一致は、データ変換の途中で発生しやすい不備です。特に、別形式の空間データ、表形式の座標一覧、現地計測データ、図面由来の境界線などをGeoJSONに変換する場合は、変換結果を必ず確認する必要があります。typeだけを見るのではなく、coordinatesやgeometriesの中身まで確認することが、実務で使えるGeoJSONを作るための基本です。

不備6：属性情報の欠落、型違い、命名ゆれがある

GeoJSONのFeatureには、geometryだけでなくpropertiesがあります。propertiesには、地物の名称、管理番号、種別、状態、更新日、担当部署、備考など、業務に必要な属性情報を格納します。地図上に点や線や面を表示するだけならgeometryがあれば足りますが、検索、分類、集計、色分け、ラベル表示、台帳連携を行うにはpropertiesの品質が重要です。

バリデーションでよく見つかる不備のひとつが、必須属性の欠落です。たとえば、設備管理データで管理IDが欠けていると、地図上の地物と台帳レコードを結び付けられません。点検データで点検日がないと、いつ取得された情報なのか判断できません。区域データで区域名や種別が欠けていると、表示や集計の条件に使えません。位置は正しくても、属性が不足していると業務データとしては不完全です。

型違いもよく発生します。本来は数値であるべき面積や延長が文字列になっている、本来は文字列であるべき管理番号が数値として扱われて先頭のゼロが消えている、日付が複数の表記形式で混在している、といったケースです。見た目には大きな問題がないように見えても、検索条件、並び替え、集計処理で不具合が起きます。特に管理番号やコード類は、数字だけで構成されていても文字列として扱うべき場合があります。

命名ゆれも実務では深刻です。同じ意味の属性が、あるファイルではid、別のファイルではID、さらに別のファイルでは管理番号になっていると、処理側で個別対応が必要になります。名称についても、name、名称、施設名、設備名などが混在すると、ラベル表示や検索で抜け漏れが発生します。GeoJSON自体はpropertiesのキー名を自由に設定できますが、自由であることは統制が不要という意味ではありません。

値の表記ゆれにも注意が必要です。種別の値として「電柱」「電柱設備」「柱」が混在していると、同じ分類として集計できません。状態の値として「使用中」「稼働中」「運用中」が混在している場合も同様です。全角半角、大小文字、空白、記号の違いも検索や集計に影響します。現場入力では人間にとって自然な表現が使われがちですが、システム処理では統一された値が求められます。

null、空文字、未入力の扱いも決めておく必要があります。属性が存在しない状態、キーはあるが値がnullの状態、値が空文字の状態、値に「不明」や「未定」と入っている状態は、それぞれ意味が異なります。これらが混在すると、未入力件数を正しく集計できません。バリデーションでは、必須項目が埋まっているかだけでなく、未入力の表現が統一されているかも確認します。

対策としては、propertiesのデータ辞書を作ることが有効です。どの属性名を使うのか、必須か任意か、値の型は何か、許容される値は何か、空欄を許すか、例外値をどう表現するかを定義します。データ辞書があれば、GeoJSONの受け入れ時に機械的なチェックができ、担当者ごとの判断のばらつきを減らせます。

また、属性情報は地図表示だけでなく、後続の業務処理から逆算して設計することが大切です。将来、施設種別で絞り込みたいのか、更新日で履歴管理したいのか、管理番号で台帳連携したいのか、点検結果で色分けしたいのかによって、必要な属性は変わります。今見える地図を作るためだけに最低限の属性で済ませると、後から分析や連携を行う段階で再整備が必要になります。

GeoJSONのバリデーションでは、geometryの正しさに目が向きがちですが、propertiesの品質も同じくらい重要です。正しい位置に正しい属性が結び付いていることで、初めて実務で使える空間データになります。

不備7：データ量、精度、重複が実運用に合っていない

GeoJSONのバリデーションでは、仕様上の正しさだけでなく、実運用に耐えられるデータかどうかも確認する必要があります。構文が正しく、座標も正しく、属性もそろっていても、データ量が大きすぎる、座標精度が過剰または不足している、重複データが多いと、表示速度や運用効率に影響します。

GeoJSONはテキスト形式であるため、同じ情報量でもバイナリ形式に比べてファイルサイズが大きくなりやすい傾向があります。細かすぎる境界線、不要な小数桁、重複した属性、使われない項目が多いデータでは、読み込みに時間がかかり、ブラウザや端末上での表示が重くなることがあります。現地で利用する場合、通信環境や端末性能によっては、データが開けない、表示に時間がかかる、操作が固まるといった問題につながります。

座標精度の扱いも重要です。小数点以下の桁数を多く残せば常に良いというわけではありません。GeoJSONでは、座標値の桁数だけを精度や不確かさの証明として解釈することはできません。元データの測位精度や業務目的に対して過剰な桁数を保持しても、実質的な精度は上がらず、ファイルサイズだけが増える場合があります。一方で、必要以上に丸めてしまうと、設備位置や境界線の精度が損なわれます。現地確認や施工管理に使うデータと、広域の概略表示に使うデータでは、必要な精度が異なります。

重複データもよく見つかる不備です。同じ管理IDのFeatureが複数存在する、同じ座標に同じ属性の点が重複している、同じポリゴンが複数回入っているといった状態です。重複があると、地図上では1つに見えても、集計では件数が二重に数えられます。点検対象数、設備数、面積、延長などの集計値がずれるため、業務判断に影響します。

似ているが完全には一致しない重複にも注意が必要です。座標がわずかに違うだけで同じ設備を表している場合や、名称の表記だけが違う同一地点が複数存在する場合があります。このような重複は単純な完全一致では検出できません。管理ID、座標距離、属性の組み合わせなど、業務に応じた判定ルールが必要です。

不要な属性や中間処理用の項目が残っていることもあります。変換元の内部ID、一時的なフラグ、作業メモ、確認用の列などがpropertiesに混入していると、ファイルサイズが増えるだけでなく、共有先に不要な情報を渡してしまうリスクがあります。公開や納品を前提とするGeoJSONでは、必要な属性だけを残す確認が欠かせません。

対策としては、まず用途に応じたデータ量と精度の基準を決めます。詳細編集用、現地閲覧用、公開表示用、集計用など、用途ごとに必要な情報量は異なります。すべての用途に同じGeoJSONを使い回すのではなく、用途に応じて簡略化や属性削減を行うと、扱いやすさが向上します。

次に、座標の小数桁を管理します。元データの精度を保持するマスターデータと、表示や共有に使う軽量データを分ける考え方が有効です。マスターデータでは必要な精度を保持し、配布用データでは業務上問題のない範囲で桁数や頂点数を調整します。ただし、境界線や測量成果に関わるデータでは、安易な簡略化が形状の意味を変える可能性があるため、必ず用途と許容誤差を確認します。

重複チェックでは、管理IDの一意性、座標の一致、属性の一致、近接距離による候補抽出を組み合わせます。完全一致の重複は自動検出しやすいですが、類似重複は確認作業が必要です。現場データでは、同じ地点を複数回取得した履歴データなのか、誤って重複したデータなのかを見分ける必要があります。履歴として残すべきデータと、重複として削除すべきデータを区別するルールを用意しておくと安心です。

実運用に合ったGeoJSONにするには、正しさ、軽さ、使いやすさのバランスが重要です。仕様上は正しくても、現場で開くたびに時間がかかるデータでは活用が進みません。逆に、軽量化を優先しすぎて必要な精度や属性を失うと、業務判断に使えなくなります。バリデーションでは、技術的な妥当性と業務上の妥当性の両方を見ることが大切です。

GeoJSONバリデーションを業務フローに組み込むポイント

GeoJSONの不備は、最後にまとめて確認するよりも、データの作成、変換、編集、共有の各段階で確認する方が効率的です。最後の納品直前に大量のエラーが見つかると、原因の切り分けが難しくなり、作業の手戻りも大きくなります。バリデーションを業務フローの中に組み込むことで、不備を早期に発見し、修正コストを抑えられます。

まず、データ作成時点で入力ルールを整えることが重要です。現地で点を取得する場合は、どの属性を必ず入力するのか、名称や種別をどの表記に統一するのか、同じ対象を重複して取得しないためにどう確認するのかを決めます。座標の取得方法や精度の目安も共有しておくと、後から座標の信頼性を判断しやすくなります。

次に、変換時のルールを固定します。表形式、図面由来データ、他の空間データ形式などからGeoJSONへ変換する際には、座標順序、座標参照系、ジオメトリ種別、属性名、文字コード、数値型、日付形式を確認します。変換処理が担当者ごとに異なると、同じ元データから異なるGeoJSONが作られる可能性があります。変換手順を標準化し、変換後に必ずバリデーションを実行することが大切です。

編集時には、手作業による破損を防ぐ工夫が必要です。GeoJSONはテキストで編集できますが、構文を壊しやすい形式でもあります。小さな修正であっても、編集後にはJSON構文チェックとGeoJSON構造チェックを行うべきです。特に、複数人で同じデータを扱う場合は、誰がいつ何を変更したかを追跡できるようにしておくと、問題発生時の原因調査が容易になります。

共有前には、受け渡し先の利用目的に合わせたチェックを行います。社内の地図表示用なのか、外部への納品用なのか、現地端末での閲覧用なのか、分析処理用なのかによって、必要な確認項目は変わります。たとえば、表示用であればファイルサイズや描画速度が重要になり、分析用であれば属性の型やジオメトリの正確性が重要になります。納品用であれば、不要な属性や内部情報が含まれていないかも確認する必要があります。

バリデーション結果の扱いも重要です。すべての警告を同じ重みで扱うと、優先順位がわからなくなります。読み込み不能につながる構文エラー、位置の誤りにつながる座標順序、面として成立しないポリゴン不備、集計に影響するID重複などは、優先度の高いエラーとして扱うべきです。一方で、任意属性の未入力や軽微な表記ゆれは、業務要件に応じて警告として扱うこともあります。

実務では、エラー、警告、確認事項を分けると運用しやすくなります。エラーは修正しない限り受け入れ不可とし、警告は担当者が内容を確認したうえで許容可否を判断し、確認事項は品質向上のために記録するという考え方です。このように分類しておくと、過剰に厳しいチェックで業務が止まることを避けながら、重大な不備は確実に防げます。

また、バリデーションの基準は一度作って終わりではありません。業務内容、取得方法、利用システム、共有先が変われば、必要なチェック項目も変わります。新しい属性を追加した場合、測位方法を変更した場合、対象エリアが広がった場合、データ量が増えた場合には、バリデーションルールも見直す必要があります。ルールを更新しながら運用することで、GeoJSONの品質を継続的に維持できます。

GeoJSONのバリデーションをうまく運用するポイントは、担当者の目視確認だけに頼らないことです。人間は文脈を理解できますが、細かい構文ミスや大量データの重複検出は苦手です。一方で、機械的なチェックは大量データに強いものの、業務上の意味までは判断できません。機械的な検査と担当者の業務判断を組み合わせることで、実用的な品質管理ができます。

まとめ：正しいGeoJSONは現場データ活用の土台になる

GeoJSONは、位置情報をわかりやすく扱える便利な形式です。しかし、実務で安定して使うためには、構文、構造、座標、ジオメトリ、属性、データ量、重複といった複数の観点からバリデーションを行う必要があります。単にファイルが開けるかどうかだけでは、業務データとして十分とは言えません。

この記事で解説した7つの不備は、GeoJSONを扱う現場で特によく見つかるものです。JSON構文エラーは読み込み不能の原因になります。GeoJSONの基本構造が崩れていると、地物として正しく解釈できません。座標順序や値、座標参照系の誤りは、位置ずれや対象外エリアへの誤表示につながります。ポリゴンの閉じ忘れやリング構造の不備は、面積計算や範囲判定に影響します。ジオメトリ種別と座標配列の階層が一致していないと、変換や表示でエラーになります。属性情報の欠落や型違い、命名ゆれは、検索、集計、台帳連携を難しくします。データ量、精度、重複の問題は、運用時の速度や信頼性に影響します。

GeoJSONの品質を高めるには、最初から完璧なデータを作ろうとするよりも、不備を早期に見つけて直せる仕組みを持つことが重要です。受領時、変換時、編集時、共有前にバリデーションを行い、エラーと警告を分類し、業務要件に合わせて判断する流れを作ることで、手戻りを大きく減らせます。

特に現地調査や設備管理、施工管理、測量成果の活用では、位置情報の正確さがそのまま判断の正確さにつながります。地図上に表示できるだけでなく、誰が見ても同じ意味で扱え、他のデータとも安全に連携できるGeoJSONを整備することが大切です。

これからGeoJSONを本格的に活用する場合は、データ取得の段階から品質を意識することが近道です。現場で取得した位置情報をそのまま業務に使える形で残し、必要な属性と結び付け、後工程で扱いやすいGeoJSONとして管理できれば、確認、共有、分析の効率は大きく向上します。バリデーションのルールを業務フローに組み込み、構文・仕様・業務要件の3段階で確認することで、信頼できる空間データの活用につながります。