GeoJSONをogr2ogrで変換する時のつまずき対策6つ

GeoJSONは、地図上の点・線・面などの位置情報を扱う実務でよく使われる形式です。JSONをベースにしたテキスト形式なので、人が読んでも構造を追いやすく、データ連携、可視化、現地調査データの整理、区域データの受け渡しなど、さまざまな場面で登場します。一方で、別形式の地理空間データをGeoJSONへ変換したり、GeoJSONを別の形式へ変換したりする作業では、思った以上につまずきが起こります。

特にogr2ogrを使った変換では、コマンド自体は短く見えても、文字コード、座標参照系、ジオメトリの不整合、属性名、ファイルサイズ、文字列の扱いなど、実務上の落とし穴がいくつもあります。エラーが出ればまだ分かりやすいのですが、もっと厄介なのは「変換は完了したように見えるのに、地図に重ねると位置がずれる」「属性が欠けている」「一部の図形だけ表示されない」といった静かな失敗です。

この記事では、GeoJSONをogr2ogrで変換する時に起こりやすいつまずきを6つに整理し、それぞれの原因と対策を実務目線で解説します。単にコマンド例を並べるのではなく、なぜその問題が起きるのか、確認時にどこを見るべきか、再発を防ぐにはどう考えればよいかまで掘り下げます。

目次

• GeoJSON変換で最初に確認すべき前提

• 対策1：座標参照系の指定ミスを防ぐ

• 対策2：文字化けと属性名の崩れを防ぐ

• 対策3：ジオメトリ不正による変換失敗を防ぐ

• 対策4：大きすぎるGeoJSONで処理が重くなる問題を防ぐ

• 対策5：属性型とNULL値の変換差を見落とさない

• 対策6：出力結果を目視だけで判断しない

• GeoJSON変換を安定させる実務フロー

• まとめ：変換作業はコマンドより確認設計が大切

GeoJSON変換で最初に確認すべき前提

GeoJSONを扱う時にまず意識したいのは、GeoJSONは単なる地図ファイルではなく、位置情報を持った構造化データだという点です。点、線、面といった図形情報に加えて、名称、種別、管理番号、更新日、調査メモなどの属性情報を含められます。そのため、変換時には「地図として開けるか」だけでなく、「図形が正しいか」「属性が欠けていないか」「座標の意味が変わっていないか」を確認する必要があります。

ogr2ogrは、地理空間データの形式変換で広く使われるコマンドラインツールです。入力形式と出力形式を指定し、必要に応じて座標変換、属性の抽出、条件指定、文字コード指定、ジオメトリ処理などを行えます。たとえば、ある形式のデータをGeoJSONに変換する場合、基本形としては出力形式、出力ファイル、入力ファイルを指定します。とてもシンプルに見えますが、実際の現場ではこの基本形だけで安全に変換できるケースばかりではありません。

GeoJSONで検索している実務担当者の場合、目的は「仕様を学ぶこと」だけではなく、「手元のデータを今すぐ使える形にしたい」というケースが多いはずです。自治体区域、道路中心線、建物ポリゴン、調査地点、設備台帳、境界線、現場写真の位置情報など、扱うデータの性質はさまざまです。元データの作成経緯も一様ではなく、過去に別形式から変換されたもの、手入力で修正されたもの、複数部署で受け渡されたもの、座標参照系が明記されていないものなどが混ざります。

このような状況では、変換コマンドを一発で決めるよりも、変換前後の確認ポイントをあらかじめ持っておくことが重要です。GeoJSON変換で起こる問題の多くは、ogr2ogrそのものの使い方だけでなく、元データの前提が曖昧なまま変換してしまうことから始まります。つまり、つまずき対策の第一歩は「このデータはどの座標で作られ、どの属性を持ち、どの粒度で使うのか」を確認することです。

特に注意したいのが、GeoJSONの座標の前提です。RFC 7946に沿ったGeoJSONでは、地理座標の座標配列は経度、緯度の順で扱われ、座標参照系はWGS 84系の経緯度を前提にします。実務では「EPSG:4326」と表現されることも多いですが、表計算や現場メモでは緯度、経度の順で扱われることも多いため、列の順番とGeoJSON内の座標順を混同しないようにします。

さらに、GDALのGeoJSONドライバでは、RFC 7946に沿った出力を明示したい場合にレイヤ作成オプションを使う場面があります。変換先のシステムが「RFC 7946準拠のGeoJSON」を求めているのか、従来仕様のGeoJSONでもよいのかは、受け渡し前に確認しておくと安全です。ここを曖昧にすると、座標参照系、ポリゴンの向き、bboxの解釈などで差が出ることがあります。

また、GeoJSONはテキスト形式なので一見扱いやすいものの、巨大なポリゴンや大量の点データをそのまま入れると、ファイルサイズが大きくなり、表示や配信で問題が出やすくなります。ファイルが開けることと、業務システムや閲覧環境で快適に使えることは別問題です。変換の目的が保管なのか、分析なのか、共有なのか、表示なのかによっても最適な出力は変わります。

この記事では、このような前提を踏まえて、ogr2ogrでGeoJSONを変換する際に特に頻出する6つのつまずきを扱います。どれも実務で起こりやすく、しかも一度原因を理解すれば予防しやすいものです。コマンドを覚えるだけではなく、問題の切り分け方を身につけることで、GeoJSON変換の安定度は大きく上がります。

対策1：座標参照系の指定ミスを防ぐ

GeoJSONをogr2ogrで変換する時に最も多いトラブルのひとつが、座標参照系の指定ミスです。変換後のデータを地図上に表示した時、位置が大きくずれる、上下左右が反転したように見える、まったく別の地域に表示されるといった問題は、まず座標参照系を疑うべきです。

座標参照系とは、地球上の位置を数値で表すための基準です。緯度経度で表す場合もあれば、平面直角座標のようにメートル単位で表す場合もあります。元データがどの座標参照系で作られているかを正しく理解しないままGeoJSONへ変換すると、数値はそのまま出力されているのに、表示側では別の意味として解釈されてしまいます。その結果、見た目には位置ずれとして現れます。

ogr2ogrでは、入力データの座標参照系を「どう解釈するか」と、出力データの座標参照系へ「どう変換するか」を分けて理解する必要があります。元データに座標参照系の情報が正しく埋め込まれている場合は、出力先の座標参照系を指定するだけで済むことがあります。しかし、元データに座標参照系情報がない場合や、誤った情報が付いている場合は、入力側の座標参照系を明示したうえで変換する必要があります。

ここで起こりやすい誤解は、「座標参照系を指定したから変換された」と思い込むことです。`-s_srs` は入力側の座標参照系を上書きして解釈するための指定、`-t_srs` は出力側へ再投影・変換するための指定です。また、`-a_srs` は出力に座標参照系を割り当てますが、座標値そのものを変換する指定ではありません。この違いを曖昧にしたまま作業すると、二重変換や未変換が起こります。

たとえば、元データがすでに緯度経度なのに、別の座標参照系から緯度経度へ変換する指定をしてしまうと、本来不要な変換が行われ、位置が崩れる可能性があります。逆に、元データがメートル単位の平面座標なのに、緯度経度として扱ってしまうと、数値の桁や範囲が合わず、地図上ではあり得ない位置に表示されることがあります。

対策としては、まず変換前に元データの座標値を数件確認します。座標の数値が経度や緯度として自然な範囲にあるか、メートル単位のような大きな数値になっているかを見るだけでも、初期判断に役立ちます。日本国内の緯度経度であれば、経度と緯度の値にはおおよその範囲があります。一方、平面座標系では、緯度経度とは異なる桁の数値が出ることが一般的です。

次に、元データに付属する定義ファイルや仕様書、受け渡し時の説明を確認します。ファイル名やフォルダ名に座標参照系らしき情報が含まれていることもありますが、ファイル名だけを信じるのは危険です。過去に変換されたデータでは、ファイル名だけが残り、中身が別の座標参照系に変わっていることもあります。必ず実際の座標値と表示結果を合わせて確認します。

変換後は、必ず既知の背景地図や基準となるデータと重ねて確認します。市区町村界、道路、河川、既知の施設点など、位置が明確なデータと重ねると、ずれの有無を判断しやすくなります。単独でGeoJSONを開いて「それらしい形に見える」だけでは不十分です。形が正しくても場所が違うことは珍しくありません。

また、GeoJSONでは座標の並び順にも注意が必要です。地理座標では経度、緯度の順で記録しますが、表形式の元データでは緯度、経度の順に列が並んでいることがあります。点データをGeoJSONへ変換する際に列指定を間違えると、日本のデータが海外や海上に飛ぶような結果になります。座標参照系の問題に見えて、実際は列の取り違えだったというケースもあります。

座標参照系のつまずきを防ぐには、コマンドを組む前に「元データの座標は何か」「出力先では何が求められるか」「指定は解釈なのか変換なのか」を整理することが大切です。特に複数人で作業する場合は、変換時に使った座標参照系の前提を作業メモに残しておくと、後から原因調査をする時に大きな助けになります。

対策2：文字化けと属性名の崩れを防ぐ

GeoJSON変換で次によく起こるのが、文字化けや属性名の崩れです。地図上の位置は正しく表示されているのに、名称、住所、分類、備考などの日本語属性が読めない文字列になることがあります。現場では、図形の位置ばかりに目が行きがちですが、業務利用では属性情報こそ重要なことが多いため、文字化けは大きな問題です。

文字化けの原因は、入力データの文字コードと、変換時に想定される文字コードが一致していないことです。GeoJSONはJSONをベースにしているため、公開・連携を前提にする場合はUTF-8で扱うのが安全です。一方で、元データ側では別の文字コードが使われている場合があります。特に古いデータ、業務システムから出力されたデータ、表計算ソフトを経由したデータ、外部委託先から受け取ったデータでは、文字コードの前提が統一されていないことがあります。

ogr2ogrで変換した結果、エラーが出ずにファイルが作成されることもあります。この場合、変換そのものは成功しているように見えますが、属性値を確認すると文字化けしていることがあります。さらに厄介なのは、すべての文字が化けるとは限らない点です。英数字は読めるが日本語だけ崩れる、特定の記号だけ化ける、長音や丸付き数字のような文字だけ欠けるといった部分的な問題もあります。

対策としては、まず入力データの文字コードを確認します。データ提供元の仕様書があればそこを見ます。仕様書がない場合は、属性値を直接確認し、代表的な日本語文字列が正しく読めるかを調べます。地名、人名、施設名、備考欄のように日本語が含まれる列を優先して見ると、問題に気づきやすくなります。

変換時には、入力側の文字コードを明示する指定が有効な場合があります。たとえばShapefileでは、`.cpg`ファイルやDBF側のコードページ情報をもとに文字コードが解釈されますが、情報がない、または実データと合っていない場合は、GDALのオープンオプションや設定で解釈を補う必要があります。同じコマンドでも、別の端末や別の環境で実行すると結果が変わる可能性があるため、業務で再現性を求めるなら文字コードの前提を明示する方が安全です。

属性名の崩れにも注意が必要です。GeoJSON自体は属性名に比較的柔軟ですが、変換元や変換先の形式には制約があることがあります。代表的な例として、ShapefileのDBF属性ではフィールド名の長さや扱える型に制限があり、元データの時点ですでに列名が短縮されている場合があります。GeoJSONに変換した後で属性名が短くなって見える場合、GeoJSONへの変換時に起きた問題ではなく、前段の形式制約が原因であることもあります。

たとえば、管理番号、管理番号枝番、管理番号旧、管理番号新のような列がある場合、変換前の形式によっては属性名の長さ制限や文字種制限の影響で、似た名前に変換されることがあります。変換後に「GeoJSONがおかしい」と考える前に、元データ側の属性名が本当に正しく残っているかを確認する必要があります。

また、日本語の属性名をそのまま使うか、英数字中心の属性名に整えるかも実務上の判断ポイントです。人が読むだけなら日本語属性名は分かりやすいですが、システム連携や自動処理を考えると、英数字と区切り文字で統一した属性名の方が扱いやすい場合があります。どちらが正解というより、利用目的に合わせて決めることが大切です。ただし、変換途中で意図せず属性名が変わるのは避けるべきです。

文字化け対策では、変換後のGeoJSONをテキストとして開き、属性値の一部を確認することも有効です。地図表示ツール上でポップアップ表示だけを確認すると、表示側が自動補正している場合や、一部の属性しか見えていない場合があります。GeoJSONの中身を直接確認すれば、文字列が正しく保存されているかをより確実に判断できます。

さらに、変換後の属性数も確認しましょう。元データに存在する列が変換後に減っていないか、空欄が増えていないか、数値だったものが文字列として扱われていないかを見ます。文字化けだけでなく、属性の欠落や型の変化も同時に確認することで、後工程でのトラブルを防げます。

文字コードや属性名の問題は、見た目の地図表示だけでは発見が遅れやすい領域です。位置が正しいから大丈夫と判断せず、属性情報まで含めて変換品質を見ることが、GeoJSONを実務で安定利用するための基本です。

対策3：ジオメトリ不正による変換失敗を防ぐ

GeoJSON変換では、ジオメトリ不正も大きなつまずきになります。ジオメトリとは、点、線、面などの図形情報そのものです。点であれば座標の組、線であれば座標列、面であれば外周や内側の穴を表す座標列が含まれます。このジオメトリに不整合があると、変換時にエラーが出たり、変換後に一部の図形が欠けたり、表示時におかしな形になったりします。

ジオメトリ不正の例としては、面が自己交差している、外周線が閉じていない、穴の向きや位置が不適切、線の頂点数が不足している、空のジオメトリが混ざっている、複数図形の型が混在している、といったものがあります。たとえば、ポリゴンの境界線がリボンのように交差している場合、人間の目では区域らしく見えても、データ構造としては正しい面と判断できないことがあります。

実務では、こうした不正ジオメトリが思った以上に混ざります。手作業で編集された区域データ、古い台帳から変換されたデータ、複数のデータを結合したもの、細かい境界を持つポリゴン、重複や隙間を含むデータなどでは特に注意が必要です。元データを作成した時点では問題が表面化していなくても、GeoJSONへ変換したり、別の表示環境で読み込んだりした時に初めて問題になることがあります。

ogr2ogrで変換する際、ジオメトリ不正があると警告やエラーが表示されることがあります。ただし、すべての問題が明確なエラーとして止まるわけではありません。一部の図形だけがスキップされる、変換は完了するが後で表示できない、処理環境によって挙動が変わる、といったケースもあります。そのため、変換ログを確認する習慣が重要です。コマンドが終了したかどうかだけでなく、途中に警告が出ていないかを見ます。

対策の第一歩は、変換前にジオメトリの妥当性を確認することです。すべての地物が同じジオメトリ型か、空の図形が含まれていないか、極端に小さい面や異常に長い線がないかを確認します。特に、面データを扱う場合は自己交差や閉じ忘れが問題になりやすいため、事前検査を行う価値があります。

次に、変換時にジオメトリ型を明示することも有効です。入力データに点、線、面が混在している場合、GeoJSONとしては複数型を扱える場面もありますが、後工程のシステムや解析処理では単一の型を期待していることがあります。たとえば、区域データとして面だけを扱うつもりなのに、誤って線データや空ジオメトリが混ざっていると、集計や面積計算で問題が出ます。

ポリゴンとマルチポリゴンの違いにも注意します。単一の面を表すデータと、複数の面をひとつの地物として表すデータでは、ジオメトリ型が異なります。離島を含む行政区域や、飛び地のある管理区域などでは、複数の面がひとつの地物にまとまることがあります。このようなデータでは、必要に応じて `PROMOTE_TO_MULTI` のような指定で型をそろえる考え方が役立ちます。一方で、無理に単一ポリゴンへ変換すると形状が欠けたり、不正な図形になったりする可能性があります。

ジオメトリ修復を行う場合は、修復によって形状が変わる可能性を理解しておく必要があります。ogr2ogrにはジオメトリを妥当な形に近づけるためのオプションがありますが、不正な面を自動修復すると、自己交差が解消される代わりに、面が分割されたり、一部が消えたりすることがあります。これは修復が悪いというより、元データの不整合を機械的に解釈した結果です。重要な境界データや法的な意味を持つ区域データでは、自動修復後に必ず目視確認と属性確認を行うべきです。

線データでは、極端に短い線や同じ座標が連続するデータにも注意が必要です。点データでは、座標が空欄のレコードや、数値として解釈できない文字列が混ざっていることがあります。点、線、面のどれであっても、ジオメトリの問題は属性テーブルだけを見ていても分かりません。地図表示、件数確認、エラーログ確認を組み合わせることが大切です。

ジオメトリ不正によるつまずきは、変換作業そのものよりも、元データの品質管理に近い問題です。ogr2ogrは変換を助けてくれますが、元データの意味を完全に判断してくれるわけではありません。だからこそ、変換前に検査し、必要に応じて修復し、変換後に差分を確認する流れを作ることが重要です。

対策4：大きすぎるGeoJSONで処理が重くなる問題を防ぐ

GeoJSONは扱いやすい形式ですが、大容量データには注意が必要です。変換自体は成功しているのに、ファイルを開くのに時間がかかる、地図表示が固まる、送受信に時間がかかる、ブラウザで表示できない、共有先で読み込めないといった問題が起こることがあります。これはGeoJSONがテキスト形式であり、座標列や属性情報がそのまま展開されるためです。

特にポリゴンデータでは、境界線の頂点数が多いほどファイルサイズが大きくなります。海岸線、道路境界、建物外形、細かく分割された区域などは、見た目以上に多くの座標を持っていることがあります。元データでは効率的に管理されていても、GeoJSONに変換すると座標がテキストとして展開されるため、サイズが一気に大きくなる場合があります。

点データでも油断はできません。数万件、数十万件の点に多数の属性が付いている場合、GeoJSONはかなり大きくなります。さらに、各地物に長い説明文や不要な属性が含まれていると、地図表示では使わない情報のためにファイル全体が重くなります。変換後の使い道が可視化であれば、すべての属性を含める必要がないこともあります。

対策としては、まずGeoJSONを何に使うのかを明確にします。保管やデータ交換が目的なのか、地図上で軽快に表示することが目的なのか、解析処理に使うのかで、適切なデータ量は変わります。表示用であれば、必要な範囲だけに切り出す、必要な属性だけを残す、形状を簡略化する、といった処理が効果的です。

範囲の切り出しは、全国データや広域データから特定の地域だけを使いたい場合に有効です。たとえば、ある市区町村内の設備だけを表示したいのに、都道府県全域や全国のデータをGeoJSONとして読み込ませるのは効率的ではありません。必要な範囲に絞ったGeoJSONを作成すれば、ファイルサイズも表示負荷も大きく下がります。

属性の絞り込みも重要です。元データには、管理用の内部コード、更新履歴、備考、予備列、過去システム用の項目など、表示や分析には不要な属性が含まれていることがあります。GeoJSONに変換する段階で必要な属性だけを出力すれば、ファイルサイズを抑えられ、利用者にとっても分かりやすいデータになります。特に、同じ情報が複数列に重複している場合や、空欄が多い列は見直しの対象です。

形状の簡略化は、ポリゴンやラインで効果があります。細かすぎる頂点を減らすことで、ファイルサイズと描画負荷を下げられます。ただし、簡略化には注意が必要です。簡略化しすぎると、境界がずれたり、細い道路や小さな区域が消えたり、隣接ポリゴンとの整合が崩れたりします。表示縮尺に応じた簡略化であれば有効ですが、正確な面積計算や境界確認に使うデータには向かない場合があります。

また、座標の小数桁数もファイルサイズに影響します。必要以上に細かい桁数を持つ座標は、用途によっては過剰です。もちろん、位置精度が重要な業務では安易に丸めるべきではありません。しかし、広域の概略表示や簡易な閲覧用途であれば、必要な精度に合わせて座標の桁数を調整することで、データを軽くできる場合があります。特にテキスト形式では、座標の桁数がファイルサイズに直結しやすい点を意識しておくとよいでしょう。

大容量GeoJSONで見落としがちなのが、変換後のファイルをそのまま共有してしまうことです。作業者の環境では開けても、受け取り側の環境ではメモリや処理性能の違いで開けないことがあります。また、ネットワーク越しに配信する場合は、読み込み時間が利用体験に直結します。GeoJSONは便利ですが、すべてをひとつのファイルに詰め込むほど使いやすくなるわけではありません。

データを分割する考え方も有効です。地域単位、レイヤー単位、用途単位でファイルを分けると、必要なものだけ読み込めます。たとえば、点データ、線データ、面データを別々のGeoJSONにするだけでも、後工程で扱いやすくなります。更新頻度が異なるデータを分けておけば、毎回すべてを再変換する必要もなくなります。

GeoJSONの重さは、変換時には成功しているように見えるため、後工程で問題になりがちです。変換直後にファイルサイズ、地物数、頂点数、属性数を確認し、用途に対して過剰でないかを判断する習慣を持つことで、表示や共有のトラブルを大きく減らせます。

対策5：属性型とNULL値の変換差を見落とさない

GeoJSONをogr2ogrで変換する時、座標や図形に比べると見落とされやすいのが属性型とNULL値の扱いです。属性型とは、ある列が文字列なのか、整数なのか、小数なのか、日付なのかといったデータの種類です。NULL値は、値が存在しないことを示す状態です。これらは地図上の見た目には直接表れにくいものの、検索、集計、分類表示、システム連携では大きな影響を持ちます。

たとえば、管理番号の列が数値として扱われると、先頭のゼロが消えることがあります。現場では「00123」と「123」は別の意味を持つことがありますが、数値として解釈されると同じように扱われてしまいます。また、郵便番号、区域コード、設備番号、調査票番号なども、見た目は数字でも実務上は文字列として扱うべき場合があります。

逆に、本来は数値として集計したい面積、延長、標高、数量、点検回数などが文字列として出力されると、後工程で並べ替えや集計がうまくいかないことがあります。文字列としての並べ替えでは、数値の大小とは異なる順序になる場合があります。地図上では問題なく表示されていても、集計表を作る段階で異常に気づくことがあります。

日付もつまずきやすい属性です。元データでは日付型として管理されていても、GeoJSON変換後には文字列として出力されることがあります。日付の表記形式が統一されていない場合、後工程で期間検索や並べ替えができないことがあります。年、月、日の順序や区切り文字が混在していると、人間には読めても機械処理では扱いにくくなります。

NULL値の扱いも重要です。元データでNULLだった項目が、変換後または読み込み側で空文字、ゼロ、属性省略のように見えることがあります。これらは似ているようで意味が異なります。NULLは「値が存在しない」、空文字は「空の文字列が存在する」、ゼロは「数値として0が入力されている」という意味になります。点検結果や測定値のようなデータでは、この違いが業務判断に影響することがあります。

たとえば、点検回数がNULLであれば未確認かもしれませんが、ゼロであれば点検回数が0回と記録されている可能性があります。高さがNULLなのか0なのかでも意味は大きく違います。変換や読み込みの過程でNULLがゼロに置き換わってしまうと、後から正しい状態を復元するのが難しくなります。

属性型とNULL値の対策としては、まず重要な列を決めることです。すべての列を同じ深さで確認するのは大変なので、業務上のキーになる列、集計に使う列、表示名に使う列、条件検索に使う列を優先して確認します。管理番号、名称、分類、日付、数値指標、ステータスなどは特に注意が必要です。

変換前後で、代表的なレコードを比較することも有効です。先頭の数件だけでなく、NULLを含むレコード、長い文字列を含むレコード、先頭ゼロを含むコード、日付が入ったレコード、小数を含むレコードなど、問題が出やすいパターンを意図的に選んで確認します。正常なレコードだけを見ていると、変換差に気づけません。

また、GeoJSONの属性は柔軟に持てますが、後工程の読み込み側がどのように型を推定するかは別問題です。GeoJSON内では数値として出力されていても、読み込み側で文字列として扱われることがあります。逆に、文字列として持たせたいコードが読み込み側で数値扱いされることもあります。そのため、GeoJSON単体の確認だけでなく、実際に利用する環境で読み込んだ時の型も確認することが大切です。

属性型を意図的にそろえたい場合は、変換前にデータ定義を確認し、必要に応じてSQLや型変換オプションを使います。ogr2ogrには属性を選択したり、フィールド型を変換したりする機能があります。ただし、型変換は便利な反面、コードの先頭ゼロや日付表記などを失う原因にもなるため、変換後のチェックとセットで使うことが前提です。

属性名と属性型を管理する簡単なデータ定義書を作っておくと、変換作業が安定します。列名、意味、想定型、NULL許容、例示値を記録しておけば、変換後のチェック基準になります。複数回変換するデータや、定期更新するデータでは特に効果があります。毎回目視で判断するより、定義に照らして確認する方が、抜け漏れを減らせます。

属性型とNULL値の問題は、地図表示の美しさとは別の品質です。しかし、実務でGeoJSONを使う場合、検索、集計、連携、台帳管理まで含めて考える必要があります。変換直後に属性を確認するひと手間が、後工程の手戻りを大きく減らします。

対策6：出力結果を目視だけで判断しない

GeoJSONをogr2ogrで変換した後、地図に表示して見た目が問題なさそうだと、そのまま完了にしてしまうことがあります。しかし、出力結果を目視だけで判断するのは危険です。地図上でそれらしく見えていても、属性が欠けている、件数が減っている、一部のジオメトリが無効になっている、座標参照系の解釈がずれている、NULL値が変わっているといった問題は見逃されやすいからです。

目視確認はもちろん重要です。位置のずれや明らかな形状崩れは、地図上で見た方が分かりやすい場合があります。しかし、目視はあくまで確認方法のひとつです。特に大量データでは、全件を目で確認することはできません。代表的な範囲だけ見て問題がなかったとしても、別の地域や別の属性パターンで問題が起きている可能性があります。

対策としては、変換前後で比較する指標を決めておきます。まず確認したいのは地物数です。入力データの件数と出力GeoJSONの件数が一致しているかを確認します。もちろん、意図的に条件抽出や結合、分割を行った場合は件数が変わることがあります。その場合でも、なぜ変わったのかを説明できる状態にしておくことが大切です。説明できない件数差は、何らかの変換漏れや除外の可能性があります。

次に、属性数と主要属性の存在を確認します。変換後のGeoJSONに必要な属性が残っているか、列名が変わっていないか、値が空になっていないかを見ます。特に、表示名、識別子、分類、日付、ステータスなどは、後工程で使われることが多いため、重点的に確認します。

ジオメトリ型の確認も必要です。面データとして出力したつもりが、実際には複数種類のジオメトリ型が混ざっていることがあります。点、線、面が混在したGeoJSONは、用途によっては問題なく扱えますが、特定の処理ではエラーの原因になります。区域データ、道路データ、地点データなど、用途に応じて想定される型が決まっている場合は、変換後に型の分布を確認します。

座標範囲の確認も有効です。出力GeoJSONの座標が、想定する地域の範囲内に収まっているかを見ます。極端に大きい値や、想定外の緯度経度が含まれている場合、座標参照系のミスや座標列の取り違えが疑われます。大量データでも、最小値と最大値を見るだけで異常に気づけることがあります。

また、変換ログの確認を作業手順に含めるべきです。ogr2ogrはエラーではなく警告を出して処理を続けることがあります。警告には、属性の変換、ジオメトリの問題、文字列の扱い、未対応要素など、後で問題になる情報が含まれていることがあります。ログを見ずに「ファイルができたから成功」と判断すると、静かな失敗を見逃します。

確認結果を記録することも大切です。変換日時、入力ファイル名、出力ファイル名、主な指定、件数、座標参照系、確認した属性、発生した警告などを簡単に残しておけば、後から同じ変換を再現しやすくなります。特に、定期的に更新するGeoJSONや、外部へ納品・共有するデータでは、変換履歴が品質保証の一部になります。

実務では、変換作業が一度きりで終わらないことが多いです。月次更新、現地調査後の追加、区域変更、属性修正など、同じような変換を繰り返します。そのたびに手作業で何となく確認していると、担当者によって品質がばらつきます。確認項目を定型化し、チェックの観点を共有しておくことで、GeoJSON変換は安定します。

目視確認は最後の仕上げとして有効ですが、それだけに頼らず、件数、属性、型、座標範囲、ログを組み合わせて確認することが重要です。ogr2ogrの変換はコマンドで完了しますが、業務データとして使えるかどうかは、変換後の検証まで含めて判断する必要があります。

GeoJSON変換を安定させる実務フロー

ここまで、GeoJSONをogr2ogrで変換する時の代表的なつまずきと対策を見てきました。では、実際の業務ではどのような流れで作業すると安定するのでしょうか。大切なのは、いきなり本番データを変換して完了にするのではなく、入力確認、試験変換、検証、本番変換、記録という流れを作ることです。

最初に行うべきことは、入力データの把握です。ファイル形式、レイヤー数、地物数、ジオメトリ型、座標参照系、文字コード、主要属性を確認します。ここで不明点が多いデータは、変換後にも問題が出やすい傾向があります。特に座標参照系と文字コードは、変換前に分かっているかどうかで作業の安定度が大きく変わります。

次に、少量のデータで試験変換します。いきなり全件を変換するより、代表的な範囲や数件を取り出して変換し、座標、属性、文字化け、ジオメトリを確認する方が効率的です。試験変換で問題を見つけてから条件を調整すれば、全件変換後の手戻りを防げます。特に大容量データでは、この段階を省略しない方が結果的に早くなります。

試験変換では、正常なデータだけでなく、問題が出やすいデータも含めます。長い名称を持つ地物、NULLを含む属性、複雑なポリゴン、飛び地を持つ区域、先頭ゼロ付きのコード、日付を含むレコードなどを確認対象にします。これにより、単純なサンプルでは見えない変換差を発見しやすくなります。

本番変換では、試験変換で確認した指定を使い、必要に応じて座標参照系、文字コード、出力属性、ジオメトリ型、範囲抽出、簡略化、座標精度などを設定します。このとき、コマンドを手作業で毎回入力するのではなく、再利用できる形で残しておくと安全です。小さな入力ミスでも出力結果が変わるため、定期処理では特に再現性が重要です。

変換後は、検証を行います。件数、属性数、主要属性、座標範囲、ジオメトリ型、文字化け、ファイルサイズを確認します。さらに、実際に利用する地図環境や処理環境で読み込み、表示や検索が期待通りに動くかを確認します。GeoJSONファイル単体では正しく見えても、利用環境での扱いに差が出ることがあるためです。

最後に、作業記録を残します。入力データの概要、変換条件、出力ファイルの概要、確認結果、注意点を残しておけば、次回作業や引き継ぎが楽になります。問題が起きた場合も、どの段階で何を指定したかが分かれば、原因を追いやすくなります。

この流れを作っておくと、GeoJSON変換は属人的な作業から、再現性のある業務プロセスに変わります。ogr2ogrは強力な変換ツールですが、強力だからこそ、指定の意味を理解し、確認の手順を整えることが大切です。

また、現地調査や設備管理のように位置精度が重要な業務では、変換後のGeoJSONだけで完結させない考え方も必要です。地図上の表示だけでなく、現地で取得した位置情報、写真、メモ、点検結果などと一体で管理することで、データの信頼性は高まります。GeoJSONはそのための受け渡し形式として便利ですが、元データの取得品質や更新フローも同じくらい重要です。

まとめ：変換作業はコマンドより確認設計が大切

GeoJSONをogr2ogrで変換する作業は、一見すると形式を指定して実行するだけの単純な処理に見えます。しかし実際には、座標参照系、文字コード、ジオメトリ、ファイルサイズ、属性型、NULL値、出力検証など、多くの確認ポイントがあります。つまずきの多くは、コマンドの書き方そのものよりも、元データの前提を確認しないまま変換してしまうことから起こります。

座標参照系の指定を誤ると、データは正しい形を保っていても、まったく違う場所に表示されることがあります。文字コードを見落とすと、日本語の名称や住所が使えなくなります。ジオメトリ不正を放置すると、一部の図形が欠けたり、後工程でエラーになったりします。大きすぎるGeoJSONは、変換には成功しても、表示や共有で使いにくくなります。属性型やNULL値の変換差は、集計や検索の精度に影響します。そして、目視だけの確認では、これらの問題を見逃す可能性があります。

だからこそ、GeoJSON変換では「どう変換するか」と同じくらい「どう確認するか」が重要です。入力データの前提を整理し、試験変換を行い、変換後に件数、属性、座標範囲、ジオメトリ型、ログを確認する。この基本的な流れを作るだけで、トラブルは大きく減らせます。

GeoJSONは、地理空間データを扱ううえで便利な形式です。ogr2ogrを使えば、さまざまな形式との変換も柔軟に行えます。ただし、便利な道具ほど、前提を誤った時の影響も大きくなります。変換結果を業務で安心して使うためには、データの意味、座標の基準、属性の扱い、利用環境まで含めて確認する姿勢が欠かせません。

現地調査や設備管理、インフラ点検、境界確認など、位置情報を扱う現場では、GeoJSONへの変換だけでなく、そもそもの位置情報を正確に取得し、後工程で扱いやすい形に整えることが重要です。特定の製品名やサービス名だけに頼るのではなく、必要な精度、更新頻度、共有方法、既存システムとの相性を確認したうえで、測位機器、記録アプリ、GIS環境、変換フローを組み合わせて設計しましょう。