GeoJSONをQGISから書き出す時に崩れを防ぐ6設定

GeoJSONは、地物の位置情報と属性情報を一つのテキスト形式で扱えるため、地図表示、現地調査、台帳管理、設計確認、関係者間の共有などで使いやすい形式です。一方で、QGISからGeoJSONを書き出す時には、座標参照系、文字コード、属性名、ジオメトリ型、座標値の丸め、対象範囲などの設定がそろっていないと、位置ずれ、属性の欠落、文字化け、面の崩れ、読み込みエラーが起きることがあります。

特に注意したいのは、QGISの画面上で正しく重なって見えることと、GeoJSONとして書き出された座標値や属性が利用先で正しく読めることは別だという点です。プロジェクトの表示設定、レイヤの座標参照系、出力時の座標変換、選択地物、出力範囲、属性の取捨選択が少しずれるだけでも、共有後に「見えるが使いにくいデータ」になってしまいます。この記事では、実務担当者がQGISからGeoJSONを書き出す前に確認したい6つの設定を、作業の流れに沿って整理します。

目次

• 座標参照系を統一して位置ずれを防ぐ

• 文字コードと属性名を整えて文字化けを防ぐ

• ジオメトリ型と形状エラーを確認する

• 座標精度と桁数を調整して軽量化と精度を両立する

• 書き出し対象とレイヤ構成を固定する

• 書き出し後の読み込み確認で共有前の崩れを見つける

座標参照系を統一して位置ずれを防ぐ

GeoJSONを書き出す時に最初に確認したいのは、座標参照系の扱いです。QGISでは、プロジェクトの座標参照系と各レイヤが持つ座標参照系が異なっていても、画面上では自動的に重ね合わせ表示されることがあります。そのため、作業中は整合しているように見えても、GeoJSONとして書き出した時に、利用先で期待した位置に表示されないことがあります。

現在広く使われるGeoJSONでは、一般的なウェブ地図やビューアで扱いやすいように、WGS 84の経度・緯度を前提に読む環境が多くあります。QGIS上で平面直角座標系や現場独自座標を使っている場合でも、外部共有用のGeoJSONでは、利用先がどの座標値を期待しているかを先に確認することが重要です。特に、ウェブ地図、簡易ビューア、クラウド型の地図確認環境に渡す場合は、経度・緯度の座標として出力する前提で確認した方が安全です。

一方、設計図、測量成果、施工管理の座標と重ねる用途では、平面直角座標系や発注者指定の座標系を使う場面もあります。ただし、その座標系のままGeoJSONとして受け渡す場合は、利用先がその前提を理解し、同じ座標参照系として読み込めることが条件になります。汎用的なGeoJSONとして配布するのか、限られた関係者間で座標系を合意したデータとして渡すのかを分けて考える必要があります。合意が難しい場合は、GeoJSONではなく、GeoPackageなど別形式での受け渡しも検討します。

注意したいのは、座標参照系を単に「割り当てる」作業と、座標値を「変換する」作業を混同しないことです。割り当ては、データが本来持っている座標参照系を指定する作業です。変換は、座標値そのものを別の座標参照系に計算し直す作業です。元データの座標参照系が誤っている状態で、出力時の座標参照系だけを変えても、正しいGeoJSONにはなりません。位置がずれているデータに対して、見た目を合わせるためだけに別の座標参照系を割り当てると、後工程で原因を追いにくくなります。

複数のレイヤを同じ業務でGeoJSON化する場合は、それぞれのレイヤが同じ基準で管理されているかも確認します。道路中心線、区域ポリゴン、施設点、調査写真位置などを別々のレイヤで持っている場合、元になった測量成果や作成時期が異なることがあります。画面上でおおむね合っていても、細部で差が出ることがあるため、基準点、境界線、道路縁、既知の施設位置などを使って照合しておくと安全です。

GeoJSONの位置ずれを防ぐには、書き出し設定だけでなく、書き出し前のデータ整理が欠かせません。元レイヤの座標参照系を確認し、出力する座標参照系を決め、必要に応じて正しい変換を行い、変換後のレイヤを別名で保存してからGeoJSONを書き出す流れにすると、作業履歴も残しやすくなります。受け渡し先に座標参照系の指定を伝える場合は、ファイル名や同梱メモに座標系名、測地系、単位、変換条件の概要を記録しておくと、再利用時の混乱を減らせます。

文字コードと属性名を整えて文字化けを防ぐ

GeoJSONでは、地物の形状だけでなく、名称、種別、管理番号、調査日、状態、備考などの属性情報も扱えます。実務では、この属性情報が検索、絞り込み、ラベル表示、台帳連携、現地確認の手がかりになります。そのため、書き出し時に文字コードや属性名の扱いが崩れると、位置は正しくても使いにくいデータになってしまいます。特に日本語の施設名、工区名、地番、道路名、調査コメントなどを含む場合は、文字化け対策が重要です。

GeoJSONはJSONをもとにしたテキスト形式であり、外部共有ではUTF-8として扱う前提の環境が一般的です。ただし、QGISからの書き出し後に別の変換ツールを通したり、古いシステムに取り込んだり、表計算ソフトで開いて再保存したりすると、日本語が崩れることがあります。作業環境では正しく表示されていても、共有先の閲覧環境、簡易ビューア、変換ツール、管理システムでは文字化けする可能性があるため、実際に使う予定の環境で属性が読めるかを確認しておくと安心です。

属性名にも注意が必要です。QGIS上では日本語の列名やエイリアスを使っていても、連携先では英数字の属性名が扱いやすい場合があります。また、空白、記号、全角文字、長すぎる名称があると、後続の処理で扱いにくくなることがあります。ラベル表示や絞り込み条件を設定する時に、属性名に空白や括弧が多いと指定ミスが起きやすくなります。ファイルを人が読むだけでなく、他の仕組みで読み込む可能性があるなら、属性名は短く、意味が分かりやすく、表記が一定になるように整えておくと扱いやすくなります。

実務で使いやすい属性設計にするには、表示用の名称と管理用のコードを分ける考え方が有効です。人が見るための施設名や地点名は日本語で保持しつつ、分類や連携に使う項目は英数字のコードにしておくと、表示と処理の両方に対応しやすくなります。たとえば、地物の種類、状態、確認区分、調査区分などは、自由記述だけにすると表記ゆれが増えます。「良好」「異常なし」「問題なし」のように意味が近い値が混在すると、集計や色分けが難しくなります。GeoJSONとして書き出す前に、選択肢や記入ルールをそろえておくことが重要です。

また、属性値の空欄、不要な列、作業用の一時項目も確認します。編集中のメモ、仮番号、確認途中のフラグ、個人名、内部管理用の情報などがそのままGeoJSONに含まれると、共有先で誤解を招くことがあります。特に、外部共有や関係者配布を想定する場合は、公開してよい属性だけを残す必要があります。GeoJSONはテキストとして中身を確認しやすい形式なので、QGISの画面上で非表示にしている属性でも、ファイル内に含まれていれば閲覧される可能性があります。

書き出し前には、属性テーブルを見直し、必要な項目、不要な項目、名称を変更する項目、値を統一する項目を整理します。QGISの書き出し設定では、出力するフィールドの選択や、出力名の調整ができる場合があります。列名の表記ルールを決め、文字化けしやすい記号や機種依存文字を避け、日付や数値の形式もそろえます。日付は表示上の見た目だけでなく、年月日として解釈しやすい形に整えると後工程で使いやすくなります。数値は単位を属性名や別項目で明確にし、備考欄に単位が混在しないようにします。

GeoJSONは柔軟な形式ですが、柔軟だからこそ入力の乱れもそのまま出力されます。文字コードと属性名を軽視すると、地図上の見た目には問題がなくても、検索できない、ラベルが出ない、集計できない、共有先で文字化けする、といった実務上の不具合につながります。書き出し前の属性整理では、列名、値、不要項目、公開範囲を確認し、書き出し後には利用先で日本語と属性構造が正しく読めるかを確認します。この二段階で見直すことが、GeoJSONの崩れを防ぐ基本です。

ジオメトリ型と形状エラーを確認する

GeoJSONを書き出す時には、ジオメトリ型の整理も欠かせません。GeoJSONでは、点、線、面、マルチパート形状などを扱えますが、元レイヤの中に想定外の形状や無効な形状が混ざっていると、書き出し後に読み込み側で表示が崩れたり、一部の地物が表示されなかったりすることがあります。特に、点データとして管理したい施設位置、線データとして管理したい道路や管路、面データとして管理したい区域や敷地などは、用途ごとにジオメトリ型を分けておくことが基本です。

QGIS上では表示できても、利用先のシステムやビューアがすべてのジオメトリ型に対応しているとは限りません。GeometryCollection、Z値やM値を含むデータ、マルチポリゴン、マルチラインなどは、環境によって扱いが変わることがあります。現場確認用の簡易ビューアや管理システムに取り込む場合は、点、線、面を分け、必要に応じて単純なジオメトリ型に整えてから書き出すと、読み込み時の不具合を減らせます。

面データでは、自己交差、穴の扱い、閉じていない境界、重複した頂点、極端に細い形状などに注意します。区域や敷地の境界を編集していると、頂点の移動や結合の過程で線が交差したり、わずかな隙間が残ったりすることがあります。画面上では塗りつぶされているように見えても、内部的には無効な形状になっている場合があります。無効な形状を含んだままGeoJSONを書き出すと、読み込み側で一部の面が反転して見えたり、塗りつぶしが欠けたり、処理時にエラーが出たりすることがあります。

線データでは、分断、重複、方向、端点の接続を確認します。道路中心線、配管、調査ルート、境界補助線などでは、見た目がつながっていても端点が微妙に離れていることがあります。GeoJSONとして表示するだけなら大きな問題にならない場合もありますが、経路、延長、接続関係、区間管理に使う場合は、端点のずれが実務上の支障になります。また、線の方向に意味がある場合は、書き出し前に方向がそろっているかを確認します。流向、進行方向、測点の並びなどを属性や別資料で管理している場合は、ジオメトリの方向と矛盾しないように注意が必要です。

点データでは、重複点、不要点、位置が不自然な点を確認します。現地調査の地点、写真位置、施設位置、境界点などを点として扱う場合、同じ場所に複数の点が重なっていたり、座標入力ミスで遠くに飛んだ点が残っていたりすることがあります。地図を広域表示した時に、対象範囲から大きく外れた点があると、全体表示の範囲が広がりすぎてデータ確認がしにくくなります。書き出し前には、対象区域の外に不要な地物がないかを確認しておくと、共有後の混乱を減らせます。

ジオメトリの確認では、単にエラーの有無を見るだけでなく、利用目的に対して形状が適切かを判断することが大切です。現場で確認するための簡易地図なのか、台帳管理に使うのか、面積や延長の確認に使うのか、関係者への説明資料として使うのかによって、必要な整備レベルは変わります。軽い確認用であれば過度に細かい編集は不要な場合もありますが、後工程で解析や集計に使う場合は、形状の正しさが結果に直結します。

書き出し前の設定としては、対象レイヤのジオメトリ型を確認し、必要に応じて点、線、面を別レイヤに分けます。そのうえで、QGISの形状チェックや属性確認を使い、無効形状、空ジオメトリ、重複、範囲外の地物を見つけます。修正後は、元データを上書きせず、修正版レイヤとして保存してからGeoJSON化すると、万一の戻し作業がしやすくなります。GeoJSONの崩れは、書き出し時の問題に見えて、実際には元データの形状不備が原因になっていることが多いため、ここを丁寧に確認することが安定した出力につながります。

座標精度と桁数を調整して軽量化と精度を両立する

GeoJSONはテキスト形式で座標値を保持するため、座標の桁数が多いほどファイルサイズが大きくなります。特に、細かい頂点を多数含む線や面のデータでは、座標値の桁数がファイル容量や表示速度に影響します。一方で、桁数を減らしすぎると、位置が丸められ、境界線や道路線形がずれたり、面の形がわずかに崩れたりすることがあります。書き出し時には、用途に応じて座標値の丸めと必要な位置精度のバランスを取る必要があります。

ここでいう桁数は、データの実際の測定精度そのものではありません。元データの測位精度や測量精度が粗い場合、GeoJSONの座標値だけを細かく出しても、位置の信頼性が高まるわけではありません。反対に、測量成果や施工管理に関わるデータを過度に丸めると、境界、延長、面積、位置照合に影響する可能性があります。桁数の設定は、ファイルを軽くするためだけでなく、受け取り側に誤った精度感を与えないためにも確認が必要です。

実務では、すべてのGeoJSONに最大限の桁数が必要とは限りません。関係者に概略位置を共有するだけなら、過度に細かい座標値は不要な場合があります。反対に、境界、施工位置、調査点、施設管理点など、位置の差が判断に影響するデータでは、丸めすぎると問題が生じます。どの程度の丸めが許容できるかは、表示目的、元データの作成方法、利用環境、確認する縮尺によって変わります。書き出し時に一律で桁数を決めるのではなく、データの役割ごとに考えることが大切です。

線や面のデータでは、頂点数の多さもファイルの扱いやすさに影響します。元データが詳細な曲線や細かな境界を持っている場合、すべての頂点をそのままGeoJSONにすると、ファイルサイズが大きくなり、表示に時間がかかることがあります。共有先が現場確認や概要把握を目的としているなら、形状を大きく崩さない範囲で簡略化を検討することがあります。ただし、簡略化を行うと境界や面積が変わる可能性があるため、法的な境界、契約範囲、施工管理に関わる線や面では慎重に判断しなければなりません。

座標精度を調整する時は、元データを直接変更せず、用途別に出力用データを作る考え方が安全です。原本としてのGISデータは必要な精度で保持し、共有用、閲覧用、軽量表示用などの目的に応じてGeoJSONを書き出します。こうすることで、軽量化のために丸めたデータと、正確性を優先したデータを混同しにくくなります。ファイル名にも「確認用」「共有用」「簡略版」などの意味が分かる情報を入れておくと、後で再利用する時に誤用を防げます。

属性情報にも同じ考え方が当てはまります。位置表示だけに使うGeoJSONであれば、すべての属性を含める必要はありません。不要な列を削除することで、ファイルサイズを抑え、読み込みや表示を軽くできます。ただし、削除した属性が後で必要になることもあるため、元データは別に残しておきます。共有先に必要な属性だけを残すことは、軽量化だけでなく、情報管理の面でも有効です。

座標値の桁数とファイル容量の設定は、単なる容量削減ではありません。位置の信頼性、表示速度、共有しやすさ、後工程での再利用性を左右する設定です。書き出し前には、GeoJSONをどこで使うのか、どの縮尺で見るのか、どの程度の位置精度が必要なのか、属性情報をどこまで含めるのかを確認します。そのうえで、過剰な桁数や不要な属性を抑えつつ、必要な精度は残す方針にすると、崩れにくく扱いやすいGeoJSONになります。

書き出し対象とレイヤ構成を固定する

GeoJSONを書き出す時に起きやすいミスの一つが、対象範囲や対象地物の取り違えです。作業中のレイヤには、確認用の地物、仮作図、過去版、比較用の線、未確定の点などが残っていることがあります。そのまま書き出すと、本来共有すべきでない地物まで含まれたり、逆に必要な地物が選択漏れで出力されなかったりします。書き出し直後に気づけば修正できますが、関係者に配布した後で発覚すると、どのファイルが正しいのか分からなくなります。

まず確認したいのは、レイヤ全体を出力するのか、選択した地物だけを出力するのかという設定です。QGISの「選択地物のみ保存」のような設定は便利ですが、選択状態に依存するため、意図しない地物が含まれたり、必要な地物が外れたりするリスクがあります。特に、複数の作業を続けて行っている場合、前の作業で選択した地物が残っていることがあります。書き出し前には、選択状態を解除するのか、意図的に選択地物だけを出すのかを明確にします。

範囲指定にも注意が必要です。表示範囲や指定したExtentに基づいて出力する場合、画面外や範囲外の地物が含まれないことがあります。現場範囲が広いデータや、飛び地のように離れた対象を含むデータでは、見えていない地物の書き出し漏れが起きやすくなります。範囲を限定して出力する場合は、対象区域、工区、調査範囲、行政区域などの基準を決め、出力前に件数や範囲を確認します。

レイヤ構成も重要です。点、線、面、写真位置、区域、管理対象、補助線などを一つのFeatureCollectionに整理するのか、用途ごとに別ファイルとして分けるのかによって、受け取り側の使いやすさが変わります。一つのファイルにまとめると受け渡しは簡単ですが、属性や表示設定の管理が複雑になることがあります。用途ごとに分けると管理はしやすくなりますが、ファイル数が増え、どれを使えばよいか分かりにくくなることがあります。実務では、利用者が何を確認したいのかに合わせて構成を決めることが大切です。

たとえば、現場で確認する担当者向けには、調査地点、対象範囲、注意箇所を分けておくと見やすくなります。管理台帳に取り込む場合は、管理対象の種別ごとに属性設計をそろえたGeoJSONにすると後工程で扱いやすくなります。説明資料として使う場合は、補助的な線や注記用の点が必要になることもありますが、それらを正式データと混同しないように名称や属性で区別しておく必要があります。

書き出し対象を固定するには、出力前に専用の作業レイヤを作る方法が有効です。元レイヤから必要な地物だけを抽出し、属性を整理し、座標参照系やジオメトリを確認したうえで、書き出し用レイヤとして保存します。この段階で、不要な地物、作業メモ、仮線、未確定情報を取り除きます。元データを直接書き出すよりも一手間かかりますが、配布用データとしての品質を安定させやすくなります。

ファイル名やフォルダ構成も、GeoJSONの取り違え防止に関わります。出力日、対象範囲、用途、版数、座標系の情報が分かる名前にしておくと、複数回書き出した時に混乱しにくくなります。「最終」「最新版」のようなあいまいな名称だけでは、後日どれが正しいか判断できなくなることがあります。日付や版数を含め、差し替え時には古いファイルを残すのか、明確に廃止するのかも運用ルールとして決めておくと安全です。

書き出し対象とレイヤ構成の設定は、GeoJSONの内容そのものを決める重要な作業です。座標や文字コードが正しくても、対象地物が間違っていれば、実務では使えないデータになります。書き出し前には、対象範囲、対象地物、選択状態、レイヤ構成、属性整理、ファイル名を確認し、共有先が迷わず使える状態に整えることが必要です。

書き出し後の読み込み確認で共有前の崩れを見つける

GeoJSONを書き出した後は、必ず読み込み確認を行います。書き出し処理が正常に完了しても、そのファイルが実際に正しく使えるとは限りません。座標がずれている、属性が欠けている、文字化けしている、一部の地物が表示されない、面が崩れている、ファイルサイズが大きすぎて読み込みに時間がかかるなどの問題は、書き出し後に確認して初めて分かることがあります。共有前の読み込み確認は、GeoJSONの品質管理として欠かせない工程です。

まず行いたいのは、書き出したGeoJSONを新しい作業環境で読み込む確認です。書き出し元のQGISプロジェクトにそのまま重ねるだけでは、元データの表示設定や座標変換に助けられて問題が見えにくい場合があります。できれば新規のQGISプロジェクトや別の確認環境で読み込み、位置、範囲、属性、件数を確認します。元レイヤと比較する時は、基準となる背景や既知点と照合し、対象範囲に対して大きなずれがないかを見ます。

次に、属性情報を確認します。属性名が想定どおりになっているか、日本語が文字化けしていないか、日付や数値が崩れていないか、不要な項目が含まれていないかを見ます。ラベル表示に使う項目が空になっていると、地図上では点や線が出ていても、現場担当者が対象を判別しにくくなります。分類や色分けに使う項目が表記ゆれを起こしていると、表示設定がうまく反映されないこともあります。GeoJSONは属性と形状を一体で扱うため、位置だけでなく属性の確認も同じ重要度で行います。

件数確認も有効です。元レイヤの地物数と、書き出し後に読み込んだGeoJSONの地物数が一致しているかを確認します。選択地物だけを書き出した場合や、範囲指定をした場合は、意図した件数になっているかを記録しておくと、後で説明しやすくなります。点、線、面を分けて書き出した場合は、それぞれの件数を確認します。件数の差がある場合は、空ジオメトリ、無効形状、選択漏れ、範囲外、フィルタ条件などを疑います。

表示確認では、縮尺を変えながら見ることも大切です。広域表示では正しく見えても、拡大すると線がずれていたり、面の端部が重なっていたり、点が道路や施設から外れていたりすることがあります。逆に、拡大表示だけで確認していると、対象外に飛んだ点や遠方の誤データに気づけないことがあります。全体表示、対象区域表示、詳細表示の順に確認すると、範囲外データと細部の崩れを見つけやすくなります。

ファイルの中身をテキストとして確認することも、場合によっては有効です。GeoJSONはテキスト形式なので、属性名、座標値、不要な情報の有無を直接確認できます。ただし、手作業で内容を書き換えると構文エラーを起こしやすいため、修正が必要な場合は元データやQGIS側で直してから再度書き出すのが基本です。中身を確認する目的は、問題の原因を把握することであり、直接編集で応急処置を重ねることではありません。

共有前には、利用者の環境で開けるかも確認します。自分の環境では問題なく開けても、受け取り側ではファイル容量、文字コード、座標参照系、属性名、対応しているジオメトリ型などの違いで問題が出ることがあります。すべての環境を事前に検証することは難しい場合もありますが、少なくとも想定する利用方法に近い形で開き、位置と属性が確認できるかを見ることが重要です。現場で使う場合は、通信状況や端末性能によって表示が重くなることもあるため、必要に応じて軽量版を用意します。

読み込み確認の結果は、簡単なチェック記録として残しておくと実務で役立ちます。出力日時、出力元レイヤ、座標参照系、地物数、確認者、確認内容、共有先、版数などを記録しておけば、後で差し替えや問い合わせがあった時に説明しやすくなります。GeoJSONは手軽に書き出せる形式ですが、手軽だからこそ複数の版が作られやすく、どれが確認済みか分からなくなりがちです。確認済みファイルと作業中ファイルを分ける運用が、共有ミスを防ぎます。

書き出し後の読み込み確認は、最後の形式的な作業ではなく、GeoJSONの崩れを見つけるための実務的な検査です。座標、属性、件数、表示、範囲、容量、利用環境を確認し、問題があれば元データに戻って修正します。この一手間を入れることで、関係者に渡した後の手戻りや、現場での確認ミスを減らせます。

まとめ

GeoJSONをQGISから書き出す時の崩れは、単に出力ボタンを押す時の設定だけで起きるものではありません。多くの場合、元データの座標参照系、属性設計、ジオメトリ、選択状態、出力範囲、確認不足が重なって発生します。そのため、安定したGeoJSONを作るには、書き出し前、書き出し時、書き出し後の三段階で確認することが重要です。

最初に、座標参照系を確認し、用途に合った出力座標を決めます。画面上で重なって見えるだけで安心せず、元レイヤの座標参照系と出力時の座標変換を区別します。汎用的なGeoJSONとして共有する場合は、WGS 84の経度・緯度を前提に読む環境が多いことを踏まえ、利用先の仕様と座標値の意味をそろえておくことが大切です。次に、文字コード、属性名、属性値を整えます。日本語の文字化け、列名の扱いにくさ、表記ゆれ、不要な内部情報の混入は、共有後に使いにくさとして表れます。

さらに、点、線、面のジオメトリ型を整理し、無効形状や範囲外データを確認します。座標値の桁数と丸めでは、必要な精度を残すこととファイルを軽くすることのバランスを取ります。必要以上に重いGeoJSONは表示や共有の負担になり、丸めすぎたGeoJSONは位置確認の信頼性を下げます。書き出し対象とレイヤ構成を固定することも重要です。選択地物だけを出すのか、全体を出すのか、用途別に分けるのかを明確にし、ファイル名や版数で取り違えを防ぎます。

最後に、書き出したGeoJSONを新しい環境で読み込み、位置、属性、件数、表示、容量を確認します。問題が見つかった場合は、GeoJSONを直接手直しするのではなく、元データやQGIS側の設定に戻って修正する方が、作業履歴を残しやすく再発防止にもつながります。

GeoJSONは、現地調査、地物管理、関係者共有、簡易な地図表示に使いやすい形式です。一方で、設定を曖昧にしたまま書き出すと、見た目の崩れや属性の欠落が起きやすくなります。実務で安心して使うには、座標、文字、形状、精度、対象、確認という6つの観点をQGISの書き出し手順に組み込み、共有前に利用先での読み込みまで確認することが大切です。