GeoJSONは、点・線・面などの地理情報を扱いやすい形式で記述できるため、現地調査結果、設備位置、道路や敷地の範囲、点検記録、施工管理用の位置情報などを地図上に重ねて確認する用途で使われます。しかし、GeoJSONファイルを用意して地図に読み込ませれば、常に意図どおりに表示されるとは限りません。座標の順序、座標系、データ量、属性情報、面データの閉じ方、表示ルール、運用時の更新方法などを事前に確認しておかないと、地物が違う場所に表示されたり、線や面が崩れたり、現場で必要な情報が見えにくくなったりします。
この記事では、GeoJSONをGoogleマップなどの地図上に表示する実装前に確認しておきたい6つの観点を、実務担当者向けに整理します。開発者だけでなく、測量・点検・施工管理・施設管理などで位置情報を扱う担当者が、仕様確認や発注前の整理に使える内容として解説します。
GeoJSONの構造と表示したい地物を確認する
GeoJSONを地図に表示する前に、まず確認したいのは、ファイルの中身がどのような構造になっていて、何を地図上に見せたいのかという点です。GeoJSONは、単なる座標の羅列ではなく、地理的な形状と、その形状に紐づく情報をまとめて扱うためのデータ形式です。実装前の段階でこの整理が曖昧なままだと、表示そのものはできても、業務で使える地図にならないことがあります。
GeoJSONでは、複数の地物をまとめる形式としてFeatureCollectionがよく使われます。その中にFeatureが並び、それぞれのFeatureがgeometryとpropertiesを持つ構造です。geometryには点、線、面などの形状情報が入り、propertiesには名称、管理番号、区分、状態、確認日、担当者、備考などの属性情報を入れられます。地図上で何かをクリックしたときに表示したい情報や、色分けに使いたい分類も、基本的にはpropertiesに整理しておくことになります。
実務でよくある失敗は、GeoJSONを「とりあえず表示するファイル」として扱い、表示対象の整理を後回しにしてしまうことです。たとえば、現地調査で取得した点を表示したいのか、道路中心線のような線を表示したいのか、施工範囲や管理区域のような面を表示したいのかによって、確認すべき項目は変わります。点であれば位置の正確さやラベル表示が重要になり、線であれば接続や方向、延長の扱いが重要になります。面であれば、閉じた形状になっているか、隣接する区域と重なっていないか、境界が意図どおりかを確認する必要があります。
また、1つのGeoJSONに複数種類の地物を混在させる場合も注意が必要です。点検箇所の点、巡回ルートの線、対象区域の面を同じファイルに入れることは可能ですが、実装側で種類ごとの表示ルールを分けなければ、すべてが同じ見た目になり、地図として読みにくくなります。地物種別をpropertiesに入れておき、その値に応じて表示方法を切り替える設計にしておくと、後から運用しやすくなります。
表示したい地物の粒度も事前に確認しておく必要があります。たとえば、道路を1路線単位で表示するのか、工区単位で分けるのか、点検区間ごとに分割するのかによって、クリック時に出す情報や検索のしやすさが変わります。大きな線や面を1つのFeatureとしてまとめすぎると、現場で「この一部だけ状態が違う」といった管理がしにくくなります。一方で、細かく分割しすぎるとファイルが重くなり、表示や管理が煩雑になります。
実装前には、GeoJSONの中に含める地物の種類、1Featureの単位、propertiesに持たせる項目、地図上での使い方を整理しておくことが大切です。表示確認の前にデータ設計を行うことで、単に地図に重ねるだけでなく、検索、絞り込み、状態確認、報告資料への転用まで見据えた使いやすいGeoJSONになります。
座標順序と座標系を確認する
GeoJSONを地図に表示するときに、基本的でありながら間違いやすいのが座標の扱いです。特に、座標の順序と座標系は、表示位置のずれに直結します。見た目の不具合としては、データが地図上に出てこない、海上や海外に表示される、対象地から大きく離れた位置に出る、線や面が極端に伸びるといった形で現れます。
GeoJSONの座標は、経度、緯度の順で記述します。日本語の業務では「緯度経度」と言うことが多いため、緯度、経度の順でデータを作ってしまうことがあります。しかしGeoJSONのcoordinatesでは、先に経度、次に緯度を入れるのが基本です。たとえば、日本国内の位置であれば、経度はおおむね120度台から150度台、緯度は20度台から40度台になることが多いため、値の並びを見れば誤りに気づける場合があります。経度と緯度が逆になっていると、地図上ではまったく別の場所に表示されることがあります。
座標系の確認も重要です。GeoJSONで一般的なWeb地図表示を行う場合、経度緯度の座標を前提にすることが多くあります。一方、測量や設計の実務では、平面直角座標系、ローカル座標、CAD上の任意座標、現場独自の基準点を使った座標などが利用されることがあります。これらの座標をそのままGeoJSONに入れても、地図上の正しい位置には表示されません。地図表示に使う前に、元データがどの座標系で作られているのかを確認し、必要に応じて経度緯度へ変換する必要があります。
特に注意したいのは、見かけ上は数値が入っているため、データとして正しそうに見えてしまうケースです。たとえば、平面直角座標のX、YをそのままGeoJSONのcoordinatesに入れると、地図表示側はそれを経度緯度として解釈しようとします。その結果、表示範囲外になったり、地図が極端にズームアウトしたりします。GeoJSONとしての文法が正しくても、座標の意味が合っていなければ、実務上は正しいデータとは言えません。
高さを扱う場合も確認が必要です。GeoJSONでは、経度、緯度に続けて高さに相当する値を持たせることがあります。ただし、通常の2次元地図表示では高さが直接反映されない場合があります。高さ情報を管理したいのか、単に2次元地図上に位置を表示したいのかによって、データの扱い方は変わります。高さを属性としてpropertiesに入れるのか、coordinatesの3つ目の値として持たせるのかは、利用目的と実装側の仕様に合わせて決める必要があります。
また、座標の桁数にも注意が必要です。桁数を落としすぎると位置精度が粗くなり、現場の点検箇所や境界確認には使いにくくなります。一方で、必要以上に細かい桁数を残しても、元の測定精度以上の意味を持つわけではありません。実務では、元データの取得方法、必要な表示精度、利用する画面の縮尺を踏まえて、過度に丸めないことと、過度な精度表現をしないことの両方が大切です。
実装前には、経度緯度の順序になっているか、元データの座標系が地図表示に適しているか、必要な変換が済んでいるか、座標の桁数が用途に合っているかを確認しましょう。この確認を丁寧に行うことで、GeoJSON表示時の大きなトラブルを減らしやすくなります。
点・線・面の形状ルールを確認する
GeoJSONでは、点、線、面をそれぞれ異なるgeometry typeで表現します。実装前には、表示したい内容に合ったgeometry typeになっているか、形状として成立しているかを確認する必要があります。構文として読み込めるGeoJSONであっても、形状ルールが実務に合っていなければ、地図上で見にくくなったり、面が正しく塗られなかったり、線が意図しない方向に結ばれたりします。
点を表す場合はPointを使います。点は、設備位置、写真撮影位置、点検箇所、基準点、看板、マンホール、境界標などの表示に向いています。点データでは、座標そのものの正確さに加えて、点の意味をpropertiesで明確にしておくことが重要です。同じ点でも、単なるメモ地点なのか、点検対象なのか、異常箇所なのか、施工済み地点なのかによって、地図上での扱いが変わります。
線を表す場合はLineStringが使われます。線は、道路、配管、電線、河川、巡回ルート、施工区間、測線などを表す際に利用されます。線データでは、座標の並び順が形状に影響します。途中の点が抜けていると線がショートカットされ、実際の経路と違う直線になってしまいます。また、別々の区間を無理に1本の線として扱うと、離れた区間同士がつながって表示されることがあります。複数の線を扱う場合は、1つの連続した線として扱うべきか、複数の線として分けるべきかを確認しておく必要があります。
面を表す場合はPolygonが使われます。面は、敷地、工区、管理区域、補修範囲、危険箇所、調査対象範囲などを表すのに向いています。Polygonでは、外周を構成する座標列が閉じている必要があります。つまり、最初の座標と最後の座標が同じになっていることが基本です。この閉じ方が不適切だと、面が正しく塗られなかったり、境界線が意図しない形になったりします。
面データでは、穴の扱いにも注意が必要です。たとえば、対象区域の中に除外区域がある場合、外周と内側のリングを分けて表現することがあります。このとき、外側の境界と内側の境界の意味を正しく整理しておかないと、塗りつぶされるべき場所と除外されるべき場所が逆に見えることがあります。実装前には、単純な面なのか、穴を含む面なのか、複数区域をまとめる必要があるのかを確認しましょう。
また、点・線・面が混在するデータでは、geometry typeごとの表示方針を決めておくことが重要です。点はアイコンや円で表示し、線は色や太さで区分し、面は塗りと境界線で表すといったように、形状ごとに見せ方を変えることで、地図が読みやすくなります。すべてを同じ色で表示すると、地図上で何が重要なのか判断しにくくなります。
形状データは、地図上に出したときに初めて違和感に気づくことも多いものです。そのため、実装前の段階で、代表的なデータだけでなく、端部、分岐、重複、穴、細長い面、離れた区域など、問題が出やすいパターンを確認しておくと安全です。GeoJSONの文法チェックだけでなく、形状として業務上の意味が正しいかを見ることが、実用的な地図表示には欠かせません。
propertiesに入れる属性情報を確認する
GeoJSONを業務で使う場合、地図上に表示される形状だけでなく、propertiesに入れる属性情報が重要になります。propertiesは、Featureに紐づく説明情報を入れる場所です。地図上でクリックしたときに表示する情報、ラベルに使う名称、色分けや絞り込みに使う分類、状態管理に使う項目などは、propertiesに整理しておくことが一般的です。
実装前には、まず「地図を見る人が何を判断したいのか」を考える必要があります。点検担当者が異常箇所を確認したいのか、管理者が対応状況を把握したいのか、施工担当者が工区や進捗を確認したいのかによって、必要な属性は変わります。単に名称だけを入れても、実務判断に必要な情報が不足することがあります。一方で、すべての情報を詰め込みすぎると、クリック時の表示が長くなり、現場で使いにくくなります。
よく使われる属性としては、管理番号、名称、種別、状態、確認日、更新日、担当区分、備考、写真の有無、優先度、対応状況などがあります。ただし、項目名は実装前に統一しておくことが大切です。同じ意味の項目が「名称」「name」「label」「表示名」のように混在していると、地図上のラベル表示や検索処理が複雑になります。日本語項目名を使うか、英数字の項目名を使うかも、運用側と実装側で合わせておく必要があります。
属性値の表記ゆれにも注意が必要です。たとえば、状態を表す値として「未対応」「未処理」「未確認」が混在していると、同じグループとして絞り込めなくなる可能性があります。色分けやフィルタに使う項目は、あらかじめ選択肢を決めておくと運用しやすくなります。自由記述の備考欄は便利ですが、分類や集計には向きません。分類に使う項目と、説明に使う項目を分けて設計することが大切です。
日付の形式も事前に決めておきましょう。確認日や更新日を入れる場合、表記形式がばらばらだと並び替えや期間検索がしにくくなります。人が読むための表示と、機械的に処理するための値を分ける設計も考えられます。少なくとも、同じ項目の中では形式を統一しておくことが重要です。
個人情報や機密情報の扱いにも注意が必要です。GeoJSONはテキスト形式で中身を確認しやすい反面、不要な情報まで入れてしまうと、共有時に意図せず外部に伝わるリスクがあります。地図表示に必要な情報と、内部管理だけに必要な情報を分け、公開範囲や共有範囲に応じてpropertiesを調整することが求められます。特に、現場写真へのリンク、担当者名、連絡先、詳細な設備情報などは、利用範囲に応じた確認が必要です。
propertiesは、後から追加することもできますが、運用開始後に項目を大きく変えると、既存データとの互換性が問題になりやすくなります。実装前の段階で、表示用、検索用、分類用、管理用の属性を整理し、項目名と値のルールを決めておくことで、地図表示の品質と運用の安定性が高まります。
表示スタイルと情報の見せ方を確認する
GeoJSONを地図に読み込むだけでは、業務で使いやすい表示になるとは限りません。地図上でどのように見せるか、どの情報を優先して表示するか、拡大縮小したときにどう見えるかを事前に確認することが重要です。表示スタイルは見た目の問題に見えますが、実際には判断のしやすさや作業効率に直結します。
点データの場合、表示する記号の大きさ、色、形、ラベルの有無を決める必要があります。すべての点にラベルを常時表示すると、点が多いエリアでは文字が重なり、地図が読みにくくなります。一方で、ラベルがないと、点をクリックしない限り内容が分からない場合もあります。重要度の高い点だけラベルを出す、拡大時だけラベルを出す、クリック時に詳細を表示するなど、利用場面に合わせた見せ方を考える必要があります。
線データの場合は、色、太さ、透過、線種が主な表示要素になります。道路やルート、設備線、施工区間などを表す場合、線が細すぎると見落としやすく、太すぎると背景地図や他の地物を隠してしまいます。状態によって色を変える場合は、色の意味を利用者が理解できるようにしておく必要があります。たとえば、未確認、確認済み、要対応、対応済みといった状態を色分けする場合、凡例や画面上の説明がないと誤解が生じます。
面データの場合は、塗りつぶしと境界線のバランスが大切です。塗りが濃すぎると背景地図が見えにくくなり、薄すぎると対象範囲が分かりにくくなります。境界線をはっきり表示することで、区域の端部を確認しやすくなります。複数の面が重なる場合は、どちらを上に表示するのか、重なった部分をどう解釈するのかも事前に確認しておく必要があります。
情報の見せ方では、クリック時に出す内容を絞り込むことも重要です。propertiesに多くの属性が入っているからといって、すべてを表示すると、必要な情報が埋もれてしまいます。現場で最初に見たい情報は、名称、状態、確認日、対応区分、備考などに限られることが多いです。詳細情報は別画面や展開表示に回すなど、段階的に見せる設計にすると使いやすくなります。
検索や絞り込みを行う場合は、表示スタイルと連動させると効果的です。たとえば、種別で絞り込んだときに対象外の地物を非表示にする、状態で絞り込んだときに該当する点だけを目立たせる、といった設計が考えられます。絞り込み条件とpropertiesの項目が合っていないと、実装後に思ったような検索ができません。表示の見た目だけでなく、操作時にどの情報を使うかまで確認しておく必要があります。
また、地図を使う環境も考慮しましょう。事務所の大きな画面で見るのか、現場の小さな画面で見るのかによって、適切な文字サイズや表示密度は変わります。屋外では画面が見づらいこともあるため、細かい色の違いだけに頼る表示は避けた方が安全です。色、形、ラベル、絞り込みを組み合わせ、誰が見ても判断しやすい地図を目指すことが大切です。
GeoJSON表示の実装前には、単に「読み込めるか」ではなく、「見て判断できるか」「操作しやすいか」「誤解なく共有できるか」を確認しましょう。表示スタイルの設計は、実務で使える地図にするための重要な工程です。
データ量・更新方法・現場運用を確認する
GeoJSONを地図に表示する実装では、データ量と更新方法の確認も欠かせません。少量のサンプルデータでは問題なく表示できても、本番データを入れた途端に読み込みが遅くなったり、操作が重くなったりすることがあります。特に、点数が多いデータ、頂点数の多い線や面、細かく分割された区域データを扱う場合は、実装前に性能面の確認をしておく必要があります。
GeoJSONは読みやすく扱いやすい形式ですが、すべての情報をそのまま地図に載せるとファイルサイズが大きくなります。現場写真の説明や長い備考、不要な属性、過剰に細かい座標が大量に含まれていると、表示に時間がかかる原因になります。地図表示に必要な属性だけを含める、詳細情報は別の管理データに分ける、表示用に形状を簡略化するなど、用途に応じた調整を検討しましょう。
線や面の頂点数も重要です。細かい曲線や複雑な境界を忠実に表現しようとすると、座標数が非常に多くなることがあります。高精度な管理が必要な場面では細かい形状が必要ですが、広域表示や概要確認では、そこまで細かい頂点が不要な場合もあります。目的に応じて、詳細表示用のデータと概要表示用のデータを分けることも考えられます。
更新方法も実装前に決めておくべきです。GeoJSONを手作業で差し替えるのか、管理画面から更新するのか、現場からアップロードするのか、定期的に自動反映するのかによって、運用の負担は大きく変わります。ファイルを都度差し替える運用は簡単ですが、誰が最新版を管理するのか、古いファイルが残らないか、更新履歴をどう確認するのかといった課題があります。
複数人でGeoJSONを更新する場合は、編集ルールも必要です。項目名を勝手に変えない、分類値を追加する場合は事前に共有する、座標系を変換してから登録する、確認済みデータだけを本番表示に使う、といったルールがないと、時間が経つにつれてデータ品質がばらつきます。地図表示の不具合が実装側の問題なのか、データ側の問題なのか判断しにくくなることもあります。
現場運用では、通信環境や端末性能も考慮する必要があります。事務所では問題なく表示できても、現場では通信が不安定だったり、画面が小さかったり、端末の処理性能に制約があったりします。必要な範囲だけを読み込む、表示する地物を絞る、初期表示では概要だけを出すなど、現場で使う前提の設計が重要です。
さらに、確認作業の流れも整理しておきましょう。GeoJSONを表示した地図を、単に閲覧するだけなのか、現場で状態を確認して更新するのか、写真やメモと紐づけるのか、報告資料の作成に使うのかによって、必要な機能は変わります。表示だけを先に実装してしまうと、後から「検索が必要だった」「更新履歴が必要だった」「現場写真と紐づけたい」といった要望が出て、作り直しになる場合があります。
GeoJSONの実装前には、本番データ量、ファイルサイズ、表示速度、更新頻度、編集者、承認の流れ、現場での利用環境を確認しましょう。地図表示はデータを読み込むだけの機能に見えますが、実務では継続的に更新され、複数人が判断に使う情報基盤になります。最初に運用まで見据えておくことで、使い始めてからの混乱を防ぎやすくなります。
まとめ
GeoJSONをGoogleマップに表示する実装では、ファイルを読み込ませる前の確認が重要です。GeoJSONは扱いやすい形式ですが、座標の順序、座標系、形状ルール、属性設計、表示スタイル、データ量、更新方法のどれかが曖昧なままだと、地図上で正しく見えないだけでなく、現場判断や管理業務にも影響します。
まず、GeoJSONの構造を理解し、何をFeatureとして扱うのか、点・線・面のどれで表現するのかを整理することが出発点です。次に、経度と緯度の順序、座標系の変換、座標の桁数を確認し、地図上の位置が正しくなるように整えます。さらに、Point、LineString、Polygonなどの形状ルールを確認し、線のつながりや面の閉じ方、複数地物の扱いに注意します。
propertiesの設計では、表示、検索、分類、管理に必要な情報を分けて考えることが大切です。項目名や分類値、日付形式が統一されていれば、後から絞り込みや色分けを行いやすくなります。表示スタイルでは、点・線・面ごとの見せ方、クリック時の情報量、ラベルの出し方、凡例や絞り込みの考え方を整理する必要があります。
最後に、データ量と運用方法を確認しましょう。サンプルでは軽く表示できても、本番では重くなることがあります。更新頻度、編集者、承認の流れ、現場での通信環境まで含めて考えることで、単なる地図表示ではなく、実務で継続して使える仕組みに近づきます。
GeoJSONを地図に重ねる目的は、位置情報を見せることだけではありません。現場の状況を共有し、確認漏れを減らし、判断を早めることにあります。そのためには、実装前の段階でデータと運用の前提を丁寧にそろえることが欠かせません。
現地で取得した点、写真、位置情報、測位結果などを業務に活用したい場合は、取得方法、座標系、属性項目、共有範囲、更新履歴をあわせて整理することが重要です。GeoJSON表示を単独の作業として考えるのではなく、現場で取得した情報をどのように地図化し、どのように確認・共有・記録していくかまで整理すると、導入後の運用イメージを具体化しやすくなります。