GeoJSONをデータベース保存する時の設計ミス5選

GeoJSONは、位置情報を含むデータを扱ううえで便利な形式です。点、線、面といった地物を、属性情報と一緒に扱えるため、現地調査、設備管理、道路管理、施工記録、点検記録、台帳整備など、さまざまな実務で利用しやすい形式です。一方で、GeoJSONをそのままデータベースに保存すればよいと考えると、あとから検索が遅い、座標がずれる、更新履歴が追えない、属性が整理できない、地図表示と業務管理がつながらないといった問題が起きやすくなります。

この記事では、GeoJSONをデータベースに保存する時に起こりやすい設計ミスを5つに整理し、実務で扱いやすい保存設計にするための考え方を解説します。

目次

• GeoJSON保存で最初に決めるべき設計方針

• 設計ミス1：GeoJSONを丸ごと保存すれば十分だと考える

• 設計ミス2：座標系と座標順序の確認を後回しにする

• 設計ミス3：属性情報の型と管理単位を整理しない

• 設計ミス4：検索・表示・更新の使い方を想定しない

• 設計ミス5：履歴管理とデータ品質確認を設計に入れない

• GeoJSONを業務データとして活かすための保存設計

• まとめ

GeoJSON保存で最初に決めるべき設計方針

GeoJSONをデータベースに保存する時は、最初に「何を保存するか」よりも「保存した後に何をしたいか」を決めることが重要です。単に地図に表示するだけなのか、範囲検索をしたいのか、点検記録と紐づけたいのか、現地写真や施工記録と一緒に管理したいのかによって、適切な保存方法は変わります。

GeoJSONは、人が読める形で地物情報を表現できるため、受け渡し形式としては扱いやすい形式です。しかし、データベースの中で長期的に管理する場合は、受け渡し形式としての便利さと、検索・更新・集計に向いた管理形式を分けて考える必要があります。GeoJSON文字列をそのまま保存するだけでは、初期開発は簡単に見えても、後工程で不便が出ることがあります。

たとえば、現場で取得した点の位置を保存するだけなら、GeoJSONをそのまま保存しても一見問題がないように見えます。しかし、あとから「この範囲内の点検箇所だけを抽出したい」「同じ施設IDの履歴を時系列で見たい」「線形に沿って近い順に並べたい」「面の内外判定をしたい」といった要件が出てくると、保存時の設計が効いてきます。設計時に業務上の使い方を想定していないと、毎回アプリ側でGeoJSONを読み解く必要が生じ、処理が複雑になります。

また、GeoJSONにはgeometryとpropertiesという考え方があります。geometryには位置や形状を表す情報が入り、propertiesには名称、ID、種別、点検日、状態、担当者、備考などの属性が入ります。これらをすべて一つの文字列として保存するのか、geometryを空間情報として扱い、主要なpropertiesを通常の列として分けて持つのかで、データベースの使いやすさは大きく変わります。

実務では、GeoJSONを「外部連携用の形式」として保存しつつ、検索や業務管理に必要な項目は別の列として整理して持つ設計が現実的です。つまり、GeoJSONそのものを残すことと、業務で使う情報をデータベースで扱いやすい形に分けることは、対立する考え方ではありません。むしろ両方を意識することで、再利用性と運用性を両立できます。

設計方針を決める時は、地物の単位、属性の単位、更新の単位、履歴の単位を明確にします。1つのFeatureを1レコードとして扱うのか、FeatureCollectionを1レコードとして扱うのか、現場単位でまとめるのか、設備単位で分けるのかを決めておかないと、後から検索や更新の責任範囲が曖昧になります。特に、点検や補修、施工管理のように、同じ場所に対して複数回の記録が蓄積される業務では、保存単位の設計がそのまま運用のしやすさにつながります。

設計ミス1：GeoJSONを丸ごと保存すれば十分だと考える

最も起こりやすい設計ミスは、GeoJSONを文字列として丸ごと保存し、それだけで十分だと考えてしまうことです。GeoJSONはそのまま保存できるため、開発初期には簡単に見えます。受け取ったデータを文字列として保存し、必要な時に取り出して地図に渡せば表示できるため、短期的には合理的に思えるかもしれません。

しかし、データベース保存の目的は、単に保管することだけではありません。検索し、絞り込み、並び替え、集計し、更新し、他の業務データと紐づけることまで含めて考える必要があります。GeoJSONを丸ごと保存するだけだと、geometryの中身やpropertiesの値をデータベースが扱いやすい形で認識できない場合があります。その結果、アプリ側で毎回文字列を解析し、必要な項目を取り出す処理が増えてしまいます。

たとえば、propertiesの中に「点検日」「施設ID」「状態」「路線名」「管理区分」などを入れている場合、それらを通常の列としても保持しておかないと、条件検索がしづらくなります。「点検日が今月のもの」「状態が要確認のもの」「特定の管理区分に属するもの」といった検索を行うたびに、GeoJSON文字列の中を解析する設計は、処理の見通しが悪くなります。データ量が少ないうちは問題が見えにくいものの、件数が増えると検索速度や保守性に影響します。

また、GeoJSONを丸ごと保存する設計では、更新の単位も曖昧になりやすいです。たとえば、propertiesの一部だけを修正したい場合でも、GeoJSON全体を書き換える必要が出ることがあります。属性だけを更新したいのにgeometryまで一緒に上書きする設計になっていると、誤更新や差分管理の難しさにつながります。逆に、geometryだけを修正したい場合も、どの属性とセットで修正されたのかが追いにくくなります。

実務では、GeoJSONを保存する場合でも、検索や管理に使う主要項目は別列として持つ設計が有効です。たとえば、地物ID、業務ID、種別、作成日時、更新日時、状態、担当者、管理区分、代表点の経度緯度、範囲情報などは、GeoJSONの中だけに閉じ込めず、データベース上で直接扱えるようにしておくと便利です。そのうえで、元のGeoJSONや出力用GeoJSONを保持すれば、外部連携や再表示にも対応しやすくなります。

ただし、すべてのpropertiesを列に分解すればよいわけではありません。属性数が多く、案件ごとに項目が変わる場合、すべてを固定列にすると、列の追加や変更が頻発して管理が難しくなります。その場合は、検索や集計に使う項目だけを列化し、補助的な属性は柔軟な形式で保持する設計が現実的です。重要なのは、どの項目が業務上の検索条件になり、どの項目が単なる表示情報なのかを分けることです。

GeoJSONを丸ごと保存する設計が悪いのではなく、丸ごと保存するだけで終わることが問題です。保存時点で、空間検索に使うgeometry、業務検索に使う属性、受け渡しに使うGeoJSONを分けて考えることで、あとから拡張しやすいデータベースになります。

設計ミス2：座標系と座標順序の確認を後回しにする

GeoJSONを扱う時に特に注意が必要なのが、座標系と座標順序です。GeoJSONの位置配列は、原則として経度、緯度の順で扱います。多くの業務資料や現場感覚では、緯度、経度の順で表現されることがあるため、この違いを理解せずに保存すると、地図上の位置が大きくずれる原因になります。

座標順序のミスは、データベース保存時には気づきにくいことがあります。数値としてはどちらも妥当に見えるため、保存処理そのものではエラーにならない場合が多いからです。しかし、地図に表示した時にまったく別の場所に出る、範囲検索に引っかからない、距離計算の結果が不自然になるといった問題として表面化します。特に、日本国内の位置情報では、緯度と経度の数値範囲が異なるため、逆転すれば気づける場合もありますが、処理の途中で変換が混在していると原因の特定が難しくなります。

また、座標系の考え方も重要です。GeoJSONとして外部連携や一般的な地図表示に使う場合は、経度緯度を前提に扱われることが多いため、元データの座標系を確認する必要があります。現場測量や設計図面では、平面直角座標系やローカル座標、現場独自の基準点を使うことがあります。一方、GeoJSONのcoordinatesに単純にX、Yの数値を入れただけでは、地図上の正しい位置を表せないことがあります。

たとえば、図面上の座標値をそのままGeoJSONのcoordinatesに入れてしまうと、地図上では意図しない場所に表示される可能性があります。図面座標、測量座標、地図表示用の経度緯度は、それぞれ意味が異なります。データベース保存時には、元データの座標系、保存時の座標系、表示時の座標系を区別して管理する必要があります。

実務でよくある問題は、変換済みの座標なのか、未変換の座標なのかがデータから判断できなくなることです。最初の担当者は把握していても、数か月後に別の担当者がデータを扱うと、どの座標系で保存されているのか分からなくなることがあります。これを避けるには、座標系に関する情報を設計書や運用ルールだけでなく、データ自体の管理項目として残すことが重要です。

たとえば、保存データには、元座標系、変換後座標系、変換日時、変換方法、変換元データの識別子などを持たせると、あとから確認しやすくなります。すべてを厳密に管理する必要がない小規模な用途でも、「このGeoJSONは地図表示用の経度緯度である」「この座標は現場ローカル座標であり、そのまま地図表示しない」といった区別は必ずできるようにしておくべきです。

座標順序と座標系のミスは、後から一括修正できるように見えて、実際には難しい場合があります。なぜなら、どのデータが正しく、どのデータが逆転しているのかを判定するための根拠が必要になるからです。全件が同じルールで間違っていればまだ修正しやすいですが、複数の入力経路があり、一部だけ変換済み、一部だけ未変換という状態になると、データの信頼性が大きく下がります。

そのため、GeoJSONをデータベースに保存する時は、保存前の入力チェックで座標範囲、座標順序、座標系の前提を確認する仕組みを入れることが大切です。人の目で地図表示を確認するだけでなく、数値範囲の妥当性、対象地域からの逸脱、極端な距離、面の自己交差、点列の不自然な飛びなどを確認することで、初期段階で多くのミスを防げます。

設計ミス3：属性情報の型と管理単位を整理しない

GeoJSONのpropertiesには属性情報を入れられるため、柔軟に見えます。しかし、この柔軟さに頼りすぎると、データベース保存後に属性の揺れが大きくなり、検索や集計が難しくなります。属性名の表記ゆれ、値の型の違い、日付形式の不一致、空欄の扱い、単位の混在などは、実務でよく起こる問題です。

たとえば、同じ施設IDを表す項目でも、あるデータでは「id」、別のデータでは「facility_id」、さらに別のデータでは「施設番号」といった名称になっていると、同じ意味の項目として扱うために変換処理が必要になります。状態を表す値も、「正常」「異常なし」「OK」「問題なし」のように複数の表記が混在すると、集計結果が分かれます。日付も、文字列として保存されているだけでは、期間検索や並び替えで思わぬ不具合が出ることがあります。

属性情報は、表示できればよい項目と、業務判断に使う項目を分けて考える必要があります。地図上のポップアップに表示するだけの備考であれば、多少自由な形式でも運用できます。しかし、検索条件、承認判断、点検状況、優先度、補修対象の抽出、報告書作成に使う項目は、型や値のルールを定めておくべきです。

特に、数値と文字列の混在には注意が必要です。延長、面積、高さ、深さ、距離、数量などをpropertiesに入れる場合、数値として扱うのか、単位付き文字列として扱うのかを決めておかないと、集計や比較ができなくなります。「10」と「10m」と「約10」のような値が混在すると、人が読むだけなら理解できても、データベース上で条件検索する時には扱いづらくなります。数値は数値として保存し、単位は別に管理するという考え方が重要です。

管理単位の整理も欠かせません。GeoJSONでは、1つのFeatureが1つの地物を表すことが一般的ですが、実務では1つの地物に複数の属性や記録が紐づくことがあります。たとえば、同じ位置に対して、現況、点検結果、補修履歴、写真、担当者コメント、承認状態が重なることがあります。これらをすべて1つのpropertiesに詰め込むと、どの情報が現在値で、どの情報が過去の記録なのか分かりにくくなります。

点検や施工管理では、同じ場所に対して繰り返し記録が発生します。その場合、地物そのものの情報と、点検ごとの記録を分ける設計が必要です。地物ID、位置、形状、管理区分などは地物の基本情報として持ち、点検日、点検結果、写真、コメント、対応状況などは記録テーブルとして別に持つ方が、履歴を追いやすくなります。GeoJSONのpropertiesにすべてを入れる設計では、過去記録の追加や修正が複雑になりやすいです。

また、属性の必須項目を決めていないことも設計ミスにつながります。GeoJSONとしてはpropertiesが空でも形式上は成立する場合がありますが、業務データとしては、地物IDや種別、作成日時、管理者などがないと運用できないことがあります。保存時に必須項目を検査しないと、あとから「地図には表示されるが、台帳と紐づかない」「検索には出るが、担当部署が分からない」といったデータが増えてしまいます。

属性情報の設計では、自由入力にする項目と選択式にする項目を分けることも大切です。自由入力は柔軟ですが、表記ゆれが増えます。選択式は入力のばらつきを抑え、集計しやすくなります。すべてを選択式にすると現場の例外に対応しづらくなるため、状態、種別、優先度、管理区分などの重要項目は選択式にし、補足説明や現場メモは自由入力にするなど、役割を分けると運用しやすくなります。

設計ミス4：検索・表示・更新の使い方を想定しない

GeoJSONをデータベースに保存する時は、保存後の使い方を具体的に想定する必要があります。特に、検索、表示、更新の3つを考えずに設計すると、運用が始まってから不便が出やすくなります。保存できることと、実務で使いやすいことは別です。

検索で問題になりやすいのは、空間条件と業務条件を組み合わせる場面です。たとえば、「この範囲内にある未対応の点検箇所」「特定の道路沿いにある要確認の設備」「指定した面に重なる施工記録」「過去1年以内に更新された地物」といった検索では、位置情報と属性情報の両方が必要になります。GeoJSONを文字列として保存しているだけだと、こうした検索を効率よく行いにくくなります。

表示でも設計の差が出ます。地図上に大量のGeoJSONを一度に表示すると、読み込みや描画が重くなることがあります。保存時に地物の範囲や代表点、ズーム段階に応じた表示制御を考えておかないと、必要以上に多くのデータを取得してしまいます。実務担当者が見たいのは、すべてのデータではなく、今の作業に必要なデータです。範囲、種別、状態、日付などで適切に絞り込めるようにすることが重要です。

更新についても注意が必要です。GeoJSONのgeometryを修正するのか、propertiesを修正するのか、関連する写真や帳票を追加するのかによって、更新対象は異なります。設計時に更新単位を分けていないと、ちょっとした属性修正でもGeoJSON全体を更新することになり、差分確認が難しくなります。複数人で編集する場合は、誰がいつ何を変更したのかも追えるようにする必要があります。

また、地図表示用のデータと編集用のデータを同じ扱いにしてしまうことも問題です。表示用には軽量な情報だけで十分な場合があります。たとえば、地図上に点を表示するだけなら、ID、位置、状態、ラベル程度で足ります。一方、編集画面では、詳細な属性、履歴、写真、承認状況などが必要になります。すべてを毎回同じGeoJSONとして取得する設計にすると、表示が重くなり、通信量や処理時間が増えます。

このような問題を避けるには、一覧表示用、詳細表示用、編集用、外部出力用を分けて考えることが有効です。データベースの中では整理された形で保存し、必要な場面でGeoJSONとして組み立てる設計にすれば、用途ごとに必要な情報だけを扱いやすくなります。反対に、受け取ったGeoJSONをそのまま表示にも編集にも出力にも使い回す設計は、最初は簡単でも、要件が増えるほど無理が出やすくなります。

検索性能を考える場合、地物の範囲情報や代表点を保持しておくことも有効です。面や線の詳細な形状を毎回すべて処理するのではなく、まずおおまかな範囲で絞り込み、その後に詳細な判定を行う考え方です。これにより、対象データが増えた場合でも、不要なデータを読み込む量を減らせます。特に、道路、河川、敷地、設備、施工範囲のように地物が多い業務では、検索の前提を設計に含めることが重要です。

さらに、GeoJSONを保存する時は、将来のデータ量も想定する必要があります。初期段階では数百件でも、現場が増え、点検回数が増え、写真や履歴が追加されると、データ量は急に増えます。小規模な検証では問題がなかった設計でも、実運用で遅くなることがあります。最初から過剰な設計にする必要はありませんが、地物単位、案件単位、期間単位でデータを分けて取得できるようにしておくと、後から対応しやすくなります。

設計ミス5：履歴管理とデータ品質確認を設計に入れない

GeoJSONを業務で使う場合、現在の形状や属性だけでなく、いつ、誰が、どのように変更したのかを追えることが重要です。特に、現地調査、設備点検、施工記録、道路管理、維持管理では、データの更新履歴が後から確認できないと、判断の根拠が曖昧になります。履歴管理を後付けしようとすると、既存データとの整合を取るのが難しくなるため、最初から設計に含めるべきです。

履歴管理でよくあるミスは、最新データだけを上書き保存してしまうことです。最新状態だけを見たい場合には便利ですが、過去の状態を確認できません。たとえば、ある面の範囲が変更された時、変更前の範囲が残っていなければ、なぜ面積が変わったのか、どの時点で変わったのか、どの記録に基づいて変わったのかを確認できません。点検結果や補修判断では、過去との差分が重要になることがあります。

履歴には、geometryの履歴とpropertiesの履歴があります。位置や形状が変わった場合と、属性だけが変わった場合では意味が異なります。たとえば、設備の位置を修正したのか、設備の状態を「対応済み」に変えたのか、担当者を変更したのかは、それぞれ業務上の意味が違います。すべてを同じ更新として扱うと、後から変更内容を読み解くのが難しくなります。

データ品質確認も重要です。GeoJSONは形式が正しければ保存できる場合がありますが、形式が正しいことと、業務上正しいことは別です。たとえば、点が対象範囲外にある、線が不自然に長い、ポリゴンのリングが閉じていない、重複する地物がある、必須属性が空欄である、日付が不自然である、同じIDが複数存在する、といった問題は、保存時の検査で見つける必要があります。

特に、現地で取得したデータは、通信環境、端末設定、入力ミス、測位状態、現場の作業状況によって品質にばらつきが出ます。座標が取得できているように見えても、精度が不十分な場合や、誤って別の地点を記録している場合があります。データベース設計では、位置の値だけでなく、取得日時、取得方法、精度の目安、確認状態、承認状態などを残せるようにしておくと、あとから信頼性を判断しやすくなります。

品質確認の仕組みは、保存前、保存時、保存後の3段階で考えると整理しやすくなります。保存前には、入力画面や取り込み処理で必須項目や座標範囲を確認します。保存時には、データベース側で重複や型の不一致を防ぎます。保存後には、定期的に不自然なデータや未確認データを抽出し、修正対象を見つけます。このように複数の段階で確認することで、品質の低いデータが蓄積されることを防ぎやすくなります。

承認フローを考えていないことも、実務上の設計ミスです。現場で登録されたGeoJSONがそのまま正式データになるのか、管理者が確認してから正式化するのかによって、必要な項目は変わります。仮登録、確認中、承認済み、差し戻し、無効といった状態を持てるようにしておくと、業務の流れに合わせてデータを管理できます。状態管理がないと、未確認データと正式データが混ざり、誤った判断につながる可能性があります。

履歴管理と品質確認は、後から追加しようとすると、既存データのどこまでを正とするかを決める作業が必要になります。そのため、最初から完璧な仕組みを作れない場合でも、作成日時、更新日時、作成者、更新者、元データID、確認状態、無効フラグなどの基本的な管理項目は持たせておくことをおすすめします。これだけでも、後からデータを整理する時の手がかりになります。

GeoJSONを業務データとして活かすための保存設計

GeoJSONをデータベースに保存する目的は、位置情報を保管することだけではありません。現場で取得した情報を、検索、確認、共有、報告、更新に活かすことが目的です。そのためには、GeoJSONを単なるファイル形式として扱うのではなく、業務データの一部として設計する必要があります。

まず意識したいのは、GeoJSONの役割を明確にすることです。外部から受け取る入力形式なのか、地図表示に使う出力形式なのか、データベース内の保存形式なのかを分けて考えます。入力形式としてのGeoJSONは柔軟で便利ですが、そのまま内部保存形式にすると、検索や品質管理が難しくなることがあります。出力形式として必要な場合は、内部データから必要な情報を組み立ててGeoJSONとして返す設計も選択肢になります。

次に、地物IDを安定して管理することが重要です。地物の位置や属性が変わっても、同じ対象であることを追えるIDが必要です。GeoJSONの中だけにIDを持たせるのではなく、データベース上の主キーや業務IDと対応させることで、点検記録、写真、帳票、履歴、承認情報と結びつけやすくなります。ID設計が曖昧だと、同じ地物が重複登録されたり、過去の記録と現在の地物がつながらなくなったりします。

また、geometryと属性の責任範囲を分けることも大切です。geometryは位置や形状を表し、属性は業務上の意味を表します。面の範囲が変わった時と、点検状態が変わった時では、変更の意味が異なります。これを区別できるようにしておくと、更新履歴や差分確認が分かりやすくなります。

保存設計では、最小限の項目で始めることも大切ですが、将来必要になりやすい項目を最初から見越しておくと運用が安定します。作成日時、更新日時、作成者、更新者、データ種別、状態、確認状態、元データの識別子、対象範囲、代表点、座標系の前提などは、多くの業務で役立つ基本項目です。これらを持っておくと、データが増えた時にも整理しやすくなります。

現場データでは、写真やメモとの連携も重要です。GeoJSONのpropertiesに写真の情報を直接詰め込むより、写真や添付情報は別の管理単位にし、地物IDや記録IDで紐づける方が扱いやすくなります。そうすることで、1つの地物に複数の写真を紐づけたり、点検回ごとに写真を分けたりできます。GeoJSONは位置と主要属性を表し、詳細な記録は関連データとして管理する考え方が実務向きです。

さらに、入力時のルールを画面や取り込み処理に反映することも欠かせません。データベース設計だけを整えても、入力段階で自由すぎるデータが入ってくると、結局は整理が必要になります。必須項目、選択肢、座標範囲、日付形式、数値単位、写真の紐づけ方などを事前に決め、登録時に確認できるようにすると、保存後の修正作業を減らせます。

GeoJSONを扱う業務では、現場での取得から管理画面での確認、帳票作成、地図表示、他システム連携まで、複数の工程があります。データベース保存の設計は、その中心に位置します。どの工程でも同じデータを安心して使えるようにするには、保存時点で位置、属性、履歴、品質、関連資料の関係を整理しておくことが必要です。

まとめ

GeoJSONをデータベースに保存する時は、形式として保存できるかどうかだけでなく、業務で継続的に使えるかどうかを考えることが重要です。GeoJSONを丸ごと保存するだけでは、検索、更新、集計、履歴管理、品質確認の場面で不便が出ることがあります。特に、座標系や座標順序、属性の型、更新単位、履歴管理を曖昧にしたまま運用を始めると、後からデータの信頼性を確認するのが難しくなります。

設計ミスを防ぐには、GeoJSONを受け渡し形式として活かしながら、データベースではgeometry、主要属性、履歴、関連情報を扱いやすい単位に分けることが大切です。地物IDを安定させ、検索に使う項目を列として整理し、座標系の前提を明記し、保存時の品質確認を入れることで、GeoJSONは単なる地図表示用データではなく、現場業務を支える情報基盤になります。

現場で取得した位置情報をGeoJSONとして活用する場合、保存設計だけでなく、取得時の精度、写真との紐づけ、確認フローまで一体で考えると、後工程の手戻りを減らせます。位置情報付きの記録を現場で扱いやすくし、データベース保存後も検索や共有に活かしたい場合は、現地取得から管理、出力までの流れを整えることが重要です。