GeoJSONのnull geometryを扱うときの4つの判断基準

GeoJSONを使って地物データを受け渡ししていると、`geometry` が `null` のFeatureに出会うことがあります。地図に点・線・面として表示されないため、最初はエラーや欠損データに見えるかもしれません。しかし、GeoJSONの仕様では、Featureが位置を持たない場合に `geometry` の値をJSONの `null` にすることが認められています。Featureは `type: "Feature"`、`geometry`、`properties` などを持つ構造であり、`geometry` はGeometryオブジェクトまたは未配置を示すJSON `null` になり得ます。GeoJSONのGeometryでは、点、線、面などの型ごとに `coordinates` の構造が決まっているため、`geometry: null` と、壊れた座標や不適切な座標配列は同じ意味ではありません。([RFC 7946][1])

実務で重要なのは、null geometryを見つけたときに、すぐ削除するのか、属性だけ残すのか、後で位置を付与するのか、表示や解析の直前で除外するのかを決めることです。判断があいまいなまま処理を進めると、地図画面では見えないのに件数には含まれる、集計結果には入っているのに空間解析からは落ちる、変換時に理由が分からないまま削除される、といった混乱が起こります。この記事では、「geojson 使い方」で調べている実務担当者に向けて、GeoJSONのnull geometryを安全に扱うための4つの判断基準を整理します。

目次

• null geometryを欠損ではなく未配置として扱う

• 属性を残す価値があるかで保存と除外を分ける

• 表示・解析・変換のどこで判定するかを決める

• 復元と監査に耐える管理情報を残す

• GeoJSONの使い方で迷わないための実務整理

null geometryを欠損ではなく未配置として扱う

最初の判断基準は、null geometryを単なる「壊れたデータ」と決めつけず、「位置がまだないデータ」として扱う余地があるかを確認することです。GeoJSONのFeatureは、現実世界の場所や対象物を地図上に表すために使われることが多い形式ですが、すべてのFeatureが最初から座標を持っているとは限りません。たとえば、台帳には対象物の名称、管理番号、種別、担当部署、調査予定日が入っているものの、まだ現地測位が終わっていない場合があります。住所や区画名は分かっていても、点として置くべき位置が確定していない場合もあります。個人情報や安全管理上の理由で位置だけを伏せ、属性だけを共有したい場合もあります。このようなFeatureは、地図上では未配置ですが、業務上のレコードとしては意味を持っています。

ここで避けたいのは、null geometryを無理に仮の座標へ置き換えることです。よくある失敗は、座標がないFeatureを `[0, 0]` のような値に変換してしまうことです。処理上は点として扱えるようになりますが、実際には存在しない場所に地物を作ってしまうため、地図表示、範囲検索、距離計算、件数集計のすべてに悪影響が出ます。仮の座標は、後から見た人にとって本物の測位結果と区別しにくく、誤った位置を根拠に判断される危険があります。未配置なら未配置として `geometry: null` を残し、位置がない理由を属性側で説明するほうが安全です。

また、`geometry: null` と `coordinates: null` は分けて考える必要があります。Geometryオブジェクトとして `type` を持たせたうえで `coordinates` を `null` にする書き方は、Geometry型に応じた座標構造を満たさないため、読み込み側の処理で失敗しやすくなります。位置がないことを表したいなら、Featureの `geometry` そのものを `null` にするのが分かりやすい整理です。反対に、点や線や面として成立しているFeatureであれば、`geometry` には適切なGeometryオブジェクトを入れ、座標順序や配列構造を確認します。GeoJSONでは位置の基本要素が数値配列であり、最初の2要素は経度と緯度、または東方向の座標と北方向の座標の順序で扱われます。ここを誤ると、null geometryとは別の座標不正として扱うべき問題になります。([RFC 7946][1])

空の座標配列も、null geometryと同一視しないほうが実務では安全です。RFC 7946では、GeoJSON処理系が空の `coordinates` 配列を持つGeometryをnullオブジェクトのように解釈する可能性に触れています。ただし、すべての読み込み側が同じ挙動をするとは限りません。ある処理では読み込めても、別の処理ではエラーになったり、空の図形として扱われたり、データ変換時に落とされたりする可能性があります。長く運用するデータほど、解釈の揺れはトラブルになります。したがって、意図が「位置未定」なら `geometry: null`、意図が「位置はあるが座標が不正」なら修正待ち、意図が「対象外なので図形を持たせない」なら属性で理由を明記、というように状態を分けることが大切です。

この基準で見ると、null geometryは削除対象ではなく、まず分類対象です。レコードが未配置なのか、測位前なのか、変換ミスなのか、秘匿処理なのか、仕様外の壊れ方なのかを切り分けます。実務では、読み込み時に `geometry` が `null` かどうかを検査し、同時に `properties` の中に管理番号、名称、発生日、取得元、位置不明の理由があるかを確認します。これにより、null geometryを見つけた段階で作業を止めるのではなく、次に保存するべきか、補正するべきか、除外するべきかを判断できるようになります。

属性を残す価値があるかで保存と除外を分ける

2つ目の判断基準は、geometryがないFeatureの属性に業務上の価値があるかどうかです。GeoJSONは地図表示のためだけに使われると思われがちですが、Featureの `properties` には、地物名、分類、点検結果、管理番号、状態、メモ、更新日時など、多くの属性情報を入れられます。位置がないからといって、その属性まで不要とは限りません。むしろ、位置がないFeatureほど、後続の調査対象や確認待ち一覧として重要な意味を持つことがあります。

たとえば、現地調査の予定リストをGeoJSONとして受け取った場合、調査前の対象物はまだ座標を持たないかもしれません。このときnull geometryのFeatureを削除すると、調査予定そのものが消えてしまいます。災害対応や設備管理のように、受付情報、通報内容、管理区域、担当者、優先度だけが先に登録され、位置が後から確定する業務でも同じです。地図上に表示できないからといってレコードを捨てると、作業漏れの原因になります。null geometryを含むFeatureは、地図レイヤーとしては非表示でも、一覧、進捗管理、照合、担当割り当てでは使える可能性があります。

一方で、属性に価値がないnull geometryもあります。変換元データの空行がFeatureとして出力されたもの、必須項目がほとんど空のもの、重複行から図形だけが欠けたもの、テストデータが混入したものなどは、保存しても混乱を増やすだけです。この場合は、削除または隔離の対象にします。ただし、削除する場合でも、なぜ削除したのかを処理ログに残しておくと、件数差の説明がしやすくなります。元データには1000件あったのに地図用データには980件しかない、という状況で、20件がnull geometryのため表示対象外になったと説明できれば、関係者間の認識違いを減らせます。

保存と除外の判断では、「地図に出せるか」だけではなく、「業務プロセスに残す必要があるか」を見ることが重要です。地図表示だけを目的にした軽量データであれば、null geometryを除外しても問題が小さい場合があります。しかし、台帳連携、点検管理、申請受付、現地調査、施工管理、履歴管理などに使うデータでは、位置がないこと自体が状態情報になります。そのため、空間データとしては未完成でも、業務データとしては保存対象になることがあります。

実務では、null geometryのFeatureに状態を表す属性を持たせると扱いやすくなります。たとえば、位置確認中、測位待ち、位置非公開、対象外、変換エラー、調査不可といった状態を、業務に合わせた値で持たせます。ここで大切なのは、状態名を人によって自由に入力させないことです。ある人は「未確認」、別の人は「確認前」、さらに別の人は「未測位」と入力すると、同じ意味のレコードを機械的に集計できません。使える値をあらかじめ決め、入力時や変換時にそろえることで、null geometryを含むFeatureも管理しやすくなります。

属性を残す場合は、IDの設計も重要です。地図上に表示できないFeatureは、クリックして選択することができません。そのため、あとから該当レコードを特定するには、地図上の位置ではなく、管理番号や外部ID、受付番号、調査番号のような識別子が頼りになります。GeoJSONのFeatureには、一般的に使われる識別子がある場合に `id` を入れることができます。元データと突き合わせる必要がある場合は、安定したIDを用意しておくと安全です。IDがないnull geometryは、後から復元や照合を行うときに迷子になりやすくなります。([RFC 7946][1])

保存すべきか除外すべきか迷う場合は、まず業務の出口を確認します。最終的に必要なのが地図画像だけなら、null geometryは表示対象外としてよい場合があります。最終的に必要なのが作業台帳、点検一覧、未対応リスト、データ品質レポートであれば、null geometryを残す価値があります。位置がないFeatureを残すかどうかは、地図の都合ではなく、業務上そのレコードを追跡する必要があるかで判断するのが実務的です。

表示・解析・変換のどこで判定するかを決める

3つ目の判断基準は、null geometryをどの段階で判定し、どの段階で除外または分岐させるかです。GeoJSONを扱う処理は、読み込み、検証、保存、表示、検索、解析、変換、出力といった複数の工程に分かれます。null geometryを入口で削除するのか、保存時には残して表示時だけ除外するのか、解析直前にフィルタするのかによって、結果の意味が変わります。ここを決めないまま処理を書くと、画面ごとに件数が違う、出力ファイルごとに対象件数が違う、同じデータなのに担当者によって結果が違う、という問題が起こります。

地図表示では、null geometryのFeatureは描画できません。点、線、面のいずれでもないため、通常の地図レイヤー上には表示対象がありません。このとき、単に何も表示しないだけで済ませると、利用者はデータが存在することに気づけません。表示画面では、地図に出した件数と、位置未設定として表示できなかった件数を分けて示すと親切です。たとえば、全体件数、地図表示件数、位置未設定件数を内部的に分けるだけでも、問い合わせ時の説明が容易になります。地図に出ないFeatureがあることを画面や一覧で伝えれば、「データが消えた」と誤解されにくくなります。

空間解析では、null geometryを含めるかどうかを事前に決める必要があります。距離計算、面積計算、重なり判定、範囲内検索、近傍検索、線形距離の集計などは、図形があることを前提にしています。null geometryをそのまま渡すと、処理が停止する、結果が空になる、対象から黙って除外されるなど、実装によって異なる挙動になります。安全な運用では、解析に入る前にgeometryがあるFeatureだけを抽出し、null geometryは解析対象外として別に件数を記録します。解析結果を報告するときも、「対象Featureのうち、位置があるものだけを空間解析した」と分かるようにしておくと、結果の解釈が安定します。

検索やフィルタでは、属性検索と空間検索を分けることが重要です。null geometryのFeatureは、属性条件には合致することがあります。たとえば、点検状態が未対応、重要度が高い、期限が近い、といった属性検索では対象に含めるべきかもしれません。一方で、指定範囲内にあるもの、現在地から近いもの、特定区域と交差するもの、といった空間条件には参加できません。属性検索では残すが、空間検索では除外するという整理をしておけば、ユーザーが検索結果を見たときに納得しやすくなります。検索結果画面でも、位置ありの結果と位置なしの結果を分けて扱うと、次の作業につなげやすくなります。

データ変換では、null geometryがもっとも見落とされやすいポイントになります。GeoJSONを別の形式へ変換するとき、変換先が図形を必須とする形式であれば、null geometryのFeatureは落ちる可能性があります。逆に、属性だけを保持できる形式に分ければ、null geometryの情報を失わずに済みます。実務では、空間データとして出力するファイルと、位置未設定の属性一覧を分けて出す方法が有効です。これにより、地図で使う側は図形だけを扱え、管理する側は未配置レコードを追跡できます。

処理の入口で厳格に弾くか、内部では保持して出口で分けるかは、システムの目的によって変わります。公開用の軽量地図であれば、入口でnull geometryを除外してもよい場合があります。ただし、除外件数と理由は残しておくべきです。業務管理や現地調査の基盤として使う場合は、入口で削除せず、保存後の利用場面ごとに分岐させるほうが安全です。表示では非表示、一覧では表示、解析では除外、品質レポートでは集計対象、といった役割分担を明確にしておくと、null geometryがあっても処理全体が安定します。

この基準を実装に落とすときは、データの読み込み直後に検証ステップを置くと扱いやすくなります。検証では、Featureかどうか、`geometry` メンバーが存在するか、値が `null` かGeometryオブジェクトか、Geometryオブジェクトなら型と座標構造が合っているか、属性に識別情報があるかを確認します。その結果を、正常なgeometryあり、正常なnull geometry、座標不正、構造不正、属性不足のように分類します。分類してから保存や表示へ進めば、後工程で原因不明のエラーになることを減らせます。

復元と監査に耐える管理情報を残す

4つ目の判断基準は、null geometryを後から復元できる状態で管理することです。null geometryを一時的な状態として扱うなら、いずれ位置を付与する工程が必要になります。そのとき、元の住所、現地メモ、図面番号、写真番号、受付番号、調査担当者、取得予定日などの情報が残っていなければ、どこに置くべきFeatureなのか判断できません。geometryがないFeatureほど、復元の手がかりになる属性を丁寧に残す必要があります。

復元を前提にする場合、位置がない理由を残すことが特に重要です。単に `geometry: null` だけでは、未測位なのか、測位に失敗したのか、意図的に非公開にしたのか、変換時に落ちたのかが分かりません。理由が分からないnull geometryは、後から担当者が見ても対処方法を決めにくくなります。未測位であれば現地取得の対象になります。住所から位置を推定できるなら照合作業の対象になります。安全上の理由で非公開にしたなら、復元してはいけない場合があります。変換エラーなら元データや変換ルールの修正が必要です。理由を属性として残せば、同じnull geometryでも扱いを変えられます。

監査の観点では、いつ、どの工程で、なぜnull geometryになったのかを追えることが大切です。最初から位置がなかったのか、加工の途中でgeometryが消えたのかでは、責任範囲も修正方法も変わります。受領時点では図形があったのに変換後にnullになったなら、変換処理に問題があるかもしれません。受領時点からnullだったなら、元データの仕様として受け入れるか、提供元へ確認する必要があります。更新履歴や処理ログに、受領件数、geometryあり件数、null geometry件数、除外件数、修正件数を残しておくと、後から品質を説明しやすくなります。

管理情報を残すときは、geometryと属性の役割を混同しないことも重要です。位置を表すべき情報はgeometryへ、状態や理由を表す情報はpropertiesへ入れる、という基本を守ります。たとえば、位置がない理由を座標値で表そうとしたり、仮の点を置いて「これは仮位置です」と別属性で補足したりすると、地図処理では本物の点として扱われるおそれがあります。仮位置を使う必要がある場合でも、それが推定位置なのか、代表点なのか、暫定位置なのかを明確にし、確定位置と同じ扱いにしない設計が必要です。業務上の精度や責任範囲が違うものを同じgeometryとして扱うと、後の判断を誤りやすくなります。

また、null geometryのFeatureに範囲情報を無理に持たせないことも大切です。GeoJSONオブジェクトには、座標範囲を示す `bbox` を持たせることができます。ただし `bbox` は、含まれるGeometry、Feature、FeatureCollectionの座標範囲を説明するための情報です。geometryがないFeatureに、根拠のない範囲を付けると、空間検索や表示範囲の計算で誤解を招きます。位置が未定なら、範囲も未定として扱い、位置が復元された後に必要な範囲情報を再計算するほうが自然です。([RFC 7946][1])

復元の運用では、null geometryを放置しない仕組みも必要です。位置未設定のFeatureが増え続けると、地図としての信頼性が下がります。定期的にnull geometry件数を確認し、理由別に集計し、測位待ちや確認待ちの件数を減らす作業を組み込みます。現地確認が必要なものは調査リストに回し、住所や管理区域から補完できるものは確認者を決め、非公開が妥当なものはその状態を確定させます。null geometryは、単なる例外ではなく、データ整備の進捗を示す指標としても使えます。

監査に耐えるデータにするには、手作業で修正した場合の記録も欠かせません。誰が、いつ、どの根拠で位置を付けたのか、元のnull geometryをどのように更新したのかを残します。現地計測で得た位置なのか、図面から読み取った位置なのか、住所から推定した位置なのかによって、位置の信頼度は変わります。位置が入ったから完了と考えるのではなく、取得方法と確認状態を残すことで、後から再点検や補正をしやすくなります。

GeoJSONの使い方で迷わないための実務整理

GeoJSONのnull geometryを扱うときは、「正しいか間違いか」だけで判断しないことが重要です。Featureの `geometry` が `null` であること自体は、位置がないFeatureを表す方法として成立します。一方で、座標配列が壊れている、Geometryの型と配列構造が合っていない、Featureに必要な `geometry` メンバーが欠けている、仮の座標で埋めている、といった状態は別の問題です。まずはnull geometryを、仕様上扱える未配置状態なのか、データ品質上の不具合なのかに分けて見ることが、安定したGeoJSON運用の出発点になります。

実務で使いやすい整理は、4つの問いに置き換えることです。第一に、このFeatureは位置がないだけで、業務上のレコードとして残す価値があるのかを確認します。第二に、位置がない理由は明確なのかを確認します。第三に、このデータを使う工程は、地図表示なのか、属性一覧なのか、空間解析なのか、形式変換なのかを確認します。第四に、後から位置を復元する必要があるのか、また復元できるだけの識別子や根拠情報が残っているのかを確認します。この4点が決まれば、削除、保存、隔離、補正、表示対象外、解析対象外といった処理方針を説明しやすくなります。

GeoJSONを初めて扱う担当者ほど、地図に出ないFeatureを「消えている」と感じやすいものです。しかし、地図表示はGeoJSONの使い方の一部にすぎません。GeoJSONには、図形と属性を一緒に運ぶ役割があります。geometryがnullでも、propertiesに意味があれば、業務上はまだ使い道があります。反対に、propertiesにも識別情報がなく、位置もないFeatureは、残すほど品質管理の負担になります。大切なのは、地図で見えるかどうかではなく、データとして追跡する必要があるかどうかを判断することです。

チームで運用する場合は、null geometryの扱いをルール化しておくと効果的です。読み込み時の検証項目、保存する属性、除外する条件、表示画面での件数表示、解析前のフィルタ、変換時の出力方法、復元時の確認手順を決めておけば、担当者ごとの判断差を減らせます。特に、地図表示用データと業務管理用データを同じGeoJSONで兼ねる場合は、null geometryをどの画面で見せ、どの処理から外すのかを文書化しておくことが大切です。ルールがあれば、地図に出ないFeatureが見つかっても、例外対応ではなく通常の品質管理として処理できます。

GeoJSONのnull geometryは、現地情報の取得が後追いになる業務、位置の確定に確認が必要な業務、属性台帳と地図を段階的に連携する業務で特に重要になります。最初から完璧な座標を持つデータだけを扱うなら問題は少ないですが、実際の現場では、先に属性が集まり、後から位置が確定することがあります。その過程でnull geometryを適切に扱えると、データを無理に捨てず、誤った仮位置も作らず、後から正しい位置へ更新しやすくなります。

最終的には、null geometryを「例外」ではなく「状態」として扱うことが、GeoJSONを実務で安定して使うコツです。位置がない状態を明確に残し、属性の価値を判断し、表示や解析では適切に分岐し、復元に必要な情報を残す。この流れを作れば、GeoJSONの使い方で迷う場面は大きく減ります。現場で取得した位置情報と属性情報を早い段階で結び付けるには、測位、記録、点検、変換、品質確認の手順をあらかじめ決め、null geometryを理由別に管理しながら少しずつ減らしていくことが大切です。