GeoJSON変換で形がずれる時に見直す5つのポイント

GeoJSONに変換した地物を地図上に表示したとき、道路や境界線が少し横にずれる、建物ポリゴンが回転したように見える、面が反転する、穴が埋まってしまう、線が不自然に飛ぶといった問題が起きることがあります。元データでは正しく見えていたのに、GeoJSON化した途端に形が崩れると、変換処理そのものが失敗しているように見えるかもしれません。しかし実務では、原因がファイル形式そのものではなく、座標参照系、経度・緯度の順序、ジオメトリ構造、精度、表示側の解釈などに隠れていることが多くあります。この記事では、GeoJSON変換で形がずれる時に見直したい5つのポイントを、現場で確認しやすい順に解説します。

目次

• GeoJSON変換で形がずれる原因はどこにあるのか

• ポイント1：座標参照系と測地系の違いを確認する

• ポイント2：経度・緯度の順序を取り違えていないか確認する

• ポイント3：ポリゴンのリング方向と穴の扱いを確認する

• ポイント4：座標の丸め・間引き・簡略化による変形を確認する

• ポイント5：表示側の投影変換と読み込み条件を確認する

• 変換前後の検証で見るべき実務チェック項目

• ずれを防ぐための運用ルール

• まとめ：GeoJSONのずれは原因を分けて確認すれば解決しやすい

GeoJSON変換で形がずれる原因はどこにあるのか

GeoJSONは、点、線、面などの地理空間情報をJSON形式で表現するためのデータ形式です。Web地図、現地調査データ、台帳管理、施設管理、施工管理、行政区域の可視化など、さまざまな用途で使われています。人間が中身を確認しやすく、他のシステムとの受け渡しにも使いやすいため、実務担当者が「まずGeoJSONに変換して確認する」という場面も少なくありません。

一方で、GeoJSONに変換したデータが地図上でずれる問題は珍しくありません。特に、測量データ、設計データ、施設台帳、古い地図データ、独自形式の位置情報などをGeoJSONへ変換する場合、変換後の表示位置や形状が元データと一致しないことがあります。ずれ方もさまざまで、全体が数メートルから数百メートルずれる場合もあれば、地物ごとに微妙に形が崩れる場合もあります。点は正しいのにポリゴンだけがおかしい、線は表示されるのに面として認識されない、といった部分的な不具合もあります。

こうした問題を解決するには、まず「位置のずれ」と「形のずれ」を分けて考えることが大切です。位置のずれは、主に座標参照系や測地系の不一致、経度と緯度の順序ミス、表示側での投影変換の問題によって起こります。一方、形のずれは、ポリゴンの構造、リングの向き、座標精度の低下、簡略化処理、複数パートの扱いなどが原因になりやすいです。見た目としては同じ「ずれ」に見えても、原因が異なれば対処方法も変わります。

標準的なGeoJSONでは、座標はWGS 84を前提に、経度、緯度の順で記述します。必要に応じて3番目の値として高さを持たせることもありますが、一般的な平面表示でまず確認すべきなのは水平位置です。元データが平面直角座標系、ローカル座標、独自の測量座標などで管理されている場合は、GeoJSONとして受け渡す前に、利用先が想定する座標参照系へ正しく変換する必要があります。この前処理が曖昧なままファイル形式だけを変換すると、GeoJSONとして文法的に読めても、地図上では意図しない場所に表示されることがあります。

また、GeoJSONは構造がシンプルに見えるため、座標配列を出力できれば変換できたように感じやすい形式です。しかし、ポリゴンには外周と内周の区別があり、複数の面を持つ場合にはジオメトリの型を適切に選ぶ必要があります。線や面の頂点数が多いデータでは、変換時に座標を丸めたり、不要と思われる点を削除したりする処理が入ることもあります。これらの処理が意図せず強く効くと、境界線や道路線形、敷地形状などが元データと違って見える原因になります。

重要なのは、GeoJSON変換で起きるずれを「変換ツールの不具合」と決めつけないことです。多くの場合、元データ、変換設定、出力ファイル、表示環境のどこかで前提が一致していません。次の章からは、実務で特に確認すべき5つのポイントを順に見ていきます。

ポイント1：座標参照系と測地系の違いを確認する

GeoJSON変換で最初に確認したいのが、元データの座標参照系です。座標参照系とは、地球上の位置をどの基準で、どの単位で、どのように座標として表すかを決めるルールです。標準的なGeoJSONの座標は経度と緯度で表されますが、元データが必ず経度緯度で管理されているとは限りません。測量や土木、建設、自治体管理、インフラ管理の現場では、メートル単位の平面座標が使われていることも多くあります。

たとえば、元データの座標値が「139.7, 35.6」のような値であれば経度緯度として直感的に理解しやすいですが、「-12000, -35000」や「350000, 4200000」のような値であれば、経度緯度ではない可能性があります。このような座標値を意味の確認なしにGeoJSONのcoordinatesへ入れても、地図上の正しい位置には表示されません。ファイル形式としてはGeoJSONになっていても、座標の意味が変換されていないためです。

特に注意したいのは、「形式変換」と「座標変換」は別の処理だという点です。元データをGeoJSONに保存するだけでは、座標参照系が自動で変わるとは限りません。平面直角座標系のデータを経度緯度のGeoJSONとして使いたい場合は、元データの座標参照系を正しく指定したうえで、目的の座標参照系へ再投影する必要があります。見た目のファイル拡張子が変わっただけでは、座標値そのものは元のまま残っていることがあります。

測地系の違いにも注意が必要です。測地系は、地球の形や位置の基準をどのように定義するかに関わる考え方です。古いデータや別の測地基準で作成されたデータを現在の地図に重ねると、全体が一定方向にずれることがあります。ずれ量が数メートルから数百メートル程度で、形そのものは大きく崩れていない場合は、測地系の違いを疑う価値があります。建物、道路、境界線が全体的に同じ方向へ移動して見える場合は、変換時に使った座標参照系の指定が正しいか確認してください。

実務では、元データの座標参照系が明記されていないこともあります。その場合は、座標値の範囲、作成元、測量時期、対象地域、過去の管理資料などから推定する必要があります。たとえば、データが日本国内の特定地域だけを対象にしているのに、座標値がメートル単位らしい場合は、その地域に対応する平面座標系が使われている可能性があります。逆に、全国や世界をまたぐデータであれば、経度緯度で管理されている可能性が高くなります。

確認のコツは、いきなり全件を変換しないことです。まずは代表的な数点を取り出し、元データの座標値、変換後の座標値、地図上の表示位置を比較します。既知の地点、たとえば交差点、建物の角、施設入口、境界杭、道路中心線の特徴点など、現実の位置を確認しやすい点を基準にすると原因を切り分けやすくなります。全体が一定方向にずれているのか、地域によってずれ方が変わるのか、形そのものが歪んでいるのかを観察することで、座標参照系の問題かどうかを判断しやすくなります。

GeoJSON変換で形がずれるときは、まず元データの座標参照系を確認し、変換処理で本当に目的の座標系へ変換されているかを見直してください。ファイルの出力形式だけを変えても、座標の前提が合っていなければ、正しい位置にはなりません。

ポイント2：経度・緯度の順序を取り違えていないか確認する

GeoJSONでよくあるミスのひとつが、経度と緯度の順序の取り違えです。一般的な会話では「緯度経度」という順番で表現されることが多いため、つい緯度、経度の順に座標を並べてしまうことがあります。しかし、標準的なGeoJSONの座標配列では、経度、緯度の順で記述します。日本付近であれば、経度はおおむね120台から150台、緯度は20台から40台の範囲に入るため、順序を逆にするとまったく別の場所に表示されます。

たとえば、本来は経度139、緯度35付近にある地点を、緯度35、経度139の順でGeoJSONに書いてしまうと、地図上では想定外の地域に飛んでしまいます。この場合、形が少しずれるというより、データ全体が極端に離れた場所に表示されることが多いです。ただし、表示環境によっては地図の表示範囲外に出てしまい、「何も表示されない」という症状になることもあります。

点データでは経度緯度の逆転に気づきやすいですが、線や面のデータでは、形が奇妙に伸びたり、地球上の意図しない場所を横切るように表示されたりすることがあります。ポリゴンの場合、座標順序だけでなくリング構造や頂点順も絡むため、単純な位置ずれより複雑に見えることがあります。特に、変換処理を自作している場合や、表形式の座標データからGeoJSONを生成している場合は、列の割り当てを必ず確認してください。

実務での確認方法はシンプルです。GeoJSONのcoordinatesを開き、最初の数点を見ます。日本国内のデータであれば、先頭の値が130前後、次の値が30前後になっているかを確認します。もし先頭の値が35前後で、次の値が139前後になっていれば、順序が逆になっている可能性が高いです。海外や広域データの場合も、対象地域の経度と緯度の範囲を事前に把握しておくと判断できます。

注意したいのは、変換元のデータ形式や管理表では、緯度、経度の順で保存されていることがある点です。現地調査アプリ、表計算ファイル、測位機器から出力されたログ、手入力の地点リストなどでは、「lat」「lon」や「latitude」「longitude」の順に並んでいることがあります。これをそのままGeoJSONの座標配列に流し込むと、順序が逆になります。GeoJSONを生成する処理では、入力列の順番ではなく、出力仕様に合わせて経度、緯度へ並べ替える必要があります。

さらに、座標に高さを含める場合も順序に注意が必要です。GeoJSONで高さを持たせる場合は、経度、緯度、高さの順にします。緯度、経度、高さの順にしてしまうと、三次元情報を含むデータでも水平位置が大きくずれます。高さの単位や基準面は別途確認が必要ですが、まず水平位置が正しいかを確認することが先です。

経度緯度の取り違えは、原因としては単純ですが、実務では非常に起こりやすいミスです。特に複数の担当者が関わるデータ加工では、ある工程では緯度経度、別の工程では経度緯度というように、表記の前提が混在しがちです。変換手順書やデータ定義書には、単に「座標」と書くのではなく、どちらが先かを明記することが重要です。

GeoJSON変換後に地物が遠くへ飛ぶ、地図上に出ない、線が不自然に長く伸びるといった症状がある場合は、座標参照系の確認とあわせて、経度と緯度の順序を必ず見直してください。短時間で確認できるうえ、原因であれば修正効果が大きいポイントです。

ポイント3：ポリゴンのリング方向と穴の扱いを確認する

GeoJSONで面データを扱う場合、ポリゴンの構造にも注意が必要です。点や線に比べて、ポリゴンは外周、内周、複数面、閉じたリングといった要素を持つため、変換時の不具合が形のずれや表示崩れとして現れやすくなります。建物、敷地、農地、行政界、作業範囲、立入禁止区域などをGeoJSONに変換する場合は、この章の内容が特に重要です。

ポリゴンは、複数の座標点をつないだ閉じた線で表されます。GeoJSONでは、外側の境界線を表すリングと、穴を表す内側のリングを区別して記述します。穴を持つポリゴンでは、最初のリングが外周、その後のリングが内周として扱われます。中庭のある建物、池を含む公園区域、除外範囲を持つ作業区域などでは、外周だけでなく内周も正しく扱う必要があります。内周を外周として扱ってしまうと、本来は穴として抜けるべき部分が別の面として表示されたり、ポリゴン全体が塗りつぶされたりします。

リング方向とは、座標点をどちら回りに並べるかということです。GeoJSONの標準仕様では、外周リングは反時計回り、穴を表す内周リングは時計回りにすることが求められています。ただし、互換性のため、リング方向がこの規則に従っていないポリゴンを読み込み側が必ず拒否するとは限りません。そのため、ある環境では正しく見えていたポリゴンが、別の環境では穴が埋まる、面が反転する、外周が崩れるといったことが起こる場合があります。

また、ポリゴンの最初の座標と最後の座標が一致していない場合も問題になります。面を構成するリングは閉じている必要があり、最初と最後の位置は同じ値である必要があります。変換時に最後の点が欠落したり、元データの閉じ方が曖昧だったりすると、表示側で自動的に閉じられることがありますが、その結果として意図しない線分が追加されることがあります。特に、細長い敷地や複雑な境界線では、最後の点の扱いが形状に大きく影響する場合があります。

複数の面を持つ地物にも注意が必要です。離れた複数の区域をひとつの属性として管理したい場合、単一のPolygonではなく、複数面を表現できるMultiPolygonを使う必要があります。これを無理にひとつの外周としてつなげてしまうと、本来離れている区域同士が線で結ばれたり、巨大な面として解釈されたりします。行政区域、飛び地、複数敷地を持つ施設、分割された施工範囲などでは、この問題が起こりやすいです。

自己交差も形のずれの原因になります。ポリゴンの外周線が途中で交差していると、どちら側を面として扱うべきかが曖昧になります。元データでは見た目上問題なく見えていても、GeoJSONに変換して面として描画したときに一部が欠けたり、三角形状に塗りつぶされたり、境界がねじれたりすることがあります。自己交差は、手作業で編集したデータや、複数の線を結合して面を作成したデータで発生しやすいです。

ポリゴンの問題を確認するには、まず点の並びと構造を見ます。coordinatesの階層が、点、線、面、複数面で正しく分かれているかを確認してください。ポリゴンなのに線のような配列になっていないか、複数面なのに単一面として扱っていないか、穴のリングが外周の後に正しく入っているかを見ることが大切です。GeoJSONは括弧の階層が深くなるため、見た目だけでは分かりにくいですが、ここを誤ると形状は正しく復元されません。

変換後に面が塗られない、穴が消える、境界線が交差して見える、一部だけ極端に伸びるといった症状がある場合は、ポリゴン構造を重点的に確認してください。位置のずれではなく形の崩れが目立つ場合、座標参照系よりもジオメトリ構造に原因があることがあります。

ポイント4：座標の丸め・間引き・簡略化による変形を確認する

GeoJSONはテキスト形式であるため、頂点数が多いデータをそのまま出力するとファイルサイズが大きくなります。道路線形、河川、等高線、境界線、建物外形、測量点を細かく含むデータでは、座標数が非常に多くなることがあります。そのため、変換時や配信用データ作成時に、座標の丸め、頂点の間引き、形状の簡略化が行われることがあります。これらの処理は表示速度やデータ容量の改善には役立ちますが、設定を誤ると形がずれる原因になります。

座標の丸めとは、小数点以下の桁数を減らす処理です。座標値の桁数は測定精度や不確かさそのものを証明するものではありませんが、数値を丸めれば座標値は変わります。経度緯度の小数点以下をどこまで残すかによって、表示位置や形状に差が出ることがあります。広域の概略図では問題にならない程度でも、建物の角、道路境界、工事範囲、設備位置など、細かな位置確認が必要な用途では大きな問題になります。

丸めの影響は、点よりも線や面で目立つことがあります。単独の点が少し移動するだけなら気づきにくい場合もありますが、ポリゴンの複数の頂点がそれぞれ丸められると、辺の角度や長さが変わり、全体の形がわずかに歪みます。細い通路、狭い敷地、複雑な外周を持つ建物では、丸めによって隣接する点が同じ座標になり、短い辺が消えてしまうこともあります。その結果、ポリゴンが無効になったり、線が折れ曲がったりします。

頂点の間引きも注意が必要です。間引きは、形状を構成する点のうち、重要度が低いと判断された点を削除する処理です。曲線に近い道路や河川を少ない点で表現できるため、見た目を軽くするには有効です。しかし、間引きの許容値が大きすぎると、カーブが直線化され、境界線が実際の位置から外れます。地図の縮尺が小さい場合は問題が目立たなくても、拡大すると元の形との差が分かります。

簡略化処理では、地物同士の関係が崩れることもあります。たとえば、隣接するポリゴンを別々に簡略化すると、本来ぴったり接していた境界線の間に隙間ができたり、逆に重なりが発生したりします。行政界や区画境界、筆界、施設境界のように、隣接関係が重要なデータでは、個別の地物を単純に簡略化するだけでは不整合が生じる可能性があります。

さらに、座標精度の扱いは用途によって適切な水準が異なります。広報用の概略地図、エリア検索用の範囲データ、現地作業で使う設備位置、測量成果に近い管理データでは、求められる精度が違います。GeoJSONを軽くしたいという理由だけで一律に小数点以下を削ると、現場確認や意思決定に使えないデータになることがあります。逆に、精度が不要な用途で過剰な頂点数を保持すると、読み込みが遅くなり、利用者にとって扱いにくいデータになります。

変換後に「全体の場所は合っているが、境界線が少し違う」「カーブが粗い」「角が丸まった、または欠けた」「隣の区画と隙間ができた」と感じる場合は、丸めや簡略化の設定を確認してください。元データと変換後データを重ねて、頂点数、座標桁数、境界線の差分を見ると原因をつかみやすくなります。

実務では、用途別に変換設定を分けることが有効です。現地作業や詳細確認に使うGeoJSONでは必要な座標精度を保ち、Web表示用や広域プレビュー用では必要に応じて軽量化する、といった運用です。ただし、軽量化したデータを正式な位置情報として再利用しないよう、ファイル名や属性情報で用途を明確にしておくことが大切です。

GeoJSON変換で形が少しずれる場合、座標参照系だけでなく、精度を落とす処理が入っていないかを必ず確認してください。特に自動処理の中に丸めや簡略化が組み込まれている場合、担当者が気づかないうちに形状が変わっていることがあります。

ポイント5：表示側の投影変換と読み込み条件を確認する

GeoJSONファイル自体に大きな問題がなくても、表示する側の設定や解釈によって、形がずれて見えることがあります。実務では、変換後のGeoJSONを地図ビューア、業務システム、Web地図、社内ツール、検証用の表示環境などで確認することが多いですが、それぞれが座標やジオメトリをどのように扱うかは同じとは限りません。そのため、ファイルだけを見て正しいと判断せず、表示側の前提も確認する必要があります。

代表的なのは、表示側が想定している座標参照系と、GeoJSON内の座標値の前提が一致していないケースです。標準的なGeoJSONの座標はWGS 84の経度緯度として扱われますが、表示側が内部的に別の投影座標へ変換して描画する場合があります。この変換が正しく行われていれば問題ありませんが、入力座標を別の座標系と誤解したり、既に変換済みの座標を再度変換したりすると、位置がずれます。

また、地図タイルや背景図との重ね合わせでもずれが起こります。GeoJSON側が正しくても、背景図が古い、または別の基準で作られている場合、重ねたときにずれて見えることがあります。特に、道路や建物が更新された地域、造成地、再開発エリア、災害後に地形が変わった場所では、背景図との不一致がデータの誤りのように見えることがあります。背景図を絶対的な正解とせず、測量成果や現地確認結果と照合する視点が必要です。

表示倍率による見え方の違いにも注意してください。低いズームレベルでは、表示側が自動的に簡略化した図形を描く場合があります。広域表示では正しく見えないのに、拡大すると正しい位置に戻る、またはその逆が起こる場合は、表示側の描画最適化やタイル化処理が影響している可能性があります。GeoJSONそのものを直接表示しているのか、いったん別の形式やタイルに変換したものを表示しているのかも確認したいポイントです。

読み込み時のエラーを無視していないかも重要です。GeoJSONの構文に小さな問題があると、表示側が一部の地物だけを読み飛ばしたり、壊れた部分を自動補正したりすることがあります。自動補正は便利ですが、補正結果が意図通りとは限りません。たとえば、閉じていないポリゴンを自動で閉じる、無効な座標を飛ばす、認識できない属性を無視する、といった処理が行われると、表示上の形が元データと変わることがあります。

文字コードや数値の扱いも間接的に影響することがあります。座標値の小数点記号、桁区切り、空文字、欠損値、文字列として保存された数値などが混在していると、変換や読み込みの過程で座標が正しく解釈されない場合があります。特に表形式のデータからGeoJSONを作る場合、数値列に余計な文字が入っていないか、空欄がゼロとして扱われていないかを確認してください。

表示側の問題を切り分けるには、複数の環境で同じGeoJSONを確認する方法が有効です。ある環境だけでずれる場合は、表示側の設定や読み込み処理に原因がある可能性が高くなります。逆に、どの環境でも同じようにずれる場合は、GeoJSONの座標値やジオメトリ構造に問題がある可能性が高いです。さらに、変換前の元データ、変換後のGeoJSON、表示結果をそれぞれ分けて確認すると、どの段階でずれが発生したのかを把握しやすくなります。

GeoJSON変換で問題が起きたときは、ファイルの中身だけでなく、表示側の投影変換、背景図、ズームレベル、読み込みログ、エラー処理まで含めて確認してください。見た目のずれは、変換そのものではなく、表示時の解釈によって発生していることもあります。

変換前後の検証で見るべき実務チェック項目

GeoJSON変換のずれを防ぐには、変換後に地図へ表示して終わりにするのではなく、変換前後の検証手順を用意しておくことが重要です。特に、業務で繰り返しGeoJSONを扱う場合や、複数の担当者がデータを受け渡す場合は、確認ポイントを標準化しておくことでトラブルを減らせます。

まず確認したいのは、座標値の範囲です。対象地域に対して、経度と緯度が妥当な範囲に入っているかを見ます。日本国内のデータであれば、経度と緯度の値が大きく外れていないか、経度緯度の順序が逆になっていないかを確認します。点データなら数件を目視で確認できますが、線や面ではすべての頂点に対して極端な値が混ざっていないかを見ることも大切です。ひとつでも異常な座標があると、線が遠くへ飛んだり、表示範囲が異常に広がったりします。

次に、元データと変換後データの重ね合わせを行います。可能であれば、同じ座標参照系にそろえたうえで、変換前後の形状を比較してください。全体が同じ方向へずれているのか、一部だけが崩れているのか、頂点数が変わっているのか、隣接する地物の関係が保たれているのかを確認します。このとき、背景地図だけを基準にするのではなく、元データとの比較を重視することが大切です。背景地図が最新でない場合、誤った判断につながります。

ジオメトリ型の確認も欠かせません。点として出すべきデータが線になっていないか、線として扱うべきデータが面になっていないか、単一面と複数面の区別が正しいかを確認します。属性情報では同じ分類に見えても、実際の形状は複数パートに分かれていることがあります。変換時に型を固定してしまうと、一部の地物だけが正しく表現されないことがあります。

ポリゴンの場合は、閉じたリング、穴の扱い、自己交差、重複、微小な隙間を確認します。特に、敷地境界や行政界のように面積計算や範囲判定に使うデータでは、見た目だけでなく、面として有効かどうかが重要です。表示上はそれらしく見えても、内部的には無効なポリゴンになっている場合、検索、集計、重なり判定などで問題が出ます。

属性情報と形状の対応も確認してください。GeoJSONでは、地物ごとにgeometryとpropertiesを持つ構造が一般的です。変換時に行の並びがずれたり、複数パートの分割で属性が欠落したりすると、形状は正しくても意味が変わってしまいます。たとえば、施設名と位置、管理番号と区画、施工範囲と作業種別が対応していなければ、地図としては表示できても業務データとしては使えません。

検証では、全件目視だけに頼らないことも大切です。件数、ジオメトリ型の内訳、座標範囲、面積や延長の概算、無効ジオメトリ数、空のgeometry数などを確認すると、目視では見逃しやすい問題を発見できます。特に大量データでは、代表地点の確認と機械的なチェックを組み合わせることで、効率よく品質を確認できます。

最終的には、変換結果を実際の利用シーンで確認します。現地調査で使うなら現地の測位結果と重ねる、台帳管理で使うなら管理番号で検索して対象地物が正しく表示されるかを見る、Web公開用なら想定されるズームレベルで見た目を確認する、といった形です。GeoJSONは汎用的な形式ですが、正しいかどうかは利用目的によっても変わります。必要な精度、表示速度、属性の完全性を用途ごとに確認してください。

ずれを防ぐための運用ルール

GeoJSON変換のずれは、発生してから原因を探すより、日常の運用で防ぐほうが効率的です。特に、毎月の更新データ、現場からの収集データ、複数部署で共有する空間情報、外部に渡す納品データなどでは、変換ルールを明確にしておくことが品質維持につながります。

最初に決めるべきなのは、標準とする座標参照系です。元データがどの座標系で作成され、GeoJSON出力時にどの座標系へ変換するのかを明文化します。「地図で使える形式にする」だけでは不十分です。経度緯度にするのか、測地系は何を前提にするのか、高さ情報を含めるのか、含める場合は単位と基準をどうするのかまで決めておくと、後工程で迷いにくくなります。

次に、変換手順を固定します。担当者ごとに違う方法で変換していると、丸め桁数、簡略化設定、ジオメトリ修正の有無がばらつきます。その結果、同じ元データから作ったはずのGeoJSONでも、担当者によって形状が違うという問題が起こります。変換処理はできるだけ手順化し、入力条件、変換設定、出力条件、検証方法をセットで管理することが望ましいです。

ファイル命名や属性にも工夫が必要です。GeoJSONファイルに、用途、作成日、座標系、精度、簡略化の有無が分かる情報を持たせておくと、後から原因を追いやすくなります。たとえば、詳細確認用と表示軽量化用のデータが混在していると、軽量化済みのデータを正式な解析に使ってしまう危険があります。ファイル名やメタ情報で区別できるようにしておくことが重要です。

元データを保管しておくことも忘れてはいけません。GeoJSONは扱いやすい形式ですが、変換後の成果物だけを残していると、ずれが見つかったときに原因を調べにくくなります。元データ、変換条件、変換日時、担当者、検証結果を一緒に残しておけば、問題が起きたときに再現性を確保できます。特に、外部から受け取ったデータを変換する場合は、受領時点の状態を保管しておくと安心です。

自動チェックの導入も有効です。GeoJSONを出力したら、座標範囲、空のgeometry、無効なポリゴン、極端に大きな面積、異常に長い線、属性欠損などを確認する仕組みを用意します。すべてを人の目で見るのは大変ですが、明らかな異常値を先に検出できれば、確認作業の負担を減らせます。現場でよく起きるミスに合わせてチェック項目を増やしていくと、運用に合った品質管理ができます。

また、データを受け渡す相手との認識合わせも大切です。GeoJSONを受け取る側が、どの座標系を想定しているのか、どの程度の精度が必要なのか、ポリゴンの穴や複数面を扱えるのかを事前に確認します。送り手が正しいと思っていても、受け手のシステムが別の前提で読み込めば、表示はずれます。仕様書や受け渡しルールに、座標順序、ジオメトリ型、文字コード、属性名、欠損値の扱いなどを記載しておくとトラブルを防ぎやすくなります。

運用ルールは一度作って終わりではありません。新しいデータ種別が増えたとき、表示環境が変わったとき、現場の測位方法が変わったときには、変換ルールも見直す必要があります。特に、スマートフォンや外部測位機器を使って現地データを収集する場面では、取得時の精度、補正方法、記録形式、時刻情報などが後工程に影響します。現地で正しく取得し、変換時に正しく扱い、表示時に正しく解釈するという一連の流れで品質を考えることが重要です。

まとめ：GeoJSONのずれは原因を分けて確認すれば解決しやすい

GeoJSON変換で形がずれる問題は、見た目だけでは原因を判断しにくいものです。しかし、確認すべきポイントを分けて見ていけば、原因の多くは切り分けられます。まずは、元データの座標参照系と測地系が正しいかを確認します。次に、GeoJSONの座標配列が経度、緯度の順になっているかを見ます。面データであれば、ポリゴンのリング方向、穴、複数面、自己交差を確認します。さらに、変換時の丸めや簡略化によって形状が変わっていないかを見直し、最後に表示側の投影変換や背景図との重ね合わせ条件を確認します。

大切なのは、GeoJSONという形式だけに注目しすぎないことです。GeoJSONは位置情報を受け渡すための入れ物であり、その中に入る座標値やジオメトリ構造が正しくなければ、正しい地図表現にはなりません。逆に、GeoJSON自体が標準的な構造で作られていても、表示側の前提が違えばずれて見えることがあります。元データ、変換処理、出力結果、表示環境を一連の流れとして確認することが、実務でのトラブル解決につながります。

現場で使う位置情報は、少しのずれが判断ミスにつながることがあります。建物や設備の位置、作業範囲、境界線、点検対象、施工記録などをGeoJSONで扱う場合は、変換後の見た目だけでなく、座標の意味、精度、属性との対応まで確認することが重要です。特に、現地で取得したデータをすばやく共有したい場合や、複数人で同じ地図情報を扱う場合は、取得から変換、確認、共有までを安定した流れにしておく必要があります。

GeoJSONのずれを減らすには、変換後の表示確認だけでなく、元データの座標参照系、座標順序、ポリゴン構造、丸めや簡略化の設定、表示環境の前提を記録しておくことが大切です。用途ごとに必要な精度と検証方法を決めておけば、問題が起きたときも原因を追いやすくなります。GeoJSONを安全に活用するためには、取得、変換、検証、共有までをひとつの品質管理プロセスとして扱うことが重要です。