GeoJSONを扱う実務では、地図に表示されない、読み込み時にエラーが出る、位置がずれる、属性が反映されないといったトラブルが起こることがあります。原因は大きな設計ミスだけでなく、カンマ、括弧、座標順、型名の表記など、小さな構文ミスにある場合も少なくありません。この記事では、GeoJSONで起こりやすいエラーの見方と、確認しやすい8つの構文ミスを整理します。
GeoJSONのエラーはどこから確認するべきか
GeoJSONのエラーを直すときは、いきなり全体を眺めて原因を探すよりも、まず「読み込み前に失敗しているのか」「読み込み後に表示だけ失敗しているのか」を分けて考えることが大切です。GeoJSONはJSON形式を土台にした地理データ形式なので、JSONとして壊れていれば、地図に表示する以前に読み込みが失敗します。一方で、JSONとしては正しいのに地物が表示されない場合は、GeoJSONとしての構造、座標順、座標系、ジオメトリの形状などを疑う必要があります。
たとえば、ファイルを開いた時点で構文エラーが出る場合は、カンマの抜け、余計なカンマ、ダブルクォーテーションの不足、閉じ括弧の不足などが原因になりやすいです。この段階では、地理情報の意味よりも、JSONとして読めるかどうかを先に確認します。見た目では小さな違いでも、1文字の抜けで全体が読み込めなくなるため、手作業で編集した直後ほど注意が必要です。
次に、ファイルは読み込めるのに地図上に何も出ない場合は、GeoJSONの構造を確認します。GeoJSONでは、地物全体を表すFeatureCollection、個別地物を表すFeature、点や線や面を表すgeometry、属性を格納するpropertiesなど、役割ごとに置く場所が決まっています。これらの階層がずれていると、エラー表示が分かりにくいまま、表示側で無視されることがあります。
また、地図上には出るものの、想定外の場所に表示される場合は、座標の順番や座標系の取り違えが疑われます。GeoJSONの位置座標は、経度、緯度の順で書くのが基本です。緯度、経度の順で書いてしまうと、日本のデータが遠く離れた場所に表示されたり、地図の範囲外に飛んだりします。測量や現場管理で扱う平面座標やローカル座標をそのまま入れた場合も、GeoJSONで想定される座標と合わず、位置が大きくずれることがあります。
エラー対応では、表示ソフトや地図ライブラリの問題だと決めつける前に、まずGeoJSONファイル単体を確認する姿勢が重要です。ファイルがJSONとして成立しているか、GeoJSONとして必要な構造を満たしているか、座標値が意図した形式かを順に確認すれば、原因の切り分けがしやすくなります。
GeoJSONの基本構造を理解してエラーを減らす
GeoJSONの構文ミスを減らすには、まず基本構造を押さえる必要があります。GeoJSONは、点、線、面などの地理情報をJSON形式で表すデータです。よく使われる形の一つが、複数の地物をまとめるFeatureCollectionです。この中にfeaturesという配列があり、その配列の中に個々のFeatureが入ります。Featureの中には、形状を表すgeometryと、属性を表すpropertiesが入ります。
この関係を理解していないと、geometryをfeaturesと同じ階層に置いてしまったり、propertiesをFeatureCollectionの直下に置いてしまったりします。見た目には似たようなJSONでも、GeoJSONとしては意味が変わるため、読み込み側が正しく解釈できません。特に、既存のデータを手で編集するときや、別形式から変換したデータを整えるときに、階層のずれが起こりやすくなります。
点を表すPointでは、coordinatesに1組の座標を入れます。線を表すLineStringでは、coordinatesに複数の座標を並べます。面を表すPolygonでは、coordinatesがさらに一段深くなり、外周リングや穴のリングを表します。複数の点、複数の線、複数の面を扱う場合は、それぞれMultiPoint、MultiLineString、MultiPolygonのように、さらに入れ子が深くなります。
この入れ子の深さは、GeoJSONのエラーの中でも特に混乱しやすい部分です。点、線、面の違いを意識せずにcoordinatesをコピーすると、見た目は座標値が並んでいても、ジオメトリ型と配列構造が合わなくなります。Pointなのに複数座標の配列になっている、PolygonなのにLineStringと同じ深さになっている、といったミスが典型です。
propertiesは、地物に付ける属性情報を入れる場所です。名称、管理番号、分類、点検日、備考など、地図上の形状以外の情報をここに入れます。Featureのpropertiesは、属性がない場合でも空のオブジェクトまたはnullとして扱われることがあります。ただし、利用するシステムや変換処理によって期待する形式が異なる場合があるため、連携先の仕様も確認しておくと安全です。属性値に余計な改行や不正な引用符が入ることもあるため、図形だけでなく属性も確認対象にする必要があります。
GeoJSONの修正では、まず大枠としてFeatureCollection、features、Feature、geometry、propertiesの関係を確認します。そのうえで、geometryのtypeとcoordinatesの構造が一致しているかを見ます。この順序で確認すると、細かい文字のミスに入る前に、構造の大きなズレを発見しやすくなります。
カンマや括弧の不足による構文エラー
GeoJSONで最も基本的で、同時に起こりやすいエラーが、カンマや括弧の不足です。GeoJSONはJSON形式で書かれるため、オブジェクトは波括弧、配列は角括弧で囲み、項目同士はカンマで区切ります。人間が読むと意味が分かるように見えても、カンマが1つ抜けているだけで機械は正しく読み込めません。
よくあるのは、properties内で属性を追加したときに、前の行との間にカンマを入れ忘れるケースです。たとえば、名称の属性の次に管理番号を追加したのに、名称の行の終わりにカンマがないと、JSONとしては不正になります。反対に、最後の項目の後ろに余計なカンマを残してしまうこともあります。環境によっては許容されるように見える場合もありますが、標準的なJSONとしては避けるべき書き方です。
括弧の不足もよく起こります。FeatureCollection全体を閉じる波括弧、features配列を閉じる角括弧、geometryの中のcoordinates配列を閉じる角括弧など、GeoJSONでは複数の括弧が入れ子になります。特にPolygonやMultiPolygonでは角括弧が何重にもなるため、手作業で修正すると閉じ忘れや閉じすぎが起こりやすくなります。
括弧のミスを見つけるには、ファイル全体を一気に見るよりも、内側から外側へ確認するのが有効です。まずcoordinatesの配列が閉じているかを見て、次にgeometry、Feature、features、FeatureCollectionの順に確認します。字下げが崩れていると構造を追いにくいため、整形してから確認すると見落としが減ります。整形によって階層が視覚的に分かれば、余っている括弧や足りない括弧を見つけやすくなります。
また、コピーしてきた文字列の中に全角の記号が混じることもあります。GeoJSONでは、キー名や文字列は半角のダブルクォーテーションで囲む必要があります。見た目が似ていても、全角の引用符や別の種類の引用符が混じると、JSONとして読めないことがあります。文章作成用の環境で編集した文字を貼り付けた場合は、特に注意が必要です。
カンマや括弧のエラーは単純ですが、ファイル全体を止める影響があります。地図に表示されない原因として、座標や地図設定を疑う前に、まずJSONとして成立しているかを確認することが基本です。構文エラーが出た場合は、最後に編集した箇所、属性を追加した箇所、coordinatesを手で変更した箇所から順に見ると、原因に近づきやすくなります。
typeの表記ミスと階層の取り違え
GeoJSONでは、typeというキーが非常に重要です。FeatureCollection、Feature、Point、LineString、Polygonなどの種類は、typeの値によって判定されます。この値の表記が間違っていると、構造がほぼ正しくても読み込みに失敗したり、意図しない扱いになったりします。
よくあるミスは、大文字と小文字の違いです。GeoJSONのtype値は、決まった表記で書く必要があります。たとえば、FeatureCollectionをfeaturecollectionのように小文字だけで書いたり、LineStringをLinestringのように途中の大文字を変えたりすると、認識されない原因になります。人間には同じ意味に見えても、データとしては別の文字列として扱われます。
次に多いのが、typeを書く階層の取り違えです。FeatureCollectionの直下に必要なtype、Featureの中に必要なtype、geometryの中に必要なtypeは、それぞれ役割が異なります。FeatureのtypeにPolygonと書いてしまい、geometryのtypeが抜けているような構造では、GeoJSONとして正しくありません。Featureはあくまで属性と形状をまとめる入れ物であり、点や線や面の種類はgeometryの中で指定します。
また、features配列の中にFeatureではなくgeometryだけを直接入れてしまうミスもあります。単独のGeometryとして扱う場面もありますが、属性付きの地物群として扱う場合は、FeatureCollectionのfeatures配列にはFeatureを入れるのが一般的です。属性を持たせたいのにgeometryだけを入れていると、propertiesが付けられず、後工程で管理番号や分類が扱えないといった問題につながります。
typeのミスは、エラーとして分かりやすく出る場合もあれば、表示されない、属性が出ない、地物数が想定より少ないといった形で現れる場合もあります。修正時は、まず最上位のtypeがFeatureCollection、Feature、Geometryのどれになっているかを確認し、用途に合っているかを見ます。FeatureCollectionの場合は、featuresが配列になっているか、各要素のtypeがFeatureになっているか、geometry内のtypeがPoint、LineString、Polygonなどの正しい値になっているかを順に確認します。
複数の地物を扱うときは、すべてのFeatureで同じ型にそろえる必要があるとは限りません。点と線と面を同じFeatureCollectionに含めることもできます。ただし、各Featureのgeometry typeとcoordinatesの構造は一致していなければなりません。見た目の管理上、型が混在していると確認が難しくなるため、実務では用途ごとにファイルを分ける、または属性で分類を明確にするなどの工夫も有効です。
coordinatesの座標順と入れ子構造のミス
GeoJSONのcoordinatesは、エラーが出なくても結果が大きく変わりやすい部分です。特に重要なのは、座標の順番です。GeoJSONの位置座標は、経度、緯度の順で記述するのが基本です。日本語の業務では緯度、経度の順で呼ぶことが多いため、その感覚で入力すると、位置が大きくずれることがあります。
たとえば、緯度が35付近、経度が139付近の地点を扱う場合、本来は139、35の順で書きます。これを35、139の順にすると、緯度として139という値が入ることになり、通常の地図表示では成立しないか、範囲外として扱われます。点が表示されない、または想定外の場所に飛ぶ場合は、まずこの座標順を確認するべきです。
次に確認したいのが、coordinatesの入れ子構造です。Pointでは、coordinatesは1つの座標ペアです。LineStringでは、複数の座標ペアを並べた配列です。Polygonでは、外周リングを表す配列の中に座標ペアが並びます。つまり、点、線、面で角括弧の深さが変わります。この深さがジオメトリ型と合っていないと、GeoJSONとして不正になったり、形状が正しく解釈されなかったりします。
LineStringなのにPointのように1組の座標だけを書いてしまうと、線として成立しません。LineStringは少なくとも2点以上の座標が必要です。PolygonなのにLineStringと同じ深さで座標を並べると、面のリングとして認識されません。MultiPolygonではさらに深い入れ子になるため、単純なPolygonから変換するときに括弧の数を誤りやすくなります。
また、座標値に文字列が混じることもあります。coordinatesに入る値は、通常は数値として書きます。変換処理や表計算データからの出力で、数値が引用符に囲まれて文字列になっている場合、読み込み側によっては正しく扱えないことがあります。属性値としての数字なら文字列でも問題になりにくい場合がありますが、座標値は地図上の計算に使われるため、数値として扱うのが基本です。
標高などの高さ情報を含める場合も注意が必要です。GeoJSONの座標には、経度、緯度に加えて高さを3つ目の値として含めることがあります。ただし、表示側や処理側が高さを利用するとは限りません。高さを入れたつもりでも無視される場合があるため、高さ情報を成果として扱う場合は、geometryの座標だけでなくpropertiesにも管理上必要な値を持たせるなど、後工程を考えた設計が必要です。
coordinatesのミスは、構文としてのエラーと、表示結果のズレの両方を引き起こします。直すときは、まずジオメトリ型を確認し、その型に必要な入れ子の深さになっているかを見ます。次に、座標が経度、緯度の順になっているか、数値として書かれているか、極端に大きい値や小さい値が混じっていないかを確認します。
Polygonの閉じ忘れとリング構造のミス
PolygonはGeoJSONの中でもミスが起こりやすいジオメトリです。理由は、面を表すために、座標を線のように並べるだけでは足りず、閉じたリングとして記述する必要があるためです。Polygonの外周リングでは、最初の座標と最後の座標を同じにして、面の境界を閉じます。この閉じ忘れがあると、面として扱えない、表示が崩れる、読み込み時に警告が出るといった問題が起こることがあります。
たとえば、四角形の面を作る場合、4つの角の座標だけを書けばよいように思えます。しかし、Polygonでは最後に最初と同じ座標をもう一度書き、リングを閉じる必要があります。最初の点に戻らないまま終わっているデータは、線としては見えても、面としての条件を満たしません。地図上では塗りつぶしが出ない、形状が欠ける、隣接する面との関係が崩れるなどの原因になります。
Polygonには外周だけでなく、穴を表す内周リングを持たせることもできます。この場合、coordinatesの中には、外周リングと内周リングが順に入ります。外周と内周の入れ子を間違えると、穴が正しく表現されなかったり、面全体が不正になったりします。穴を使わない単純なPolygonでも、外周リングをさらに配列で包む必要があるため、LineStringよりも角括弧が一段深くなります。
また、リングの向きについても注意が必要です。GeoJSONの仕様では外周と内周の向きに関する考え方がありますが、実際の利用環境では向きの違いを自動的に補正する場合もあります。ただし、面積計算、重なり判定、データ変換などを行う場合は、リングの向きや自己交差の有無を確認することが重要です。表示できているから問題ないと判断すると、後工程で計算結果が合わないことがあります。
自己交差もPolygonの代表的な問題です。外周リングが途中で交差していると、見た目には面らしく見えても、幾何としては不正または扱いにくい形になります。現場範囲、敷地範囲、補修範囲などを手作業で作成した場合、点の順番を間違えてリボンのようにねじれた面になることがあります。この場合、構文エラーではなく形状エラーとして扱う必要があります。
Polygonの修正では、最初に最初の座標と最後の座標が一致しているかを確認します。次に、coordinatesの入れ子がPolygonの構造になっているかを見ます。さらに、座標の順番が外周をなぞる順序になっているか、線が交差していないか、穴を使う場合は外周と内周が分かれているかを確認します。面データは点や線よりもチェック項目が多いため、手作業での修正後には必ず表示確認と形状確認を行うことが大切です。
Featureとpropertiesまわりの記述ミス
GeoJSONでは、形状情報だけでなく属性情報も重要です。実務で扱うデータでは、点や線や面に対して、名称、種別、管理番号、作業日、点検結果、担当区分などの情報を持たせることが多くあります。これらは通常propertiesに入れますが、propertiesまわりの記述ミスによって、地図上の表示や検索、絞り込み、帳票作成に影響が出ることがあります。
まず注意したいのは、propertiesがFeatureの中に置かれているかどうかです。propertiesは、FeatureCollection全体の共通情報を入れる場所ではなく、各Featureに紐づく属性を入れる場所です。FeatureCollectionの直下にpropertiesを書いても、個々の地物の属性としては扱われないことがあります。複数地物の属性を管理する場合は、それぞれのFeatureにpropertiesを持たせる必要があります。
次に、propertiesの値に使う文字列の扱いです。JSONでは、文字列はダブルクォーテーションで囲みます。属性値に説明文を入れるとき、文章中にダブルクォーテーションが含まれると、そのままでは構文が壊れることがあります。改行や特殊な記号が混じる場合も注意が必要です。現場メモをそのまま貼り付けると、見えにくい制御文字や不正な改行が入り、読み込みエラーの原因になることがあります。
属性名の揺れも実務上の問題です。たとえば、あるFeatureではname、別のFeatureではName、さらに別のFeatureでは名称というように、同じ意味の項目名が混在すると、表示や検索の設定が安定しません。GeoJSONとしての構文は正しくても、後工程で属性が拾えない原因になります。データを作成する段階で、属性名のルールを決めておくことが重要です。
propertiesに数値や真偽値を入れる場合も、文字列として扱うのか数値として扱うのかを決めておく必要があります。管理番号のように先頭のゼロを残したい値は、数値ではなく文字列として扱った方がよい場合があります。一方、面積、延長、点検回数のように計算に使う値は、数値として扱う方が後工程で便利です。構文エラーではなくても、型の設計が曖昧だと、集計や判定で問題が出ます。
propertiesが空の場合は、空のオブジェクトとして書くか、利用環境に合わせてnullにするかを考える必要があります。一般的には、属性がない場合でも空のオブジェクトとしておくと、後から属性を追加しやすくなります。ただし、既存システムとの連携では決まった形式が求められることがあるため、出力先の仕様に合わせることが大切です。
Featureとpropertiesのミスは、地図に表示されるかどうかだけでは判断できません。形状は見えているのに、クリックしても情報が出ない、分類表示が効かない、ラベルが出ない、検索に引っかからないといった場合は、propertiesの位置、属性名、値の型、文字列の書き方を確認します。GeoJSONを現場管理や台帳整理に使うなら、geometryだけでなくpropertiesも成果物の品質として確認する必要があります。
nullや空配列を扱うときの注意点
GeoJSONでは、データが未入力の場合や、後で追加する予定の項目がある場合に、nullや空配列を使うことがあります。しかし、nullや空配列の使い方を誤ると、読み込み側が想定どおりに処理できないことがあります。特に、geometryやcoordinatesに空の値が入っている場合は注意が必要です。
geometryがnullのFeatureは、属性だけを持ち、形状を持たない地物として扱われることがあります。このようなデータは、一覧や属性管理では意味がある場合もありますが、地図上には表示できません。表示されない地物があるとき、単純にエラーだと判断する前に、そのFeatureのgeometryがnullになっていないかを確認する必要があります。
coordinatesが空配列になっている場合も問題になります。Pointでcoordinatesが空になっていれば、点の位置が分かりません。LineStringで座標が1点だけ、または空であれば、線として成立しません。Polygonでリングが空であれば、面として成立しません。空配列はJSONとしては正しくても、GeoJSONの形状としては不十分な場合が多くあります。
properties内の値としてnullを使う場合は、未入力なのか、該当なしなのか、意図的に空にしているのかを区別しにくくなります。たとえば、点検結果がnullの場合、まだ点検していないのか、点検対象外なのか、入力漏れなのかが分かりません。実務データでは、後から別の担当者が見ても意味が分かるように、空欄の扱いを事前に決めておくことが重要です。
また、空文字とnullの違いにも注意が必要です。空文字は文字列として存在しているが中身がない状態です。nullは値そのものがない状態です。表示上はどちらも空に見えることがありますが、検索、抽出、変換の処理では別の扱いになることがあります。属性データを後工程で集計する場合は、どちらを使うかを統一しておくと混乱を避けられます。
エラー修正の観点では、nullや空配列が原因で地図に出ないのか、構造そのものが壊れているのかを分けて見る必要があります。JSONとして正しいから問題ないとは限らず、GeoJSONとして意味のある形状になっているかを確認します。特に、自動変換で作成されたGeoJSONでは、元データに形状がないレコードが混じり、geometryがnullのFeatureが出力されることがあります。表示対象だけを抽出するのか、属性管理用として残すのかを判断して整理することが大切です。
座標系や単位の思い込みによる表示位置のずれ
GeoJSONのトラブルでは、構文が正しくても位置がずれることがあります。この場合に疑うべきなのが、座標系や単位の思い込みです。GeoJSONで一般的に使われる座標は、経度と緯度による地理座標です。一方、測量、設計、施工管理、点群処理、図面管理などの実務では、平面直角座標、ローカル座標、メートル単位の座標、図面上の任意原点などが使われることがあります。
このような座標を変換せずにGeoJSONのcoordinatesへ入れると、地図上では想定外の場所に表示されます。たとえば、メートル単位のX座標、Y座標をそのまま経度、緯度として扱えば、値の範囲がまったく合わないため、地図の表示範囲外になります。構文チェックでは問題が出ないため、原因に気づきにくい点が厄介です。
また、X、Yの順番と経度、緯度の順番を混同することもあります。測量や図面では、Xを南北方向、Yを東西方向として扱う場面があり、一般的な数学座標や画面座標の感覚とも異なる場合があります。GeoJSONに変換する際は、元データのXとYが何を意味しているのかを確認し、経度、緯度の順に正しく並べ替える必要があります。
座標系の違いは、少しのズレではなく、数百メートルから数千キロメートルの大きなズレとして現れることがあります。一方で、測地系や変換条件の違いによって、数十センチから数メートル程度のズレとして現れることもあります。現場の境界、構造物、出来形、点検位置などを扱う場合、この程度のズレでも実務上は大きな問題になります。
高さ情報についても同じです。GeoJSONの座標に高さを含めたとしても、それが標高なのか、現場基準高さなのか、図面上の高さなのかを明確にしなければ、後で解釈がずれます。地図表示だけを目的にする場合は高さが使われないこともありますが、点検記録や3次元的な管理につなげる場合は、高さの基準をpropertiesなどで明記しておく方が安全です。
座標系や単位の問題を避けるには、GeoJSONを作成する前に、元データの座標の意味を確認することが重要です。経度、緯度なのか、平面座標なのか、ローカル座標なのか、単位は度なのかメートルなのか、原点はどこなのかを整理します。構文エラーを直しても位置が合わない場合は、ファイルの書き方ではなく、変換前の前提に原因があると考えるべきです。
GeoJSONを修正するときの実務フロー
GeoJSONのエラーを効率よく直すには、原因を思いつきで探すのではなく、確認順序を決めておくことが有効です。まず最初に行うべきなのは、JSONとして読めるかどうかの確認です。ここでカンマ、括弧、引用符、余計な文字の混入を確認します。JSONとして不正な状態では、GeoJSONとしての確認に進んでも正しい判断ができません。
次に、GeoJSONの大枠を確認します。最上位がFeatureCollectionなのか、単独のFeatureなのか、単独のGeometryなのかを確認し、用途に合っているかを見ます。複数地物を扱う一般的な実務データであれば、FeatureCollectionの中にfeatures配列があり、その中にFeatureが並ぶ形が扱いやすいです。ここで階層がずれている場合は、座標の中身を見る前に構造を修正します。
その次に、各Featureのgeometryを確認します。geometryのtypeがPoint、LineString、Polygonなどの正しい値になっているか、coordinatesの入れ子構造がtypeと一致しているかを見ます。点なら1組の座標、線なら複数座標、面なら閉じたリングというように、形状の条件を確認します。Multi系のジオメトリでは、通常の型よりも入れ子が一段深くなることを意識します。
その後、座標値そのものを確認します。経度、緯度の順になっているか、数値として扱えるか、値の範囲が妥当か、極端な外れ値がないかを見ます。日本周辺のデータであれば、経度と緯度の大まかな範囲を意識するだけでも、座標順のミスや単位の取り違えに気づきやすくなります。座標が平面座標やローカル座標の場合は、GeoJSONに入れる前に変換が必要です。
次にpropertiesを確認します。属性名に揺れがないか、文字列が正しく囲まれているか、数値として扱うべき値が文字列になっていないか、未入力値の扱いが統一されているかを見ます。表示だけなら問題が見えなくても、後工程の検索、分類、集計で不具合が出ることがあるため、属性も必ず確認対象に含めます。
最後に、修正前後の比較を行います。GeoJSONはテキストで管理できるため、どこを変更したかを残しやすい形式です。エラーを直す過程で別の箇所を壊してしまうこともあるため、元ファイルを残したうえで修正版を作成し、変更内容を確認することが大切です。特に現場成果や台帳連携に使うデータでは、修正履歴が分からないと後で原因追跡が難しくなります。
実務では、1つのエラーを直しただけで終わらず、同じ種類のミスが他のFeatureにもないかを確認することが重要です。1箇所で座標順が逆になっていれば、同じ変換処理で作られた他の地物も同じ問題を持っている可能性があります。1つのpropertiesで属性名が違っていれば、別の地物にも表記揺れがあるかもしれません。エラー修正は点の作業ではなく、データ全体の品質確認として進めることが大切です。
現場データを扱うなら記録から見直すことも重要
GeoJSONのエラーは、ファイルを編集する段階だけで発生するわけではありません。元になる現場記録、測量結果、点検メモ、写真位置、図面情報の段階で整理が不十分だと、GeoJSONに変換した後で不具合として表面化します。つまり、GeoJSONの修正だけではなく、元データの取り方や管理方法を見直すことも重要です。
たとえば、点検位置を後からGeoJSON化する場合、位置情報の基準が曖昧だと、点をどこに置くべきか判断できません。写真の撮影位置なのか、対象物の位置なのか、作業者が立っていた位置なのかによって、同じ点検記録でもGeoJSON上の意味が変わります。属性として記録する名称や管理番号も、現場で統一されていなければ、propertiesに入れた後で検索や分類が難しくなります。
面データも同様です。補修範囲、調査範囲、施工範囲などをGeoJSONで表す場合、外周をどの順序で取得したのか、始点と終点が一致しているのか、隣接範囲と重複していないのかを元の段階で確認する必要があります。GeoJSON上でPolygonを閉じることはできますが、元の範囲指定が曖昧であれば、正しい面とは言えません。
現場で取得したデータを後から整理する場合は、位置、属性、写真、メモ、日時が分断されやすくなります。GeoJSONに変換するときに、どの写真がどの地物に対応するのか、どのメモがどの点検箇所に対応するのかを手作業で結び付けると、入力ミスや紐づけミスが発生しやすくなります。構文としては正しいGeoJSONでも、実務上の意味が間違っていれば、成果物としては危険です。
そのため、GeoJSONのエラーを減らすには、作成後のチェックだけでなく、作成前の記録方法も整える必要があります。現場で位置情報を取得する時点で、対象物、撮影位置、メモ、属性、日時を一体で残せれば、後からGeoJSON化するときの迷いが減ります。修正作業も、単に括弧や座標を直すだけでなく、元データとの対応を確認しながら進められます。
GeoJSONのエラー対応に時間がかかっている場合は、ファイル修正だけでなく、現場でどのように位置と属性を記録するかまで見直すことが有効です。位置の基準、座標系、属性名、写真やメモとの紐づけをあらかじめ決めておけば、変換後の修正や確認の負担を減らしやすくなります。GeoJSONを地図表示だけでなく、現場データの共有や台帳整理に使う場合は、入力時点のルールづくりが品質を左右します。
まとめ
GeoJSONのエラーを直すには、まずJSONとして正しいかを確認し、そのうえでGeoJSONとしての構造、ジオメトリ型、coordinatesの入れ子、座標順、propertiesの書き方を順番に確認することが大切です。カンマや括弧の不足、typeの表記ミス、coordinatesの階層違い、Polygonの閉じ忘れ、propertiesの位置や属性名の揺れ、nullや空配列の扱い、座標系や単位の思い込みは、実務で特に起こりやすいミスです。
GeoJSONはテキストで扱えるため修正しやすい一方、1文字の違いや1段の入れ子の違いで読み込み結果が大きく変わります。エラーが出たときは、表示環境のせいにする前に、ファイル単体の構文、構造、座標、属性を切り分けて確認します。特に、地図上に表示されない場合と、表示されるが位置がずれる場合では、疑うべき原因が異なります。
また、GeoJSONの品質は、作成後の修正だけで決まるものではありません。元になる現場記録や位置情報、属性管理が曖昧であれば、構文上は正しいデータでも実務で使いにくくなります。点検、測量、施工範囲、補修範囲、写真記録などをGeoJSONで活用するなら、現場での記録方法から整理することが重要です。
構文ミスを減らし、位置と属性がそろったデータを作ることができれば、GeoJSONは地図表示だけでなく、現場状況の共有、台帳整理、点検記録の確認、施工前後の比較にも活用しやすくなります。GeoJSONのエラー対応をきっかけに、データの作り方と現場記録の流れを見直すことで、後工程の確認作業を安定させやすくなります。